Une douzaine (ou deux) d'enseignements tirés de 15 ans de gestion des incidents logiciels

En tant qu'ingénieur logiciel, gérer les incidents est une tâche ardue. Vous recevez cette page de garde à 3 heures du matin un samedi matin ? Cela peut être effrayant, suceur d’âme et tout à fait un épisode odieux. Si cela se produit fréquemment sur votre lieu de travail, cela peut littéralement provoquer un SSPT.

Malheureusement, cela fait partie intégrante de l’air du temps du logiciel. Au contraire, ce sont ces feux à travers lesquels la véritable ingénierie se forge. Ces incidents vous apprennent à concevoir des systèmes renforcés et, dans de nombreux cas, à ne pas le faire.

Cet article aborde 2 aspects de la manière de gérer les incidents logiciels :

• 🛠️ Les pratiques qu'il faut inculquer à sa plateforme logicielle et à ses équipes pour prévenir et tirer les leçons de ces expériences.

• 🧘 L'attitude qu'il faut avoir pour être résilient et sortir de ces expériences non seulement indemne, mais avec plus que ce qu'ils ont vécu.

Les sujets que nous aborderons sont —

1. Automatisez vos systèmes autant que vous le pouvez
2. Suivi des indicateurs avancés et retardés
3. Les alertes « exploitables » doivent être évidentes
4. Établir des chaînes d'appels et des chemins d'escalade clairs
5. Donnez aux premières lignes les moyens de prendre de grandes décisions
6. Tous les incidents ne sont pas égaux
7. Résolvez d'abord, posez des questions plus tard
8. Assurez-vous qu'une personne est responsable
9. Communiquer clairement et fréquemment
10. Des autopsies irréprochables sont cruciales
11. Les suivis des autopsies sont cruciaux
12. Les incidents ne sont pas graves tant que le MTTD est faible
13. L'humour est le grand égalisateur

Plongeons-nous dans quelques détails !

Automatisez vos systèmes autant que vous le pouvez

Vous souhaitez vraiment minimiser le nombre d'incidents dont vous êtes informé, soit par l'intermédiaire de vos clients, soit par le biais de graves écarts comptables, quelques jours ou semaines après le début de l'incident. Bien que « automatisation » soit un mot galvaudé en ingénierie, c'est l'un de ces domaines dans lesquels vous souhaitez vraiment trouver le bon équilibre entre le rapport signal/bruit et garantir que vous et votre équipe recevez des alertes sans avoir besoin d'aucune intervention humaine.

S’il y a trop de choses parmi lesquelles choisir, allez au très haut niveau. Quelle est la mesure de niveau le plus élevé que vous pourriez choisir ? Celui si les systèmes de composants ne fonctionnent pas comme prévu, s'écartera-t-il de la norme ? Il peut s'agir de suivre les revenus circulant via la plateforme (pour une plateforme de commerce électronique, financière ou basée sur le dollar) ou le nombre d'utilisateurs actifs actuels (pour les plateformes de médias sociaux).

Si vous voyez les chiffres s'effondrer ou chuter d'un écart type ou deux, alertez immédiatement l'équipe de développement. Concentrer les premières alertes (ou les plus importantes) sur le pouls de l’entreprise ou sur l’expérience utilisateur principale sera une excellente mesure à surveiller. Au fur et à mesure que vous devenez plus sophistiqué et comprenez mieux le système, vous pouvez commencer à approfondir la pile du point de vue de l'observabilité.

Suivi des indicateurs avancés et retardés

Les indicateurs avancés sont de nature prédictive et sont susceptibles d’indiquer un problème sur le point de se produire, tandis que les indicateurs retardés sont post-hoc et sont représentatifs des conséquences une fois que le problème est bien avancé. Si vous pouvez exploiter les indicateurs avancés (comme par exemple « la durée de la session » qui commence à diminuer) en plus ou à la place des indicateurs retardés (comme par exemple « le nombre de commandes passées en chute libre »), vous pouvez probablement éviter quelque chose qui c'est assez catastrophique.

Les alertes « exploitables » devraient être évidentes

Vos alertes doivent être évidentes afin que les prochaines étapes à suivre en cas de déclenchement soient parfaitement claires. Qu'il s'agisse de déterminer la gravité du problème, de résoudre l'incident ou de remédier au problème, l'alerte doit contenir suffisamment de détails. Vous voulez vous assurer que cela ne nécessite pas beaucoup de discussions préalables pour déterminer quoi faire avec l’alerte.

