SRE culture et principes d'ingénierie

1) Qu'est-ce que la culture SRE

La culture SRE est un ensemble de valeurs et de pratiques qui rendent la fiabilité gérable : les objectifs SLO → les erreurs budgétaires → les risques de changement conscients → la stabilisation rapide → l'apprentissage sur les incidents.
Le paradigme clé : la vitesse ≠ l'ennemi de la fiabilité. La vitesse de sortie est possible lorsque les risques sont dosés et automatisés.

• User-centric : désignons la fiabilité telle que l'utilisateur la voit (SLI/SLO).
• Automation-first : toute action répétée → script/stratégie/contrôleur.
• Blamelessness : les erreurs sont systémiques, nous enquêtons sur les causes, pas sur les gens.
• Data-driven : solutions basées sur des métriques et des budgets d'erreurs.
• Simplicity : mécanismes simples et vérifiables> solutions « magiques ».

2) Principes d'ingénierie de base SRE

1. SLO/SLI et le budget des erreurs sont la base des priorités et de l'alerte.
2. L'incident → la stabilisation → RCA - d'abord les symptômes, puis les causes.
3. Réduire le travail manuel (toil) est l'objectif de ≤ 50 % du temps SRE, avec un temps inférieur.
4. La préparation - « production read.... » est obligatoire avant le trafic extérieur.
5. Simplicité et isolation - moins d'interconnexions, plus de contraintes de radius blast.
6. L'observation par défaut est les métriques/logs/pistes, les widgets SLO, les synthétiques.
7. Les changements sont contrôlés - livraison progressive, mise en place canariale, auto-rollback.
8. Security by design - secrets, accès, audit, privilèges minimaux.
9. Cycles d'apprentissage - drague, jeux de chaos, post-mortem, rétrospectives.
10. FinOps-conscience - « prix de neuf », cost-to-serve, SLO efficace.

3) Rituels et processus

3. 1 Production Readiness Review (PRR)

• SLI/SLO, dashboard et alerts (fast/slow burn).
• Endpoints de santé '/healthz ', '/readyz', '/startupz '.
• Runbook/pleybuk incident, owner/on-call, escalation chain.
• Backups/plan DR, limites de ressources, calculs budgétaires.
• Tests de tolérance aux pannes (indicateurs ficha, scripts rollback).

3. 2 Réunion d'information hebdomadaire SLO

Statut error-budget par service.
Incidents en une semaine, CAPA-Progress.
Risque de sortie : là où le dégagement est autorisé/limité (selon le budget).

3. 3 Post mortem sans charges

Les faits et le temps, l'influence de l'utilisateur qui a aidé/empêché.
Causes systémiques (processus/outils), pas « coupable ».
CAPA spécifique avec les propriétaires et les délais, publicité en interne.

3. 4 Jeux de chaos et de drague

Injections planifiées de défaillances (réseau, OBD, cache, nodules) + SLO cible.
« Game day » : temps de stabilisation, mesure MTTR, ajustement des pleybooks.

4) Alerting et bruit

• Alert only on symptoms : le SLO ou le chemin de l'utilisateur est perturbé.
• Multi-window, multi-burn : canaux rapides et lents.
• Quorum/anti-flapping : retards 'for', suppression en maintenance.
• La part de « CPU> 80 % » est de tels signaux dans les dashboards, pas dans le pager.

• La part active est ≥ 80 %.
• Temps médian-à-ack ≤ 5 minutes (P1).
• Baisse de « Pager fatigue » : ≤ de 1 page de nuit par semaine par ingénieur.

5) Gestion du changement

Progressive delivery: canary → 10% → 25% → 50% → 100%.
Auto-rollback par signaux SLO (erreurs/latence).
Feature-flags et kill-switch au lieu d'une restauration globale.
Change policy by risk: fast lane для low-risk; Le BOU n'est qu'un risque élevé.

yaml steps:
- setWeight: 10
- analysis: { template: "slo-check" } # fail ⇒ rollback
- setWeight: 25
- analysis: { template: "slo-check" }

6) Réduction du toil (travail manuel de routine)

Exemples de sources toil : déchargements manuels, redémarrages, tickets « donnez accès », nettoyage des files d'attente.

• Inventaire des tâches répétables → automatisation/autoservices.
• KPI :% du temps sur toil, « étapes automatisées/incident », « minutes à self-service ».
• Catalogue des services de la plateforme (namespaces, OBD, files d'attente, dashboards, alertes).

7) Observabilité et SLO-premier design

Golden Signals (latency, traffic, errors, saturation).
Cartes SLO dans chaque équipe : objectif, fenêtre, budget, burn-alert.
Drilldown : des métriques aux logs/pistes ; 'trace _ id'dans les logs par défaut.
Synthétique : blackbox + scripts headless (login/deposit/checkout).

8) Gestion de la capacité et résilience

