Dis... papa ? 👧

C'est quoi un·e SRE ? đŸ€”

~$ whoami

Denis GERMAIN

width:50 @zwindler

#geek đŸ‘šâ€đŸ’» #SF đŸ€–đŸ‘œ #courseAPied đŸƒâ€â™‚ïž


*Les slides de ce talk sont sur le blog

Dis... papa ? 👧

C'est quoi un·e SRE ? đŸ€”

Pourquoi ce talk ?

"SRE, c'est comme DevOps, non ?"

height:500 height:500

Alors qu'en vrai, c'est plutÎt ça

center width:1100px

Simpsons Against DevOps

Back to basics

"Mais ça, c'était avant !"


center width:800

DevOps

Courant de pensée théorisé ~2008

  • AmĂ©lioration continue sur cycles courts
  • DĂ©ploiements rĂ©guliers, testĂ©s, automatisĂ©s
  • Surveillance de l'exploitation et de la qualitĂ©

center height:220

DORA 👧🐒🎒📜

DORA - Devops Research and Assessment

  • Programme de recherche Google
    • 7 ans / 32000 pros
    • meilleurs "performers"
    • leurs pratiques

Software delivery performance

  • "4 key metrics (+1)"
    • Lead Time
    • Mean Time To Restore
    • Change Fail Percentage
    • Deployment Frequency
    • (NEW) Reliability

DORA DevOps Quick Check

Culture d'entreprise

Les entreprises qui "performent" sont celles qui véhicule une culture de l'information, de l'apprentissage (CoP) et de la confiance (sécurité psychologique, blameless)

High-trust and emphasizes information flow is predictive of software delivery performance and organizational performance in technology

DORA - DevOps Culture

Et Google inventa les SREs

Quel rapport en SRE et Devops ?

DevOps, c'est un ensemble de principes, pas un poste

On peut simplifier DevOps en 2 sujets majeurs :

  • Outillage
  • Culture d'entreprise & "agilitĂ©"

Devops is a bad name. Google may have named it best: SRE. We are the pit crew. We chase the 9's; we are lazy and refuse to do anything manually more than once (reddit "go into DevOps")

Qui a inventé le SRE ? (1/2)

  • Ben Treynor Sloss (VP engineering @Google)

SRE is what happens when you ask a software engineer to design an operations team



Qui a inventé le SRE ? (2/2)

  • 50–60% are Google Software Engineers
  • The other 40–50% are candidates who were very close to the qualifications, and who in addition had a set of skills useful to SRE but is rare for software engineers.

Les principes du SRE

Toil (tears and sweat)

Contrairement aux Ops (sic), un Dev déteste faire des tùches répétitives

  • Travail manuel, rĂ©pĂ©titif, automatisable, sans valeur ajoutĂ©e, augmente linĂ©airement avec la capacitĂ©
  • RĂ©duit le moral des Ă©quipes, pas scalable, cercle vicieux

SRE book - Eliminating toil

