Auteur: Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, et al.

Année de parution: 2016

Éditeur: O’Reilly

Lien vers mes notes manuscrites numérisées

Lien pour acheter ce livre

Vous pouvez aussi entièrement consulter le livre gratuitement (et légalement!) en ligne

J’ai récemment décidé d’essayer quelque chose avec mes reviews de lecture: commencer à écrire en français, quel que soit la langue originale du livre. Précédemment, j’assumais qu’il était toujours mieux de commenter une œuvre dans le même langage que j’ai effectué ma lecture. Toutefois, cela peut être handicapant. En effet, j’aimerais continuer à améliorer mon écriture en français, que j’ai un peu délaissé dans les dernières années, notamment dû à cette règle non écrite. Écrire en français, peu importe le langage de la source, me permet d’améliorer mon français, tout en exposant des sujets parfois non traduits dans ma belle langue natale.

C’est un test, on verra si ça tient la route à long terme. On se lance!

Site Reliability Engineering, c’est toute une brique. Ce livre me hante depuis 2018, l’année où j’ai découvert l’univers DevOps. Il fait partie d’un trio de livres publiés autour de 2015 qui sont, selon ma compréhension, devenus des incontournables du domaine:

Pourquoi ai-je choisi de lire ce livre maintenant?

J’ai choisi de lire ce livre pour plusieurs raison. La première, évidente, est que je ne voulais pas laisser un livre me donner l’impression que je tolère mes faiblesses connues. Armé de mon système d’apprentissage, je savais que je serais maintenant en mesure d’extraire tout le jus utile de ce livre.

En 2025, ma situation est différente de celle qu’elle était en 2018. Je ne suis plus un développeur DevOps. Je suis maintenant un scrum master qui accompagne, entre autres, une équipe responsable de la plateforme de développement interne de la compagnie (“DevOps”, bien que je préfèrerais largement dire “Site Reliability Engineers”, surtout après la lecture de ce livre).

Quand j’ai rejoint la compagnie, Laurent, notre coach agile, m’a recommandé la lecture de trois livres afin de bien me remplir la tête d’idées utiles:

Ainsi, j’avais vraiment envie d’enfin mettre ce livre derrière moi, afin d’enfin pouvoir affirmer avec confiance et simplicité: “Oui! Je l’ai lu!”

Maintenant, le vrai test: qu’en ai-je appris? C’est ce que nous explorerons pour le reste de ce review.

De quoi parle le livre dans son ensemble?

Ce livre est un recueil de chapitres qui s’apparentent à des articles. En fait, certains chapitres ont directement été publiés sous forme d’articles par le passé. Le grand thème est la pratique “Site Reliability Engineer” née chez Google suite aux requis extraordinaires qu’ils ont dû atteindre pour satisfaire leurs milliards d’utilisateurs. Ce livre permet donc de lever le rideau sur leurs pratiques afin de s’en inspirer dans nos propres entreprises.

Chaque chapitre a été écrit par des auteurs différents. On traite de Site Reliability Engineering sous tous ses angles. Pour résumer simplement, le Site Reliability Engineering est un ensemble de techniques visant à assurer la fiabilité d’un service web à un niveau qui satisfait juste assez les utilisateurs. Ne pas être fiable fait fuir les utilisateurs, mais être trop fiable coûte si cher en temps et en argent qu’il empêche systématiquement l’innovation.

Que dit-on en détail, et comment?

  • Que sont les “error budgets”, et comment permettent-ils l’innovation?
  • Que sont les Service Level Indicators (SLI), Service Level Objectives (SLO), Service Level Agreements (SLA)
  • Comment distribuer les rôles lors d’un incident
  • Comment rédiger un rapport d’incident
  • Comment former un Site Reliability Engineer
  • Comment configurer un réseau pour assurer sa fiabilité dans “le vrai monde”
  • …

Les sujets traités sont autant vaste qu’en profondeur. C’est une mine d’or pour le lecteur patient, ou l’ingénieur qui saura s’orienter dans la table des matières.

Qu’est-ce que j’ai appris?

Voici, en vrac, quelques idées que j’ai retenues comme intéressantes.