Vous pouvez coller ces détails dans le contenu de l'alerte elle-même, ou si elle est assez détaillée, vous pouvez créer un lien vers un ou plusieurs runbooks que l'équipe gère pour ces types de problèmes.

Établir des chaînes d'appels et des chemins d'escalade clairs

Il est essentiel d'avoir une idée claire de ce qui se passe lorsqu'une alerte est déclenchée, y compris à qui elle est acheminée en fonction d'éléments tels que la propriété du service, la connaissance du fuseau horaire, etc., pour garantir une réponse rapide. Au-delà de cette première ligne de défense immédiate, il est également essentiel de garantir que l’on sait clairement comment et à qui l’intervenant peut transmettre l’incident.

Souvent, si le problème est complexe ou d’une portée bien plus grande qu’une seule personne ne peut le gérer, il peut être nécessaire de faire appel à des personnes plus expérimentées (ou à plusieurs personnes dans l’équipe) ainsi qu’à des parties prenantes interfonctionnelles. Rendre tout cela facilement accessible via des outils (comme PagerDuty, OpsGenie) ou une documentation claire (livres d'exécution, pages wiki, README de dépôt) pourrait faire la différence entre un incident catastrophique ou un rien de bon.

Donnez aux premières lignes les moyens de prendre de grandes décisions

Même si vous avez besoin de chemins d'escalade clairs, vous ne voulez pas que ce soit la réponse par défaut. Vous devez donner aux premiers intervenants les moyens de prendre des mesures concrètes pour endiguer l’hémorragie ou de prendre des décisions sur place pour y remédier, sans avoir besoin de consulter la haute direction. C'est à la fois bénéfique pour l'entreprise en termes de limitation des retombées, ainsi que pour les employés à qui l'on confie une haute responsabilité et qui leur font confiance pour prendre de grandes décisions. Réduisez les formalités administratives et augmentez la capacité d’action des individus.

Tous les incidents ne sont pas égaux

Outre des éléments tels que les chaînes d'appels et les voies d'escalade, un autre élément de garantie important est une échelle de priorité des incidents. Il s'agit généralement d'une référence rapide pour le premier intervenant ou le commandant de l'incident. Cela les aide à identifier rapidement la gravité de l'incident et à le qualifier comme tel, car il peut justifier différents niveaux de réponse.

Il est essentiel pour les intervenants de faire la différence entre les incidents critiques (comme les pannes de système ou la corruption de données financières) et les problèmes mineurs (tels que les problèmes de palette de couleurs) afin d'éviter les fausses alarmes. Cela garantit également que la réponse de l’équipe reste efficace et ciblée.

Résolvez d’abord, posez des questions plus tard

Sans aucun doute, l’une des choses les plus importantes à faire est de résoudre l’incident le plus rapidement possible. Vous ne voulez pas passer du temps à philosopher sur les raisons pour lesquelles quelque chose s'est produit ou sur la façon dont cela aurait pu être évité, alors que l'incident est en cours. Vous pouvez réserver cela pour l'autopsie. Pour le moment, concentrez-vous impitoyablement sur la résolution de l’incident et posez les questions difficiles plus tard.

Assurez-vous qu'une seule personne est responsable

Parfois, les incidents peuvent devenir trop importants. Ils touchent trop de services, couvrent plusieurs domaines commerciaux ou ont tout simplement un impact considérable en termes de revenus ou de réputation. C'est à ce moment-là qu'il est absolument crucial qu'une seule personne soit désignée pour « agent de la circulation » pendant tout l'incident. Chez Place Exchange, nous avons institué des « commandants d'incident » qui sont un petit groupe de personnes formées à la réponse aux incidents complexes.

La raison pour laquelle il est si important d’avoir ce type de rôle est que lorsque plusieurs parties sont impliquées, quelqu’un doit diriger le trafic. Souvent, les ingénieurs commencent à se plonger dans des terriers concernant la complexité du problème ou à essayer de comprendre comment résoudre le problème.

Le rôle du commandant de l'incident est de maintenir le groupe concentré sur la résolution rapide de l'incident. Ils veillent à ce que chacun ait un penchant pour l’action et, même si les enquêtes parallèles peuvent être importantes, il est encore plus important de garantir un élan vers l’avant. Ils sont également chargés de garantir une communication claire et constante avec les parties prenantes et partenaires internes et externes.

Les commandants d'intervention démarrent généralement une ligne de communication vocale synchrone, comme un groupe Slack ou une réunion Google Meet. Cela garantit que les personnes essentielles à la résolution de l’incident sont en contact permanent. Il est étonnant de constater à quel point cette petite chose est efficace par rapport au simple fait de permettre aux gens de résoudre des problèmes de manière asynchrone en utilisant le chat.

Les commandants d'intervention sont également chargés de veiller à ce qu'il y ait une délégation claire pour les tâches qui doivent être accomplies et de s'assurer qu'il y a une responsabilité pour obtenir des réponses ou des résultats pour ces tâches.

Comme on dit, si on demande à 2 personnes de nourrir un cheval, le cheval meurt. Un commandant d’incident empêche que cela se produise et est en fin de compte responsable de la résolution rapide de l’incident.

Communiquer clairement et fréquemment

Les gens pardonneront souvent la panne de leur application ou logiciel préféré s’ils sont tenus informés de la manière dont l’équipe travaille dur pour résoudre l’incident. Essayer de garder les choses cachées, soit parce que vous ne sentez pas avoir une maîtrise complète de l'incident, soit parce que vous et votre équipe vous sentez gênés, ne sont pas des raisons pour empêcher la communication de circuler vers l'extérieur.

Assurez-vous que la communication est concise, fréquente et transparente pour vos partenaires internes et externes, car cela contribuera à renforcer la bonne volonté.

Des autopsies irréprochables sont cruciales

Les autopsies ou les rétrospectives post-incident sont importantes pour construire une culture d’apprentissage, et elles doivent absolument être irréprochables. Soyez critique à l’égard du processus et non de la personne. Personne n'est plus dur avec lui-même que la ou les personnes qui auraient pu causer cela, et vous ne gagnez rien à les flageller en public. Au contraire, toutes les recherches suggèrent que vous perdez en faisant cela. Les gens d'Etsy savent bien mieux en parler, alors allez lire https://www.etsy.com/codeascraft/blameless-postmortems si vous voulez en savoir plus.

Les suivis des autopsies sont cruciaux

Bien qu’il soit important de réaliser des autopsies par soi-même pour sensibiliser et créer des boucles de rétroaction permettant de tirer des leçons de ces incidents, les actions discutées pour éviter que cela ne se reproduise à l’avenir sont peut-être plus importantes. Si le groupe a identifié un ensemble de lacunes ou de vulnérabilités dans le système, il est extrêmement important qu'il se concentre et s'efforce de les résoudre en temps opportun afin d'éviter que le même problème ne se reproduise.

Il est difficile de prévenir les incidents, et cela constitue généralement une conversation difficile avec votre entreprise et vos clients. Mais si le même incident se reproduit encore et encore, cela devient à la fois beaucoup plus difficile à défendre et indique un grave problème de santé et de compétences de l’équipe.

Les incidents ne sont pas graves tant que le MTTD est faible

Tout le monde comprend. Même les gens d’affaires comprennent. Créer des logiciels est DIFFICILE, et dans un monde où tous nos logiciels ont des centaines ou des milliers de dépendances, où les lignes de faille pourraient se fissurer, il est impossible de le prédire. La merde va frapper le ventilateur, et tout va bien. Nous ne pouvons pas empêcher les incidents de se produire. Cependant, ce qui aide vraiment, c'est de s'assurer que le MTTD de vos incidents est vraiment faible.

Le temps moyen de détection (MTTD) est un indicateur de performance clé (KPI) qui mesure le temps moyen nécessaire à une organisation pour identifier un incident ou une menace de sécurité. Il est difficile de généraliser, compte tenu du domaine d'activité, de la gravité de l'impact, etc., mais si vous parvenez à réduire votre MTTD de quelques secondes à quelques minutes, vous pourrez probablement réduire considérablement l'impact d'un incident plutôt que de le dire. durait des heures à des jours (sans parler des semaines ou des mois, ce qui est malheureusement tout à fait possible).

L'humour vous soulage de la douleur du moment

Tout cela est tellement GRAVE ! L'argent se perd ! Les clients vivent une expérience terrible ! Cependant, au milieu de tout cela, j’ai trouvé qu’il était essentiel d’avoir le sens de l’humour. Nous ne devons pas oublier que tout le monde est un être humain dans ce processus et traverse différents degrés de stress. Injecter des doses d’humour à des moments appropriés aide à soulager une partie de cette pression.

Cela crée un sentiment de camaraderie qui donne à l’équipe le sentiment d’être ensemble plutôt que d’être sur une île en enfer.

C'est terminé. Merci d'avoir lu!

⭐ Si vous aimez ce type de contenu, assurez-vous de me suivre ou de vous abonner à https://a1engineering.substack.com/subscribe ! ⭐

Photo vedette par Julien L sur Unsplash