Planification de la capacité : RPS/concurrence ciblée, stock par AZ/région.
Bulkhead/shedding : isolation des pools, défaillance des fonctions secondaires d'abord.
Backpressure et files d'attente : contrôle lag, DLQ, concurrence adaptative.
Failover et DR : RPO/RTO, dri DR régulier.

9) La sécurité dans le cadre de la fiabilité

Secrets : gestionnaire de secrets, accès JIT, audit.
Garde WAF/DDoS sur le périmètre, limites par client/tenant.
PII-minimisation, DSAR/Legal Hold dans les incidents.
Sécurité de la chaîne d'approvisionnement : signature d'artefacts, politique d'images de base.

10) Santé il-colla

Rotations sans « solitaires », fenêtres de repos claires.
Le seuil « réveiller la nuit » est seulement P1/P2 par SLO.
Psychogygien : le déficit de sommeil est enregistré comme un risque opérationnel.
Métriques : Paji/ned, Paji/Ingénieur de nuit, temps de récupération.

11) Métriques de maturité SRE

SLO coverage : proportion de voies critiques avec SLO/alerts ≥ 90 %.
Gouvernement Error-budget : il existe des règles freeze et s'appliquent.
Toil : ≤ 30-40 % du temps, tendance à la baisse.
MTTD/MTTR : médianes en dynamique trimestrielle.
Taux de mitigation automatique :% des incidents d'action automatique.
PRR pass-rate : proportion de sorties qui ont été prêtes.
Postmortem SLA : SEV-1 est un postmortem ≤ 48 heures.

12) Documentation et connaissances

• Runbooks/playbooks (top scripts : 5xx spike, DB lag, Kafka lag, NodeNotReady, TLS).
• Cartes SLO et dashboards.
• Listes de chèques PRR et modèles de communiqués.
• Catalogue des services de la plate-forme et OLA/SLA.
• Matériel didactique : SRE 101, Chaos 101, On-call 101.

13) Anti-modèles

Hero-culture : « sauveteurs » au lieu de fictions systémiques.
Alerting bruyant : CPU/disques dans le pager, des centaines de signaux inutiles.
« DevOps est un être humain » : responsabilité floue, pas de propriétaires.
L'absence de SLO : « garder tout vert » → le chaos de la priorité.
Postmortem retardé et « chasse aux sorcières ».
Des reculs mondiaux sans canaries.
Secrets dans le configo/repo ; pas d'audit des actions.
Observability comme « beaux graphiques » sans signaux activables.

14) Modèles d'artefacts

14. 1 SRE-Charte (fragment)

yaml mission: "Make reliability manageable and economical"
tenets:
- "User - SLI/SLO Center"
- "Automation-first, minimizing toil"
- "Blameless & learning"
governance:
error_budget:
freeze_threshold: 0. 8 # 80% of the budget burned ⇒ release frieze review_cadence: "weekly"
oncall:
paging_policy: "SLO-only, P1/P2 at night"
health_metrics: ["pages_per_week", "night_pages_per_engineer"]

14. 2 Mini-PRR chèque list

• SLI/SLO et burn-alerts personnalisés
• Endpoints de santé et synthétiques
• Runbook/playbook + propriétaire/on-call
• Drapeau Rollback/ficha/canari
• Dashboards de latitude/erreurs/trafic/saturation
• Limites/quotas/guardrails de sécurité
• Plan DR et backup testés

15) Mise en œuvre par étapes (4 sprints)

Sprint 1 - Fondation

Identifier les chemins utilisateur critiques et SLI.
Formuler SLO et lancer burn-alerts.
Entrez le PRR et les playbooks minimaux.

Sprint 2 - Gestion des changements

Canaries, auto-rollback sur SLO.
Opérations self-service, annuaire de services.
Inventaire toil et plan d'automatisation.

Sprint 3 - Cycles de formation

Rituel post mortem, calendrier des jeux du chaos.
Dashboards SLO + incidents, rapports error-budget.

Sprint 4 - Optimisation et échelle

Portefeuille SLO, FinOps « cost per 9 ».
Mise en œuvre de la discipline DR, audit de sécurité.
KPI on-colla, prévention du burn-out.

16) Mini-FAQ

SRE = « réparer tout » ?
Non. SRE gère le système de fiabilité : SLO, alerting, processus, automatisation et formation.

Comment convaincre une entreprise d'investir dans la fiabilité ?
Montrez le ROI : réduction du MTTR, augmentation de la conversion, moins de crédits SLA, en dessous du cost-to-serve, sorties stables.

Ai-je besoin d'équipes SRE distinctes ?
Modèle hybride : SRE stratégique dans la plateforme + embedded-SRE dans les produits critiques.

Résultat

La culture SRE n'est pas un poste, mais une façon de travailler avec le risque : SLO → le budget des erreurs → les changements gérés → l'automatisation → la formation. Fixez les principes, commencez les rituels (PRR, post-mortem, jeux de chaos), retirez le toil, construisez l'observabilité « par défaut » et prenez soin de lui-même. Vous obtiendrez ainsi une vitesse de développement constante, des versions prévisibles et une plate-forme fiable et économique.