SRE vs DevOps : quel modèle pour votre organisation ?

Nous entendons souvent : "Sommes-nous une équipe DevOps ou SRE ?" La réponse : ça dépend de votre maturité, votre taille, et vos priorités. Et souvent, vous commencez par DevOps et migrez progressivement vers SRE.

Comprendre la différence est critique pour structurer vos équipes à bon escient.

DevOps : la philosophie

DevOps est une culture et ensemble de pratiques qui rapproche dev et ops.

Objectif : réduire le friction entre développement et production, en donnant aux devs plus de responsabilité opérationnelle.

Caractéristiques :

• Devs et ops travaillent dans une même équipe
• Déploiements fréquents (plusieurs fois par jour)
• Automation de l'infra (Infrastructure as Code)
• Propriété partagée : "You build it, you run it"
• Feedback rapide (logs, métriques centralisées)

Exemple : Une équipe de 8 personnes (6 devs + 2 ops-minded) gère une application end-to-end : code, CI/CD, déploiement, support production.

Avantages DevOps

• Velocity : les devs poussent directement en production, pas d'attente ops
• Ownership : les devs se sentent responsables du code en production
• Cost-effective : une équipe, zéro handoff

Inconvénients DevOps

• À partir d'une certaine scale (> 100 services), c'est difficile à gérer
• Les devs se noient dans l'ops et ne font plus de code métier
• Manque de standardisation (chaque équipe a ses patterns)

SRE : la discipline

SRE = Site Reliability Engineering. C'est une discipline qui applique software engineering à l'opération.

Objectif : rendre la production aussi fiable que possible, sans laisser les devs gérer tous les détails opérationnels.

Caractéristiques :

• Équipe SRE séparée des devs (mais étroitement liée)
• SLOs explicites ("99.95% d'uptime")
• Error budgets (si on dépasse, on ralentit les déploiements)
• Automation de la reliability (pas juste de la rédaction de runbooks manuels)
• Obsession pour toil reduction (éliminer les tâches répétitives)

Exemple : Une équipe platform SRE (10-15 personnes) maintient la plateforme Kubernetes partagée. Chaque équipe produit déploie via GitOps, mais ne gère pas les incidents critiques.

Avantages SRE

• Standardization : patterns uniformes, moins de variabilité
• Expertise : SRE se concentrent sur la reliability, pas dilués dans le code métier
• Scalability : une équipe SRE peut supporter 50+ services
• Incident management : discipline rigoureuse, post-mortems systématiques

Inconvénients SRE

• Coût supérieur (équipe dédiée)
• Risque de silos : "ce n'est pas mon problème, c'est SRE"
• Overhead process (SLO definition, error budget tracking)

Les DORA Metrics : comment mesurer ?

Avant de choisir, mesurez où vous êtes actuellement. Les DORA metrics (définies par Google, popularisées par le "Accelerate" book) sont le standard :

# Mesurer vos métriques DORA

# 1. Deployment Frequency : nombre de merges/semaine
git log --oneline --since="7 days ago" | wc -l

# 2. Lead Time : temps moyen entre commit et deploy
# (nécessite tagging ou CI logs)

# 3. Change Failure Rate : nombre de incidents / nombre de deployments
# (d'un incident tracking system)

# 4. MTTR : durée moyenne des incidents
# (d'un incident tracking system)

Si vous mesurez :

• Deployment Frequency < 1/semaine → DevOps primaire ou SRE non mature
• Change Failure Rate > 30% → Problèmes de testing/stability

SLO, SLI, SLA : les briques de SRE

SLI : Service Level Indicator

C'est une métrique mesurée : "Quel % des requêtes répondent en < 100ms ?"

SLI = (nombre de requêtes complétées en < 100ms) / (nombre total de requêtes)

Exemples :

• Latency : % des requêtes répondant en < X ms
• Availability : % du temps le service est up
• Error rate : % des requêtes réussissant
• Throughput : requêtes par seconde supportées

SLO : Service Level Objective

C'est la cible : "Nous visons 99.5% de disponibilité."

SLO = target pour le SLI

SLA : Service Level Agreement

C'est le contrat : "Nous garantissons 99.9% ou vous êtes remboursé."

