---
title: "Site Reliability Engineering, and the parts a bank can't copy"
description: "A bank can't copy Google's SRE package, but the ideas underneath transfer, and regulators have started writing the target."
url: "https://michael.zazon.us/notes/site-reliability-engineering-and-the-parts-a-bank-cant-copy"
published: "2026-04-28T12:00:00-04:00"
kind: "book-notes"
subject: "operations"
tags: ["sre"]
---
[Site Reliability Engineering](https://sre.google/sre-book/table-of-contents/) (O'Reilly, 2016, available online for free at sre.google) introduced the industry to the concepts of SLOs, error budget, and toil (repetitive manual work). The standing reaction from outsiders since the book's publication has been "this only works if you have unlimited money". Ben Treynor Sloss says in the introduction "SRE is what happens when you ask a software engineer to design an operations team." This explains the tone of the book. If you work in IT at a bank or a Fortune 500 company, instead of asking "should we do SRE?" it's more useful to ask "which parts of SRE will still work outside of Google?"

The enforcement mechanism travels the worst. Google's typical policy is when a service's error budget is exhausted, feature launches are frozen until reliability improves. This assumes releases are the primary cause of failures, and that the product team can stop shipping. In a large enterprise, unreliability usually comes from vendor integrations and shared infrastructure that no single team releases. A freeze collides with regulatory deadlines and change boards that run on their own calendar.

The operational work cap suffers from the same problem. The book says at least half of each SRE's time should be on engineering projects, and toil beyond that point means excess ops load gets returned to developers. This assumes your organization is willing to give the pager back to dev teams when SREs get overwhelmed, which few enterprises are built to do. That's the part I'd rule out.. adopting the whole package, launch freezes and all, with a cap enforced by shifting work between teams.

On the other side of the debate, many companies simply renamed their ops team and did nothing more. The title is now drifting toward "ops support" as platform teams absorb the engineering work. I've spent ten years working with large financial institutions and Fortune 500 companies, now as a principal cloud architect. The problem isn't the title.. it's the organization. If your SREs aren't writing code and aren't in the room when architecture decisions are made, they're an ops team with a new badge. The first question for any company that has SREs: what does the word mean to them?

What *is* transferable is the idea behind each mechanism. An SLO is a reliability number your business agrees to and signs. Toil is something you measure and cap (and you can enforce the cap through planning, not a reorg). You don't need Google's org chart for either one. But they do let a large org talk about reliability before an outage forces the issue.

Regulated industries have an external version. The UK's operational resilience rules ([FCA PS21/3](https://www.fca.org.uk/publication/policy/ps21-3-operational-resilience.pdf)) tell banks and insurers to identify their important business services, set an impact tolerance for each (the maximum tolerable disruption), and prove they're staying within it. The deadline for compliance was at the end of March 2025. The impact tolerance is the outer bound that contains the internal SLO. The regulator writes the target; it's your job to set a tighter one for yourself.

[Diagram: Three nested bands showing impact tolerance, SLO and error budget](https://michael.zazon.us/notes/site-reliability-engineering-and-the-parts-a-bank-cant-copy)

This changes the purpose of the error budget. I think the error budget transfers least as a rule and most as a language. A bank can't freeze launches based on the error budget alone, but it can make the SLO the number that product, operations, and risk argue about, as long as they stay within the regulator's tolerance. The gap between the SLO and perfect reliability is what each side spends on change, and spending becomes a negotiation instead of a freeze.

Toil is worth watching because it hasn't changed much at all. The [Catchpoint SRE Report 2026](https://catchpoint.com/blog/sre-report-2026-what-surprised-us-what-didnt-and-why-the-gaps-matter-most) still shows practitioners spending about a third of their time on toil, roughly flat year on year. The AI-enabled toil reduction shows up mostly in managers' answers, much less in engineers' answers. If AI is the enterprise's new automation budget, is anyone measuring toil before and after the way the book's 50% cap assumed?