💣 sur la production !
production post-mortem erreur
rédigé par Nicolas Caillet le 07/12/2022

Le maintien en production d’instances client n’est pas toujours chose aisĂ©e, surtout lorsque l’on essaie d’automatiser le plus d’actions possibles. Une erreur dans un script automatisĂ© et c’est la catastrophe ! L’équipe a pu s’en apercevoir Ă  ses dĂ©pens un beau jeudi midi de septembre. Tout a commencĂ© par un appel disant :

« Jean-Pierre, que se passe-t-il, notre instance ne répond plus et les fichiers ont été supprimés ».

â„č Cet article relate le dĂ©roulement d’un incident en production et a vocation Ă  partager les enseignements et bonnes pratiques Ă  mettre en Ɠuvre.

Le contexte

Depuis le dĂ©but du mois de septembre, notre Ă©quipe teste et met en place des configurations avec AWX. Pour ceux qui ne connaissent pas AWX, il s’agit d’une interface graphique qui permet de lancer des playbooks Ansible, tout en ayant une gestion fine des droits et accĂšs, selon les besoins de chaque utilisateur.

🎯 dĂ©charger l'Ă©quipe IT de certaines tĂąches et Ă©viter les erreurs liĂ©es Ă  l’inattention et/ou aux tĂąches rĂ©pĂ©titives.

Jusqu’au jeudi 29 septembre, pas de souci Ă  l’utilisation, tout se passait comme prĂ©vu ✅.

Le besoin

AprĂšs les tests de crĂ©ation et de mise Ă  jour en production de services vient le test de suppression d’instance sur la production. Sur le papier, tout est fait pour se dĂ©rouler Ă  merveille, aucun problĂšme dĂ©tectĂ© sur la prĂ©-production ! Dans la pratique
 Rien ne se dĂ©roule comme prĂ©vu.

đŸ’„ AjoutĂ© Ă  un manque d’attention, cela a donnĂ© un combo explosif avec la suppression pure et simple de 16 instances Tracim. Certaines utilisĂ©es en internes, d’autres Ă©tant des instances clients.

⁉ Que s'est-il passĂ© ?

La chronologie

Un post-mortem ne vient pas sans chronologie. Voici donc ce qu’il s’est passé :

29/09/2022 :

- 12 h 03 : Lancement de la commande de suppression d’une seule instance ;
- 12 h 05 : Le playbook démarre sans incident, pause repas, la commande suit son cours ;
- 12 h 15 : PremiĂšre alerte interne d’un salariĂ©. L'instance Tracim interne est indisponible ;
- 12 h 20 : 🔎 Investigation et dĂ©tection d’un problĂšme technique : le service ne tourne plus sur le serveur ;
- 12 h 22 : Suite des investigations oĂč l'on dĂ©couvre que le service n’existe plus sur le serveur : plus de fichiers de configs ou de logs ;
- 12 h 25 : ☎ On fait du tĂ©lĂ©travail : premiers Ă©changes tĂ©lĂ©phoniques pour tenter de savoir ce qui se passe ;
- 12 h 30 : Réaction : on restaure notre instance interne ;
- 12 h 57 : On se rend compte que d’autres instances sont touchĂ©es ;
- 12 h 59 : Identification et kill de la commande problĂ©matique qui continuait de s’exĂ©cuter. (Comme quoi la communication est importante !) ;
- 13 h 10 : État des lieux des instances affectĂ©es et dĂ©finition des prioritĂ©s de remise en route ;
- 14 h 41 : Restauration de la premiÚre instance client ;
- 17 h 00 : On s'aperçoit de l’indisponibilitĂ© de certaines sauvegardes (ou sauvegarde incomplĂšte) ;
- 19 h 00 : On prend conscience que deux instances ne sont pas complÚtement « détruites ». (Investigations pour ne restaurer que le nécessaire. Gain de temps par rapport à la quantité de données.) ;
- 20 h : Dans notre prĂ©cipitation, on s’est trompĂ©s dans l’état des lieux. On dĂ©tecte que deux instances supplĂ©mentaires sont impactĂ©es ;
- 20 h 38 : Restauration de la derniÚre instance client ;

30/09/2022 :

- Recherche des problématiques sur le script de sauvegarde ;

En tout et pour tout, l’incident aura durĂ© 9 h avec impact pour certains utilisateurs.

🏾 Durant ces heures, nous sommes passĂ©s d’un trou dans la raquette Ă  une raquette sans cordage, en dĂ©couvrant progressivement l’enchaĂźnement de diffĂ©rentes dĂ©faillances.

