Étape 5 : Réagir et apprendre

La façon dont votre application réagit aux événements perturbateurs influence sa fiabilité. Il est également essentiel de tirer les leçons de l'expérience et de la manière dont votre application a réagi aux perturbations dans le passé pour améliorer sa fiabilité. 

La phase de réponse et d'apprentissage se concentre sur les pratiques que vous pouvez mettre en œuvre pour mieux répondre aux événements perturbateurs dans vos applications. Il inclut également des pratiques qui vous aideront à tirer le meilleur parti des expériences de vos équipes opérationnelles et de vos ingénieurs.

Création de rapports d'analyse des incidents

Lorsqu'un incident survient, la première mesure à prendre est de prévenir le plus rapidement possible de nouveaux dommages aux clients et à l'entreprise. Une fois l'application rétablie, l'étape suivante consiste à comprendre ce qui s'est passé et à identifier les mesures à prendre pour éviter que cela ne se reproduise. Cette analyse post-incident est généralement capturée sous la forme d'un rapport qui documente l'ensemble des événements qui ont entraîné une détérioration de l'application, ainsi que les effets de l'interruption sur l'application, les clients et l'entreprise. Ces rapports deviennent de précieux outils d'apprentissage et devraient être largement diffusés au sein de l'entreprise.

Note

Il est essentiel d'effectuer une analyse des incidents sans attribuer de responsabilité. Supposons que tous les opérateurs aient pris les mesures les meilleures et les plus appropriées compte tenu des informations dont ils disposaient. N'utilisez pas les noms des opérateurs ou des ingénieurs dans un rapport. Invoquer une erreur humaine comme cause de déficience peut inciter les membres de l'équipe à être surveillés afin de se protéger, ce qui se traduirait par la saisie d'informations incorrectes ou incomplètes.

Un bon rapport d'analyse des incidents, tel que celui documenté dans le processus Amazon Correction of Error (COE), suit un format standardisé et tente de saisir, de manière aussi détaillée que possible, les conditions qui ont entraîné une détérioration de l'application. Le rapport détaille une série d'événements horodatés et capture des données quantitatives (souvent des métriques et des captures d'écran provenant de tableaux de bord de surveillance) qui décrivent l'état mesurable de l'application au cours de la chronologie. Le rapport doit rendre compte des processus de réflexion des opérateurs et des ingénieurs qui ont pris des mesures, ainsi que des informations qui les ont conduits à leurs conclusions. Le rapport doit également détailler les performances des différents indicateurs, par exemple, quelles alarmes ont été déclenchées, si ces alarmes reflétaient correctement l'état de l'application, le délai entre les événements et les alarmes qui en ont résulté, et le temps nécessaire pour résoudre l'incident. La chronologie décrit également les runbooks ou les automatisations qui ont été initiés et comment ils ont aidé l'application à retrouver un état utile. Ces éléments du calendrier aident votre équipe à comprendre l'efficacité des réponses automatisées et des réponses des opérateurs, notamment la rapidité avec laquelle ils ont résolu le problème et leur efficacité à atténuer les perturbations.

Ce portrait détaillé d'un événement historique est un puissant outil pédagogique. Les équipes doivent stocker ces rapports dans un référentiel central accessible à l'ensemble de l'entreprise afin que d'autres puissent examiner les événements et en tirer des leçons. Cela peut améliorer l'intuition de vos équipes quant à ce qui peut mal tourner en production.

Un référentiel de rapports d'incidents détaillés devient également une source de matériel de formation pour les opérateurs. Les équipes peuvent utiliser un rapport d'incident pour organiser une journée de jeu sur table ou en direct, au cours de laquelle les équipes reçoivent des informations reprenant la chronologie enregistrée dans le rapport. Les opérateurs peuvent parcourir le scénario à l'aide d'informations partielles provenant de la chronologie et décrire les actions qu'ils entreprendraient. Le modérateur du jour du match peut ensuite fournir des conseils sur la façon dont l'application a réagi en fonction des actions de l'opérateur. Cela développe les compétences des opérateurs en matière de dépannage, afin qu'ils puissent anticiper et résoudre les problèmes plus facilement.

Une équipe centralisée chargée de la fiabilité des applications doit conserver ces rapports dans une bibliothèque centralisée accessible à l'ensemble de l'entreprise. Cette équipe devrait également être chargée de maintenir le modèle de rapport et de former les équipes sur la manière de rédiger le rapport d'analyse des incidents. L'équipe de fiabilité doit examiner régulièrement les rapports afin de détecter les tendances au sein de l'entreprise qui peuvent être prises en compte par le biais de bibliothèques logicielles, de modèles d'architecture ou de modifications des processus d'équipe.

