Answers: <p>Thankfully, since Site Reliability Engineering developed internally at Google and only recently has started to make its way into the broader community, it is fairly well-defined.  What <em>isn't</em>, though, is web operations (or "systems administration" - as an example of the lack of clarity, you use both in your question).  It's difficult to discuss the differences between two things when you're not altogether sure what one of them is.</p>
  
  <p>But I'm an adventurous fellow, so I'll give it a shot.</p>
  
  <hr>
  
  <p>In very traditional shops, developers and sysadmins are very siloed from each other.  The devs build an app, then consider their job complete as soon as their code has been committed.  The sysadmins take the build artifacts (which may be just the code, if it's an interpreted language) and deploy it to production servers.  It's the sysadmins' job to keep the application running smoothly, and in general manage the production environment.  However, often performance problems come from architecture issues in the app; the sysadmins don't have the programming knowledge to know what the app is doing, and the developers don't know how the app acts in the production topology with production traffic, so no one is equipped by themselves to solve the problem.</p>
  
  <p>Additionally, the developers are usually judged on how quickly they can produce new features, while the sysadmins are judged on how infrequent the app breaks in production.  Since change is one of the leading causes of breakage, this puts the two departments at odds with each other - an old rivalry that hurts the business and the people involved.</p>
  
  <p>At some point, some developer-centric companies <a href="https://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html" rel="noreferrer">got so annoyed at this</a> that they began practicing "NoOps" - they eliminated their operations departments and the perceived roadblocks that came with them.  In reality, this meant that developers took on operations roles, but maintained their old titles.</p>
  
  <p>In <a href="https://gist.github.com/jallspaw/2140086" rel="noreferrer">a discussion surrounding NoOps</a>, John Allspaw, then VP of Technical Operations at Etsy and an editor of <a href="http://rads.stackoverflow.com/amzn/click/1449377440" rel="noreferrer">the well-respected Web Operations book</a>, defined roles at Etsy this way:</p>
  
  <blockquote>
    <p>Etsy Operations is responsible for:</p>
    
    <ul>
    <li>Responding to outages, takes on-call</li>
    <li>Alerting systems thresholding, design</li>
    <li>Architecture design and review</li>
    <li>Building metrics collection</li>
    <li>Application configuration</li>
    <li>Infrastructure buildout/management</li>
    </ul>
    
    <p>Etsy Development is responsible for:</p>
    
    <ul>
    <li>Responding to outages, takes on-call</li>
    <li>Alerting systems thresholding, design</li>
    <li>Architecture design and review</li>
    <li>Building metrics collection</li>
    <li>Application configuration</li>
    <li>Shipping public-facing code</li>
    </ul>
    
    <p>Neither of those lists are comprehensive, I'm sure I'm missing
    something there. While Etsy Ops has made production-facing application
    changes, they're few but real (and sometimes quite deep). While Etsy
    Dev makes Chef changes, they're few but real. If there's so much
    overlap in responsibilities, why the difference, you might ask? Domain
    expertise and background. Not many Devs have deep knowledge of how TCP
    slow start works, but Ops does. Not many Ops have a comprehensive
    knowledge of sorting or relevancy algorithms, but Dev does. Ops has
    years of experience in forecasting resource usage quickly with
    acceptable accuracy, Dev doesn't. Dev might not be aware of the pros
    and cons of distributing workload options across all layers1-7, maybe
    only just at 7, Ops does. Entity-relationship modeling may come
    natural to a developer, it may not to ops. In the end, they both
    discover solutions to various forms of Byzantine failure scenarios and
    resilience patterns, at all tiers and layers.</p>
  </blockquote>
  
  <p>In his world, developers and ops engineers had very similar high-level skill sets and responsibilities; where they differed was in their expertise.  Their differing specialties encouraged them to work together to solve problems, and their common base-level skills gave them a language in which to do that.</p>
  
  <p>This is generally the definition of web operations that I land on for most cases.  So it's the one we're going to continue along with.</p>
  
  <hr>
  
  <p>So then, what is Site Reliability Engineering?</p>
  
  <p>The Google SRE book opens with a definition of SRE... and then another one... and then spends a chapter continuing to define the role and an entire book covering the specifics.  Even when developed in one organization, it seems that it's difficult to condense the job down to one single agreed-upon definition.</p>
  
  <p>To start with, we need to walk back to 2003, when Ben Traynor joined Google and founded what came to be the first Site Reliability Engineering team.  Recall that a few paragraphs ago we were in the early 2010s; but in 2003, the industry was still pretty set on the sysadmin/developer divide as the natural way of things.  So when Ben says that SRE was what would happen if a software engineer created an operations team, this was a much more radical melding of the two worlds than it appears now.</p>
  
  <p>The definition given in the preface emphasizes each of the three words individually:</p>
  
  <ul>
  <li><strong>Engineering</strong> - the use of computer science and engineering concepts to solve problems</li>
  <li><strong>Reliability</strong> - a focus on making systems more scalable, more reliable, and more efficient</li>
  <li><strong>Service</strong> - the later evolution of "site", emphasizing that SREs are responsible for networked services</li>
  </ul>
  
  <p>The introduction chapter lists the tenets of Site Reliability Engineering as:</p>
  
  <ul>
  <li><strong>Ensuring a durable focus on engineering</strong> - taking pre-emptive action to avoid frequent pages and other "toil"</li>
  <li><strong>Persuing maximum change velocity without violating a service's SLO</strong> - a subject that can easily have its own several-hundred word answer, but roughly summarized as <em>helping</em> developers make changes, as long as they don't cause <em>too many</em> issues</li>
  <li><strong>Monitoring</strong> - automatic alerts when things go wrong</li>
  <li><strong>Emergency response</strong> - fixing things when they're broken</li>
  <li><strong>Change management</strong></li>
  <li><strong>Capacity planning</strong></li>
  <li><strong>Provisioning</strong></li>
  <li><strong>Efficiency and performance</strong> - ensuring that a service performs <em>at</em> an expected level - bottlenecking hurts users, but excess capacity costs money</li>
  </ul>
  
  <hr>
  
  <p>I'd categorize Site Reliability Engineering as a specialized subset of modern Web Operations.  An SRE organization focuses heavily on automating <em>everything</em>, to a degree that is only cost-effective in fairly large companies.  Ideas like error budgets can only work when your service has many, many requests, as otherwise you lose granularity (for a smaller service, a particular error could affect 0-20% of your requests, depending on the minute).  Related areas like security are absent from the SRE definition because companies large enough to have true SRE teams have dedicated teams for security.</p>
  
  <p>The SRE program, as defined by Google, is web ops developed for the specific needs of Google, and not necessarily applicable elsewhere.</p>
  
  <p>However, Site Reliability Engineering has been expanding in broader industry use recently.  My current job title is an SRE, even though I work at a much smaller company and my job description fits pretty well with John Allspaw's 2012 Etsy web ops definition.  My theory is that we've been progressing through titles as a shorthand for espousing the evolution of a single field:</p>
  
  <ul>
  <li>We started as <strong>sysadmins</strong>.</li>
  <li>Then as web sites became more of a "thing", job postings started to refer to <strong>web operations engineers</strong> to distinguish sysadmins who specialized in the web from those who also handled general office IT.</li>
  <li>Then <strong>DevOps</strong> was supposed to separate out those who were comfortable using programming to reduce their web ops workload.</li>
  <li>But as DevOps got muddled by <a href="https://devops.stackexchange.com/q/788/960">the lack of a clear definition</a>, we adopted <strong>Site Reliability Engineering</strong> to specify that we're looking for people who are on-call supporting production services.</li>
  </ul>
  
  <p>So what is the difference between a sysadmin and an SRE?  The year in which they received their title.  What is the difference between traditional operations and site reliability engineering?  SRE is merely the current incarnation of ops, using new tools (hello, containers!) and, as networked programs continue to become more larger and more important, an increased focus on practices that allow one engineer to do <em>more</em>.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-03T17:31:37.087Z
Answers: A few more interesting pieces of reading (that I don't necessarily agree with):  https://charity.wtf/2016/06/30/devops-vs-sre-delayed-coverage-of-the-dumbest-war/ , https://charity.wtf/2016/05/31/wtf-is-operations-serverless/ , https://www.susanjfowler.com/blog/2016/10/13/the-ops-identity-crisis
Answers: Xiong Chiamiov
Answers: CC BY-SA 3.0
Answers: 2017-06-03T17:23:53.877Z
Answers: 2017-06-03T17:23:53.877Z
Answers: Xiong Chiamiov
Body: <blockquote>
    <p>"SRE is what happens when you ask a software engineer to design an operations team." – <a href="https://www.amazon.co.uk/Site-Reliability-Engineering-Production-Systems/dp/149192912X" rel="noreferrer"><em>Site Reliability Engineering</em></a> </p>
  </blockquote>
  
  <p>Since <a href="https://www.amazon.co.uk/Site-Reliability-Engineering-Production-Systems/dp/149192912X" rel="noreferrer">Google's Site Reliability Engineering Book</a> was released, on more than one occasion I have been told that SRE is an extension of the existing Operations or Application Support model.</p>
  
  <p>We've had a couple of questions that defined differences between Sys. Admins, DevOps Engineers and Site Reliability Engineers:</p>
  
  <ul>
  <li><a href="https://devops.stackexchange.com/q/157/397">What is the difference between Sysadmin and DevOps Engineer?</a></li>
  <li><a href="https://devops.stackexchange.com/q/86/397">What is the difference between SRE and DevOps?</a></li>
  <li><a href="https://devops.stackexchange.com/q/788/397">What could be a valid definition of DevOps to introduce it to a novice?</a></li>
  </ul>
  
  <p>However none of these questions or their answers describe the <strong>differences between a Systems Administrator and a Site Reliability Engineer</strong>.</p>
  
  <p>In broader terms: what are the <em>key differences</em> between Google's practice of Site Reliability Engineering and the traditional separated Development and Operations functions within a business.</p>
  
Tags: <sre><operating-model><sysadmin>
Title: What is the difference between the traditional Development and Operations Model and Site Reliability Engineering?
UserDisplayName: Richard Slater
ThreadText: # What is the difference between the traditional Development and Operations Model and Site Reliability Engineering?
  
  (Asked by: username_0 on 2017-04-16)
  
  > "SRE is what happens when you ask a software engineer to design an operations team." – [*Site Reliability Engineering*](https://www.amazon.co.uk/Site-Reliability-Engineering-Production-Systems/dp/149192912X)
  
  Since [Google's Site Reliability Engineering Book](https://www.amazon.co.uk/Site-Reliability-Engineering-Production-Systems/dp/149192912X) was released, on more than one occasion I have been told that SRE is an extension of the existing Operations or Application Support model.
  
  We've had a couple of questions that defined differences between Sys. Admins, DevOps Engineers and Site Reliability Engineers:
  
  * [What is the difference between Sysadmin and DevOps Engineer?](https://devops.stackexchange.com/q/157/397)
  * [What is the difference between SRE and DevOps?](https://devops.stackexchange.com/q/86/397)
  * [What could be a valid definition of DevOps to introduce it to a novice?](https://devops.stackexchange.com/q/788/397)
  
  However none of these questions or their answers describe the **differences between a Systems Administrator and a Site Reliability Engineer**.
  
  In broader terms: what are the *key differences* between Google's practice of Site Reliability Engineering and the traditional separated Development and Operations functions within a business.
  
  **Tags:** sre, operating-model, sysadmin
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-06-03. Score: 7 | Accepted answer
  
  Thankfully, since Site Reliability Engineering developed internally at Google and only recently has started to make its way into the broader community, it is fairly well-defined. What *isn't*, though, is web operations (or "systems administration" - as an example of the lack of clarity, you use both in your question). It's difficult to discuss the differences between two things when you're not altogether sure what one of them is.
  
  But I'm an adventurous fellow, so I'll give it a shot.
  
  ---
  
  In very traditional shops, developers and sysadmins are very siloed from each other. The devs build an app, then consider their job complete as soon as their code has been committed. The sysadmins take the build artifacts (which may be just the code, if it's an interpreted language) and deploy it to production servers. It's the sysadmins' job to keep the application running smoothly, and in general manage the production environment. However, often performance problems come from architecture issues in the app; the sysadmins don't have the programming knowledge to know what the app is doing, and the developers don't know how the app acts in the production topology with production traffic, so no one is equipped by themselves to solve the problem.
  
  Additionally, the developers are usually judged on how quickly they can produce new features, while the sysadmins are judged on how infrequent the app breaks in production. Since change is one of the leading causes of breakage, this puts the two departments at odds with each other - an old rivalry that hurts the business and the people involved.
  
  At some point, some developer-centric companies [got so annoyed at this](https://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html) that they began practicing "NoOps" - they eliminated their operations departments and the perceived roadblocks that came with them. In reality, this meant that developers took on operations roles, but maintained their old titles.
  
  In [a discussion surrounding NoOps](https://gist.github.com/jallspaw/2140086), John Allspaw, then VP of Technical Operations at Etsy and an editor of [the well-respected Web Operations book](http://rads.stackoverflow.com/amzn/click/1449377440), defined roles at Etsy this way:
  
  > Etsy Operations is responsible for:
  >
  > * Responding to outages, takes on-call
  > * Alerting systems thresholding, design
  > * Architecture design and review
  > * Building metrics collection
  > * Application configuration
  > * Infrastructure buildout/management
  >
  > Etsy Development is responsible for:
  >
  > * Responding to outages, takes on-call
  > * Alerting systems thresholding, design
  > * Architecture design and review
  > * Building metrics collection
  > * Application configuration
  > * Shipping public-facing code
  >
  > Neither of those lists are comprehensive, I'm sure I'm missing
  > something there. While Etsy Ops has made production-facing application
  > changes, they're few but real (and sometimes quite deep). While Etsy
  > Dev makes Chef changes, they're few but real. If there's so much
  > overlap in responsibilities, why the difference, you might ask? Domain
  > expertise and background. Not many Devs have deep knowledge of how TCP
  > slow start works, but Ops does. Not many Ops have a comprehensive
  > knowledge of sorting or relevancy algorithms, but Dev does. Ops has
  > years of experience in forecasting resource usage quickly with
  > acceptable accuracy, Dev doesn't. Dev might not be aware of the pros
  > and cons of distributing workload options across all layers1-7, maybe
  > only just at 7, Ops does. Entity-relationship modeling may come
  > natural to a developer, it may not to ops. In the end, they both
  > discover solutions to various forms of Byzantine failure scenarios and
  > resilience patterns, at all tiers and layers.
  
  In his world, developers and ops engineers had very similar high-level skill sets and responsibilities; where they differed was in their expertise. Their differing specialties encouraged them to work together to solve problems, and their common base-level skills gave them a language in which to do that.
  
  This is generally the definition of web operations that I land on for most cases. So it's the one we're going to continue along with.
  
  ---
  
  So then, what is Site Reliability Engineering?
  
  The Google SRE book opens with a definition of SRE... and then another one... and then spends a chapter continuing to define the role and an entire book covering the specifics. Even when developed in one organization, it seems that it's difficult to condense the job down to one single agreed-upon definition.
  
  To start with, we need to walk back to 2003, when Ben Traynor joined Google and founded what came to be the first Site Reliability Engineering team. Recall that a few paragraphs ago we were in the early 2010s; but in 2003, the industry was still pretty set on the sysadmin/developer divide as the natural way of things. So when Ben says that SRE was what would happen if a software engineer created an operations team, this was a much more radical melding of the two worlds than it appears now.
  
  The definition given in the preface emphasizes each of the three words individually:
  
  * **Engineering** - the use of computer science and engineering concepts to solve problems
  * **Reliability** - a focus on making systems more scalable, more reliable, and more efficient
  * **Service** - the later evolution of "site", emphasizing that SREs are responsible for networked services
  
  The introduction chapter lists the tenets of Site Reliability Engineering as:
  
  * **Ensuring a durable focus on engineering** - taking pre-emptive action to avoid frequent pages and other "toil"
  * **Persuing maximum change velocity without violating a service's SLO** - a subject that can easily have its own several-hundred word answer, but roughly summarized as *helping* developers make changes, as long as they don't cause *too many* issues
  * **Monitoring** - automatic alerts when things go wrong
  * **Emergency response** - fixing things when they're broken
  * **Change management**
  * **Capacity planning**
  * **Provisioning**
  * **Efficiency and performance** - ensuring that a service performs *at* an expected level - bottlenecking hurts users, but excess capacity costs money
  
  ---
  
  I'd categorize Site Reliability Engineering as a specialized subset of modern Web Operations. An SRE organization focuses heavily on automating *everything*, to a degree that is only cost-effective in fairly large companies. Ideas like error budgets can only work when your service has many, many requests, as otherwise you lose granularity (for a smaller service, a particular error could affect 0-20% of your requests, depending on the minute). Related areas like security are absent from the SRE definition because companies large enough to have true SRE teams have dedicated teams for security.
  
  The SRE program, as defined by Google, is web ops developed for the specific needs of Google, and not necessarily applicable elsewhere.
  
  However, Site Reliability Engineering has been expanding in broader industry use recently. My current job title is an SRE, even though I work at a much smaller company and my job description fits pretty well with John Allspaw's 2012 Etsy web ops definition. My theory is that we've been progressing through titles as a shorthand for espousing the evolution of a single field:
  
  * We started as **sysadmins**.
  * Then as web sites became more of a "thing", job postings started to refer to **web operations engineers** to distinguish sysadmins who specialized in the web from those who also handled general office IT.
  * Then **DevOps** was supposed to separate out those who were comfortable using programming to reduce their web ops workload.
  * But as DevOps got muddled by [the lack of a clear definition](https://devops.stackexchange.com/q/788/960), we adopted **Site Reliability Engineering** to specify that we're looking for people who are on-call supporting production services.
  
  So what is the difference between a sysadmin and an SRE? The year in which they received their title. What is the difference between traditional operations and site reliability engineering? SRE is merely the current incarnation of ops, using new tools (hello, containers!) and, as networked programs continue to become more larger and more important, an increased focus on practices that allow one engineer to do *more*.
  
  > **Comments:**
  > **username_1**: A few more interesting pieces of reading (that I don't necessarily agree with):  https://charity.wtf/2016/06/30/devops-vs-sre-delayed-coverage-of-the-dumbest-war/ , https://charity.wtf/2016/05/31/wtf-is-operations-serverless/ , https://www.susanjfowler.com/blog/2016/10/13/the-ops-identity-crisis  
  
  ---
  
  