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

Chez PagerDuty, notre approche consiste à examiner de manière globale votre infrastructure, vos applications orientées client et vos produits. Nous les différencions en décrivant ces éléments comme des « services » qui se rejoignent et constituent un « service métier ». Cette configuration permet aux équipes de mieux gérer ces services afin que, lorsque des incidents se produisent, les intervenants puissent obtenir un contexte beaucoup plus rapidement. Mais comment ?

Tout d'abord, parlons un peu de prestations de service Les services sont conçus pour durer et ils survivent généralement aux équipes qui les ont développés à l'origine. En d'autres termes, les gens vont et viennent, et les équipes s'organisent et se réorganisent en permanence. Et le transfert de propriété d'une équipe à un service ne se produit pas seulement une fois par an ou seulement lors de réorganisations. Les gens adoptent de nouveaux services, héritent d'anciens et échangent la propriété même pendant 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, aucun service du tout), vous devrez refaire toute la configuration de votre réponse aux incidents à chaque réorganisation des équipes. De plus, vous perdez des connaissances institutionnelles et des données analytiques importantes au fur et à mesure que les équipes changent. Cela ressemble à un cauchemar, n'est-ce pas ?

C'est pourquoi PagerDuty a construit notre plateforme pour permettre aux organisations d'orienter facilement leurs processus de gestion des incidents autour des services, ce qui permet aux équipes de se développer et d'évoluer au fil du temps, et offre une meilleure visibilité sur l'état et les tendances des services. tout cela 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.

Obtenez 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 configuration de votre processus d'incident, le support de production et la configuration autour des équipes ; c'est-à-dire que vous adoptez une approche basée sur l'équipe. Cela signifie que vous avez probablement un mélange d'équipes ITSM, DevOps et ITOps, avec des équipes commerciales/techniques définissant les services aux entreprises , et de nombreuses autres équipes qui possèdent différents services.

Alors, comment passer d'une organisation basée sur le travail en équipe à une organisation basée sur le service ? C'est plus facile que la plupart des gens le pensent.

Commencez par identifier vos services métier de premier niveau qui sont des parties distinctes des produits ou des applications avec lesquels votre client interagit pour effectuer des tâches ou obtenir des résultats spécifiques. Par exemple, « connexion », « panier d’achat » et « recherche » sont tous des services métier. Ensuite, pour chaque service métier, identifiez les services techniques qui contribuent à ce service métier. Chaque service technique doit idéalement être détenu et développé par une équipe à la fois, même si plusieurs équipes contribuent à sa maintenance à long terme.

Une fois que vous avez identifié vos services métier et les services techniques correspondants qui les prennent en charge, vous pouvez désormais réaliser de nombreuses tâches intéressantes. Par exemple, les équipes peuvent désormais voir ce qui se passe en temps réel dans l'entreprise pour 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 concerne plusieurs équipes et services.

Lorsque les événements sont acheminés vers des services distincts et séparés qui reflètent les services de votre environnement, il est plus facile pour tout le monde de communiquer sur ce qui se passe. De plus, les intervenants ont un aperçu des autres incidents qui se produisent 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 un service en panne. Mais un autre intervenant de l'équipe de base de données a également reçu la même notification. Étant donné que vous pouvez désormais consulter les incidents associés sur plusieurs services, vous pouvez voir qu'il s'agit d'un problème de base de données. Vous pouvez donc arrêter de travailler sur le problème puisque vous savez que l'équipe de base de données s'en chargera.

S'aligner sur l'entreprise et ses besoins

La plupart des entreprises ont encore aujourd'hui une organisation en équipe pour leur processus de gestion des incidents. Et même si cette organisation est plus simple à mettre en place au début, elle devient difficile à gérer à long terme à mesure que l'entreprise grandit et évolue. Pourquoi ?

Le silos 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 se produit parce que les intervenants doivent passer plus de temps à analyser ce qui est réellement affecté (est-ce que je reçois des alertes concernant le service A ou B ? Quel niveau de réponse est requis ?) avant de déterminer ce qu'il faut faire. N'oubliez pas : la plupart des équipes possèdent au moins 10 services différents et l'organisation des informations sur les événements de manière à ce que les alertes soient acheminées vers des services distincts les aidera à mieux comprendre ce qui se passe.

En revanche, les organisations qui adoptent une approche axée sur les services pour mettre en place un pont entre les services techniques et commerciaux ont un impact explicite sur l'entreprise et les clients, car cela fournit un contexte sur l'importance d'un service donné. Cela fournit également un langage commun pour la communication, aidant les organisations à automatiser le partage de mises à jour de statut concises et exploitables avec ceux qui ont besoin de les connaître. (Par exemple, le service A prend en charge notre système de devis à encaissement et nécessite une réponse élevée en cas d'incident par rapport au service B, qui est un service interne non essentiel sans SLA.)

Mais une configuration basée sur une équipe est tellement plus simple

Comme je l'ai mentionné plus tôt, il est vrai qu'il est plus facile au départ d'utiliser une approche en équipe pour configurer et mettre en place votre processus de gestion des incidents. Toutefois, à long terme, les inconvénients l'emportent sur les avantages. Par exemple, avec une approche en équipe, vous ne pourrez pas :

• Évaluer les 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 intervenants commerciaux 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'un changement organisationnel se produit, 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 configurer votre processus de gestion des incidents , demandez-vous d’abord : « Pourquoi est-ce que je configure un appel pour commencer ? »

La réponse la plus probable : vous le mettez en place parce que vous avez besoin d'une équipe ou de quelqu'un pour réagir rapidement lorsqu'un incident survient. Et nous avons vu beaucoup d'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 très importantes. Mais la raison pour laquelle nous vous recommandons d'orienter d'abord la configuration et l'installation de votre gestion des incidents autour des services est que cela vous offre :

• Visibilité nécessaire pour comprendre la santé des services et améliorer les processus
• Informations pour voir les tendances afin d'identifier les points chauds
• Capacité de voir facilement et rapidement quelle équipe prend en charge quels services au lieu 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 faire des affaires, et tout ce qui a un impact sur ce processus doit être rapidement traité. Et la meilleure façon d’y parvenir est d’adopter une approche basée sur les services, car elle vous permet de comprendre qui doit travailler sur quoi et comment hiérarchiser les tâches au lieu de perdre du temps à fouiller dans les différentes équipes pour accéder aux services.