Gestion des incidents pour les équipes haute vélocité
Incidents informatiques : l'avenir de la gestion, de la réponse et de la prévention
Par le passé, l'équipe chargée de répondre aux incidents technologiques était presque toujours l'équipe informatique. Souvent, une équipe installée dans un Network Operations Center, ou NOC, surveillait les systèmes et répondait aux pannes. Un fournisseur pouvait avoir conçu le logiciel, mais le déploiement et l'exploitation incombaient à l'équipe informatique opérationnelle du client. Aujourd'hui, grâce à la prolifération des services cloud, le fournisseur développe le logiciel et se charge du déploiement et de l'exploitation.
Pourtant, la gestion des incidents demeure une pratique de base de l'ITSM. Et l'équipe informatique élabore depuis longtemps des lignes directrices, gère des budgets et assume l'ensemble des tâches de diagnostic, de réparation, de documentation et de prévention des incidents majeurs.
Bien sûr, comme pour tout ce qui concerne la technologie, le passé ne prédit pas nécessairement l'avenir. De plus, la pratique de la gestion des incidents est actuellement en train de changer. Les équipes DevOps, SecOps et celles chargées de l'architecture sont de plus en plus impliquées. Les nouvelles technologies et les produits interconnectés ont changé notre méthode de gestion des incidents. Et les mentalités, les pratiques et les structures d'équipe changent afin de s'adapter au contexte.
Alors, comment la gestion des incidents évolue-t-elle et qu'est-ce que cela signifie pour l'avenir de nos rôles, produits, processus et équipes ?
En route vers la décentralisation
Il y a cinq ans, si vous aviez demandé à une équipe informatique qui était chargée de la gestion des incidents, elle vous aurait la plupart du temps répondu : « nous ».
Posez la même question aujourd'hui, et vous êtes susceptible d'entendre parler non seulement des équipes informatiques, mais aussi DevOps, SecOps et celles chargées de l'architecture. De nombreuses organisations se tournent lentement vers l'approche « You built it, you run it » (Vous l'avez conçu, vous en êtes responsable).
Les avantages évidents de cette approche ? Elle réduit la pression sur les équipes informatiques et accélère les temps de réponse en transférant la responsabilité aux personnes les plus familières avec le code. Cela réduit les temps d'arrêt et maximise la productivité de l'équipe. Cela encourage également le code de qualité. (Si vous êtes la personne que l'on réveille à 3 heures du matin pour résoudre un bug, il y a fort à parier que vous vérifierez à deux fois le code la prochaine fois avant sa mise en ligne afin d'éviter qu'une telle situation ne se reproduise.)
Le défi de cette approche ? Les organisations ont encore besoin d'une certaine centralisation. La direction doit avoir accès aux rapports et à la documentation. Les parties prenantes des entreprises veulent des mises à jour. Elles veulent voir des métriques d'incident comme la durée moyenne de résolution et le temps moyen d'accusé de réception. Elles attendent des mises à jour claires des incidents, des rapports post-mortem d'incident et des tâches de remédiation.
Pour de nombreuses entreprises qui s'orientent, avec succès, vers la décentralisation, la réponse à ce défi est une technologie qui permet la décentralisation et l'autonomie de l'équipe : cela permet de flexibiliser la résolution des incidents tout en centralisant l'information afin de maintenir l'activité dans la boucle.
Le long parcours vers la décentralisation
Comme pour tout autre changement important susceptible de perturber les workflows et d'entraîner des conséquences imprévues, il est logique que de nombreuses organisations adoptent la décentralisation à petits pas.
Elles commencent par identifier une équipe dont la culture se prête bien à un tel changement et qui gère une app ou un produit à faible risque. Ensuite, elles transfèrent la gestion des incidents pour l'app ou le produit spécifique de cette équipe à l'équipe identifiée. L'équipe est formée, un planning d'astreinte est implémenté et les progrès sont suivis au fil du temps, en posant des questions telles que :
- A-t-elle amélioré les délais de récupération ?
- Quelles barrières culturelles a-t-elle rencontrées ?
- Quels outils l'équipe informatique a-t-elle dû mettre en place ?
- Quels processus a-t-elle dû communiquer ?
- Les mises à jour système opérées par cette équipe sont-elles meilleures ?
- Le nombre d'incidents a-t-il diminué ?
- Si nous décidons d'étendre cette décentralisation à d'autres équipes, que pouvons-nous retenir de ce premier test ?
Ces cas de test servent de base pour décider s'il faut implémenter un framework « You built it, you support it » dans l'entreprise et, le cas échéant, comment le déployer efficacement au sein des équipes.
Décentralisation = collaboration entre équipes
Cette évolution vers la décentralisation nécessite également de passer à une collaboration entre équipes. Si l'équipe DevOps est impliquée dans la gestion des incidents, elle doit avoir son mot à dire lors des réunions visant à définir le processus de gestion des incidents informatiques. Si l'équipe informatique contribue encore à orienter les pratiques de gestion des incidents, elle doit être impliquée dans les revues post-mortem effectuées par d'autres équipes.
Chaque équipe apporte ses propres forces à la table de gestion des incidents. Les équipes informatiques sont douées pour développer des pratiques et de la documentation et suivre les directives. Les équipes DevOps sont douées en matière de changement et d'apprentissage. L'équipe SecOps peut apporter une perspective sur la sécurité.
Pour favoriser une plus grande collaboration entre équipes, les entreprises partagent ouvertement l'information, favorisent l'empathie entre équipes et évitent les reproches, utilisent le chat pour maintenir les équipes connectées lors des incidents et priorisent les revues d'incident où tout le monde a son mot à dire.
Le passage de réactif à proactif
Dans les lignes directrices ITIL, la gestion des incidents traditionnelle est perçue comme une pratique distincte de la prévention des incidents. Les deux sont des pièces importantes du puzzle ITSM, mais ne se produisent pas souvent parallèlement.
Le problème de cette approche est qu'elle maintient la gestion des incidents à un état réactif. Les employés d'astreinte sont chargés de gérer les problèmes urgents, et une fois résolus, ils passent au suivant. Le seul objectif en tête est la reprise, et la remise en service du système.
Mais la reprise ne fait pas tout. De plus en plus d'équipes informatiques s'en rendent compte et l'adoptent au fil du temps, en intégrant la prévention dans le processus de gestion des incidents et en utilisant des métriques telles que la durée moyenne de résolution plutôt que le temps moyen jusqu'à la remise en route pour évaluer leurs performances.
Cette approche est souvent appelée gestion des problèmes et a pour objectif de rapprocher les processus pour s'assurer que les équipes ne répondent pas seulement à un problème puis passent à un autre, mais qu'elles soient capables de répondre, de récupérer et d'apprendre de l'incident, en appliquant ces leçons tirées aux problèmes à portée de main et aux produits et services plus larges qu'elles gèrent.
De nombreuses organisations informatiques d'entreprise ont une pratique dédiée à la gestion des problèmes. Elles la traitent généralement comme un processus distinct pour une équipe distincte. Chez Atlassian, nous préconisons d'aller encore plus loin et d'utiliser une approche mixte où les équipes informatiques opérationnelles et de développement intègrent la pratique de gestion des problèmes dans leur gestion des incidents. Cela permet d'avoir une meilleure visibilité sur l'incident et de s'assurer que l'analyse de l'incident n'est pas réalisée trop longtemps après celui-ci.
En effet, à long terme, il est plus utile de prévenir les incidents que d'y répondre rapidement.
Gardez le cap grâce aux processus et à la documentation
L'un des défis inhérents à ce passage à une gestion des incidents collaborative entre équipes, est que certaines d'entre elles abordent les processus et la documentation de manière plus « insouciante » que d'autres.
C'est l'un des domaines dans lesquels l'équipe informatique peut apporter une valeur significative en assurant une supervision, même si d'autres équipes prennent en charge la gestion de leurs propres produits. En effet, personne ne veut gérer un incident majeur à 3 heures du matin, à moitié endormi et sans un plan solide.
En intégrant d'autres équipes dans le processus de gestion des incidents, l'équipe informatique peut les aider à répondre aux questions essentielles qui façonneront ce plan. Par exemple :
- Quelle est votre réponse aux incidents ?
- Quelles sont les valeurs que vous allez suivre ?
- Comment réagirez-vous en cas d'incident ?
- Où sont les informations dont vous avez besoin pour les systèmes critiques que vous prenez en charge ? S'il s'agit de plusieurs systèmes, comment pouvez-vous rassembler ces informations et les rendre facilement accessibles aux experts d'astreinte ?
- Votre processus et votre documentation sont-ils collaboratifs et révisables par l'équipe ?
Votre culture d'entreprise est-elle prête au changement ?
Cette transition vers la décentralisation, la collaboration et une approche mixte associant la gestion des incidents et la gestion des problèmes nécessite plus qu'une simple redistribution des responsabilités : vous devez nommer un professionnel de l'informatique qui participera à un post-mortem DevOps. La clé du succès ici ne réside pas dans la technologie ou même les processus, mais dans la création d'une culture interne qui soutient ces changements.
Il s'agit de la partie que de trop nombreuses entreprises essaient d'ignorer, et c'est la base d'une transition réussie. Alors, à quoi ressemble une culture qui soutient la gestion des incidents décentralisée, collaborative et orientée vers l'avenir ?
Chez Atlassian, nous pensons qu'elle s'articule autour de ces concepts centraux :
L'ouverture et le partage des informations
Si les équipes n'ont pas connaissance du travail de leurs coéquipiers et ne peuvent pas y accéder, nous manquons des opportunités exceptionnelles pour renforcer la communication, améliorer les meilleurs processus et les produits.
Une approche centrée sur le client
Lorsque nous posons des questions comme « Qu'est-ce qu'il y a de mieux pour le client ? » parfois, les réponses que nous obtenons ne tiennent pas compte de nos pratiques actuelles. Il est nécessaire de se concentrer intentionnellement sur le client pour évoluer vers la communication, les processus et les efficacités structurelles qui nous permettent, en fin de compte, d'optimiser nos produits pour les clients.
Des contrôles d'intégrité réguliers
Comment se porte chaque équipe ? Quel est le ressenti des membres de l'équipe ? Qu'est-ce que l'équipe peut améliorer ? Quelles sont ses réussites ? Chez Atlassian, nous avons un playbook de l'équipe qui nous aide à vérifier la santé de nos équipes et à les initier à de nouvelles méthodes de travail.
Empathie
Si l'équipe DevOps pointe du doigt l'équipe informatique et que cette dernière se concentre sur l'approche la plus détendue de DevOps, la collaboration ne fonctionnera pas. Il est essentiel de favoriser l'empathie et les liens entre équipes si nous voulons qu'elles communiquent, innovent et collaborent correctement.
L'autonomisation
Les équipes devraient être habilitées à résoudre rapidement les problèmes et à prendre, dans la mesure du possible, des décisions de manière indépendante. Leurs membres doivent savoir qu'ils ont les moyens de s'exprimer s'ils ont une question, une suggestion ou une préoccupation, quelle que soit leur position dans la hiérarchie ou leur expérience.
Lorsque les développeurs juniors sentent qu'ils peuvent participer lors des réunions et signaler un problème, même si quelqu'un de plus expérimenté était en charge de ce code, il en résulte des idées innovantes, des processus améliorés et des bugs détectés avant même d'intégrer le code.
Découvrez la communication sur les incidents grâce à Statuspage
Dans ce tutoriel, nous allons vous montrer comment utiliser des modèles d'incident pour communiquer efficacement pendant les pannes. Vous pouvez les adapter à de nombreux types d'interruption de service.
Lire ce tutorielModèles et exemples de communication sur les incidents
Lorsque vous répondez à un incident, les modèles de communication sont d'une valeur inestimable. Obtenez les modèles que nos équipes utilisent, ainsi que d'autres exemples pour les incidents courants.
Lire cet article