(p. 30) Example of cost/benefit analysis for availability improvement: - Proposed improvement in availability target: 99.9% -> 99.99% - Proposed increase in availability: 0.09% - Service revenue: 1M dollars - Value of improved availability: $1M * 0.09% = 900

If the cost of improving availability by 0.09% is < 900 dollars, it is worth the investment. If the cost > 900 dollars, the costs will exceed the projected increase in revenue.

Assumant qu’un service ne peut jamais être disponible à 100% (c’est une asymptote qu’on approche, par exemple 99.99999%), le gain monétaire d’ajouter un 9 après la virgule peut être calculé. On constate avec l’exemple ci-haut qu’il faut qu’un service soit extrêmement rentable pour qu’il vaille la peine de le rendre stable à 99.99% du temps.

Ce calcul simple mais un peu contre-intuitif permet de calculer la valeur d’un gain en disponibilité de service. Il permet rapidement de prendre une décision qui nous évitera de dépenser plus que nécessaire.

(p. 43) To save effort, build a set of reusable SLI templates for each common metric, for example:

Characteristic Example value
Aggregation intervals Averaged over 1 minute
Aggregation regions All the tasks in a cluster
How frequently measurements are made Every 10 seconds
Which requests are included HTTP GETs from black-box monitoring jobs
How the data is acquired Through our monitoring, measured at the server
Data-access latency Time to last byte

Les SLIs permettent de mesurer l’atteinte des SLOs. Or, la mesure d’un SLI doit être précise et sans ambiguïté. J’ai aimé ce template qui peut être utilisé comme base afin de définir notre propres SLIs.

(p. 60) The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on those four:

  • Latency: The time it takes to service a request. It’s important to distinguish between the latency of successful requests and the latency of failed requests; a slow error is even worse than a fast error.
  • Traffic: Usually HTTP requests per second, perhaps broken out by the nature of the requests
  • Errors: Explicit (500), Implicit (200 returns wrong content), or by policy (> 1 second wait = FAIL)
  • Saturation: Memory, CPU, …

Je dois l’avouer, le monitoring, ce n’est pas vraiment mon fort. J’adore regarder des graphiques et voir l’état de mon service, mais je n’ai jamais été fan du travail requis pour créer ces graphiques et les rendre fiables.

Or, j’aime ce modèle des 4 Golden Signals qui me permettent de voir plus clair les différentes catégories de choses à mesurer. Ce sera utile quand viendra le temps de réfléchir comment visualiser l’état de nos services.

How long you can you work on making a routine task more efficient before you’re spending more time than you save: https://xkcd.com/1205

Je ne connaissais pas ce XKCD! Je l’ai trouvé bien sympathique. En résumé, c’est une grille qui permet de calculer le maximum de temps qu’on devrait investir pour automatiser une tâche qu’on effectue à intervalles réguliers.

(p. 73) The self-professed nirvana of SRE: to automate ourselves out of a job.

Je trouve cette phrase sympathique. Je ne sais pas à quelle point elle peut tenir dans le vrai monde, surtout à une époque où l’IA menace les emplois et l’économie n’est pas favorable pour les travailleurs. Ce livre a été écrit à une autre époque! Reste que je comprends l’esprit de cette phrase. On veut automatiser notre travail, afin de pouvoir pousser encore plus loin l’amélioration de ces choses qu’on ne trouve jamais le temps de faire, tout cela dans le but de maximiser l’efficacité de notre offre à nos utilisateurs.

Voici d’autres notions intéressantes, présentées dans le même ordre qu’elles apparaissent dans le livre:

(p. 127) Limiting the number of engineers in the on-call rotation ensures that engineers do not lose touch with the production systems.

(p. 128) Adequate compensation needs to be considered for out-of-hours support. Google offers time-off-in-lieu or straight cash compensation, capped at some proportion of overall salary. The compensation cap represents, in practice, a limit on the amount of on-call work that will be taken on by any individual. This compensation structure ensures incentivization to be involved in on-call duties as required by the team, bu also promotes a balanced on-call work distribution and limits potential drawbacks of excessive on-call work, such as burnout or inadequate time for project work.

