Files
nexus/sreweekly/articles/298/06-what-sre-is-not.html
2026-09-12 17:23:01 +08:00

506 lines
32 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
<title>What SRE is not</title>
<meta name="HandheldFriendly" content="True" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="https://blog.relyabilit.ie/assets/css/style.css?v=QmDy475QI3K1foi7" />
<script>
var siteUrl = 'https://blog.relyabilit.ie';
</script>
<script>
var localTheme = localStorage.getItem('attila_theme');
switch (localTheme) {
case 'dark':
document.documentElement.classList.add('theme-dark');
break;
case 'light':
document.documentElement.classList.add('theme-light');
break;
default:
break;
}
</script>
<style>
.theme-dark:root {
--ghost-accent-color: #ff6633;
}
@media (prefers-color-scheme: dark) {
html:not(.theme-light):root {
--ghost-accent-color: #ff6633;
}
}
</style>
<link rel="icon" href="https://storage.ghost.io/c/35/8b/358be036-5da7-4000-beff-df259098e18a/content/images/2021/09/App-Amethyst.ico" type="image/x-icon">
<link rel="canonical" href="https://blog.relyabilit.ie/what-sre-is-not/">
<meta name="referrer" content="no-referrer-when-downgrade">
<meta property="og:site_name" content="RelyAbility Blog">
<meta property="og:type" content="article">
<meta property="og:title" content="What SRE is not">
<meta property="og:description" content="We used to have a difficulty in our community - thankfully less prevalent now -
with rootless questions of identity. Of course, it&#x27;s not wrong to ask who we
are, what we&#x27;re here for, and what should we be doing: every profession benefits
from regular reflection. But too much of">
<meta property="og:url" content="https://blog.relyabilit.ie/what-sre-is-not/">
<meta property="og:image" content="https://images.unsplash.com/photo-1553293373-2ad550294aa9?crop&#x3D;entropy&amp;cs&#x3D;tinysrgb&amp;fit&#x3D;max&amp;fm&#x3D;jpg&amp;ixid&#x3D;MnwxMTc3M3wwfDF8c2VhcmNofDIyfHxub3R8ZW58MHx8fHwxNjM3ODY0MzU3&amp;ixlib&#x3D;rb-1.2.1&amp;q&#x3D;80&amp;w&#x3D;2000">
<meta property="article:published_time" content="2021-10-26T18:51:54.000Z">
<meta property="article:modified_time" content="2021-11-26T15:34:25.000Z">
<meta property="article:tag" content="gatekeeping">
<meta property="article:tag" content="horizontal">
<meta property="article:tag" content="is-not">
<meta property="article:tag" content="sre-identity">
<meta property="article:publisher" content="https://www.facebook.com/ghost">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="What SRE is not">
<meta name="twitter:description" content="Questions of identity solved by asking what we aren&#x27;t">
<meta name="twitter:url" content="https://blog.relyabilit.ie/what-sre-is-not/">
<meta name="twitter:image" content="https://images.unsplash.com/photo-1553293373-2ad550294aa9?crop&#x3D;entropy&amp;cs&#x3D;tinysrgb&amp;fit&#x3D;max&amp;fm&#x3D;jpg&amp;ixid&#x3D;MnwxMTc3M3wwfDF8c2VhcmNofDIyfHxub3R8ZW58MHx8fHwxNjM3ODY0MzU3&amp;ixlib&#x3D;rb-1.2.1&amp;q&#x3D;80&amp;w&#x3D;2000">
<meta name="twitter:label1" content="Written by">
<meta name="twitter:data1" content="Niall Murphy">
<meta name="twitter:label2" content="Filed under">
<meta name="twitter:data2" content="gatekeeping, horizontal, is-not, sre-identity">
<meta name="twitter:site" content="@niallm">
<meta name="twitter:creator" content="@niallm">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="800">
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"publisher": {
"@type": "Organization",
"name": "RelyAbility Blog",
"url": "https://blog.relyabilit.ie/",
"logo": {
"@type": "ImageObject",
"url": "https://storage.ghost.io/c/35/8b/358be036-5da7-4000-beff-df259098e18a/content/images/2021/09/Logo---Alternate-Layout---Black-2.png"
}
},
"author": {
"@type": "Person",
"name": "Niall Murphy",
"image": {
"@type": "ImageObject",
"url": "https://storage.ghost.io/c/35/8b/358be036-5da7-4000-beff-df259098e18a/content/images/2021/11/recent-headshot--2-.jpg",
"width": 622,
"height": 587
},
"url": "https://blog.relyabilit.ie/author/niallmurphy/",
"sameAs": [
"http://www.relyabilit.ie",
"https://x.com/niallm"
]
},
"headline": "What SRE is not",
"url": "https://blog.relyabilit.ie/what-sre-is-not/",
"datePublished": "2021-10-26T18:51:54.000Z",
"dateModified": "2021-11-26T15:34:25.000Z",
"image": {
"@type": "ImageObject",
"url": "https://images.unsplash.com/photo-1553293373-2ad550294aa9?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDIyfHxub3R8ZW58MHx8fHwxNjM3ODY0MzU3&ixlib=rb-1.2.1&q=80&w=2000",
"width": 1200,
"height": 800
},
"keywords": "gatekeeping, horizontal, is-not, sre-identity",
"description": "We used to have a difficulty in our community - thankfully less prevalent now -\nwith rootless questions of identity. Of course, it's not wrong to ask who we\nare, what we're here for, and what should we be doing: every profession benefits\nfrom regular reflection. But too much of it, and you never converge, and moving\nforward becomes impossible.\n\nThough, as I say, I think things are settling and existential questions are much\nless urgent than they were, the profession continues to grow. Many new f",
"mainEntityOfPage": "https://blog.relyabilit.ie/what-sre-is-not/"
}
</script>
<meta name="generator" content="Ghost 6.64">
<link rel="alternate" type="application/rss+xml" title="RelyAbility Blog" href="https://blog.relyabilit.ie/rss/">
<script defer src="https://cdn.jsdelivr.net/ghost/portal@~2.71/umd/portal.min.js" data-i18n="true" data-ghost="https://blog.relyabilit.ie/" data-key="b25ad4e06b5e0cae96b3fa8e63" data-api="https://niallmurphy.ghost.io/ghost/api/content/" data-locale="en" crossorigin="anonymous"></script><style id="gh-members-styles">.gh-post-upgrade-cta-content,
.gh-post-upgrade-cta {
display: flex;
flex-direction: column;
align-items: center;
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif;
text-align: center;
width: 100%;
color: #ffffff;
font-size: 16px;
}
.gh-post-upgrade-cta-content {
border-radius: 8px;
padding: 40px 4vw;
}
.gh-post-upgrade-cta h2 {
color: #ffffff;
font-size: 28px;
letter-spacing: -0.2px;
margin: 0;
padding: 0;
}
.gh-post-upgrade-cta p {
margin: 20px 0 0;
padding: 0;
}
.gh-post-upgrade-cta small {
font-size: 16px;
letter-spacing: -0.2px;
}
.gh-post-upgrade-cta a {
color: #ffffff;
cursor: pointer;
font-weight: 500;
box-shadow: none;
text-decoration: underline;
}
.gh-post-upgrade-cta a:hover {
color: #ffffff;
opacity: 0.8;
box-shadow: none;
text-decoration: underline;
}
.gh-post-upgrade-cta a.gh-btn {
display: block;
background: #ffffff;
text-decoration: none;
margin: 28px 0 0;
padding: 8px 18px;
border-radius: 4px;
font-size: 16px;
font-weight: 600;
}
.gh-post-upgrade-cta a.gh-btn:hover {
opacity: 0.92;
}</style>
<script defer src="https://cdn.jsdelivr.net/ghost/sodo-search@~1.8/umd/sodo-search.min.js" data-key="b25ad4e06b5e0cae96b3fa8e63" data-styles="https://cdn.jsdelivr.net/ghost/sodo-search@~1.8/umd/main.css" data-sodo-search="https://niallmurphy.ghost.io/" data-locale="en" crossorigin="anonymous"></script>
<link href="https://blog.relyabilit.ie/webmentions/receive/" rel="webmention">
<script defer src="/public/cards.min.js?v=ShRHxgy4po8zN-Wf"></script>
<link rel="stylesheet" type="text/css" href="/public/cards.min.css?v=WwnU9jw5ancNC8Gc">
<script defer src="/public/member-attribution.min.js?v=AKG4hWena9j3yX3I"></script>
<script defer src="/public/ghost-stats.min.js?v=vFcCUf6ZQ0Hyhc8h" data-stringify-payload="false" data-datasource="analytics_events" data-storage="localStorage" data-host="https://blog.relyabilit.ie/.ghost/analytics/api/v1/page_hit" tb_site_uuid="358be036-5da7-4000-beff-df259098e18a" tb_post_uuid="45097ad8-3bda-42d2-8db4-dddb3e9326ab" tb_post_type="post" tb_member_uuid="undefined" tb_member_status="undefined" tb_gift_link=""></script><style>:root {--ghost-accent-color: #b18cfe;}</style>
</head>
<body class="post-template tag-gatekeeping tag-horizontal tag-is-not tag-sre-identity">
<div class="nav-header">
<nav class="nav-wrapper" aria-label="Main">
<span class="logo">
<a href="https://blog.relyabilit.ie" title="Home"><img src="https://storage.ghost.io/c/35/8b/358be036-5da7-4000-beff-df259098e18a/content/images/2021/09/Logo---Alternate-Layout---Black-2.png" alt="Logo" /></a>
</span>
<ul>
<li class="nav-main-website"><a href="https://www.relyabilit.ie/"><span>Main Website</span></a></li>
<li class="nav-blog"><a href="https://blog.relyabilit.ie/"><span>Blog</span></a></li>
<li class="nav-help"><a href="https://ghost.org/docs/"><span>Help</span></a></li>
</ul>
<ul class="nav-meta">
<li class="nav-twitter">
<a aria-label="Twitter" href="https://x.com/niallm" title="@niallm" target="_blank">
<i class="icon icon-twitter" aria-hidden="true"></i>
<span>@niallm</span>
</a>
</li>
<li class="nav-facebook">
<a aria-label="Facebook" href="https://www.facebook.com/ghost" title="ghost" target="_blank">
<i class="icon icon-facebook" aria-hidden="true"></i>
<span>ghost</span>
</a>
</li>
<li class="nav-search" style="display: none;">
<a title="Search">
<i class="icon icon-search" aria-hidden="true"></i>
<span>Search</span>
</a>
</li>
<!--
<li class="nav-subscribe">
<a href="#/portal">Subscribe</a>
</li>
-->
</ul>
</nav>
<div class="nav-wrapper-control">
<div class="inner">
<a class="nav-menu" role="button"><i class="icon icon-menu" aria-hidden="true"></i>Menu</a>
<a class="nav-search" style="display: none;" title="Search" role="button"><i class="icon icon-search" aria-hidden="true"></i></a>
</div>
</div>
</div>
<div class="nav-close" role="button" aria-label="Close"></div>
<section class="page-wrapper">
<div class="progress-container">
<span class="progress-bar"></span>
</div>
<header class="post-header has-cover ">
<div class="inner">
<span class="post-info">
<span class="post-type">Article</span>
<span class="post-count">gatekeeping</span>
</span>
<h1 class="post-title">What SRE is not</h1>
<div class="post-meta">
<div class="post-meta-avatars">
<figure class="post-meta-avatar avatar">
<a href="/author/niallmurphy/" class="author-avatar">
<img class="author-profile-image" src="https://storage.ghost.io/c/35/8b/358be036-5da7-4000-beff-df259098e18a/content/images/2021/11/recent-headshot--2-.jpg" alt="Niall Murphy" />
</a>
</figure>
</div>
<h4 class="post-meta-author"><a href="/author/niallmurphy/">Niall Murphy</a></h4>
<time datetime="26-10-2021">26 Oct 2021</time> &bull; 8 min read
</div>
<div class="post-cover cover">
<img
srcset="https://images.unsplash.com/photo-1553293373-2ad550294aa9?crop&#x3D;entropy&amp;cs&#x3D;tinysrgb&amp;fit&#x3D;max&amp;fm&#x3D;jpg&amp;ixid&#x3D;MnwxMTc3M3wwfDF8c2VhcmNofDIyfHxub3R8ZW58MHx8fHwxNjM3ODY0MzU3&amp;ixlib&#x3D;rb-1.2.1&amp;q&#x3D;80&amp;w&#x3D;320 320w,
https://images.unsplash.com/photo-1553293373-2ad550294aa9?crop&#x3D;entropy&amp;cs&#x3D;tinysrgb&amp;fit&#x3D;max&amp;fm&#x3D;jpg&amp;ixid&#x3D;MnwxMTc3M3wwfDF8c2VhcmNofDIyfHxub3R8ZW58MHx8fHwxNjM3ODY0MzU3&amp;ixlib&#x3D;rb-1.2.1&amp;q&#x3D;80&amp;w&#x3D;640 640w,
https://images.unsplash.com/photo-1553293373-2ad550294aa9?crop&#x3D;entropy&amp;cs&#x3D;tinysrgb&amp;fit&#x3D;max&amp;fm&#x3D;jpg&amp;ixid&#x3D;MnwxMTc3M3wwfDF8c2VhcmNofDIyfHxub3R8ZW58MHx8fHwxNjM3ODY0MzU3&amp;ixlib&#x3D;rb-1.2.1&amp;q&#x3D;80&amp;w&#x3D;960 960w,
https://images.unsplash.com/photo-1553293373-2ad550294aa9?crop&#x3D;entropy&amp;cs&#x3D;tinysrgb&amp;fit&#x3D;max&amp;fm&#x3D;jpg&amp;ixid&#x3D;MnwxMTc3M3wwfDF8c2VhcmNofDIyfHxub3R8ZW58MHx8fHwxNjM3ODY0MzU3&amp;ixlib&#x3D;rb-1.2.1&amp;q&#x3D;80&amp;w&#x3D;1920 1920w"
src="https://images.unsplash.com/photo-1553293373-2ad550294aa9?crop&#x3D;entropy&amp;cs&#x3D;tinysrgb&amp;fit&#x3D;max&amp;fm&#x3D;jpg&amp;ixid&#x3D;MnwxMTc3M3wwfDF8c2VhcmNofDIyfHxub3R8ZW58MHx8fHwxNjM3ODY0MzU3&amp;ixlib&#x3D;rb-1.2.1&amp;q&#x3D;80&amp;w&#x3D;1920"
alt="What SRE is not" />
</div>
</div>
</header>
<main class="content" role="main">
<article class="post tag-gatekeeping tag-horizontal tag-is-not tag-sre-identity">
<div class="inner">
<section class="post-content">
<p>We used to have a difficulty in our community - thankfully less prevalent now - with rootless questions of identity. Of course, it's not <em>wrong</em> to ask who we are, what we're here for, and what should we be doing: every profession benefits from regular reflection. But too much of it, and you never converge, and moving forward becomes impossible.</p><p>Though, as I say, I think things are settling and existential questions are much less urgent than they were, the profession continues to grow. Many new folks are still joining with similar questions about our purpose, how we achieve it, and so on. How, then, should we best address this?</p><p>Rather than pointing these new joiners at the fixed list of responsibilities present in the original SRE book, I thought it might be better to try a new approach: defining what SRE was by looking at what it's <em>not</em>. Or to put it another way, what can you remove from SRE and have it still be SRE<em>?</em></p><p>Here are my suggestions.</p><!--kg-card-begin: markdown--><table>
<thead>
<tr>
<th>If you don't have this...</th>
<th>... are you doing SRE?</th>
</tr>
</thead>
<tbody>
<tr>
<td>Access to internal source code</td>
<td>No</td>
</tr>
<tr>
<td>Ability to change internal source code/system design</td>
<td>No</td>
</tr>
<tr>
<td>Ability to cap operational work</td>
<td>No</td>
</tr>
<tr>
<td>Organizational cross-cutting ability</td>
<td>No</td>
</tr>
<tr>
<td>Ability to write code in the first place</td>
<td>No, but temporarily is okay</td>
</tr>
<tr>
<td>Operational responsibilities</td>
<td>No, but temporarily is okay</td>
</tr>
<tr>
<td>SLOs</td>
<td>Yes, but it's better if you have them</td>
</tr>
<tr>
<td>A large-scale system to manage</td>
<td>Yes, but it's better if you have some</td>
</tr>
<tr>
<td>Ability to avoid vendor kit</td>
<td>Yes</td>
</tr>
<tr>
<td>A mono-repo</td>
<td>Yes</td>
</tr>
<tr>
<td>SRE job title</td>
<td>Irrelevant</td>
</tr>
</tbody>
</table>
<!--kg-card-end: markdown--><p><em><strong>Access to internal source code.</strong></em> An SRE team without access to source code, either for their products/services, or infrastructure, can still do <em>some</em> useful things. They can make distributed systems designs, trace issues back to an endpoint or contributing factor of some kind, and write useful tools.</p><p>But this lack of access affects MTTR, destroys parity of esteem, undermines building closer relationships between the two teams, prevents deep engineering contributions to the supported systems, and sharply circumscribes SRE team possibilities. Unlike the ability to change the code, if the SRE team can't even be trusted to <em>see</em> the code, that indicates a deeper relationship pathology it would be hard to recover from. </p><p><em><strong>Ability to change internal source code/system design.</strong></em> The good news is that an SRE team with read-only access to source code can perform more accurate problem resolution, and can understand the systems more deeply. As a result, they can come up with ideas for deep engineering contributions - but they aren't allowed to do them. That’s almost worse than the previous situation!</p><p>However, there's a reasonable situation where this makes sense, and that's where individuals in the SRE team have to satisfy the product engineering team of their competence with the code. Though this might come across as condescending in your individual situation, I actually don't judge here - folks are going to be cautious about source code, and legitimately so. But to my mind, this could only ever be a temporary (albeit perhaps somewhat long-lived) situation for an individual; a permanent barrier would mean an SRE relationship was impossible.</p><p>A similar discussion applies to system design as well. If an SRE team can't influence the design phase of the SDLC for the systems they're minding, that's not engineering. Of course, it might take quite a while to demonstrate competence at doing so: that's fine.</p><p><em><strong>Ability to cap operational work.</strong></em> (We might also call this "SRE team having autonomy over how their time is spent", for reasons which will become clear.)</p><p>The key behaviour enabled by having a cap on operational work is that operational work almost by definition requires some element of immediate attention or task-focus. If you can’t do anything other than respond to an issue, by definition you can’t put together the project time required to solve a general class of problems with software. If in turn you can’t solve classes of problems with software, in a general environment of growing services (which ~all cloud services are) you either have more work over the same amount of people, which is bad, or linearly growing numbers of people, which is bad. So I feel as a function of autonomy, a function of organizational back pressure, and a function of just getting the job done, an SRE team needs to be able to do this.</p><p>Whether it's 50% or some other number, I doubt matters in the short-term, but if you don't give a team at least as much time to reflect, clean up, and engineer as they spend in purely reacting, they are not SREs.</p><p><em><strong>Organizational cross-cutting ability.</strong></em><strong> </strong>One of the cultural aspects of SRE that is often misunderstood is the implications of being the guardians of the user experience. Reliability is a holistic thing; it's not an attribute or property in the gift of any one silo, so guarding that experience necessarily requires moving outside your own team, to assemble the end-to-end picture. This leads to a situation where SRE often acts as "horizontal glue between vertical silos", to coin a phrase.</p><p>Well, what happens when you <em>can't</em> do that? In very hierarchical environments, where you are literally not allowed to talk to other teams without going up and down a chain of command; in environments where work items are processed primarily <a href="https://www.usenix.org/conference/srecon18europe/presentation/edwards?ref=blog.relyabilit.ie">via context-free agents in ticket queues</a>; or in environments where information about the customer experience is hidden, protected, or otherwise gate-kept, SRE struggles to work.</p><p>To be clear, there's (potentially) a huge difference between declared policy and actual practice here; if "leadership says" you have to go through the chain of command, but in practice people just talk to each other and help out as they would anyway, that's SRE-compatible for sure.</p><p>But if the organization is structured so as to prevent this kind of work, then it's not SRE compatible. (Indeed, it might be incompatible with many other things too.)</p><p><em><strong>Ability to author code.</strong></em> Some idealised SRE team whose members can't write software, or can’t be in a position to within some agreed timeframe, is an operations team with distributed systems expertise. While this provides value in and of itself, not having the ability to write code loses the SRE team one of the key ways it can contribute meaningfully to scaling, reliability, monitoring, and so on. To my mind, this is not an SRE team. There may well be a path to being an SRE team, particularly if the individuals are competent in a related domain, and are willing to acquire knowledge in the other. An SRE team should, of course, have a spectrum of experience and inclination within it, including both systems expertise and software expertise.</p><p><em><strong>Without operational responsibilities.</strong></em> An SRE team without operational responsibilities can still do useful work, particularly if the products/services are in the process of launching (design &amp; pre-launch can be an incredibly valuable period for SRE contributions) but a permanent removal of operational responsibilities breaks one of the main feedback loops utilised by SRE to improve the product. As a result, I think a complete withdrawal of operational responsibilities must be temporary (perhaps extended, but temporary), or I don't think this is an SRE team.</p><p>Do please be aware that despite various assumptions, on-call is not the primary value SRE provides, and neither do operational responsibilities have to be provided primarily as on-call.</p><p><em><strong>SLOs.</strong></em> There are many great practices that flow from having SLOs for your services, and much of value that is gained by being able to trade off priorities in services, but the author has been in a number of teams either without SLOs, that took a long time (~year) to settle on SLOs, and even a team where a relatively relaxed SLO was chosen by fiat and it was explicitly forbidden to spend more time finding a better one. So I am forced to conclude you don't need them to be doing SRE, though whether or not you can continue to do that indefinitely is very much another question.</p><p>FWIW, having SLOs unlocks disciplined tradeoffs between services, deciding on appropriate work, whether issues are important enough to care about, and a lot of organizational goodness - and also is a great way to be objective about what the user experience should be.</p><p><em><strong>A large-scale system.</strong></em> An SRE team without a large-scale system to look after is still a perfectly valid thing, providing either that the system will grow significantly at some point in the future (in which case preparation in advance is useful), or that the time cannot be spent more usefully on something else. “Large” is also a subjective definition, geared not just on the sizes of the systems in question but also the scoped competence of the individuals in question. “Business importance” can stand in for “large” too, of course, it is just that much of SRE expertise is most fruitfully applied across a large number of systems, amount of data, or high number of users.</p><p>In short, you don't need it, though having it helps apply expertise in a high-leverage way.</p><p><strong><em>Supporting vendor kit.</em> </strong>In a way, this is a special case of source code not being available. Note that source code not being directly available does not necessarily prevent SRE improving manageability or scalability of a piece of kit; devices often offer some kind of management API even if they don’t expose their full range of capabilities, or their source generally. Sometimes they can be automatically managed even if they don’t provide an explicit API: for example, Traffic team in Google supported Netscalers with a collection of perl scripts that SSH’d into the machines and redefined VIPs on the fly. (Not joking, sadly.) Traffic team was a completely legitimate SRE team despite having to work with this for some years, before a self-developed system called Maglev replaced them.</p><p>So supporting vendor kit, even kit for which you don’t have code, does not necessarily mean you can’t do SRE: if the majority is entirely proprietary or not automatically manageable, then yes, it is a major problem, but as a subcomponent, it’s not. </p><p><em><strong>Mono-repos.</strong></em> A mono-repo, while convenient in the general case, is not required for SRE to be SRE. The main benefit of it in the general case is the ability to track down a software path, derive what log messages actually mean, figure out appropriate people to talk to, and so on. If there is delayed access to segments of the code, that may have an effect on MTTR, but does not represent a conclusive blocker. (Access to source code as a general point is covered above.)</p><p><em><strong>Job title.</strong></em> SRE work does not require the SRE job title to perform. Conversely, having the SRE job title but not doing SRE work creates confusion and dismay. </p><h3 id="conclusion">Conclusion</h3><p>Though I've given you a lot of separate headings above, the summary is probably this: SRE is an <em>engineering</em> role. (The clue is in the name, I suppose!) The headings above talk about ability to write code, influence design, and so on - fundamentally, these are all proxies for the ability to do engineering. There are some practices that are perhaps more central or more peripheral than others, and there are some situations which might be temporarily bearable, particularly in startup mode - but fundamentally, if you can't do engineering, it's not SRE.</p><p>It is occasionally useful to spell out the specifics though, so if you find yourself in a position where you feel you're not doing SRE, have a look at the above list, see what's missing, and maybe you can start good conversations about fixing that. Maybe even point your leadership at this page, which could start opening the doors for actual engineering. Or perhaps it means those doors are more thoroughly locked, in which case many other companies await the arrival of motivated SREs desiring to improve their engineering abilities with pleasure.</p><h3 id="acknowledgements">Acknowledgements</h3><p>Review from David Blank-Edelman, Liz Fong-Jones, and the SREfarers crew: Narayan Desai, Laura Nolan, Emil Stolarsky, Nicole Forsgren, Jez Humble, Murali Suriar, and John Looney.</p>
</section>
<section class="post-footer">
<div class="post-share">
<span class="post-info-label">Share</span>
<a title="Twitter" aria-label="Twitter" class="twitter" href="https://twitter.com/share?text=What SRE is not&url=https://blog.relyabilit.ie/what-sre-is-not/" onclick="window.open(this.href, 'twitter-share', 'width=550,height=235');return false;">
<i class="icon icon-twitter" aria-hidden="true"></i>
</a>
<a title="Facebook" aria-label="Facebook" class="facebook" href="https://www.facebook.com/sharer/sharer.php?u=https://blog.relyabilit.ie/what-sre-is-not/" onclick="window.open(this.href, 'facebook-share','width=580,height=296');return false;">
<i class="icon icon-facebook" aria-hidden="true"></i>
</a>
<a title="LinkedIn" aria-label="LinkedIn" class="linkedin" href="https://www.linkedin.com/shareArticle?mini=true&amp;url=https://blog.relyabilit.ie/what-sre-is-not//&amp;title=What SRE is not" onclick="window.open(this.href, 'linkedin-share', 'width=930,height=720');return false;">
<i class="icon icon-linkedin" aria-hidden="true"></i>
</a>
<a title="Email" aria-label="Email" class="email" href="mailto:?subject=What SRE is not&amp;body=https://blog.relyabilit.ie/what-sre-is-not/">
<i class="icon icon-mail" aria-hidden="true"></i>
</a>
</div>
<aside class="post-tags">
<span class="post-info-label">Topic</span>
<a href="/tag/gatekeeping/">gatekeeping</a> <a href="/tag/horizontal/">horizontal</a> <a href="/tag/is-not/">is-not</a> <a href="/tag/sre-identity/">sre-identity</a>
</aside>
</section>
<div id="commento"></div>
<script defer
src="https://cdn.commento.io/js/commento.js">
</script>
<aside class="post-nav">
<a class="post-nav-next" href="/sre-practitioner-interview-series/">
<section class="post-nav-teaser">
<i class="icon icon-arrow-left" aria-label="Next post"></i>
<h2 class="post-nav-title">SRE Practitioner Interview Series</h2>
<p class="post-nav-excerpt">A quick moment for some self-promotion - I very much enjoyed this&hellip;</p>
<p class="post-nav-meta"><time datetime="02-12-2021">02 Dec 2021</time></p>
</section>
</a>
<div class="clear"></div>
</aside>
</div>
</article>
</main>
<div class="search-wrapper">
<div class="search">
<form class="search-form">
<input class="search-field" type="text" placeholder="Search …">
<button class="search-button" type="submit">
<i class="icon icon-search" aria-hidden="true"></i>
</button>
</form>
<div class="popular-wrapper">
<h4 class="popular-title">Topics</h4>
<span class="popular-tags post-tags">
<a href='/tag/models/'>models: 6</a>
<a href='/tag/sre-identity/'>sre-identity: 4</a>
<a href='/tag/slos/'>SLOs: 4</a>
<a href='/tag/organizational/'>organizational: 3</a>
<a href='/tag/incidents/'>incidents: 3</a>
<a href='/tag/planning/'>planning: 2</a>
<a href='/tag/future/'>future: 2</a>
<a href='/tag/gatekeeping/'>gatekeeping: 1</a>
<a href='/tag/horizontal/'>horizontal: 1</a>
<a href='/tag/is-not/'>is-not: 1</a>
<a href='/tag/legibility/'>legibility: 1</a>
<a href='/tag/okrs/'>okrs: 1</a>
<a href='/tag/systems-thinking/'>systems-thinking: 1</a>
<a href='/tag/google/'>google: 1</a>
</span>
</div>
<div class="search-result"></div>
</div>
<button class="search-wrapper-close" aria-label="Close"></button>
</div>
<div class="nav-footer">
<nav class="nav-wrapper" aria-label="Footer">
<span class="nav-copy">RelyAbility Blog &copy; 2026 <a class="nav-rss" title="RSS" href="https://blog.relyabilit.ie/rss/" target="_blank"><i class="icon icon-rss" aria-hidden="true"></i></a></span>
<span class="nav-credits">Published with <a href="https://ghost.org">Ghost</a> &bull; Theme <a href="https://github.com/zutrinken/attila">Attila</a> &bull; <a class="menu-item js-theme" href="#" data-system="System theme" data-dark="Dark theme" data-light="Light theme"><span class="theme-icon"></span><span class="theme-text">System theme</span> </a> </span>
</nav>
</div>
</section>
<script type="text/javascript" src="https://blog.relyabilit.ie/assets/js/script.js?v=GM11IFKYlUnuOcir"></script>
<script>
$(document).ready(function () {
var viewport = $(window);
var post = $('.post-content');
// Responsive videos with fitVids
post.fitVids();
// Format code blocks and add line numbers
function codestyling() {
$('pre code').each(function(i, e) {
// Code highlight
hljs.highlightBlock(e);
// No lines for plain text blocks
if (!$(this).hasClass('language-text')) {
var code = $(this);
// Calculate amount of lines
var lines = code.html().split(/\n(?!$)/g).length;
var numbers = [];
if (lines > 1) {
lines++;
}
for (i = 1; i < lines; i++) {
numbers += '<span class="line" aria-hidden="true">' + i + '</span>';
}
code.parent().append('<div class="lines">' + numbers + '</div>');
}
});
}
codestyling();
// Reading progress bar on window top
function readingProgress() {
var postBottom = post.offset().top + post.height();
var viewportHeight = viewport.height();
var progress = 100 - (((postBottom - (viewport.scrollTop() + viewportHeight) + viewportHeight / 3) / (postBottom - viewportHeight + viewportHeight / 3)) * 100);
$('.progress-bar').css('width', progress + '%');
(progress > 100) ? $('.progress-container').addClass('complete'): $('.progress-container').removeClass('complete');
}
readingProgress();
// Trigger reading progress
viewport.on({
'scroll': function() {
readingProgress();
},
'resize': function() {
readingProgress();
},
'orientationchange': function() {
readingProgress();
}
});
});
</script>
<!-- 100% privacy friendly analytics -->
<script async defer src="https://scripts.simpleanalyticscdn.com/latest.js"></script>
<noscript><img src="https://queue.simpleanalyticscdn.com/noscript.gif" alt="" referrerpolicy="no-referrer-when-downgrade" /></noscript>
</body>
</html>