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à 🙏🏻.