Comment le processus de réponse aux incidents est-il mis en place dans votre organisation ?

Chez PagerDuty, notre approche Il s'agit d'examiner globalement votre infrastructure, vos applications client et vos produits. Nous les différencions en les qualifiant de « services » qui constituent un « service métier ». Cette configuration permet aux équipes de mieux gérer ces services, de sorte qu'en cas d'incident, les intervenants puissent obtenir un contexte beaucoup plus rapidement. Mais comment ?

Tout d’abord, parlons un peu de services Les services sont conçus pour durer et survivent généralement aux équipes qui les ont développés initialement. Autrement dit, les employés vont et viennent, et les équipes s'organisent et se réorganisent constamment. Et le transfert de propriété d'une équipe à un service ne se produit pas seulement une fois par an ou lors de réorganisations. Les employés adoptent de nouveaux services, héritent d'anciens et transfèrent la propriété, même pour quelques semaines seulement, au cours d'un projet spécifique.

Ainsi, si vous orientez votre plateforme de réponse aux incidents vers les équipes, puis vers les services (ou pire, si vous n'en orientez aucun), vous devrez repenser entièrement votre système de réponse aux incidents à chaque réorganisation d'équipe. De plus, vous perdrez des connaissances institutionnelles et des données analytiques importantes au fil des changements d'équipe. Cela ressemble à un cauchemar, n'est-ce pas ?

C'est pourquoi PagerDuty a construit sa plateforme pour permettre aux organisations d'orienter facilement leurs processus de gestion des incidents autour des services, ce qui permet aux équipes de grandir et d'évoluer au fil du temps, et offre une meilleure visibilité sur la santé et les tendances des services. le tout sans impacter la manière dont ces services sont fournis, maintenus et améliorés, contribuant ainsi à réduire les temps d'arrêt prolongés et l'impact négatif sur les clients.

Bénéficiez d'une meilleure visibilité sur l'impact commercial, la santé des services et les tendances au fil du temps

Si vous êtes comme la plupart des entreprises, vous orientez probablement la mise en place de vos processus d'incident, le support de production et la configuration autour des équipes ; autrement dit, vous adoptez une approche collaborative. Cela signifie que vous disposez probablement d'équipes ITSM, DevOps et ITOps mixtes, les équipes métier/techniques définissant services aux entreprises , et de nombreuses autres équipes qui possèdent différents services.

Alors, comment passer d'une organisation en équipe à une organisation basée sur les services ? C'est plus simple qu'on ne le pense.

Commencez par identifier vos principaux services métier, qui constituent des éléments distincts des produits ou applications avec lesquels vos clients interagissent pour réaliser des tâches ou obtenir des résultats spécifiques. Par exemple, « connexion », « panier » et « recherche » sont tous des services métier. Ensuite, pour chaque service métier, identifiez les services techniques qui y contribuent. Idéalement, chaque service technique devrait être géré et développé par une seule équipe à la fois, même si plusieurs équipes contribuent à sa maintenance à long terme.

Une fois vos services métier et les services techniques correspondants identifiés, vous pouvez accomplir de nombreuses tâches intéressantes. Par exemple, les équipes peuvent désormais visualiser en temps réel la situation au sein de l'entreprise afin de mieux comprendre si un problème est isolé ou a un impact plus large, ce qui permet une réponse mieux coordonnée lorsqu'il touche plusieurs équipes et services.

Lorsque les événements sont acheminés vers des services distincts, reflétant ceux de votre environnement, il est plus facile pour chacun de communiquer sur ce qui se passe. De plus, les intervenants bénéficient d'un aperçu des autres incidents survenant dans l'ensemble de votre infrastructure.

Par exemple, disons que vous êtes sur le Équipe d'ingénierie de fiabilité du site et recevez une notification concernant une panne de service. Un autre intervenant de l'équipe base de données a également reçu la même notification. Grâce à la possibilité d'examiner les incidents associés sur plusieurs services, vous pouvez identifier un problème de base de données. Vous pouvez donc interrompre le traitement du problème, sachant que l'équipe base de données s'en chargera.

S'aligner sur l'entreprise et ses besoins

Aujourd'hui, la plupart des entreprises utilisent encore un processus de gestion des incidents en équipe. Si cette méthode est simple à mettre en place au départ, elle devient complexe à gérer à long terme, à mesure que l'entreprise grandit et évolue. Pourquoi ?

Le silos Les informations produites avec cette approche créent de la confusion chez les intervenants. Il est plus difficile de orchestrer une réponse efficace Lorsqu'un incident survient, les intervenants doivent consacrer du temps supplémentaire à l'analyse des éléments réellement affectés (suivent-ils le service A ou B ? Quel niveau d'intervention est requis ?) avant de déterminer la marche à suivre. N'oubliez pas : la plupart des équipes possèdent au moins dix services différents. Organiser les informations relatives aux événements de manière à acheminer les alertes vers des services distincts les aidera à mieux comprendre la situation.

À l'inverse, les organisations qui privilégient les services pour la mise en place d'une infrastructure articulent les services techniques et métiers, ce qui a un impact significatif sur l'entreprise et les clients, car cela permet de contextualiser l'importance d'un service donné. Cela fournit également un langage commun de communication, permettant aux organisations d'automatiser le partage de mises à jour concises et exploitables avec les personnes concernées. (Par exemple, le service A prend en charge notre système de devis et nécessite une réponse plus élevée en cas d'incident, contrairement au service B, qui est un service interne non essentiel sans contrat de niveau de service.)

Mais une configuration en équipe est tellement plus simple

Comme je l'ai mentionné précédemment, il est vrai qu'une approche collaborative pour la configuration et la mise en place de votre processus de gestion des incidents est plus simple au départ ; cependant, à long terme, les inconvénients l'emportent sur les avantages. Par exemple, avec une approche collaborative, vous ne pourriez pas :

• Évaluer le impact sur les entreprises des incidents en temps réel
• Analysez l'impact de vos services sur la fiabilité ou la stabilité de votre application
• Évaluez avec précision le rayon d'action des problèmes, ce qui est important car ils s'étendent généralement sur plusieurs services
• Déterminez rapidement les acteurs de l'entreprise qui doivent être informés lors d'incidents majeurs

De plus, une approche basée sur l'équipe manque de flexibilité pour apporter des changements à mesure que les équipes changent et se réorganisent. De plus, vous devrez constamment réorganiser vos équipes et vos services chaque fois qu'il y a un changement organisationnel, ce qui réduit votre capacité à innover.

Alors, quelle approche vous convient le mieux ?

Avant de décider si vous devez adopter une approche basée sur l’équipe ou sur les services pour la mise en place de votre processus de gestion des incidents , demandez-vous d’abord : « Pourquoi est-ce que je m’installe sur appel pour commencer ? »

La réponse la plus probable : vous le mettez en place parce que vous avez besoin d'une équipe ou d'une personne capable de réagir rapidement en cas d'incident. Et nous avons vu de nombreuses entreprises configurer leur configuration avec une approche axée sur l'équipe, car, eh bien, vous avez une équipe, vous voulez vous assurer que tout le monde est sur la rotation d'astreinte, et c'est rapide et facile à mettre en place de cette façon.

Mais si vous prenez du recul, une approche plus optimisée consiste à réfléchir aux services pris en charge par vos équipes, car cela vous permet plus de flexibilité en ce qui concerne les changements. les équipes peuvent changer au fil du temps, mais les services qu’elles prennent en charge peuvent rester les mêmes.

Ne vous méprenez pas : les équipes sont essentielles. Mais si nous vous recommandons d'axer d'abord la configuration et l'installation de votre gestion des incidents sur les services, c'est parce que cela vous offre :

• Visibilité nécessaire pour comprendre la santé des services et améliorer les processus
• Informations pour voir les tendances et identifier les points chauds
• Capacité de voir facilement et rapidement quelle équipe prend en charge quels services plutôt que de devoir d'abord passer par plusieurs équipes et comprendre ces couches avant d'arriver au service

En fin de compte, ce qui importe vraiment à l'entreprise, c'est de pouvoir poursuivre ses activités, et tout impact sur cette activité doit être traité rapidement. La meilleure façon d'y parvenir est d'adopter une approche axée sur les services, car elle permet de comprendre qui doit travailler sur quoi et comment prioriser les tâches, au lieu de perdre du temps à fouiller dans les différentes équipes pour accéder aux services.