C’est gĂ©nĂ©ralement de cette façon que l'on arrive Ă  une catastrophe đŸ’„.

Au final, on s’en sort bien, car les seules donnĂ©es dĂ©finitivement perdues Ă©taient des donnĂ©es de test (instances client en phase de test de Tracim). C’est un coup de chance, et un enseignement dans la douleur.

đŸ‘„ Les erreurs arrivent, ce qui compte, c’est d’en tirer des enseignements pour progresser. C’est ce que l’on a fait et c’est ce que l’on partage ici.

L'analyse

Voici ce qui a pu ĂȘtre relevĂ© a posteriori et les diffĂ©rentes actions prises pour remĂ©dier Ă  ces problĂ©matiques :

⏳ Ne jamais lancer de nouvelle opĂ©ration pendant une absence

Tel qu’indiquĂ© dans la chronologie, l'opĂ©ration a Ă©tĂ© lancĂ©e avant de partir en pause repas avec une absence de la personne ayant lancĂ© la commande. đŸČ

🎯 : Éviter de lancer des opĂ©rations sans rester en supervision jusqu’à la fin de l’action. Cela permet une vigilance accrue et une intervention rapide en cas de dĂ©tection d’un problĂšme. C’est particuliĂšrement critique sur de nouvelles opĂ©rations.

📝 Le plan de reprise sur incident doit ĂȘtre disponible en dehors des outils concernĂ©s

Une des problĂ©matiques identifiĂ©e durant cet incident est que les documents indiquant la marche Ă  suivre pour remettre en route une instance sont uniquement disponibles sur notre instance Tracim interne. Aucun autre exemplaire ni papier ni sur un autre poste / serveur. Cela entraĂźne forcĂ©ment des complications lorsque l’on ne se souvient pas de toutes les Ă©tapes nĂ©cessaires Ă  la remise en route d’une instance !

💭 C’est une chose Ă  laquelle on ne pense pas forcĂ©ment en amont du problĂšme, mais avoir la documentation « vitale » nĂ©cessaire et accessible est important ! (et ça paraĂźt Ă©vident aprĂšs coup 😉).

🎯 Avoir une copie de la documentation de remĂ©diation Ă  un autre emplacement. Une version papier peut Ă©galement une solution.

đŸ’Ÿ - VĂ©rifiez rĂ©guliĂšrement vos sauvegardes !

Lors de la tentative de restauration de certaines instances, nous avons dĂ©couvert que certaines sauvegardes des bases de donnĂ©es n’étaient pas rĂ©alisĂ©es correctement, depuis plus d’un mois pour certaines.

Notre script de sauvegarde et notre monitoring de ces derniĂšres n’ont dans les deux cas pas remontĂ© d’erreur.

đŸ•”đŸ» Une modification du script de sauvegarde des bases de donnĂ©es a Ă©tĂ© rĂ©alisĂ©e mi-aoĂ»t ; lors de son dĂ©ploiement fin aoĂ»t, il s’est avĂ©rĂ© que ce n’est pas la mĂȘme personne qui a rĂ©alisĂ© la mise en production. Cela a entraĂźnĂ© un oubli de copie de tous les fichiers nĂ©cessaires au fonctionnement du changement.

De plus, le script ne générait pas d'erreur en cas de fichier mal formaté en entrée et interrompait silencieusement la création des sauvegardes.

Enfin, le monitoring des sauvegardes ne remontait pas d’erreur puisqu’une partie des donnĂ©es Ă©tait malgrĂ© tout sauvegardĂ©e.

Ces trois éléments ont entraßné un dysfonctionnement silencieux des sauvegardes.

🎯 Plusieurs actions ont Ă©tĂ© mises en place pour remĂ©dier Ă  ces diffĂ©rents problĂšmes :

- Gestion des erreurs de formatage de fichier pour remonter une alerte ;
- Monitoring plus exhaustif des éléments à sauvegarder par instance ;
- Vérification manuelle réguliÚre des sauvegardes ;

 🐛 Bug sur l’outil utilisĂ© pour l’automatisation

