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 
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 |  |
|
| Persister les creds letsencrypt | Prevent | Pierre | High | |
C’est un peu technique, mais si vous avez des questions, n’hésitez pas j’essaierai d’expliquer