- prod-opsgdpr
Le client voulait les données de prod en préprod. J'ai dit non, puis je lui ai donné mieux.
Une demande raisonnable d'un client raisonnable : que la préprod ressemble à la prod, avec de vraies données. Pourquoi ç'aurait été la pire décision de sécurité du projet, comment j'ai dit non sans conflit, et le pipeline de seed anonymisé qui a rendu la préprod plus utile qu'une copie ne l'aurait été.
- prod-opssecurity
Le certificat a expiré en silence, et les scans n'ont jamais cessé
Un cron de renouvellement a tourné chaque nuit pendant des mois sans jamais rien renouveler, à cause d'une seule lettre. Pendant ce temps, le serveur encaissait des milliers de scans et de tentatives de brute-force par jour. Voici ce que CrowdSec a réellement bloqué, les règles nginx qui ont tenu, les ports que je n'aurais jamais dû exposer, et pourquoi Cloudflare est l'étage suivant.
- prod-opsdevops
Les utilisateurs m'écrivaient pour des 500 avant que je les voie
Chaque erreur en production était loguée avec console.error puis mourait dans un fichier de log que personne ne lisait. Les clients étaient devenus mon suivi d'erreurs. Voici comment j'ai branché un suivi compatible Sentry dans Express et React, avec sourcemaps, regroupement, et une seule règle d'alerte qui se déclenche vraiment.
-
Je grepais du JSON en SSH pendant que la production était en panne
Pendant un incident, ma stack d'observabilité était une session SSH, docker logs et grep. Voici le montage à budget zéro qui l'a remplacée sur le même VPS : Uptime Kuma sur les healthchecks que j'avais déjà, Dozzle pour les logs en direct, et l'alerte qui arrive maintenant sur mon téléphone.
- prod-opsdevops
Le push du vendredi qui m'a appris à interdire le commit sur main
Un git push à 18h un vendredi a déployé direct en production, sans test, et a fait tomber l'API. Rien dans le pipeline ne pouvait l'empêcher, parce qu'il n'y avait pas de pipeline. Voici celui que j'ai construit : main protégée, une CI qui lance les tests, des images construites hors du serveur.
-
Des backups de base qui restaurent vraiment : le pgdata que j'ai perdu
J'ai supprimé un répertoire de données Postgres qui vivait dans un bind mount, sans rien derrière. Mon plan de backup, c'était l'espoir. Voici le setup de backup pas cher sur un seul VPS que j'aurais dû avoir, y compris l'étape que tout le monde saute.
-
Docker n'a jamais redémarré ma base : le prix de restart: no
Un conteneur est mort la nuit et rien ne l'a relancé, parce que chaque service était en restart: no. Les healthchecks que j'avais ne pouvaient pas aider, et la raison surprend la plupart des gens.
-
Les tests étaient déjà écrits. Rien ne les a jamais lancés.
Une régression est arrivée en production, et le test qui l'aurait attrapée était déjà dans le repo. Il n'y avait aucun script de test, et le seul workflow CI ne se déclenchait jamais sur un push. Comment j'ai câblé tout ça.
-
Docker a contourné mon pare-feu : le port de la base était ouvert sur internet
Mon pare-feu bloquait le port 5432. Il était joignable depuis internet quand même, parce que Docker écrit ses propres règles iptables que vos règles INPUT et ufw ne voient jamais. Pourquoi, et comment vraiment le fermer.
-
Le docker build qui a rempli le disque et fait tomber la production
La production est tombée sans changement de code. La cause : un docker compose build qui orphelinait une nouvelle image <none> à chaque déploiement jusqu'à remplir le disque. Ce qui l'a vraiment vidé, et le vrai correctif.
-
Faire tourner un SaaS sur un seul VPS avec Docker Compose : l'audit honnête
Tout le produit tourne sur un seul VPS derrière un docker-compose.yml. Voici pourquoi c'était le bon choix au lancement, et la carte honnête de chaque point de défaillance unique qu'il cache.