SRE

- how do you reduce toil?

@_YEG SRE practices like building proactive resources for incidents (runbooks, etc), using SLOs to not overreact to incidents, investing in infrastructure that reduces redundant work... these SRE methods and more reduce toil :)

@_YEG 1-Recognize it; 2-Invest the time/resources to automate

99.999% of environment availability :)

SRE brings a perspective of the value being delivered to the customer more so than devops which usually stops at delivery into production.

turning around the business model. - from reactive to proactive

SRE practices is rather complementary to DevOps. It focuses on customer satisfaction.

@drkurta Excellent - so Ops into DevOps :-)

@RjSriram15 But why? Can you substantiate the cost/value trade-off? Especially if the underlying network infra is less reliable?

Understanding customer journey is really hard for eng teams #sre

treat issues with same respect as new features / enhancements

Establishing a "universal language" across the whole org of reliability based on user happiness

Top to down approach - renegotiating contracts. - move away from SLA driven approach

SRE can also help with scaling individual devops team practices across the organization - working as a platform team (a la _Team Topologies_)

preventing churn - continuous relationship rather one -time contract

SLA --> SLOs & SLIs --> OKRs

focusing on how the end user/customer is impacted across all aspects of development and operations

Writing your customer journey + success is hard. If the business can't do it - engineers don't have a chance to succeed. #sre #devops

@RjSriram15 At a certain point of baseline reliability, you need to focus on containment and quick remediation of incidents to achieve more overall reliability.

> SLIs --> OKRs

This part is a subject for debate. SLIs should be indeed metrics for measuring Key Results in the OKR framework, but at the same time not all KRs should be measurable as SLIs

@oleg_nenashev yes indeed words matter too. sticking with the agreed objective for time to learn is key. orgs tend to have little patience

(edited)

@RjSriram15 or the other direction?

@dbmahon indeed many orgs have little patience and even less long-term strategy. Some of them confuse lack of patience and failing fast unfortunately. So they always fail...

@DBMahon most of the organizations today are reactive and are still at SLAs.. There should be a roadmap to move in both the directions

Shared responsibility model .. collaboration

Adopt customer first mindset

.@bajpaigarima1 The key ingredient is definitely psychological safety and a generative culture (in the Westrum typology)

Looking for systemic causes of problems to make meaningful improvement, instead of just blaming an individual

Can you elaborate on generative culture ?

Automation can be one aspect to look at as well

Shift -right ..

established expectations of various roles, especially during incidents, in order to drive continuous learning

.@bajpaigarima1 Westrum's generative culture is characterized by performance orientation, high cooperation, shared risks, failure leads to inquiry, implementing novelty

By establishing roles and expectations across various teams/functions, this allows for promoting safe, high cooperative "blameless" cultures, focusing on objective/factual based conversations, especially during high stress situations

Thanks for having us! :)

Happy January 2022!

Glad to be joining this live online chat about the Reliability trends for DevOps!

Thank you @bajpaigarima1, Blameless is excited to be here!

(edited)