RĂ©duire le toil

  • Automatiser les tĂąches rĂ©pĂ©titives
  • DĂ©velopper du tooling interne
  • Documenter (pour l'exploit' & pour l'astreinte)
  • Corriger les problĂšmes de fiabilitĂ© (post-incident)

xkcd/1205

Accepter que ça va casser

Rappel : la disponibilité d'un service se calcule en % sur une période donnée. 99,9% (aka 3 neufs) sur 1 an = 8h d'indisponibilité max

Le risque 0 n'existe pas !

  • Service disponible Ă  100% == impossible
  • Plus t'as de 9, plus c'est cher
  • Au bout d'un moment, les utilisateurs ne voient plus la diffĂ©rence
    • C'est mĂȘme contreproductif !

Un cluster trop resilient

  1. SĂ©curiser RabbitMQ avec un cluster
  2. Les développeurs ne prévoient que des retry sur une courte période
  3. RabbitMQ est down 1h
  4. Les applications tombent en cascade




SRE book - Global Chubby Planned Outage

Observabilité

  • SystĂšme distribuĂ© == systĂšme complexe
    • Difficile d'avoir une vue d'ensemble !
  • Instrumenter les services, au fur et Ă  mesure
  • S'inspirer des 4 golden signals
    • latence, trafic, erreurs, saturation
  • Black box, White box
  • Attention Ă  ne pas tout observer !

Service Level Objectives

  • Le client est-il content (ou pas) d'utiliser le service ?
  • Indicateurs quantifiables sur la fiabilitĂ© du service
    • disponibilitĂ© d'une app, latence d'une page, etc
  • Objectif de fiabilitĂ© du service
    • ex. 99,9% des requĂȘtes HTTP rĂ©pondues en moins de 30 ms

center width:600

Error budgets

MĂ©trique objective qui permet de dĂ©terminer Ă  quel point un service peut ĂȘtre non-fiable pendant une pĂ©riode donnĂ©e :

  • Service accessible 99,9% du temps == j'ai droit Ă  10 minutes de downtime par semaine

(it) removes the politics from negotiations between the SREs and the product developers when deciding how much risk to allow.

J'en fais quoi, moi, de ton Error Budget ?

Contre-intuitivement... IL FAUT L'UTILISER !

  • SLO atteint == prioriser les livraisons
  • SLO pas atteint == pas grave
    • Prioriser tout ce qui amĂ©liore la fiabilitĂ©

Fail fast, fail often
Move fast and break things (width:50)

Blameless postmortems ☠

Rapidement aprĂšs un incident, Ă©crire un postmortem

  • Timeline des Ă©vĂ©nements
  • ComprĂ©hensible et dĂ©taillĂ©e
    • causes, consĂ©quences, investigation, rĂ©solution
  • Actions correctives postĂ©rieures
  • Blameless

Blameless.com - Post-mortems best practices
DanvOps - Comment faire d'un échec un moyen de s'améliorer

Astreinte

Hope for the best, plan for the worst

  • Documenter les services
    • Faire des schĂ©mas d'infra
    • Avoir une vision claire de l'ownership
    • Donner des commandes simples
  • Scenarii Wheel of misfortune / War rooms

Doctolib - First time on call

Pas si faux, finalement

center width:1100px

Simpsons Against DevOps

Dans quel cas ça ne marche pas ?

  • Les Errors Budgets sont une rĂ©ponse organisationelle au problĂšme du mur de la confusion
  • PrioritĂ© aux nouvelles fonctionnalitĂ©s si le service est "fiable"
  • Stakeholders qui n'adhĂšrent pas = intĂ©ret des principes SRE faible

center width:550

OK, c'est comme ça chez Google.

Mais IRL ?

Le bon et le mauvais SRE

  • Ce n'est pas
    • un ingĂ©nieur Java Fullstack Devops
  • Ce n'est pas (juste)
    • un sysadmin qui administre un cluster Kubernetes
    • un dev qui amĂ©liore la CI/CD

memenetes & cyanide and happyness

Une analyse des tĂąches d'un SRE

Points communs dans plusieurs offres d'emploi SRE

  • DĂ©ployer et maintenir l'infrastructure
  • DĂ©velopper du tooling et automatiser le toil
  • GĂ©rer le monitoring / amĂ©liorer l'observabilitĂ©
  • DĂ©finir (ou aider Ă  dĂ©finir) les SLO/SLI/error budgets
  • Etre d'astreinte (et participer aux post-mortems)
  • Diffuser les bonnes pratiques

Spike - SRE 2021 / 30 job postings analysis

Le chemin pour devenir SRE

  • Avoir envie d'aider les Devs
  • Vouloir faire de l'infra (si on et Dev)
  • Ne pas avoir peur du code (si on est Ops)
  • DĂ©tester les tĂąches rĂ©pĂ©titives
  • Connaitre un minimum le cloud et l'outillage "Cloud-native"

Blog Padok - De développeur à SRE
Page reddit - "go into DevOps"

Quelles qualités pour un SRE ?

⚠ Totalement subjectif et probablement biaisĂ© ⚠

  • Aimer apprendre / curiositĂ©
  • Aimer transmettre
  • Etre tenace, voire un peu obstinĂ©
  • Savoir rester rĂ©aliste
  • Faire preuve d'empathie

Maintenant, vous savez !

(ce qu'est un·e SRE 😎)

center

Conclusion

  • MĂ©tier "inventĂ©" par Google
  • Proche de la philosophie DevOps
  • Applicable ailleurs si le top management s'implique
  • Explicitez ce que vous attendez d'un SRE dans les annonces


  • D'ailleurs...
    • Je cherche des collĂšgues, on s'en parle aprĂšs 😉 ?

That's all folks

width:800 center

Des questions ?

center width:500

Sources

Aller plus loin sur le SRE

DevOps

Backup slides

height:50 en quelques chiffres


  • CrĂ©Ă©e en 2007
  • 73M de titres
  • 16M d'utilisateurs actifs
  • ~35k connections par seconde
  • 600 passionnĂ©s (pas que de musique)

Je cherche des collĂšgues !