Concepts SRE

Les pratiques et méthodologies fondamentales du Site Reliability Engineering.

🎯

Service Level Objectives (SLO)

Les SLO sont des objectifs mesurables de fiabilité qui guident les décisions d'ingénierie. Ils définissent ce que "fiable" signifie pour chaque service.

Types de SLO courants

Disponibilité

99.9% uptime mensuel

Latence

p99 < 200ms

Throughput

1000 req/s supportés

Correctness

99.99% données correctes

💰

Error Budget

L'Error Budget est la quantité d'erreurs "autorisées" basée sur votre SLO. C'est un outil de décision qui aligne développeurs et SRE.

SLO
Error Budget/mois
Downtime autorisé
99%
1%
7h 18min
99.9%
0.1%
43min 50s
99.99%
0.01%
4min 23s

✅ Budget OK

Déployez, expérimentez, prenez des risques calculés

❌ Budget épuisé

Freeze des déploiements, focus sur la stabilité

🔧

Toil

Le Toil est le travail manuel, répétitif, automatisable et sans valeur durable. Un objectif clé du SRE est de le réduire à moins de 50% du temps.

Caractéristiques du Toil

🔄 Répétitif

Se reproduit régulièrement

👆 Manuel

Requiert une intervention humaine

⚙️ Automatisable

Pourrait être fait par une machine

📉 Sans valeur durable

N'améliore pas le système

📈 Scale linéairement

Plus de services = plus de toil

Exemples de Toil

  • Répondre manuellement aux tickets de provisionnement
  • Redémarrer des services manuellement
  • Copier-coller des configurations
  • Exécuter des scripts manuellement
🚨

Incident Management

Processus structuré pour répondre aux incidents, minimiser l'impact et apprendre pour éviter les récurrences.

1

Détection

Alerting automatique basé sur les SLI

2

Triage

Évaluer la sévérité et l'impact

3

Mitigation

Restaurer le service ASAP

4

Résolution

Fix permanent du problème

5

Postmortem

Analyse et action items

📝

Blameless Postmortems

Analyse d'incident sans blâme individuel. Focus sur les systèmes et processus, pas sur les personnes. L'objectif est d'apprendre et d'améliorer.

Structure d'un postmortem

  1. Summary: Résumé de l'incident
  2. Impact: Utilisateurs affectés, durée, SLO impact
  3. Timeline: Chronologie détaillée des événements
  4. Root Cause: Cause profonde identifiée
  5. Action Items: Actions pour éviter la récurrence
  6. Lessons Learned: Ce qu'on a appris
🧠

Les humains font des erreurs, les systèmes doivent les tolérer

🔍

Demander "pourquoi" le système a permis ça, pas "qui" l'a fait

📈

Chaque incident est une opportunité d'amélioration

📊

Les 4 Golden Signals

Les 4 métriques essentielles à monitorer pour tout service, selon Google SRE.

⏱️

Latency

Temps de réponse des requêtes (succès ET erreurs)

🚦

Traffic

Volume de requêtes (req/s, sessions, transactions)

Errors

Taux d'échecs (HTTP 5xx, exceptions)

📈

Saturation

Niveau d'utilisation des ressources (CPU, mémoire, I/O)

📊

Capacity Planning & Forecasting

Planification prospective des ressources nécessaires pour supporter la croissance future. Analyse des tendances, projections, et dimensionnement proactif.

Activités

Trend analysis, growth forecasting, what-if scenarios, procurement

Horizons

Court terme (1-3 mois), moyen terme (3-12 mois), long terme (1-3 ans)

Outils

Prometheus, Grafana, CloudWatch, ML forecasting

📚

Blameless Postmortems & Learning Culture

Rétrospectives d'incidents sans culpabilisation. Focus sur systèmes et processus plutôt qu'individus. Extraire des lessons learned et améliorer continuellement.

Blameless - blâmer les gens n'améliore pas les systèmes
Root cause analysis - pourquoi c'est arrivé (pas qui)
Action items - améliorations concrètes
Transparency - partager les learnings avec tous
🔄

Change Management & Deployments

Processus contrôlé pour introduire des changements en production. Minimiser les risques tout en permettant l'innovation rapide.

Types de changements

Standard, emergency, planned maintenance

Stratégies déploiement

Blue-green, canary, rolling, feature flags

Governance

CAB, change windows, rollback plans

👁️

Observability Maturity & Full-Stack Visibility

Au-delà du monitoring traditionnel. Logs + Metrics + Traces pour comprendre n'importe quel incident. Correlation entre les trois piliers de l'observabilité.

The Three Pillars

Metrics (quantitatif), Logs (détail), Traces (causality)

Full-stack

Application, infrastructure, network, security, business

Stack populaire

Prometheus, Loki, Jaeger, ou managed (DataDog, NewRelic)

🌪️

Chaos Engineering & Resilience Testing

Injection délibérée de défaillances en production pour tester la résilience. Identifie les modes de défaillance avant qu'ils ne se produisent réellement.

Types d'expériences

Latency injection, pod kills, network partitions, resource saturation

Principes

Commencer petit, steady state definition, monitoring constant

Outils

Gremlin, Chaos Toolkit, Phaul

💰

Cost-Aware Operations

Optimisation des coûts comme objectif explicite parallèle à la fiabilité. Chaque décision d'ingénierie a une dimension coût.

Balancing

Coût vs performance vs availability - trade-offs explicites

Tactics

Right-sizing, spot instances, reserved capacity, auto-shutdown

Metrics

Cost per request, cost per SLO unit, FinOps dashboards

💻

Observability as Code

Définition de dashboards, alertes, SLOs et runbooks en code versionné. Les configurations observabilité sont reviewées, testées, et deployées comme l'application.

Artefacts

Dashboard definitions, alert rules, SLO configs, runbooks

Benefits

Consistency, auditability, CI/CD integration, version control

Tools

Terraform, Pulumi, Grafana-as-Code, Prometheus rules files

🗄️

Database Reliability & Optimization

Specialization SRE focus sur les databases : backup/restore, replication, failover, query optimization, schema evolution.

Key areas

HA setup, backup strategies, recovery testing, performance tuning

Challenges

Data consistency, failover time, schema changes, capacity

Patterns

Primary-replica, multi-master, sharding, read replicas

☁️

Multi-Cloud & Hybrid Reliability

Opérer de façon fiable sur plusieurs cloud providers ou hybrid on-prem/cloud. Abstractions, federation, et disaster recovery inter-cloud.

Défis

APIs différentes, vendor lock-in, latence inter-cloud

Patterns

Abstraction layers, workload distribution, active-active

Tools

Kubernetes (multi-cloud), Terraform, CloudFormation, Ansible

🤝

Customer SLA Management & Communication

Communication transparente avec les clients sur la fiabilité et les incidents. Gérer les expectations, crédits SLA, status pages.

Components

SLA definition, status page, incident communication, credits/compensation

Messaging

Transparent, timely, honest - même les mauvaises nouvelles

Tools

Statuspage.io, Opsgenie, PagerDuty