This is absolutely true. But 1) infrastructure as a service has enabled up the stack sw teams to not have to be experts in infrastructure, and 2) if the people who write software don't know how to operate it at scale, a SRE team isn't going to make it magically operate at scale.
-
-
I think we're in violent agreement; I think your argument is predicated upon an incorrect understanding of what SRE is. My argument is that SRE is a partner team of specialists that helps product dev teams write better software, rather than being a team that just does the ops.
1 reply 3 retweets 19 likes -
Replying to @lizthegrey @_msw_ and
and indeed, I'd regard SRE of 10 years ago as an antipattern. Certainly
@maascamp,@whereistanya, and others have been pushing harder and harder on the "SRE is a prod force-multiplier, rather than always needing to do some degree of ops" angle. That's what I'd call modern SRE.1 reply 1 retweet 4 likes -
Replying to @lizthegrey @migueldeicaza and
I am indeed talking about SRE of 10 years ago, not modern SRE. The tweet at top of the thread triggered my "building ops teams is an antipattern" response.
1 reply 1 retweet 1 like -
Replying to @_msw_ @migueldeicaza and
Ah. I think that what
@maascamp said perhaps required some explication about how it applies to modern SRE teams: (1) SREs (regardless of org structure) need to touch prod to understand the problems (2) The more services they work on, no matter how small each service's burden...1 reply 0 retweets 3 likes -
Replying to @lizthegrey @_msw_ and
... means that there's a tendency of the ops work to increase and swallow that SRE's time unless you bound the fraction of time they spend on toil. so (3) while we try to reduce the support load of each service, both to help the SRE and the product dev SWE team running it...
1 reply 0 retweets 2 likes -
Replying to @lizthegrey @_msw_ and
you need to have a concrete limit on how much time an SRE spends touching prod - >10%, <40%. And that means an SRE can never support infinity services. Does that maybe better contextualize?
3 replies 0 retweets 3 likes -
Replying to @lizthegrey @migueldeicaza and
At AWS the teams that partner with service teams to help develop operational excellence (e.g., by facilitating operational readiness review, running the weekly ops meeting, and building tooling for cross service health visibility) *never* touch prod services built by other teams.
2 replies 1 retweet 7 likes -
Replying to @_msw_ @migueldeicaza and
I'd be very interested in hearing a talk by some of those folks. The SREcon Asia CfP is open and we've noticed that we never seem to hear from Amazon. Can you pass the CfP onto the right people at Amazon?https://www.usenix.org/conference/srecon19asia/call-for-participation …
1 reply 0 retweets 2 likes -
Replying to @lizthegrey @_msw_ and
I think that the only way that we can really get a shared conversation is to talk to each other, and I appreciate that you've engaged here even though you've gotten pushback from myself and others <3
2 replies 0 retweets 3 likes
I'll write and post a bunch on my take on our (Amazon) BizDevOps approach next week. The way we even frame things is so different that it really deserves a long treatment to contextualise and convey.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.