Votre meilleur DevOps a démissionné hier. Pas de préavis. Juste un Slack : "Je ne peux plus. C'est insoutenable."
Deux semaines avant, il/elle vous avait dit "ça va". Lors du 1:1 dernier mois, tout semblait normal. Mais en backstage, c'était déjà terminé.
C'est un pattern que nous voyons partout en ce moment. Les équipes DevOps sont en burnout massif. Et contrairement au burnout dans d'autres domaines, c'est particulièrement dangereux, parce qu'une équipe DevOps fatiguée, c'est une infrastructure fragile. Une infrastructure fragile, c'est du downtime. Du downtime, c'est des revenus perdus.
Il faut agir vite.
Reconnaître le burnout DevOps
Le burnout DevOps ne ressemble pas au burnout dans la vente ou le marketing. C'est plus sournois.
Signe 1 : Alert fatigue
Vous recevez 200+ alertes par jour. 95% sont des faux positifs ou du bruit. Votre équipe DevOps apprend à les ignorer. Jusqu'au jour où une vraie alerte passe inaperçue et you have a 2-hour outage.
C'est pas de la malveillance. C'est juste que quand tu vois 10,000 alertes par mois, ton cerveau refuse de les traiter. C'est une protection cognitive.
Signe 2 : On-call impossible
Vous avez une rotation on-call, mais elle n'existe que sur le papier. En réalité, trois personnes répondent aux 90% des incidents. Pourquoi ? Parce que les autres n'ont pas la connaissance ou la confiance pour agir seuls.
Résultat : 3 personnes en sleep deprivation permanente. Les autres se sentent inutiles mais culpabilisent de ne pas "être au niveau". C'est toxique dans les deux sens.
Signe 3 : Cognitive load insoutenable
Un bon DevOps doit connaître : Kubernetes, networking, storage, observabilité, disaster recovery, compliance, sécurité, infra-as-code, CI/CD, multiple cloud providers, databases, queuing systems, etc. Et on attend qu'il/elle soit expert sur tout. Immédiatement.
Quand on demande à quelqu'un de retenir 15+ systèmes complexes dans sa tête, avec des choses qui changent chaque semaine (kubernetes version X.Y.Z a un nouveau bug, Terraform a deprecié cette syntaxe), c'est un overload cognitif.
Le cerveau cède.
Signe 4 : Pas de temps pour améliorer
Votre équipe passe 80% du temps en réaction (incidents, questions urgentes, "peux-tu redémarrer le cluster ?") et 20% du temps en proactif (automation, monitoring, documentation, architecture).
Résultat : les problèmes ne se résolvent jamais. Vous restez sur la même roue de hamster. Après 2-3 ans, l'équipe est exténuée.
Signe 5 : Turnover
Personne ne reste plus de 18 mois. Et ceux qui partent ne parlent plus bien de vous. C'est le canari dans la mine.
D'où ça vient ? (Spoiler : c'est culturel, pas technique)
La tentation facile c'est de blâmer les outils : "Kubernetes est trop complexe, Prometheus est trop hard, notre infra est un legacy chaos."
C'est vrai que c'est compliqué. Mais le vrai problème est organisationnel.
Architecture pas à jour. Vous avez une micro-infra pour une méga-application. Ou l'inverse. Vous essayez de faire Kubernetes quand une VM suffirait. Ou vous stubborn restez sur bare metal alors que le cloud vous sauverait du travail.
Tooling consolidation zéro. Vous avez 5 monitoring tools (Datadog, Prometheus, New Relic, custom scripts). 3 IaC frameworks (Terraform, Ansible, CloudFormation). 2 orchestration layers. C'est chaos.
Ownership flou. Qui est responsible pour le disaster recovery ? Pour la sécurité réseau ? Pour les upgrades Kubernetes ? Si ce n'est pas clair, personne ne dort bien la nuit.
No-SRE mindset. Vous traitez DevOps comme "les gars qui fixent les choses quand ça casse". Pas comme une team stratégique qui doit concevoir pour la résilience et l'automation.
Pas de documentation. Seule une personne sait comment le système marche. Elle est devenue single point of failure. Et elle le sait. C'est anxiogène.
Les solutions réelles (pas du bullshit motivational)
1. Alert triage et silence intelligent
D'abord, arrêtez d'alerter sur du bruit. Ça veut dire :
- Revoir chaque alert rule. Demandez-vous : "Si cette alerte se déclenche à 3h du matin, vais-je vraiment me lever ?" Si non, ce n'est pas une oncall alert.
- Autoresolution smart. Certaines alertes se règlent toutes seules (un pod crash, Kubernetes le redémarre). Ne pas alerter sur ça.
- Seuils corrects. Une DB à 85% CPU n'est pas une urgence. Une DB à 99% CPU qui reste pendant 10 minutes, oui. Les seuils doivent être scientifiques, pas arbitraires.
Target : < 10 oncall alerts par semaine. Si vous êtes à 200 par jour, vous êtes à l'inverse de "reliability", vous êtes à "alarm fatigue".
2. On-call sustainable
Vous ne pouvez pas avoir 3 personnes en rotation si y'a 20 incidents par week. C'est mathématiquement impossible.
Donc deux optionen :
Option A : Réduire les incidents (la bonne)
- Mieux architect (pas de single points of failure)
- Chaos engineering (tester vos défaillances avant qu'elles n'arrivent)
- Observabilité (détecter les problèmes avant qu'un customer les détecte)
Option B : Augmenter la capacité (la moins chère court terme, la plus chère long terme)
- Embaucher plus
- Ou outsourcer to an MSP
Ensuite, rotation decente :
- Minimum 4 personnes en rotation (si 1 est malade, 1 en vacation, tu as toujours 2)
- Max 1 semaine on-call par mois par personne
- On-call hours claires (9h-18h, ou 24/7, clair)
- Compensation pour incidents nocturnes (jour off, prime, peu importe)
Chez les bons SRE shops, on-call c'est un event rare et bien rémunéré. Pas une fatalité permanente.
3. Cognitive load reduction
Ça veut dire : simplifier les systèmes.
Architecture pragmatique :
- Pas de microservices si un monolithe suffit
- Pas de Kubernetes si une VM suffit
- Pas de k3s chez vous si un managed Kubernetes existe
C'est contre-intuitif pour les CTO qui veulent faire cool architecture. Mais un système simple qu'on maîtrise c'est mieux qu'un système cool qu'on combat.
Tooling consolidation :
- 1 monitoring tool principal (Prometheus ou Datadog, pas 5)
- 1 IaC framework principal (Terraform ou Ansible, pas 3)
- 1 incident management tool (PagerDuty ou autre, mais un seul)
Une personne devrait pouvoir apprendre tout le stack en 2 mois, pas 2 ans.
Documentation obligatoire :
- Chaque component doit avoir un README
- Chaque process doit avoir un runbook
- Les décisions architecturales doivent être expliquées (pourquoi Kafka et pas RabbitMQ ? Répondez en écrit)
Quand quelqu'un part, l'infra ne doit pas partir avec lui.
4. Réducible time-to-problem
30% du temps DevOps est dépensé à "figurer out what's wrong". Vous pouvez réduire ça avec :
Observabilité moderne :
- Structured logging (logs JSON, pas du text libre)
- Correlation IDs (tracker un request à travers 10 services)
- Distributed tracing (voir exactement où la latence se passe)
Quand un incident arrive, vous devez répondre en < 5 minutes : "Quel service a crashed ? Pourquoi ? Depuis quand ?" Pas 45 minutes de debug.
Coût : CHF 500-2,000/mois en outils, mais vous économisez 10-15 heures par mois en incident triage.
5. Managed services vs self-managed
Voici une question que vous devez vous poser honnêtement :
Avez-vous vraiment l'expertise et l'envie de gérer Kubernetes 24/7 en production ?
Si non, arrêtez. Utilisez un managed Kubernetes (Hikube.cloud, AWS EKS, GCP GKE). Vous payez 10-20% plus cher mais vous économisez 40% du travail DevOps.
C'est un calcul économique simple : 1 FTE DevOps = CHF 100,000-150,000/an. Managed service = CHF 50,000-100,000/an. Différence : CHF 50,000. Vous payez moins pour avoir meilleur SLA.
De même pour databases, message queues, load balancers, etc. Si y'a une managed option et tu n'as pas une vraie raison de self-host, utilise la managed.
Metrics que vous devez suivre
- On-call incidents par week. Target : < 5 (pour une team de taille normale). Si > 10, quelque chose break.
- Mean time to resolve (MTTR). Target : < 15 minutes pour incidents critiques. Si vous êtes à 45 min, observabilité est faible.
- Percentage time on-call vs proactive. Target : 20% reactive, 80% proactive. Si vous êtes inversé, vous êtes en trouble.
- Team turnover. Vous devez avoir attrition < 15% annuel. Si c'est > 20%, burnout est probable.
- Vacation coverage. Pouvez-vous prendre 2 semaines vacation sans urgency call ? Si non, vous êtes screwed.
En résumé
Le burnout DevOps est réel, il coûte cher (turnover, incidents, mental health), et il vient pas d'un manque de talent de votre équipe. Il vient d'une mauvaise architecture organisationnelle et technique.
Réduire alert fatigue, respectable on-call, cognitive load, simplifier les systèmes, et doubler down sur observabilité, ça marche. Vous allez avoir une équipe stable, confiante, et productive.
Et si vous avez pas le temps ou l'expertise pour faire ça en interne, y'a pas de honte à faire appel à un MSP. Beaucoup d'enterprises de 500+ employés utilisent Hidora pour améliorer justement ça : on prend les responsabilités on-call et optimization, votre team se concentre sur innovation.
Your people are your best asset. Burnout kills that asset. Fix it.
À lire aussi :
Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert
