<div dir="ltr">Jorden,<div><br></div><div>Thanks for comments and can't say I disagree with any of them. It's worth noting that SRE is an immature discipline while Google is a large, fairly disciplined mega-company (~ 50k engineers of which SRE makes up about ~ 2k). Different product teams and SRE teams linked to them operate differently based on maturity of the services and teams. Like Kubernetes, having SREs may not make sense for smaller organisations.</div><div><br></div><div>Couple of comments on specific points:</div><div><ul><li>Oncall rotations for developers: The philosophy here was two fold: 1) build relationships between the product dev and sre teams such that performance, operational requirements were included from early on in the development process and 2) as a stick to ensure developers didn't chuck solutions with high opex cost over to the SRE teams. #2 was rarely used but an effective deterrent with management support.<br><br></li><li>"Error budgets" are objective measures in a place where it's easy to be subjective. How bad is "we've been serving 500s for 1 hour..."? It's an effective tool for setting expectations and communicating to wider audiences ("why are these features not shipping?"). It is unlikely to be needed in smaller, less mature settings. I would certainly expect it to be used in a performing SRE team but probably not in a "forming" or "storming" team.</li></ul></div><div><br></div><div>I would certainly advocate for picking the skills and philosophical pieces from the SRE "toolbox" that make the most sense for the OSMF at this point in time.<br></div><div><br></div><div>For me, the following areas make the most sense for the OSMF to invest in, in 2020 (based on my limited knowledge):</div><div><ul><li>Capacity planning</li><li>Resource optimisation (i.e. reduce the cost of delivering the current services)</li><li>Automation (releases, change management, etc)</li><li>Monitoring and alerting</li></ul></div><div>Any of those could take 12+ months to design, plan and implement with an average SRE team so expectations should be set appropriately.</div><div><br></div><div>From what I've read so far in the thread, both the board and existing system administrators are supportive of the additional support. Finding the right candidate will not be trivial but will add a lot of value.</div><div><br></div><div>Regards</div><div><br></div><div>Donal</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 26 Jul 2020 at 15:55, Jorden Verwer <jorden@verwer.express> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
It's been a while since I last participated on this mailing list, but <br>
this subject drew my attention. See, all the people I know that call <br>
themselves "Senior Site Reliability Engineer" are just glorified system <br>
administrators - and not particularly good ones at that. Now that I know <br>
that this term is just a Googleism, it makes more sense - there is a <br>
broad desire in the industry to emulate Google, because Google is <br>
successful (for certain definitions of the term "success", anyway), so <br>
emulating them must necessarily lead to success for other organizations <br>
as well, right? And obviously it's enough to just copy the labels <br>
without actively implementing any meaningful changes, because then <br>
everything else will automatically fall into place...<br>
<br>
Cynicism aside, I recognize that there may be valid reasons for adopting <br>
a new approach to system administration, I just don't think one should <br>
blindly follow Google in any matter. Google has a tendency to behave <br>
very idiosyncratically, sometimes even going against basic design <br>
principles of systems they use. While this may or may not work for them, <br>
it often doesn't work for others, especially those that don't understand <br>
the "why" of Google's approach and concentrate only on the "how" (which <br>
they often don't really understand either). Please note that I'm not <br>
accusing OSMF of any of this, I'm just explaining my reasons for <br>
replying.<br>
<br>
Reading through the introductory chapter of the book that was mentioned <br>
earlier, one piece in particular had me worried:<br>
<br>
"And once an SRE team is in place, their potentially unorthodox <br>
approaches to service management require strong management support. For <br>
example, the decision to stop releases for the remainder of the quarter <br>
once an error budget is depleted might not be embraced by a product <br>
development team unless mandated by their management."<br>
<br>
The "we're out of money, drop everything" line of thinking is extremely <br>
orthodox. I hope I'm misinterpreting this text fragment, because if its <br>
authors truly think this is an unorthodox approach, I see no reason to <br>
take anything else they say seriously either.<br>
<br>
Something else caught my eye as well:<br>
<br>
"integrating developers into on-call pager rotations"<br>
<br>
This is a bad idea. Most competent developers don't want to waste their <br>
time on such menial jobs. I recognize that it's sometimes a necessity in <br>
smaller organizations, but bigger organizations waste their talents by <br>
making developers perform operational chores. To be fair, they do <br>
present a credible rationale for this approach, but I think developers <br>
should be held accountable for excess operational workloads caused by <br>
their efforts regardless of arbitrary limits like the 50% criterion that <br>
is mentioned here.<br>
<br>
Then later on it turns out that they committed the cardinal sin of using <br>
a term they made up ("error budget") before defining it, causing me to <br>
erroneously interpret it as a financial concept through no fault of my <br>
own. I'm intentionally not going back to edit the earlier part of my <br>
email, to show you just how annoying this is. I'd recommend attending a <br>
high-quality course in technical writing to prevent this from happening <br>
again. And yes, I realize I'm barking up the wrong tree here, but I just <br>
had to vent.<br>
<br>
Having said all that, I do think some aspects of "the Google approach" <br>
are certainly valuable and insightful, especially the part about <br>
monitoring. I'm certainly not dismissing it outright. It actually seems <br>
to be one of the better "DevOps" (a term which is far too broad to <br>
really be meaningful) approaches out there. And I certainly don't want <br>
to tell others how they should be doing their jobs, so I won't. If this <br>
is how the volunteers want to strengthen their team, I won't tell them <br>
otherwise. If, on the other hand, this is something the board wants and <br>
the people doing system administration were involved merely to <br>
rubber-stamp the board's plan, so to speak, then I'd like to encourage <br>
them to openly voice any objections they may have. I don't know which <br>
scenario is correct and which isn't, but the people who need to know <br>
certainly do.<br>
<br>
All in all, I'd be willing to give this a try, but the permanent (or <br>
open-ended) nature of the proposed employment contract makes this <br>
impossible. Furthermore, my experience in leading and participating in <br>
volunteer organizations that employ paid staff as well has taught me <br>
that such a setting requires even more time than usual to evaluate an <br>
employee's fitness for a particular function. Therefore I would like to <br>
suggest starting out with (for instance) a one-year contract and then <br>
starting a thorough evaluation at about three quarters of that time. Of <br>
course, an employee that's clearly dysfunctional should be fired <br>
earlier, but I'm talking about the "We're okay with what you've been <br>
doing so far" scenario. You'll really want to ask yourself the question <br>
if this person is a good long-term addition to the team, leaving open <br>
the option that despite all their good work, the answer is no.<br>
<br>
Regards,<br>
<br>
Jorden<br>
<br>
_______________________________________________<br>
osmf-talk mailing list<br>
<a href="mailto:osmf-talk@openstreetmap.org" target="_blank">osmf-talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/osmf-talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/osmf-talk</a><br>
</blockquote></div>