Site Reliability Engineering, 2nd Edition

Preface

Ten years ago, the first edition of Site Reliability Engineering set out to explain what Site Reliability Engineering (SRE) is and how Site Reliability Engineers (SREs) do it at Google. In the subsequent years, the role has become widespread beyond Google, and the approach we described has become broadly accepted in the industry. Meanwhile, the technology underpinning running large-scale distributed computing systems has become much more standardized and commoditized: unless you have very specific needs, you’re unlikely to build your own load balancer or your own distributed consensus system with Paxos—you’re probably either buying it as a service from a cloud provider or running an instance of open source software.

Furthermore, as we write this, AI is in the process of radically accelerating change in our field, as well as many others. We have no crystal ball to forecast what the future of running production environments will be like in another 10 years—or even, quite possibly, 10 months.¹

But what hasn’t changed? The fundamentals: SREs continue to be engineers, focusing on system reliability, for large-scale distributed computing services.

All of those trends, combined with what we know has stayed the same, have caused us to shift the focus of this edition toward the things we didn’t address in much detail the first time around—things that support well-functioning teams: the sociotechnical aspects of SRE. As a result, you’ll see more on understanding the value of what ...