The conversation

Lessons learnedExperience excerpt · English

What I found most fascinating is that Google essentially rediscovered what is important in a …

What I found most fascinating is that Google essentially rediscovered what is important in a sysadmin and codified the contract between feature developers and reliability roles. Instead of having feature developers feeling like they have no say in operational requirements, and instead of having reliability staff fighting unstable mess: properly making the contract means everyone gets heard. Contrasted to devops which despite coming out later was in vogue when this book came out; which caused the muddying of the role of sysadmin to meaning either: * a sysadmin practicing agile (the original definition btw) * a software engineer with enough OS skills to carry the pager (the popular one), or * a team consisting of sysadmins and software developers with no barrier between them (10+ deploys per day style). Everyone had their own definition of DevOps. So when SRE came clear: sysadmins are needed, stop trying to push everything into one person, heres how we fix the tension between teams: it was a breath of fresh air. …

Original discussionGoogle's SRE Book (2017)84 source comments · at import
5

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 5

Direct replies available in this import. Original-language excerpts.

JU

I don't think that's how the SRE role is described in the book. It shifts the boundaries between sysadmins and developers to give developers much more freedoms in deciding the operational parameters of how their softwane is run/released but also gives SREs the ability to push back if they get handed over some piece of software that's not sufficiently following recommended patterns that make actually operating it mostly automated.

Full original
RA

Sysadmin originally meant Unix greybeards who were competent at C and could write and implement, say, Kerberos. Then in the 90s-2000s the term came to primarily refer to Windows admins clicking around Active Directory and Group Policy for large enterprises. The "sysadmins can't code" thing came grom that time and the early 2010s when all the cool startups were building on Linux and the available pool of sysadmins were largely Windows specialists. Then DevOps came along trying to get Windows sysadmins that were dabbling in Linux into modern development practices, and SRE came along trying to revitalise the old Unix greybeard style with modern software development practices.

Full original
OO

That may what sysadmin meant back in the 80s and 90s but it's not what it means now. I would never describe myself, a SRE-SE, as a sysadmin because I would be describing someone whose primary job is to operate software and iterate on configuration. SRE-SEs on the other hand are SWEs, they just have a focus in systems adjacent software whereas a SRE-SWE is someone who can dig into compiler level issues and optimization. Both write application code, do analysis, and write policy. A sysadmin of today would be out of place on a team like that.

Full original
AL

* SRE are sysadmins with Go * DevOps are sysadmins with Python * Sysadmins are sysadmins with Perl (stolen from twitter, can't find the source)

Full original
DO

I think you’re right, but I want to relate a story where the agile team leader decided that devops meant “developer operations”, or in other words the development team. Sometimes all you can do is shake your head.

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.