SLA >= SLO (on promet moins qu'on peut faire)

Error Budget

Si votre SLO est 99.9% (30-min downtime autorisé par mois), vous avez un error budget de 30 minutes.

Error Budget = (1 - SLO) × temps période
             = (1 - 0.999) × 43,200 min
             = 43.2 min par mois

Utilisation :

• Si vous avez 20 min de downtime ce mois, il vous reste 23 min
• Si vous les épuisez, les déploiements se ralentissent (code review, tests additionnels)
• Cela crée une tension saine entre velocity et reliability

# Exemple Prometheus SLO definition
apiVersion: v1
kind: ConfigMap
metadata:
  name: slo-config
data:
  slo.yaml: |
    apiVersion: v1
    kind: SLOGroup
    metadata:
      name: api-service
    spec:
      serviceName: "api"
      slos:
      - name: "availability"
        description: "% of successful requests"
        target: 0.999
        indicator:
          latencyThreshold: 100ms
      - name: "latency"
        description: "% of requests under 100ms"
        target: 0.95
        indicator:
          latencyThreshold: 100ms

Le choix : DevOps vs SRE

Choisir DevOps si :

• < 20 services
• Équipes < 10 personnes
• Tolérance aux incidents modérée (95-99% acceptable)
• Velocity > Stability
• Peu de dépendances cross-team

Choisir SRE si :

• 50 services

• Équipes > 50 personnes
• Uptime critique (99.9%+)
• Stability ≥ Velocity
• Services dépendants (A → B → C)
• Compliance strict (Tier 1 SLA externe)

Choisir Hybrid si (cas le plus courant) :

• Vous avez actuellement un modèle DevOps
• Vous avancez vers une maturité SRE
• Certaines équipes proches du code (DevOps), d'autres fokus infra (SRE)

Recommandation pour organisations 500+ personnes : Hybrid. Une équipe platform SRE (10-20) maintient l'infra partagée, mais chaque squad produit reste DevOps pour son service.

Architecture recommandée pour 500+ collaborateurs

┌─────────────────────────────────────────┐
│ Platform SRE Team (15 personnes)        │
│ - Kubernetes infra                      │
│ - Database reliability                  │
│ - Observabilité stack                   │
│ - Incident commander                    │
└─────────────────────────────────────────┘
           ↓
┌──────────────────────┬──────────────────────┬──────────────────────┐
│ Squad A (8 devs)     │ Squad B (10 devs)    │ Squad C (6 devs)     │
│ DevOps model:        │ DevOps model:        │ DevOps model:        │
│ - Own their code     │ - Own their code     │ - Own their code     │
│ - Deploy via GitOps  │ - Deploy via GitOps  │ - Deploy via GitOps  │
│ - SLA support from   │ - SLA support from   │ - SLA support from   │
│   Platform SRE       │   Platform SRE       │   Platform SRE       │
└──────────────────────┴──────────────────────┴──────────────────────┘

Éléments partagés maintenu par Platform SRE :

• Kubernetes cluster
• Monitoring/alerting (Prometheus/Grafana)
• Logging (ELK, Splunk)
• Incident management
• On-call rotation pour P1/P2
• Disaster recovery
• Capacity planning

Éléments possédés par chaque Squad :

• Code source
• Déploiements (GitOps/ArgoCD)
• Feature development
• Unit/integration tests
• Backlog

Interface :

• Squad utilise Platform SRE via Slack/runbooks
• Platform SRE escalade dans les incidents critiques
• Weekly alignment meeting
• Shared SLOs, error budgets

Métriques de succès

Après 6 mois d'implémentation SRE, vous devriez voir :

Deployment Frequency   : 1/jour → 2-3/jour
Lead Time             : 3 semaines → 3 jours
Change Failure Rate   : 25% → 10-15%
MTTR                  : 2 heures → 30 min
Toil                  : 50% ops → 20% ops
Developer Satisfaction: +30%

Conclusion

DevOps et SRE ne s'opposent pas. SRE est une évolution de DevOps avec plus de discipline et d'échelle.

À retenir :

• Commencez DevOps (simpler, plus rapide)
• À partir d'une certaine complexité, migrez vers SRE
• Pour 500+ personnes, hybrid est le sweet spot
• Mesurez avec DORA metrics, définissez des SLOs explicites
• Error budgets créent une tension saine velocity ↔ reliability

Hidora aide les organisations à structures leurs équipes selon ce modèle et à implémenter les practices SRE/DevOps correctement.

À lire aussi :

• SLA vs Managed Services : comprendre les modèles de support
• Équipe DevOps : comment éviter le burnout

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert