Fondamentaux de la collaboration en exploitation¶

Comprendre l'historique des silos, les principes DevOps et SRE, et la responsabilité partagee.

Le mur de la confusion¶

Pendant des decennies, les organisations ont séparé strictement les équipes de développement et d'opérations. Les devs livrent une application "par-dessus le mur", les ops la font tourner sans en connaître les entrailles. Résultat : chaque camp optimise ses propres objectifs au detriment de l'ensemble.

graph LR
    subgraph Avant
        D1["Dev\n(livrer vite)"] -->|"mur de la confusion"| O1["Ops\n(stabilite avant tout)"]
    end
    subgraph Apres
        D2["Dev"] <-->|"collaboration continue"| O2["Ops"]
        D2 <-->|"responsabilite partagee"| P2["Prod"]
        O2 <-->|"feedback loop"| P2
    end

Problèmes engendres par les silos¶

• Les bugs de production remontent vers les devs sans contexte
• Les ops bloquent les déploiements pour limiter les risques
• Le blame circule entre équipes sans résolution systematique
• Le temps de mise en production s'allonge (mois, voire trimestres)
• La fiabilité se dégradé car personne n'a de vision globale

DevOps : principes CALMS¶

DevOps n'est pas un outil ni un titre de poste. C'est un ensemble de principes culturels et organisationnels.

Le modèle CALMS¶

Ce que DevOps n'est pas¶

• Un titre de poste "DevOps Engineer" qui reabsorbe les silos
• Un outil ou une suite logicielle
• Uniquement du CI/CD ou de l'infrastructure-as-code
• Une transformation qui se fait en quelques semaines

SRE : l'implémentation de DevOps par Google¶

Le SRE (Site Reliability Engineering) est une discipline créée par Google pour résoudre à grande échelle les problèmes que DevOps pose en théorie.

Principes fondamentaux du SRE Book¶

• Éliminer le toil : les tâches opérationnelles manuelles repetitives doivent être automatisees
• Error budgets : la fiabilité est un curseur entre rapidité et stabilité, pas un objectif absolu
• Toil cap : les SRE ne passent pas plus de 50% de leur temps sur du toil
• Postmortems blameless : chaque incident devient une source d'apprentissage systematique
• SLO/SLI/SLA : la fiabilité se mesure avec des indicateurs objectifs partagés avec le business

Comparaison des modèles¶

"You build it, you run it"¶

Ce principe, popularise par Werner Vogels (CTO d'Amazon), signifie que les équipes qui developpent un service sont egalement responsables de son exploitation en production.

Implications concrètes¶

• L'équipe est d'astreinte pour son propre service
• Elle reçoit les alertes, elle géré les incidents de premier niveau
• Elle voit directement l'impact de ses choix techniques en production
• Elle est incitee a investir dans la fiabilité, l'observabilité et l'automatisation

Conditions de succès¶

L'ownership ne fonctionne que si l'équipe dispose des outils et de l'autonomie nécessaires :

• Accès aux logs, métriques, traces en production
• Capacité de déployer et de rollback sans passer par un autre silo
• Runbooks clairs et à jour pour les scenarios d'incidents courants
• Soutien de l'organisation : l'on-call doit être soutenable, pas epuisant