Postmortem #1 - 27 Juillet

Postmortem #1

Résumé

Dans le cadre de l’analyse du cycle de vie de nos services, nous avons mis en place du monitoring supplémentaire. Celui-ci, par mauvaise configuration de notre part, a rempli le disque racine du serveur sur lequel il tournait, ce qui a fait tomber tous les services de ce serveur.

Durées

Start Time Incident Detected By(User-reported/ Ad-hoc monitoring/ Alerting system)
Detection Time 27/07 21h37 Time to Detect (TTD) 1minute par UptimeRobot
Mitigation Time 28/07 00h42 Time to Mitigate (TTM) 3h05
Resolution Time 28/07 11h39 Time to Resolve (TTR) 14h03

Chronologie

Date/Time Who/What Action/ Impact
27/07 - 18h05 Pierre redémarre le monitoring scaphandre Il est redémarré en mode debug, les logs commencent à s’accumuler
21h37 Serveur k a le disk system plein tous les services du serveur k tombent
28/07 00h42 Tim voit le soucis et nettoie le disk Les services repartent et le container letsencrypt est aussi nettoyé
1h15 Le disk est de nouveau plein de logs Les services retombent
10h13 Le probleme des logs est identifié et nettoyé Les services reviennent
11h20 Un service est toujours manquant, redémarrage du container letsencrypt Tous les certs sont renouvelés, les services retombent
11h39 Tous les certs sont renouvellés Tous les services sont de nouveau stable sur ce serveur.

Impact

Impact sur les utilisateurices

Ce serveur est le dernier de nos serveurs historiques. Il tourne sur libre.sh v1 et donc docker-compose.
Les services ne sont pas redondés sur celui-ci.
Quelques nuages et forum historiques tournent sur ce serveur.
Tous les onlyoffice tournent sur ce serveur et étaient donc partiellement accessible sur la plage de la maintenance.
Et quelques services internes tournent aussi sur ce serveur, comme le support ou le git.

Impact sur l’infrastructure

Les backups de la nuit du 27 au 28 Juillet n’ont pas pu tourner.

Cause de l’incident ?

Déclencheur(s)

Démarrer le service scaphandre en mode debug était une mauvaise idée :slight_smile:

Mitigation & Résolution

Il suffisait de l’éteindre et d’enlever le mode debug.

Leçons apprises

Nous avons alors appris que le container lets’encrypt du serveur k ne persiste pas ses credentials, c’est bien dommage, cela nous aurait évité 20m de downtime supplémentaire.

Ce qui s’est bien passé

A chaque fois que le problème est connu des admin, la résolution intervient quelques dizaines de minutes après.

Ce qui s’est mal passé

  • il ne faut pas démarrer des container trop verbeux
  • il faut persister les creds letsencrypt

Actions

Action Item Type (Mitigate/ Prevent/ Process/ Other) Who Priority Bug # Due Date
Limiter la taille des logs par container Prevent Hugo High :white_check_mark:
Persister les creds letsencrypt Prevent Pierre High :white_check_mark:

C’est un peu technique, mais si vous avez des questions, n’hésitez pas :slight_smile: j’essaierai d’expliquer :slight_smile:

Reboot du serveur pour appliquer les changements décidés cette après-midi.

Le serveur est up et les services redémarrent.

Fin de l’incident.