Incidents informatiques : l'avenir de la gestion, de la réponse et de la prévention

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.

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.

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.

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.

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 ?

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 :