Skip to content

SRE Book

Part I - Introduction

Approche classique

Traditionnellement, un ops/sysadmin a pour role de faire tourner le service et réagir aux évènements et aux changements.

  • Changements = mise à jour de code, gestion de changements sur la conf
  • Evènements = failure en prod, problèmes de déploiement etc

Plus le système grossit, plus le nombre d'updates et d'évènements augmente => la team sysadmin doit absorber cette charge.

Désavantages:

  • couts directs: actions manuelles pour le traitement des changements et évènements.
  • couts indirects: le fossé se creusent entre dev et ops. Les deux équipes ont un vocabulaire différent, une conception du risque et de la stabilité différentes, ainsi que des objectifs différents (nouvelles fonctionnalités applicative vs stabilité du système en Prod!) .

Conséquences:

  • chez les ops: ralentissement de la prise en charge des changements. On ajoute des checks, des barrières avant de valider les changements.
  • chez les devs: on cherche à contourner les déploiements avec des "flag flips", des "cherrypicks" ou des "mises à jour incrémentales"

Approche SRE

SRE c'est quoi?

SRE: Site Reliability Engineering

Historique: débuts en 2003 chez Google. On donne pour mission à un ingénieur en développement logiciel de diriger une ops team de 7 personnes. L'ops team est formée d'ingénieurs en developpement logiciel majoritairement

Objectif de l'équipe SRE:

  • une équipe qui s'ennuie très rapidement sur les tâches manuelles * une équipe qui possède les compétences nécessaires pour automatiser elle-même leur travail, même quand la solution est compliquée
  • l'équipe doit solutionner ses problèmes par le développement, pas par le recrutement de personnes pour absorber la charge opérationnelle
  • à part ça, l'objectif de l'équipe est le même que n'importe quelle ops team

Règles de l'équipe SRE:

  • 50% du temps doit être passé à développer
  • 50% du temps doit être passé à travailler en opération

Bénéfices observés:

  • innovation rapide
  • l'équipe ops accepte les changements rapides
  • efface le fossé entre dev et ops
  • améliore les équipes produits: les ops communiquent et forment les développeurs par leurs interactions

Difficultés observés:

  • recruter un SRE est difficile, nécessite le double profil développement logiciel + ingénieur système.
  • nécessite un fort support management, car des méthodes peu orthodoxes peuvent être proposées par la team SRE pour corriger durablement des problèmes (ex: convaincre une équipe de stopper toutes ses releases le temps de corriger des defects)

Devops ou SRE?

Devops est une généralisation de SRE

SRE est une implémentation de Devops

Principes

Le fonctionnement d'une équipe SRE est entièrement codifié par des principes et règles d'interaction.

Objectif de ces principes: permettre le focus des équipes sur l'activité d'ingénierie et pas la partie opération

Périmètre de responsabilité de l'équipe SRE:

Chaque point sera détaillé dans cette partie:

  • S'assurer de conserver 50% du temps sur du développement
  • Permettre une vélocité de changements maximale en respectant les SLO
  • Répondre aux incidents via astreinte, tickets etc.
  • Monitoring
  • Gestion des changements
  • Planning de capacité
  • Provisioning
  • Performance applicative

Principes fondateurs

Fonctionnement normal et valve de sécurité:

  • le travail ops de l'équipe SRE est mesuré en permanence
  • quand le travail ops est en excès, il est redirigé aux équipes produits
  • quand la charge ops diminue en-dessous des 50%, la redirection stoppe

Métrique partagée dev/ops:

Rappel: L'équipe produit veut le maximum de vélocité de changement (innovation rapide). L'équipe ops veut la stabilité maximum du produit.

Pour éviter les conflits et avoir une conscience partagée du produit, création d'une métrique partagée par les deux parties: le budget d'erreur (error budget).

Exemple:

  • Le budget d'erreur du produit est 0.01% de disponibilité (99.9% disponible)
  • On se permet donc de prendre des risques (tant que ca reste dans le budget)
  • Les ops s'attendent à des pannes (tant que ca reste dans le budget)
  • Consquences: les deux équipes ont moins peur des pannes, et l'acceptent comme le prix nécessaire à l'innovation.

