⚙️ DevOps — concept, histoire, pratiques, toolchain & KPIs

Objectifs : ce que DevOps optimise vraiment

DevOps vs SRE (complémentaires)

Dans la pratique : DevOps construit les “routes pavées” ; SRE définit les garde-fous fiabilité et le run.

Organisation (ce qui marche)

• Ownership : une équipe produit garde la responsabilité du run (au moins niveau 1), avec support plateforme.
• Plateforme : une équipe “platform” fournit des golden paths (templates, pipelines, observability, auth, IaC modules).
• Self-service : provisionner, déployer, observer sans ticket (avec policy-as-code).
• Blameless : postmortems orientés système, pas personnes.

Release management : “on déploie souvent sans trembler”

Patterns :
- Feature flags (déployer sans activer)
- Canary release (5% → 25% → 100%)
- Blue/Green (switch instant)
- Rollback (version N-1) + roll-forward (fix rapide)
- Database migrations safe (expand/contract)
        

Run : ce que “ops-friendly” veut dire

People : la partie “invisible” mais décisive

• Blameless : on corrige le système, pas les personnes.
• Shared ownership : pas de “mur” Dev/Ops.
• Toil reduction : automatiser ce qui se répète.
• Platform as product : l’outillage interne a un backlog, des SLA, une UX.

Gates (ce qui bloque un déploiement)

Database migrations “safe” (expand/contract)

Pattern expand/contract :
1) Expand : ajouter colonnes/tables compat (nullable, defaults)
2) Deploy app compatible (lit ancien + nouveau)
3) Backfill data (job idempotent)
4) Switch reads/writes (feature flag)
5) Contract : supprimer ancien schéma
=> objectif : zéro downtime, rollback possible
        

Piège : migrations “destructives” au mauvais moment (DROP/ALTER lourds) sans stratégie.

Rollback & recovery (à préparer avant)

Rollback application :
- redeploy version N-1 (artifact immuable)
- revert feature flags
- vérifier SLO

Rollback DB :
- éviter autant que possible (complexe)
- préférer migrations backward-compatible
- snapshots/restore en dernier recours

Toujours :
- runbook + exercice (game day)
        

SLI / SLO / Error budget

SLI = mesure (ex: % requêtes < 300ms)
SLO = cible (ex: 99.9% sur 30 jours)
Error budget = marge d'erreur acceptable

Usage :
- si budget consommé -> freeze features, fiabilisation
- sinon -> on ship
        

Alerting utile (pas du bruit)

• Page uniquement si action immédiate requise.
• Préférer symptom-based (SLO breach) plutôt que cause-based partout.
• Chaque alerte doit avoir : runbook + owner + severity.
• Éviter : alertes CPU sans contexte, “flapping”, seuils statiques ignorants du trafic.

Incident response + postmortem (blameless)

Incident flow :
1) Detect (alert/SLO)
2) Triage (severity, scope)
3) Mitigate (rollback, disable feature, scale)
4) Communicate (status)
5) Resolve (root cause fix)
6) Postmortem (actions préventives + automation)

Postmortem = document système :
- timeline
- contributing factors
- detection gaps
- corrective actions (owner + due date)
        

Supply-chain (ce qui devient critique)

Pratiques :
- SBOM généré (liste deps)
- signature des artifacts (images, packages)
- provenance (build attestations)
- registries privés
- pin versions + allowlist
- mise à jour deps régulière
        

Objectif : savoir “ce qui tourne en prod” et pouvoir patcher vite.

Runtime security (prod)

• Least privilege (IAM minimal, RBAC, service accounts).
• Secrets management (pas d’env vars en clair si possible, rotation).
• Hardening images (base minimal, patch cadence).
• Network policies (segmentation, egress control).
• Audit logs (who did what).

SLO & Run metrics

FinOps (cost/unit)

Mesurer :
- coût par requête / par utilisateur / par job
- coût stockage / logs / traces
- coût des environnements non utilisés

Leviers :
- right sizing
- autoscaling
- retention policies
- budgets + alerting
        

Qualité (signal “long terme”)

• Flakiness tests (%)
• Time-to-detect incidents
• Backlog dette technique (et sa tendance)
• Vulnérabilités ouvertes (âge moyen)
• MTBF (time between failures) si pertinent

Symptômes “ça ne marche pas”

• Déployer prend des heures/jours et nécessite des experts.
• CI rouge en permanence, tests flakey, scripts non maintenus.
• On-call “panique”, pas de runbooks.
• Les incidents se répètent (pas d’actions postmortem).
• La plateforme est évitée (pas d’UX, pas de golden path).

Remèdes (concrets)

1) Mettre un "golden pipeline" standard (template)
2) Imposer parity staging/prod (IaC, versions)
3) Ajouter rollback + progressive delivery
4) Observabilité minimale + runbooks
5) Réduire alert noise (SLO based)
6) Security scanning + secret manager
7) Ownership clair + postmortems actionnables