Réalisation d'examens opérationnels

Comme indiqué dans la section Étape 4 : Exploitation, les évaluations opérationnelles sont l'occasion de passer en revue les dernières mises à jour des fonctionnalités, les incidents et les indicateurs opérationnels. La revue opérationnelle est également l'occasion de partager les enseignements tirés des mises à jour des fonctionnalités et des incidents avec l'ensemble de la communauté des ingénieurs de votre organisation. Au cours de l'examen opérationnel, les équipes examinent les déploiements de fonctionnalités annulés, les incidents survenus et la manière dont ils ont été gérés. Cela donne aux ingénieurs de l'ensemble de l'organisation l'occasion de tirer des leçons de l'expérience des autres et de poser des questions.

Proposez vos évaluations opérationnelles à la communauté des ingénieurs de votre entreprise afin qu'elle puisse en savoir plus sur les applications informatiques qui gèrent l'entreprise et les types de problèmes qu'elle peut rencontrer. Ils emporteront ces connaissances avec eux lors de la conception, de la mise en œuvre et du déploiement d'autres applications pour l'entreprise.

Examen des performances des alarmes

Les alarmes, comme indiqué lors de la phase d'exploitation, peuvent entraîner des alertes sur le tableau de bord, la création de tickets, l'envoi d'e-mails ou l'envoi d'une pagination des opérateurs.  Une application comportera de nombreuses alarmes configurées pour surveiller divers aspects de son fonctionnement. Au fil du temps, la précision et l'efficacité de ces alarmes doivent être revues afin d'accroître la précision des alarmes, de réduire le nombre de faux positifs et de consolider les alertes dupliquées.

Précision de l'alarme

Les alarmes doivent être aussi spécifiques que possible afin de réduire le temps que vous devez consacrer à l'interprétation ou au diagnostic de la perturbation spécifique à l'origine de l'alarme. Lorsqu'une alarme est déclenchée en réponse à une défaillance de l'application, les opérateurs qui reçoivent l'alarme et y répondent doivent d'abord interpréter les informations transmises par l'alarme. Les informations peuvent être un simple code d'erreur correspondant à un plan d'action tel qu'une procédure de restauration, ou elles peuvent inclure des lignes provenant des journaux d'applications que vous devez consulter pour comprendre pourquoi l'alarme a été déclenchée. Au fur et à mesure que votre équipe apprend à utiliser une application plus efficacement, elle doit affiner ces alarmes pour les rendre aussi claires et concises que possible.

Comme il est impossible d'anticiper toutes les perturbations possibles d'une application, il y aura toujours des alarmes générales qui nécessiteront l'analyse et le diagnostic de l'opérateur. Votre équipe doit s'efforcer de réduire le nombre d'alarmes générales afin d'améliorer les temps de réponse et de réduire le temps moyen de réparation (MTTR). Idéalement, il devrait y avoir une one-to-one relation entre une alarme et une réponse automatisée ou exécutée par l'homme.  

Faux positifs

Les alarmes qui ne nécessitent aucune action de la part des opérateurs mais qui produisent des alertes sous forme d'e-mails, de pages ou de tickets seront ignorées par les opérateurs au fil du temps.  Régulièrement, ou dans le cadre d'une analyse des incidents, passez en revue les alarmes pour identifier celles qui sont souvent ignorées ou qui ne nécessitent aucune action de la part des opérateurs (faux positifs).  Vous devez vous efforcer de supprimer l'alarme ou de l'améliorer afin qu'elle émette une alerte exploitable aux opérateurs.

Faux négatifs

Lors d'un incident, les alarmes configurées pour alerter pendant l'incident peuvent échouer, peut-être en raison d'un événement qui a un impact inattendu sur l'application.  Dans le cadre de l'analyse d'un incident, vous devez passer en revue les alarmes qui auraient dû être déclenchées mais qui ne l'ont pas été. Vous devez vous efforcer d'améliorer ces alarmes afin qu'elles reflètent mieux les conditions susceptibles de découler d'un événement. Il se peut également que vous deviez créer des alarmes supplémentaires correspondant à la même interruption mais déclenchées par un symptôme différent de la perturbation.

Alertes dupliquées