(p. 132) Google has a company-wide annual disaster recovery event called DiRT (Disaster Recovery Training) that combines theoretical and practical drills to perform multiday testing of infrastructure systems and individual services.

J’aime beaucoup cette idée de faire un DiRT par année avec l’ensemble de la compagnie. Par le passé chez nesto, j’ai eu la chance de participer à un tel exercice avec l’équipe DevOps + sécurité. Nous avions simulé un incident de ransomware sur papier et tableau blanc, et c’était intéressant de réellement réfléchir à savoir lesquels de nos systèmes étaient “sauvables”, qui était disponible pour nous aider, quelles méthodes on pensait utiliser dans quel ordre, qui avait les connaissances requises, etc.

Un exemple du genre de questions qu’on doit se poser durant ce genre d’exercice apparaît ci-dessous:

(p. 159)

  • What is the building power fails?
  • What if the network equipment racks are standing in 2 feet of water?
  • What if the primary datacenter suddenly goes dark?
  • What if someone compromises your web server?
    • What do you do?
    • Who do you call?
    • Who will write the check?
    • Do you have a plan?
    • Do you know how to react and how systems react?
    • Could you minimize the impact if it happened now?
    • Could the person sitting next to you do the same?

Passons à un autre sujet,

(p. 150) Example of a structured log:

{
    "Timestamp": "2021-07-27 14:52:55.1623",
    "Level": "Info",
    "Message": "New report created",
    "UserId": "4253",
    "ReportId": "4567",
    "Action": "Report_Creation",
}

Je ne suis pas un expert en logging et monitoring, alors j’apprécie beaucoup les exemples de bonnes pratiques faciles à adopter dans ce domaine. Cette structure permet de standardiser les messages au sein d’une équipe ou d’une organisation qui travaille sur une application. Ça permet de plus facilement trouver ce qu’on cherche par la suite.

Gestion d’incident

Je suis passioné par tout ce qui touche la gestion d’incident. J’aime imaginer des scénarios d’incident où tout le monde connait son rôle à l’avance et que ce soit cet avantage qui permette d’atteindre le succès.

Ci-dessous on décrit les rôles typiques à distribuer lors d’un incident. Cela a du sens, et j’ai déjà utilisé une structure similaire dans les équipes où j’ai travaillé.

(p. 163) Roles to delegate as part of an incident:

  • Incident commander
    • holds high-level state of the incident
    • assigns responsibilities based on need/priority
    • holds all undelegated positions by defualt
    • removes roadblocks if appropriate
  • Operation team
    • Should be the only group modifying the system during an incident
  • Communication
    • Public face of the incident
    • Issues periodic updates to the incident response team and stakeholders (via email)
    • May include keeping the incident document accurate and up to date
  • Planning (longer term issues)
    • Filing bugs
    • Ordering dinner
    • Arranging handoffs
    • Tracking how the system has diverged from the norm so it can be reverted once the incident is resolved

C’est important de savoir quand déclarer un incident!

(p. 166) Set clear conditions for declaring an incident, for example:

  • Do you need to involve a second team in fixing the problem?
  • Is the outage visible to customers?
  • Is the issue unsolved even after an hour’s concentrated analysis?

If yes to any of these, probably an incident.

Plus important encore que de savoir déclarer quand un incident a lieu est de savoir quand il est nécessaire d’écrire un postmortem à son sujet. C’est cette bonne pratique qui nous permet d’apprendre en tant que groupe, mais aussi en tant qu’individus. Bien sûr, on ne peut pas tout documenter dans la vie, mais quand les choses tournent mal, c’est le meilleur moment pour le faire. On ne sait jamais quand l’histoire va décider de se répéter, et ce genre d’information s’avère souvent extrêmement précieuse par la suite:

(p. 170) Common postmortem triggers include:

  • User-visible downtime or degradation beyond a certain threshold
  • Data loss of any kind
  • On-call engineer intervention (release rollback, rerouting of traffic, etc.)
  • A resolution time anove some threshold
  • A monitoring frailure (which usually implies manual incident discovery)

