The Site Reliability Workbook: Practical Ways to Implement SRE [pdf]
services.google.com
services.google.com
Rather than just talk about how we're supposed to do this stuff, we can share how we actually do it. Pick some recipes (procedures, configs, documentation, tooling, workflows, etc), learn from previous teams, and go to town. Contribute back the things you've done/changed/learned to the wiki.
I bought the domain sre.pizza because it was funny and easy to remember. I can set up a wiki there this weekend...
[1] https://en.wikipedia.org/wiki/ITIL [2] https://en.wikipedia.org/wiki/IT_risk_management [3] https://en.wikipedia.org/wiki/Information_technology_managem... [4] https://en.wikipedia.org/wiki/Operations,_administration_and... [5] https://en.wikipedia.org/wiki/Operations_management [6] https://en.wikipedia.org/wiki/Network_and_service_management...
Their report breaks down some stuff on what should be done on what maturity level and then it shows data on how many actually are doing it.
edit: a web search picked up https://www.bsimm.com/content/dam/bsimm/reports/bsimm8.pdf, I'd guess it's this one.
companies SRE efforts range from world leading to fiscally irresponsible- and revealing the latter to the world will be actionable - against the "whistle blower" and yourself (publisher).
Wikileaks looks like it does to protect against that. (partially)
So you can either look like wikileaks, and have a genuine survey of current state of play, or you can have a "this is how we did awesome SRE at the tiny portion of the big co I was employed by" talks.
I don't have an answer if you are in the irish countryside and want to start from somewhere else.
That would be a question worth answering
And the companies that are likely to be jerks about it are unlikely to be doing interesting SRE work. I'd like stories of hard-won success (or cautionary tales of failure), not just ranting about how much Company X sucks and how broken they are.
And the legal department will be jerks if the latter get the spotlight.
Please launch it - I hope it will do well.
We're a small team and we started implementing SLOs for services, we're slowly building our SRE teams, with the purpose of "SRE embeds" in existing engineering teams.
A must read for anybody that wants to do systems engineering / devops / whatever sys admins are called these days. A must read for any technical lead.
Copying their full process probably won't make you the next Google, but figuring out how to take their learnings and apply them at the right time is a great way to give yourself a leg up.
Collectively tech seems to evolve rapidly but at the individual/team/org level it’s rife with cargo-culture and resistance to change. It’s not even exclusively caused by stubborn behavior since change requires time and resources that may not be afforded to teams unless they can hitch it to a feature or initiative. When the big players level up industry practices they decrease the defensibility of sticking with old ways. New tools designed around the new principles and a million blog posts changes the landscape.
Show me any org or decent sized team and I’ll find you members of it that could have told you what needs to change in their environment to get to the next level but face an uphill battle. The big players not only give them supporting evidence with moves like this, they raise the bar or shift our entire thinking. Without that shift the holdouts can hide behind a lack of consensus and cargo culture.