3 ms·

SRE seems the better approach. Make an error budget, measure reliability, stop releasing in favor of reliability engineering if the budget is missed, use the fr

by ipnon 4y ago

SRE seems the better approach. Make an error budget, measure reliability, stop releasing in favor of reliability engineering if the budget is missed, use the free time reduce toil. DevOps seems to degrade to disorganization because the incentives are not aligned between product development and software engineering.

jameshart 4y ago
“Make an error budget, measure reliability, stop releasing in favor of reliability engineering if the budget is missed” These are all things that fall in the realm of ‘ops’. ‘Dev’ops is an approach to ‘doing ops’. It is one that adopts certain practices that are common in ‘dev’elopment - such as defining things programmatically, using automated repeatable processes to generate work product, and using automated testing and verification. So what you describe as ‘SRE’ doesn’t seem to me to be ‘not devops’. Seems like a set of ideas that would benefit from a devops kind of approach.
tootie 4y ago
I think you've hit at the heart of the problem, but swapping the DevOps model for SRE is robbing Peter to pay Paul. Last place I worked with a 100+ person tech team had more of an SRE model. The SRE team were charged with reliability. They had no incentive to delivery features or to improve developer experience. As a result, developer tools sucked, there was s rigid release schedule, every bug was met with a rollback. This was probably an extreme case because the team was also not very good, but either way it was a clear case of misaligned incentives. The entire point of DevOps was collective ownership with a shared goal of customer value that is function of feature richness, quality and reliability. It's the Holy Grail of efficiency, it's just really hard to build that kind of culture.
- ipnon 4y ago
  Seems like the sweet spot is DevOps style reliability ownership with SRE style indicators, objectives and agreements.
jedberg 4y ago
If you think SRE and DevOps are opposed to each other, then you might be doing one of them wrong. I headed up SRE at Netflix, and our sister teams wrote the software and managed the tools that enabled the developers to continuously deploy and operate their own services. We were in charge of reliability, but we did it through chaos testing and accountability, and enhancing the deployment tools to warn devs that they might be doing something high risk, but still letting them do it.

by ipnon 4y ago

jameshart 4y ago

“Make an error budget, measure reliability, stop releasing in favor of reliability engineering if the budget is missed” These are all things that fall in the realm of ‘ops’. ‘Dev’ops is an approach to ‘doing ops’. It is one that adopts certain practices that are common in ‘dev’elopment - such as defining things programmatically, using automated repeatable processes to generate work product, and using automated testing and verification. So what you describe as ‘SRE’ doesn’t seem to me to be ‘not devops’. Seems like a set of ideas that would benefit from a devops kind of approach.

tootie 4y ago

I think you've hit at the heart of the problem, but swapping the DevOps model for SRE is robbing Peter to pay Paul. Last place I worked with a 100+ person tech team had more of an SRE model. The SRE team were charged with reliability. They had no incentive to delivery features or to improve developer experience. As a result, developer tools sucked, there was s rigid release schedule, every bug was met with a rollback. This was probably an extreme case because the team was also not very good, but either way it was a clear case of misaligned incentives. The entire point of DevOps was collective ownership with a shared goal of customer value that is function of feature richness, quality and reliability. It's the Holy Grail of efficiency, it's just really hard to build that kind of culture.

ipnon 4y ago
Seems like the sweet spot is DevOps style reliability ownership with SRE style indicators, objectives and agreements.

jedberg 4y ago

If you think SRE and DevOps are opposed to each other, then you might be doing one of them wrong. I headed up SRE at Netflix, and our sister teams wrote the software and managed the tools that enabled the developers to continuously deploy and operate their own services. We were in charge of reliability, but we did it through chaos testing and accountability, and enhancing the deployment tools to warn devs that they might be doing something high risk, but still letting them do it.