~$ whoami

Denis GERMAIN

@zwindler(@framapiaf.org)

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


*Les slides de ce talk sont sur le blog

Pourquoi ce talk ?

"SRE, je connais, c'est comme DevOps !"

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

center

Simpsons Against DevOps

Back to basics

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


center

DevOps

Courant de pensée théorisé ~2008 (Patrick Debois)

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

center

DORA 👧🐒🎒📜

  • Pour moi DevOps c'est ... ?
    • Outillage
    • Culture d'entreprise & "agilitĂ©"

Software delivery performance

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

DORA DevOps Quick Check

Culture d'entreprise

Performers : culture de l'information, de l'apprentissage (CoP) et culture de la confiance (sécurité psychologique, blameless)

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

Pourquoi DevOps ne tient pas ses promesses ? (GĂ©rĂŽme Egron et Guillaume Mathieu) / DORA - DevOps Culture

Et Google inventa les SREs

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

  • Ben Treynor Sloss (VP engineering @Google)
  • 2003 (bien avant DevOps !)

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



SRE book - Introduction

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.

SRE book - Introduction
Class SRE implements DevOps (playlist YouTube)

Les principes du SRE

Toil (tears and sweat)

Contrairement aux Ops (sic), les Devs détestent 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
    • ops & astreinte
  • Corriger les problĂšmes de fiabilitĂ© (post-incident)

xkcd/1205: Is It Worth the Time?

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 !

Astreinte

  • 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, Chaos engineering, ...

Doctolib - First time on call

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
  • et surtout...

How to Fight Production Incidents?

Les principes du SRE (suite)

Ok, mais c'est quoi la diff avec sysadmin ?

Accepter les pannes comme "normales"

100% is the wrong reliability target for basically everything
-- Ben Trainoy Sloss

  • Plus on veut de 9, plus ça demande des efforts (e^)
    • les utilisateurs ne voient plus la diffĂ©rence
    • temps d'ingĂ©nierie pas allouĂ© aux fonctionnalitĂ©s
    • parfois c'est mĂȘme contre-productif !

SRE book - Global Chubby Planned Outage

BLAMELESS postmortems ☠

  • Blameless (consĂ©quence de "accept failure as normal")
  • "sĂ©curitĂ© psychologique"




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

Site Business Reliability Engineer

Est ce que le client est content d'utiliser le service ?

  • = % utilisateurs trouvent le service fiable

center

CUJ / SLI / SLO

If reliability is a feature, how do you prioritize it instead of other features?

  1. DĂ©terminer des "Critical User Journey"
  2. SLI: Indicateurs sur la fiabilité du service (dispo, latence)
  3. SLO: Objectif de fiabilité du service (ex. 99,9% < 30ms)

Practical Guide to setting SLOs / SLOs at BlaBlaCar / métriques S.M.A.R.T.

Error budgets

On inverse la logique de la disponibilité

  • Service accessible 99,9% == inaccessible 0,1% du temps

Une mĂ©trique objective qui permet de dĂ©terminer Ă  quel point un service peut ĂȘtre non-fiable pendant une pĂ©riode donnĂ©e sans que ça n'impacte le business

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

Contre-intuitivement... IL FAUT L'UTILISER

  • SLO atteint ⇔ utilisateurs contents (!!!)
    • Faire les interventions disruptives
    • Faire des tests "risquĂ©s", chaos eng., etc.
  • SLO pas atteint ⇔ pas grave
    • Prioriser tout ce qui amĂ©liore la fiabilitĂ©

Pas si faux, finalement

center

Simpsons Against DevOps

Et IRL, ça se passe comment ?

Dans quel cas ça ne marche pas ?

  • Les Errors Budgets sont une rĂ©ponse organisationnelle
  • PrioritĂ© aux nouvelles fonctionnalitĂ©s si le service est "fiable"
  • Stakeholders qui n'adhĂšrent pas = intĂ©ret des principes SRE faible

center

Ce qu'on attend d'un SRE

  • DĂ©ployer et maintenir l'infrastructure
  • DĂ©velopper (tooling /rĂ©duire toil)
  • Diffuser les bonnes pratiques
    • Monitoring / observabilitĂ©
    • DĂ©finir (ou aider Ă  dĂ©finir) les SLO/SLI/error budgets
  • Être d'astreinte (+ post-mortems)

Spike - SRE 2021 / 30 job postings analysis / memenetes

Quelle "personnalitĂ©" pour ĂȘtre SRE ?

⚠ Totalement subjectif et probablement biaisĂ© ⚠

  • Vouloir faire de l'infra (si on est Dev)
  • Ne pas avoir peur du code (si on est Ops)
  • DĂ©tester les tĂąches rĂ©pĂ©titives (👋 Ben Treynor Sloss)
  • Être tenace, ...
    • ... mais savoir rester rĂ©aliste !
  • Aimer transmettre / communiquer, faire preuve d'empathie

Quelles compétences ?

  • Linux & les bases en rĂ©seau
  • 1 langage & git
  • 1 cloud provider
  • 1 outil d'automatisation / IaC
  • 1 outil de monitoring
  • Quelques outils "Cloud-native"

Padok - De dev Ă  SRE / Reddit - "go into DevOps" / Roadmap to DevOps / Tweet Anas Khan

Conclusion

Conclusion

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

@zwindler
Slides sur blog.zwindler.fr

Sources

Aller plus loin sur le SRE

DevOps