Bonnes pratiques et conseils en matière de réponse aux incidents

1. Préparez toujours un « Jump Bag »

Un « Jump Bag », ou grand sac d'intervention destiné aux personnes intervenant sur les incidents, contient toutes les informations critiques auxquelles les équipes doivent pouvoir accéder dans les meilleurs délais. Même s'il s'agit le plus souvent d'un document numérique, il s'avère judicieux de centraliser les informations fournies aux intervenants.

Le « Jump Bag » peut inclure différents éléments :

• Plans de réponse aux incidents
• Listes de contacts
• Planning(s) d'astreinte
• Politiques de remontée
• Liens vers les outils de conférence
• Codes d'accès
• Documents de politique
• Documentation technique et runbooks

2. Utilisez des runbooks

Les runbooks fournissent des conseils sur les étapes à suivre dans un scénario donné. Ils sont particulièrement importants pour les équipes qui appliquent des rotations d'astreinte lorsqu'un expert système n'est pas immédiatement disponible. Un ensemble bien géré de runbooks permet aux équipes d'intervenir plus rapidement et de créer une base de connaissances partagée sur les pratiques de réponse aux incidents.

3. Acceptez le chaos, encouragez la stabilité

L'ingénierie du chaos consiste à expérimenter dans des systèmes en introduisant intentionnellement des défaillances afin de comprendre comment rendre ces systèmes plus solides. Chaos Monkey en est un exemple. Initialement développé par Netflix, cet outil teste la résilience du réseau en arrêtant intentionnellement les systèmes de production.

4. Réfléchissez au-delà des NOC

Traditionnellement, les Network Operations Centers (NOC) servent de hub de surveillance et d'alerte pour les systèmes informatiques à grande échelle. Les outils modernes de gestion des incidents permettent de rationaliser considérablement ce processus. En automatisant les workflows d'envoi des alertes sur la base des types d'alerte définis, des plannings d'équipe et des politiques de remontée, le risque d'erreur humaine ou de retards peut être évité.

5. Agrégez au lieu d'aggraver

Il n'y a rien de pire que de recevoir un flux continu d'alertes provenant de plusieurs outils de surveillance. En centralisant ce flux via un seul outil, les équipes peuvent mieux filtrer les interférences pour se concentrer rapidement sur les problèmes qui nécessitent une attention particulière.

6. N'oubliez pas : le savoir, c'est le pouvoir

Une alerte de base indique un problème, mais ne donne pas toujours des précisions. Cela entraîne des retards inutiles, car les équipes doivent enquêter et déterminer les causes de ce problème. En associant les alertes et les informations techniques entourant leur déclenchement, le processus de remédiation peut démarrer plus rapidement.

7. Définissez des alertes pour vos alertes

L'expression latine « quis custodiet ipsos custodes » (« Qui garde les gardes ? ») identifie un problème universel. Les outils de surveillance utilisés par les équipes informatiques et de développement sont tout aussi vulnérables aux incidents et aux temps d'arrêt que les systèmes qu'ils sont censés protéger. Les processus d'alerte globaux garantissent que l'intégrité des systèmes et des outils qui les surveillent est contrôlée en permanence.

8. Arrêtez l'hémorragie

Un médecin officiant au sein de services de triage sait qu'il fera plus de mal que de bien s'il essaie de résoudre tous les problèmes en même temps. Il se focalise donc sur des actions immédiates qui stabilisent suffisamment le patient pour pouvoir le transférer vers le service compétent. Dans les domaines technologiques, les actions de maîtrise se concentrent sur des solutions temporaires (isolement d'un réseau, régression d'un build, redémarrage de serveurs, etc.) qui limitent au moins le périmètre de l'incident ou, mieux encore, remettent les systèmes en ligne.

9. Ne faites pas cavalier seul

Dans les équipes informatiques et DevOps, la culture des héros est une philosophie sur le déclin. L'ère où un seul ingénieur travaillait tard le soir et les week-ends parce qu'il était le seul à pouvoir remettre les systèmes en ligne est révolue. Au lieu de cela, les équipes travaillent… en équipe. La chaîne est aussi solide que son maillon le plus faible. Le travail réalisé est le fait de toute l'équipe et pas seulement de la « rockstar » du groupe.

10. Soyez transparent

Si les utilisateurs subissent une interruption de service, l'incident est généralement publié dans les plus brefs délais. Pour anticiper ce genre de problème, les équipes devraient mettre en place un plan de communication sur les incidents. L'objectif est de renforcer la confiance des clients en reconnaissant publiquement l'interruption et de veiller à ce que des mesures soient prises pour y mettre fin. Les outils comme Statuspage sont parfaits pour communiquer ces informations.

11. Apprenez de vos erreurs

En grande majorité, les équipes informatiques et DevOps déclarent examiner uniquement les « pannes majeures ». Même si c'est un bon début, cette approche ne tient souvent pas compte des incidents mineurs qui peuvent avoir un impact sur le long terme. Un rapport circonstancié n'est pas nécessaire pour chaque incident, mais une analyse post-mortem s'avère toujours utile.

12. Déterminez la cause profonde (il n'y en a pas !)

Mais n'y a-t-il vraiment qu'une seule cause profonde ? Lors de l'analyse d'un incident, la cause « profonde » est rarement unique. Souvent, les systèmes sont beaucoup trop complexes et interdépendants pour définir une seule cause profonde d'un incident. Même si la cause profonde semble apparente (par exemple, une erreur de frappe qui fait planter une app), il y a généralement lieu de déterminer les facteurs externes qui ont entraîné le plantage de l'app (ou qui ne l'ont pas empêché). Recherchez plusieurs causes profondes pour mieux comprendre vos incidents.

13. Évitez les reproches

L'objectif de chaque post-mortem d'incident devrait être de comprendre ce qui n'a pas fonctionné et ce que vous pouvez faire pour éviter que des incidents similaires ne se reproduisent. Remarque importante : ce processus ne doit pas être l'occasion de jeter le blâme. Les équipes qui recherchent un coupable au lieu d'analyser le problème laissent les émotions prendre le pas sur la compréhension de la situation.

Dernier point

Dans les environnements modernes de gestion des incidents, le changement est la seule constante. Les systèmes sont donc continuellement sous pression. Les équipes qui en sont conscientes comprennent également qu'il leur faut déterminer quand, et non si, les systèmes vont tomber en panne. La prise de mesures pour se préparer à ces pannes est essentielle à la réussite continue et devrait être intégrée dans les processus des équipes d'ingénierie.

Une solution de gestion des incidents comme Jira Service Management vous aidera à tous ces niveaux, de l'organisation de votre planning d'astreinte et de vos alertes à l'unification des équipes pour optimiser la collaboration et à l'exécution des post-mortems d'incident.