[post-mortem] serveur de courriels hors-service

Marien / le 11 mars 2021

Suite à l’incendie d’hier chez OVH, le serveur de courriels utilisé par Flus a été mis hors-service. Même si l’impact a été minime pour le service, je voulais prendre le temps de revenir sur l’incident et en tirer des conclusions. Je crois que cet exercice vous permet également de savoir où vous mettez les pieds en vous inscrivant sur Flus. En plus, c’est assez plaisant à faire 😊

Chronologie

  • 1h50 : premier SMS du service de monitoring m’indiquant qu’un premier serveur ne répond pas
  • 2h34 : second SMS pour m’indiquer qu’un second serveur (celui de courriels) ne répond pas (moi je dors à cette heure-ci hein 😴)
  • 3h42 : Octave Klaba annonce l’incendie sur Twitter
  • 7h30 : je me lève et vois les SMS, je ne m’inquiète pas immédiatement
  • 9h00 : je me connecte au PC et vois rapidement le message Twitter, je fais le lien avec les SMS reçus pendant la nuit
  • 9h05 – 9h40 : vérification du fonctionnement des différents services que j’héberge, désactivation de la vérification par courriel de flus.io car bloquant lors de la phase d’inscription
  • 9h43 : annonce de l’incident sur status.flus.io et relai sur les réseaux sociaux
  • 9h59 : commande d’un nouveau serveur chez Hetzner pour réinstaller un serveur de courriels
  • 10h00 – 11h40 : réinstallation du système avec Ansible, récupération et mise en place du backup du serveur de courriels
  • 11h40 : premier test de fonctionnement du serveur ok
  • 11h45 – 12h15 : changement configuration des DNS pour pointer vers le nouveau serveur, modification de la configuration des applications Flus pour utiliser celui-ci
  • 12h15 : annonce que les services sont à nouveau opérationnels sur status.flus.io, et relai sur les réseaux sociaux
  • 12h20 – 13h00 : modification DNS et configuration des autres applications que j’héberge personnellement
  • 13h10 : je vais manger ! 🍴

Ce qui s’est bien passé

  • je n’ai pas paniqué (important ça !)
  • j’ai immédiatement cherché à mitiger ce qui pouvait être cassé (ex. les inscriptions sur flus.io)
  • du point de vue du service Flus, rien de critique n’a été touché
  • je pense avoir communiqué comme il fallait, là où je le devais/pouvais
  • la remise en service du serveur a été plutôt rapide
  • le monitoring a fonctionné : malgré les courriels HS, j’ai reçu les SMS au bon moment
  • le monitoring, bien que chez OVH, n’était pas installé à Strasbourg, ouf !
  • les backups ainsi que mes scripts Ansible étaient opérationnels, pas de gros souci à déplorer
  • les backups dataient de la nuit même, à 1h du matin, soit une heure avant la coupure du service
  • ma documentation pour réinstaller le serveur était plutôt correcte et accessible (là aussi, sur un serveur OVH non impacté)

Ce qui s’est moins bien passé

  • je n’ai pas réagi en voyant les SMS : j’étais habitué pendant un temps à recevoir des faux-positifs et donc à prêter moins attention à ces alertes (clairement une erreur de ma part)
  • je n’avais pas de procédure bien établie en cas d’incident, je me suis senti perdu au début
  • la documentation technique pour relancer le service était éparpillée : les différentes parties se trouvaient là où elles devaient être, mais j’ai manqué d’un document pour faire le lien entre elles
  • il y avait quelques petites erreurs dans la documentation : rien de grave, mais ça ajoute de la charge mentale au mauvais moment
  • tout ça fait que j’ai été assez lent au démarrage, j’aurais pu être plus réactif
  • je suis parti sur la solution de changer l’hôte au niveau DNS, alors que j’aurais pu faire pointer l’ancien hôte sur la nouvelle adresse IP (c’était plus ou moins assumé dans la précipitation, mais je voulais faire ce changement il y a quelque temps et c’était une occasion)
  • l’installation du système n’est pas entièrement automatisé, notamment la création des utilisateurs et la configuration SSH
  • j’ai eu de la chance que la documentation technique et le monitoring ne soient pas touchés

Conclusion

Dans l’ensemble je crois m’en être assez bien sorti, la plupart de choses mises en place ont fonctionné comme prévu. Il me reste toutefois quelques actions à prendre :

  • écrire une procédure en cas d’incident (je m’en occupe juste après la publication de ce post-mortem) et faire le lien entre les différentes parties de documentation technique
  • faire en sorte que la documentation technique critique soit dupliquée, idéalement hors-ligne
  • refaire une passe sur la documentation technique, exécuter les commandes dans l’ordre pour vérifier qu’elles sont correctes
  • mieux me former à Ansible, améliorer mes scripts et compléter ce qui peut être automatisé
  • augmenter la fréquence des backups en fonction de la charge système
  • considérer la réplication du service de monitoring
  • changer mon « conditionnement mental » pour ne plus ignorer les SMS venant du monitoring
  • en cas de faux-positifs, il faudra que je corrige immédiatement l’erreur pour qu’elle n’arrive plus (ce qui a déjà été fait pour les faux-positifs précédents)

retourner au carnet