SRE

common vocabulary building starts with education & awareness and not leaving anyone behind

Do incident post mortems help non engineers understand incidents? @bajpaigarima1

the business leaders should also talk in the same vocabulary as engineers.. ;)

Postmortems are great for eng + devops teams to learn but how do you elevate to others?

connecting the business, users and technology with a common language is a typical task of a business analyst

@WSzepesi the in-between 'glue' is helpful but it doesn't bring the teams closer together. it's a translation agent

Sales, marketing, CS, and product teams could really leverage reliability as a distinct advantage over their closest competitors. The next step is simply to get business and SRE teams on that same page by focusing on user experiences.

But when developers are shipping hundreds of changes every day, can the biz analysts really keep up? It's important to practice empathy across all biz functions - which requires people to understand each other's values and language

I think by crafting retrospectives to include a breakdown of user impact, other teams can use them to understand how users are feeling and what solutions they can bring to help them

Yes, the whole requirement for Business Analysts is caused by different cultures needing a translator!

AI based monitoring

-Buy-in mindset and not carrying the same baggage from the past

Reliability Engineering platform - is for everyone #lowcode

Datascience integration into SLI,SLO modelling , error budgets & policies

auto remediation engine??

agreeing on SLOs is really hard for disparate, large teams

@RjSriram15 interesting

Integrating with the tools used across the pertinent teams - reduces the onboarding effort

SLOs and SLIs to contextualize based on user impact

integrating - SRE tools and orchestrating it in secure & reliable way

Reliability doesn't only mean fixing the issues, but also the communication to customers as these issues are being fixed. Communication is something that a lot of service providers struggle with, which can impact how users view how "reliable" a service is.

Effectively collecting info across all systems (both social and technical) which contribute to the systemic reliability is key

@drkurta how do we add features of social engineering to #SRE platform

@bajpaigarima1A Reliability Engineering platform is about people, processes and tools and automation and how data and communication flows.

@drkurta something like gamification

So far, facilitating reflection through retrospective processes along with the good management practices that support psychological safety is the best that we have

The field of cognitive systems engineering has a lot of insight on how to reduce cognitive load and make the tools into good co-workers

(edited)

Welcome -we are eager to have your views on this topic :-)

Welcome!

Welcome @oleg_nenashev! SLO is a concept which has been around for years. There seems to be a renewing interest for SLO management. Why is that?

@NicolasPhilip8 The industry achieved a lot in application monitoring and analysis, with AI like @Dynatrace Davis AI making miracles happen.

At the same time standard met do not represent impact on users well. It influences finances, not a container being down. Hence SLOs

+1. Not all services need 99,999 or any other reliability for a casual life service. What they need is a good UX, especially responsiveness, data consistency, and sometimes security.

@oleg_nenashev optimizing for many SLIs is challenging especially as the company scales and new features are added. How often should you review SLIs / SLOs?

Continuous all the things! SLIs should be reviewed every time a component changes; SLOs should probably be reviewed at least quarterly.

At least every quarter IMHO. I am actually a big fan of OKRs when they are done right, so for me reviewing SLOs/SLIs are a part of the OKR process. Just because SLOs make good objectives too

- 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