Site Reliability Engineering (SRE) is a term (and associated job role) coined by Ben Treynor Sloss, a VP of engineering at Google.
SRE is a job role, a set of practices Google found to work, and some beliefs that animate those practices. If you think of DevOps as a philosophy and an approach to working, you can argue that SRE implements some of the philosophy that DevOps describes.
«SRE is what happens, when you ask a software engineer to design an operations function.»
SRE embodies the philosophy of DevOps but has a much more prescriptive way of measuring and achieving reliability through engineering and operations work. In other words, SRE prescribes how to succeed in the various DevOps areas. For example, the table below illustrates the five DevOps pillars and the corresponding SRE practices:
So, in a way, class SRE implements interface DevOps.
Yet there are significant differences as well. DevOps is in some sense a wider philosophy and culture.
DevOps is relatively silent on how to run operations functions at a detailed level. For example, it is not prescriptive around the precise management of services. It chooses instead to concentrate on breaking down barriers in the wider organization, which has much value, too.
SRE, on the other hand, has relatively narrowly defined responsibilities and its remit is generally service-oriented (and end-user-oriented) rather than whole-business-oriented. As a result, it brings an opinionated intellectual framework (including concepts like error budgets to the problem of how to run systems effectively. Although SRE is, as a profession, highly aware of incentives and their effects, it is in turn relatively silent on topics like siloization and information barriers. It would support CI (Continuous Integration) and CD (Continuous Delivery) not necessarily because of the business case, but because of the improved operational practices involved.
Or, to put it another way, SRE believes in the same things as DevOps but for slightly different reasons.
This Blog Post is mostly based on SRE vs. DevOps: competing standards or close friends?