Une interruption qui altère votre application est susceptible de provoquer de multiples symptômes et d'entraîner plusieurs alarmes.  Régulièrement, ou dans le cadre d'une analyse d'incident, vous devez passer en revue les alarmes et alertes émises.  Si les opérateurs ont reçu des alertes dupliquées, créez des alarmes agrégées pour les regrouper en un seul message d'alerte.

Réalisation d'examens des métriques

Votre équipe doit collecter des indicateurs opérationnels concernant votre application, tels que le nombre d'incidents par niveau de gravité par mois, le temps nécessaire pour détecter l'incident, le temps nécessaire pour identifier la cause, le temps nécessaire pour y remédier, ainsi que le nombre de tickets créés, d'alertes envoyées et de pages créées. Passez en revue ces indicateurs au moins une fois par mois pour comprendre la charge de travail qui pèse sur le personnel opérationnel, le signal-to-noise ratio auquel il est confronté (par exemple, alertes informatives par rapport aux alertes exploitables) et pour savoir si l'équipe améliore sa capacité à exploiter les applications sous son contrôle. Utilisez cette revue pour comprendre les tendances relatives aux aspects mesurables de l'équipe des opérations. Sollicitez des idées auprès de l'équipe sur la manière d'améliorer ces indicateurs.  

Fournir des formations et des habilitations

Il est difficile de saisir une description détaillée d'une application et de son environnement à l'origine d'un incident ou d'un comportement inattendu. En outre, modéliser la résilience de votre application pour anticiper de tels scénarios n'est pas toujours simple. Votre organisation doit investir dans des supports de formation et de facilitation permettant à vos équipes opérationnelles et à vos développeurs de participer à des activités telles que la modélisation de la résilience, l'analyse des incidents, les journées de jeu et les expériences d'ingénierie du chaos. Cela améliorera la fidélité des rapports produits par vos équipes et les connaissances qu'elles capturent. Les équipes seront également mieux équipées pour anticiper les défaillances sans compter sur un groupe d'ingénieurs plus restreint et plus expérimenté qui doivent apporter leur point de vue par le biais de révisions planifiées.

Création d'une base de connaissances sur les incidents

Un rapport d'incident est un résultat standard d'une analyse d'incident. Vous devez utiliser le même rapport ou un rapport similaire pour documenter les scénarios dans lesquels vous avez détecté un comportement anormal de l'application, même si l'application n'a pas été altérée. Utilisez la même structure de rapport standardisée pour saisir les résultats des expériences chaotiques et des journées de jeu. Le rapport représente un instantané de l'application et de son environnement à l'origine d'un incident ou d'un comportement inattendu. Vous devez stocker ces rapports standardisés dans un référentiel central accessible à tous les ingénieurs de l'entreprise.  

Les équipes opérationnelles et les développeurs peuvent ensuite effectuer des recherches dans cette base de connaissances pour comprendre ce qui a perturbé les applications dans le passé, quels types de scénarios auraient pu provoquer des perturbations et ce qui a permis d'éviter toute détérioration des applications. Cette base de connaissances devient un accélérateur pour améliorer les compétences de vos équipes opérationnelles et de vos développeurs, et leur permet de partager leurs connaissances et leurs expériences. En outre, vous pouvez utiliser les rapports comme matériel de formation ou comme scénarios pour les journées de jeu ou les expériences de chaos afin d'améliorer l'intuition de l'équipe opérationnelle et sa capacité à résoudre les problèmes liés aux perturbations.

Note

Un format de rapport normalisé donne également aux lecteurs un sentiment de familiarité et les aide à trouver plus rapidement les informations qu'ils recherchent.

Mettre en œuvre la résilience en profondeur

Comme indiqué précédemment, une organisation avancée mettra en œuvre plusieurs réponses à une alarme. Il n'y a aucune garantie qu'une réponse sera efficace. En superposant les réponses, une application sera mieux équipée pour échouer correctement. Nous vous recommandons de mettre en œuvre au moins deux réponses pour chaque indicateur afin de garantir qu'une réponse individuelle ne devienne pas un point de défaillance unique susceptible de mener à un scénario de reprise après sinistre.  Ces couches doivent être créées par ordre séquentiel, de sorte qu'une réponse successive ne soit effectuée que si la réponse précédente s'est révélée inefficace. Vous ne devez pas exécuter de réponses à plusieurs niveaux à une seule alarme. Utilisez plutôt une alarme qui indique si une réponse a échoué et, dans l'affirmative, déclenche la réponse en couches suivante.