Quand on écrit un postmortem, il est important qu’il soit sans blâme. On fait tous des erreurs dans la vie, et parfois certaines de ces erreurs vont avoir un impact négatif à grande échelle. La clé est de ne pas démoniser ceux qui font des erreurs, sinon ils vont commencer à les cacher, ce qui va nuire à notre capacité d’apprendre collectivement. Mieux vaut accepter l’erreur, en refusant qu’elle arrive à nouveau.

Le phrasage dans un postmortem peut faire toute la différence du monde. Voyez ci-dessous qu’il est possibe de véhiculer la même information avec (pointing fingers) et sans blâme (blameless):

(p. 171)

Pointing fingers Blameless
“We need to rewrite the entire complicated backend system! It’s been breaking weekly for the last three quarters and I’m sure we’re all tired of fixing things onesy-twosy. Seriously, if I get paged one more time I’ll rewrite it myself…” “An action item to rewrite the entire backend system might actually prevent these annoying pages from continuing to happen, and the maintenance manual for this version is quite long and really difficult to be fully trained up on. I’m sure our future on-callers will thank us!”

Un schéma de postmortem facile à utiliser. La prochaine fois que vous souhaitez discuter d’un incident dans le but d’en apprendre quelque chose, je vous recommande de partir de ce schéma et de documenter chaque section du mieux que vous pouvez.