Un bug ou une mauvaise comprĂ©hension de l’outil utilisĂ© ont menĂ© Ă  cet Ă©vĂšnement. Utilisant des outils open source, nous avons donc crĂ©Ă© un ticket (disponible ici : https://github.com/ansible/awx/issues/12991).

Nous ignorons si cela sera traitĂ© un jour, mais la problĂ©matique n’est donc plus inconnue.

Les autres mesures que l'on a mises en Ɠuvre

Vous avez pu trouver les 4 principales actions prises suite Ă  cet incident, mais ce ne sont pas les seules. Voici une liste d’actions qui ont Ă©tĂ© ou vont ĂȘtre mises en place Ă  moyen terme :

- đŸ’Ÿ Suppression "soft" : lors de la suppression d'une instance, une sauvegarde est rĂ©alisĂ©e. Elle permet de rĂ©cupĂ©rer les donnĂ©es dans le dernier Ă©tat oĂč elles Ă©taient ;
- đŸ©ș Ne pas se prĂ©cipiter : il est important d'analyser de maniĂšre approfondie l’incident et ses impacts avant de prendre des mesures de correction ;
- ☎ Informer les clients et utilisateurs : il est important de tenir les personnes informĂ©es, ce n’est jamais agrĂ©able, mais cela Ă©vite les mauvaises surprises ;
- đŸ–„ïž PrĂ©voir une restauration automatisĂ©e du retour en production depuis une sauvegarde ;

đŸ’ȘđŸ» Tout ne s’est pas mal passĂ© non plus...

MalgrĂ© toutes les dĂ©faillances, plusieurs Ă©tapes se sont bien dĂ©roulĂ©es et il ne faut pas oublier de considĂ©rer le positif lors d’évĂšnements de ce genre 😃.

đŸ‘„ Bonne coordination de l’équipe

Le travail de restauration et de reprise sur incident s’est bien dĂ©roulĂ© et la communication continue entre les membres de l’équipe, malgrĂ© la distance. Nos outils de visioconfĂ©rence nous ont permis de nous tenir informĂ©s de maniĂšre continue sur l’avancĂ©e des opĂ©rations.

🔎 RapiditĂ© de dĂ©tection

Comme indiquĂ© dans la chronologie, la premiĂšre dĂ©tection de l’incident a eu lieu trĂšs rapidement. Les solutions de mitigations ont mis un peu plus de temps Ă  ĂȘtre mises en place, car ce genre d’incident Ă©tait une dĂ©couverte pour nous.

🚅 RapiditĂ© de rĂ©tablissement

Nous pouvons voir dans la chronologie que le rĂ©tablissement a Ă©tĂ© relativement rapide pour tous les clients. Cela a Ă©tĂ© possible grĂące Ă  la coordination Ă©voquĂ©e prĂ©cĂ©demment, mais Ă©galement grĂące au temps pris entre 13 h 00 et 14 h 30 pour automatiser les points les plus chronophages de la restauration d’une instance Ă  partir d’une sauvegarde. C'est un point que nous allons encore travailler Ă  l’avenir pour encore gagner en rĂ©activitĂ©.

🚒 Restauration des services basĂ© sur l’impact client de la dĂ©faillance

La dĂ©finition de clients prioritaires nous a permis de savoir sur quelles instances travailler en prioritĂ© pour permettre un retour Ă  la normale le plus tĂŽt possible. Nous n’avons pas de clients plus importants que d’autres ; nous avons en revanche des instances Tracim qui sont utilisĂ©es en permanence tandis que d’autres sont utilisĂ©es de maniĂšre plus ponctuelle. Une interruption de service a donc moins potentiellement d’impact certaines instances.

🍀 Chance

Tous ces Ă©lĂ©ments rĂ©unis indiquent quand mĂȘme qu’un facteur chance nous a bien aidĂ©. Les instances oĂč la sauvegarde de la base de donnĂ©es n’étaient pas disponibles sont des instances de tests, par consĂ©quent, nous n’avons pas perdu de donnĂ©es clients. đŸ’Ș

🍀 Il faut savoir profiter de la chance, mais il ne faut pas se reposer sur elle : nous avons pris les mesures nĂ©cessaires pour que ce facteur ne soit plus un facteur clĂ© de succĂšs.

Conclusion

De maniĂšre globale, nous nous en sommes bien tirĂ©s. Un post-mortem rĂ©alisĂ© la semaine suivante nous a permis de cibler des points d’actions prioritaires pour remĂ©dier Ă  certaines problĂ©matiques.

đŸ€žđŸż Nous croisons les doigts pour que ce genre de problĂšme n’arrive plus, mais ce baptĂȘme du feu nous a permis de nous amĂ©liorer !

Nous espĂ©rons que la lecture de ce retour d’expĂ©rience vous aura Ă©tĂ© utile et vous incitera Ă  appliquer des rĂšgles et bonnes pratiques que vous auriez nĂ©gligĂ©es jusque-lĂ  đŸ™đŸ».