Importance de la culture d'entreprise

L'entreprise et pas que l'équipe SRE doivent partager les concepts suivants:

L'entreprise doit comprendre et supporter le concept de valve de sécurité. Ainsi l'entreprise tentera d'avoir le minimum d'overflow en créeant des produits qui génèrent peu de charge ops.

L'entreprise doit s'efforcer d'avoir une culture "blame-free": lors des postmortems, on ne pointe pas du doigt les individus et on ne tente pas non plus de minimiser les erreurs pour se "couvrir".

Monitoring

La stratégie de montoring doit aller plus loin que "si la métrique dépasse ce seuil, envoyer un mail". En effet: le mail doit être lu, un humain doit interpréter l'erreur et décider d'une action.

Stratégie SRE: "si la métrique dépasse ce seuil, le système interprète l'erreur et l'humain est notifié lorsqu'il faut prendre une action"

Le système doit être capable de produire les éléments suivants:

Element produit Action à prendre par l'humain
Alerte Action immédiate requise!
Ticket Action requise, mais pas immédiate
Logs Aucune, à lire uniquement si un diagnostic complet est requis

Réponse à incident

Rappel des métriques de panne

  • MTTF: temps moyen entre les pannes
  • MTTR: temps moyen jusqu'à la réparation

Le meilleur moyen de mesurer l'efficacité d'une réponse à une incident est le MTTR (à quelle vitesse l'équipe répare la panne).

Stratégies SRE:

  • enregistrer à l'avance les pannes courantes / best practiques dans un playbook multiplie par 3 le MTTR
  • préparer les ingénieurs à la réponse à incident via des exercices (fausses pannes, disaster/chaos engineering etc)

Postmortems:

  • un postmortem doit être écrit pour tout incident, même s'il n'a pas généré d'astreinte
  • le postmortem doit aller jusqu'à la root cause du problème
  • des actions doivent être assignées pour s'améliorer ou ne plus rencontrer le problème

Gestion des changements

L'auteur observe qu'à Google, 70% des pannes sont dues à la gestion de changement.

Stratégie SRE:

  • Utiliser des déploiements progressifs (canary)
  • Diagnostiquer rapidement et de façon précise le problème
  • Réaliser des rollbacks
  • Ces 3 pratiques doivent être réalisées avec le minimum d'intervention humaine possible (taches répétitives et totalement automatisables).

Planning de capacité

Planning de capacité = s'assurer qu'on est capable de tenir la charge dans le futur.

  • Etre conscient des sources de charge: organique (adoption naturelle du produit), inorganique (campagne marketing, feature importante, évènements extérieurs).
  • Réaliser des tests de charge

Provisioning

En plus du temps pour acquérir plus de capacité, il faut prendre en compte le temps de provisionner les machines, la validation de ces nouvelles machines etc.

Performance applicative

L'utilisation de ressources sur une infra est une fonction de la charge, de la capacité et de la performance applicative. Il est donc logique que l'équipe SRE ait pour responsabilité de surveiller et améliorer la performance d'un applicatifs (ne pas oublier que l'équipe SRE dispose des compétences pour modifier les applicatifs eux-même).

La prod chez Google

TL;DR

Cette section explique la terminologie spécifique Google et les challenges rencontrés par Google au niveau de son infra.

Ils ont par exemple un usage spécifique du mot serveur:

Terminologie Google Signification
Machine Hardware ou VM
Serveur Applicatif qui implémente un service
Rack Groupe d'une dizaine de machines
Cluster Groupe de racks
Datacenter Groupe de clusters
Campus Désigne les datacenters qui sont proches les uns des autres
Borg / Kubernetes Orchestrateur qui gère les taches et alloue dynamiquement les machines aux serveurs
D serveur de fichier partagé disponible sur toutes les machines d'un cluster
Colossus (basé sur D) Colossus est multi-cluster et ajoute réplication + chiffrement
Bigtable (basé sur Colossuss) DB NoSQL qui peut gérer des databases de l'ordre du Pb
Spanner (basé sur Colossus) interface qui permet de query les données Colossus en SQL