(p. 175) Postmortem template (full example

  • Date
  • Authors
  • Status: action items in progress? complete?
  • Summary
  • Impact
  • Root causes
  • Trigger
  • Resolution
  • Detection
  • Action items
  • Lessons learned
    • What went well
    • What went wrong
    • Where we got lucky (near misses)
  • Timeline
  • Supporting information

(p. 290) No asynchronous distributed consensus algorithm can guarantee progress in the presence of an unreliable network.

J’aime mettre de l’emphase sur cette phrase compliquée qui représente pour moi le fait que le Site Reliability Engineering, c’est une science à part entière.

(p. 346) The factors of data integrity failure modes

Root cause Scope Rate
User action Wide Big bang, instant
Operator error Narrow, directed Slow and steady
Application bug
Infra defect
Hardware fault
Site disaster

In total, there are 24 combinations of types of data failures. An effective restore plan must account for any of these failure modes occurring in any combination.

Personne n’aime les incidents de pertes de données. Or, je n’étais pas conscient qu’on pouvait les classifier en 24 catégories distinctes, basées sur trois modes d’échec. Cette catégorisation pourrait permettre une meilleure communication quand vient le temps d’expliquer à quelqu’un le type d’incident auquel on doit faire face.

(p. 393) A blueprint for bootstrapping an SRE to on-call and beyond

Le Site Reliability Engineering est un role très jeune dans notre industrie, et donc le chemin pour “créer” un SRE n’est pas toujours très clair, surtout quand il s’agit de l’embarquer dans nos systèmes afin de le rendre autonome pour assister ses pairs. J’ai trouvé bien utile cette image résumant le parcours d’une nouvelle embauche SRE chez Google.

(p. 401) Disaster role playing game show: Once a week, a victim is chosen to be put on the spot and a real scenario taken from the company’s history is thrown at them. They tell the host what they would do or query to understand or solve the problem, and the host tells the victim what happens with each action or observation.

Une idée à essayer, peut-être?

(p. 414) Running the gauntlet

Enfin, aucun rapport avec le SRE, mais j’ai appris dans une note en bas de page l’origine de l’expression “running the gauntlet”. C’était une façon complètement barbare de torturer/exécuter publiquement des prisonniers. OUCH!

Comment vais-je utiliser ce que j’ai appris?

C’est beaucoup d’information à digérer d’un coup. Je ne pourrai pas utiliser immédiatement toutes les notions que j’ai rencontrées ici. Je vais d’abord partager ces idées avec mon équipe pour voir ce qui résonne avec eux.

Personnellement, je guette le prochain incident avec l’intention d’en tirer un maximum de profit. Je voudrai voir qu’est-ce qui fonctionne bien dans notre gestion d’incidents, où est-ce qu’on a pu suivre les meilleures pratiques de SRE, quelle serait la prochain idée à tester, etc. Ainsi, toutes les notions que j’ai incluses dans ce review et dans les star quotes ci-bas seront, je l’espère, un bon point de repère pour la suite.

Pourquoi dois-je utiliser ce que j’ai appris?

Je veux utiliser les notions de SRE contenues dans ce livre parce que j’ai un profond respect pour les pratiques technologiques de Google. Je trouve qu’en terme d’innovation, ils sont des champions, et ils m’inspirent beaucoup. Je trouve que ce livre est précieux parce qu’il explique les méthodes de Google sans entrer dans une posture marketing “nous sommes meilleurs que tout le monde.”

En résumé, j’ai confiance en Google dans ce domaine, ne serait-ce que parce que c’est chez eux que le concept du Site Reliability Engineering est né. Je ne veux pas réinventer la roue: je veux l’essayer le plus vite possible!

Quand vais-je utiliser ce que j’ai appris?

Cela devra peut-être attendre, parce que chez Alloprof nous avons la chance d’avoir relativement peu d’incidents, comparativement aux endroits où j’ai travaillé par le passé. Or, je serai patient, et lorsque nous aurons notre prochain incident, je sortirai ces notes afin d’être certain d’en retirer le maximum.

Si vous souhaitez feuilleter ce livre gratuitement et légalement, vous pouvez le faire en ligne à https://sre.google/sre-book/table-of-contents/.

Le verdict de Félix:
👍

📚 Vocabulaire

  • (p. 67) panacea: A cure-all remedy for all ills or difficulties
  • (p. 423) postvitam: TBD

⭐ Star Quotes

Foreword

Preface

Part I: Introduction

Chapter 1: Introduction

  • (p. 3) Hope is not a strategy.
  • (p. 7) ⭐ One could view DevOps as a generalization of several core SRE principles to a wider range of organizations, management structures, and personnel. One could equivalently view SRE as a specific implementation of DevOps with some idiosyncratic extensions.
  • (p. 8) Postmortems should be written for all significant incidents, regardless of whether or not they paged; postmortems that did not trigger a page are even more valuable, as they likely point to clear monitoring gaps.
  • (p. 8) In general, for any software service or system, 100% is not the right reliability target because no user can tell the difference between a system being 100% available and 99.999% available.
  • (p. 9) [Finding the right reliability target for the system] isn’t a technical question at all—it’s a product question, which should take the following considerations into account:
    • What level of availability will the users by happy with, given how they use the product?
    • What alternatives are available to users who are dissatisfied with the product’s availability?
    • What happens to users’ usage of the product at different availability levels?
  • (p. 9) Monitoring should never require a human to interpret any part of the alerting domain. Instead, software should do the interpreting, and humans should be notified only when they need to take action.
  • (p. 10) There are three kinds of valid monitoring output:
    • Alerts (a human needs to take action)
    • Tickets (a human needs to take action, but not immediately)
    • Logging (no one needs to look at this, but it can be used for diagnostic or forensic purposes)
  • (p. 10) The most relevant metric in evaluating the effectiveness of emergency response is how quickly the response team can bring the system back to health—that is, the mean time to recovery (MTTR).

Chapter 2: The Production Environment at Google, from the Viewpoint of an SRE

Part II: Principles

  • (p. 23) ⭐ Eliminating toil is one of SRE’s most important tasks. Toil is mundane, repetitive operational work providing no enduring value, which scales linearly with service growth.
  • (p. 23) Monitoring is an absolutely essential component of doing the right thing in production. If you can’t monitor a service, you don’t know what’s happening and if you’re blind to what’s happening, you can’t be reliable.
  • (p. 24) Simplicity is a quality that, once lost, can be extraordinarily difficult to recapture.

Chapter 3: Embracing Risk

  • (p. 27) $\text{Availability} = \frac{\text{uptime}}{\text{uptime} + \text{downtime}} = \frac{\text{successful requests}}{\text{total requests}} $
    • (1) is Time-based
    • (2) is Aggregate (works better for distributed services)
  • (p. 29) Which is worse for the service: a constant low rate of failures, or an occasional full-site outage? Both types of failure may result in the same absolute number of errors, but may have vastly different impacts on the business.
  • (p. 34) Not enough testing and you have embarrassing outages, privacy data leaks, or a number of other press-worthy events. Too much testing, and you might lose your market.
  • (p. 35) As long as the uptime measured is above the SLO—in other words, as long as there is error budget remaining—new releases can be pushed.

Chapter 4: Service Level Objectives

  • (p. 40) An easy way to tell the difference between an SLO and an SLA is to ask “What happens if the SLOs aren’t met?”: if there is no explicit consequence, then you are almost certainly looking at an SLO.
  • (p. 40) Google Search is an example of an important service that doesn’t have an SLA for the public: we want everyone to use Search as fluidly and efficiently as possible, but we haven’t signed a contract with the whole world.
  • (p. 42) User studies have shown that people typically prefer a slightly slower system to one with high variance in response time.
  • (p. 43) ⭐ Start by thinking about (or finding out!) what your users care about, not what you can measure.
  • (p. 45) Defend the SLOs you pick: if you can’t ever win a conversation about priorities by quoting a particular SLO, it’s probably not worth having that SLO.
  • (p. 46) Users build on the reality of what you offer, rather than what you say you’ll supply, particularly for infrastructure services. If your service’s actual performance is much better than its state SLO, users will come to rely on its current performance. [That’s the risk of overachieving.]

Chapter 5: Eliminating Toil

  • (p. 53) Toil is fine in small doses, and if you’re happy with those small doses, toil is not a problem. Toil becomes toxic when experienced in large quantities.

Chapter 6: Monitoring Distributed Systems

  • (p. 57) Unless you’re performing security auditing on very narrowly scoped components of a system, you should never trigger an alert simply because “something seems a bit weird.”
  • (p. 58) Your monitoring system should address two questions: what’s broken, and why?
  • (p. 64) It’s better to spend much more effort on catching symptoms than causes; when it comes to causes, only worry about very definite, very imminent causes.

Chapter 7: The Evolution of Automation at Google

  • (p. 67) Automation is a force, not a panacea.
  • (p. 79) Automation processes can vary in three respects:
    • Competence, i.e. their accuracy
    • Latency, how quickly all steps are executed when initiated
    • Relevance, or proportion of real-world process covered by automation
  • (p. 80) ⭐ The most functional tools are usually written by those who use them.

Chapter 8: Release Engineering

Chapter 9: Simplicity

  • (p. 97) “The price of reliability is the pursuit of the utmost simplicity.” —C.A.R. Hoare, Turing Award Lecture
  • (p. 98) “Unlike a detective story, the lack of excitement suspense, and puzzles is actually a desirable property of source code.” —Google engineer Robert Muth
  • (p. 99) “Perfection is finally attained not when there is no longer more to add, but when there is no longer anything to take away.” —Antoine de Saint-Exupéry
  • (p. 99) The fewer methods and arguments we provide to consumers of the API, the easier that API will be to understand, and the more effort we can devote to making those methods as good as they can possible be.
  • (p. 99) A small, simple API is usually also a hallmark of a well-understood problem.
  • (p. 101) Every time we say “no” to a feature, we are not restricting innovation; we are keeping the environment uncluttered of distractions so that focus remains squarely on innovation and real engineering can proceed.

Part III: Practices

Chapter 10: Practical Alerting from Time-Series Data

Chapter 11: Being On-Call

  • (p. 130) When an incident occurs, it’s important to evaluate what went wrong, recognize what went well, and take action to prevent the same errors from recurring in the future.
  • (p. 130) ⭐ All paging alerts (i.e. make a cellphone ring) should (…) be actionable.
  • (p. 132) An operational underload is undesirable for an SRE team. Being out of touch with production for long periods of time can lead to confidence issues, both in terms overconfidence and underconfidence, while knowledge gaps are discovered only when an incident occurs.

Chapter 12: Effective Troubleshooting

  • (p. 133) “Being an expert is more than understanding how a system is supposed to work. Expertise is gained by investigating why a system doesn’t work.” —Brian Redman
  • (p. 137) Novice pilots are taught that their first responsibility in an emergency is to fly the airplane; troubleshooting is secondary to getting the plane and everyone on it safely onto the ground.

Chapter 13: Emergency Response

  • (p. 151) ⭐ Regardless of the stakes involved or the size of the organization, one trait that’s vital to the long-term health of an organization and that consequently sets the organization apart fvrom others, is how the people involved respond to an emergency.
  • (p. 158) There is no better wat to learn than to document what has broken in the past. History is about learning from everyone’s mistakes.

Chapter 14: Managing Incidents

  • (p. 167) Pay attention to your emotional state while responding to an incident. If you start to feel panicky or overwhelmed, solicit more support.

Chapter 15: Postmortem Culture: Learning From Failure

  • (p. 169) “The cost of failure is education.” —Devin Carraway
  • (p. 170) Postmortems are expected after any significant event. Writing a postmortem is not punishment—it is a learning opportunity for the entire company.
  • (p. 171) Removing blame from a postmortem gives people the confidence to escalate issues without fear.
  • (p. 172) An unreviewed postmortem might as well never have existed.

Chapter 16: Tracking Outages

Chapter 17: Testing for Reliability

  • (p. 191) Shipping software that is obviously broken is among the most cardinal sins of a developer. It takes little effort to create a series of smoke tests to run for every release.

Chapter 18: Software Engineering in SRE

  • (p. 206) Team size should not scale directly with service growth.
  • (p. 209) Specify the requirements, not the implementation (intent-based capacity planning).

Chapter 19: Load Balancing at the Frontend

Chapter 20: Load Balancing in the Datacenter

Chapter 21: Handling Overload

Chapter 22: Addressing Cascading Failures

  • (p. 283) Once a service passes its breaking point, it is better to allow some user-visible errors or lower-quality results to slip through than try to fully serve every request.

Chapter 23: Managing Critical State: Distributed Consensus for Reliability

Chapter 24: Distributed Periodic Scheduling with Cron

Chapter 25: Data Processing Pipelines

Chapter 26: Data Integrity: What You Read Is What You Wrote

  • (p. 343) The real focus of (…) backup efforts should be data recovery, which distinguishes real backups from archives.
  • (p. 343) No one really wants to make backups; what people really want are restores.
  • (p. 345) Backups are a tax paid on an ongoing basis for the municipal service of guaranteed data availability.
  • (p. 356) “Bad” data doesn’t sit idly by, it propagates.
  • (p. 359) ⭐ You only know that you can recover your recent state if you actually do so.
  • (p. 367) ⭐ Never think you understand enough of a complex system to say it won’t fail in a certain way.
  • (p. 368) Recognizing that not just anything can go wrong, but that everything will go wrong is a significant step toward preparation for any real emergency.

Chapter 27: Reliable Product Launches at Scale

Part V: Management

Chapter 28: Accelerating SREs to On-Call and Beyond

  • (p. 400) “Those who cannot remember the past are condemned to repeat it.” —George Santayana
  • (p. 400) When writing a postmortem, keep in mind that its most appreciative audience might be an engineer who hasn’t yet been hired.

Chapter 29: Dealing with Interrupts

  • (p. 410) When a person is concentrating full-time on intererupts, interrupts stop being interrupts. When you’re (focusing on) interrupts, your projects are a distraction.
  • (p. 411) A 20-minute interruption while working on a project entails two context switches; realistically, this interruption results in a loss of a couple of hours of truly productive work.
  • (p. 412) When a person comes into work each day, they should know if they’re doing just project work or just interrupts. Polarizing their time in this way means they get to concentrate for longer periods of time on the task at hand.
  • (p. 420) ⭐ The most effective phrasing for a postmortem is to say, “Mistakes are inevitable in any system with multiple subtle interactions. You were on-call, and I trust you to make the right decisions with the right information. I’d like you to write down what you were thinking at each point in time, so that we can find out where the system misled you, and where the cognitive demands were too high.”
  • (p. 423) A postvitam, in contrast to a postmortem, (explains) the critical decisions at each step that led to success.

Chapter 31: Communication and Collaboration in SRE

Chapter 32: The Evolving SRE Engagement Model

Part V: Conclusions

Chapter 33: Lessons Learned from Other Industries

  • (p. 465) When something goes wrong (…), it’s important to evaluate all of the following:
    • What happened
    • The effectiveness of the response
    • What we would do differently next time
    • What actions will be taken to make sure a particular incident doesn’t happen again.

Chapter 34: Conclusion