Adopt Google SRE and DORA practices to become a software company

Get Started. It's Free
or sign up with your email address
Adopt Google SRE and DORA practices to become a software company by Mind Map: Adopt Google SRE and DORA practices to become a software company

1. Catch the opportunity

1.1. The digital economy is growing faster

1.2. The first mover get an advantage

1.3. Startup agility matters more than large enterprise size

1.4. The digital natives go to digital

1.5. Keep value generation inside

2. Know what is hard early

2.1. Innovator & Reliable

2.1.1. Reliability

2.1.1.1. If it is not reliable enough then all other features are ignored by the users

2.1.1.2. So, reliability IS the key feature

2.1.2. Velocity

2.1.2.1. Empower a short time to market

2.1.2.2. Digital lower entry barriers and facilitate volatil user behaviour

2.1.2.3. So, velocity is the essence of the digital economy

2.1.3. Problem statement

2.1.3.1. Up to now stability = slow or no changes

2.1.3.2. 70% of production outages = changes

2.1.3.3. Developers rewarded on velocity

2.1.3.4. Operations rewarded on stability

2.1.3.5. This structural misalignment generates

2.1.3.5.1. Conflicts

2.1.3.5.2. Siloed behaviours

2.1.4. Solution idea

2.1.4.1. Being able to release FAST and STABLE, is the new capability to win the digital competition

3. Go for hybrid

3.1. Keep the classical model

3.1.1. Cost efficient but not designed for agility

3.1.2. Is definitely valuable and will persist for a whole family to IT workloads

3.1.3. Is certainly not adapted to operate the new digital workloads

3.2. Add Innovation & reliability capabilites

3.2.1. to unlock digital grow in a sustainable maner

3.3. So that it respect

3.3.1. the opportunity

3.3.1.1. Digital workloads need a specifiy Fast & Fiable new paradigm

3.3.2. the users

3.3.2.1. The digital natives go to digital

3.3.3. each others

3.3.3.1. Legacy is great when cost driven matter most

3.3.3.2. Fast & reliable is great when time to maket matter most

3.3.3.3. Hybrd value diversity

4. How Google can help

4.1. Site Reliability Engineering

4.1.1. Balance

4.1.1.1. vs

4.1.1.1.1. innovation cadence

4.1.1.1.2. reliability

4.1.1.2. measuring the user experience

4.1.2. SRE How ?

4.1.2.1. CUJ

4.1.2.1.1. 1. Identify business critical app with short release cadence

4.1.2.1.2. 2. Identify most important feature, aka Critical User Journeys

4.1.2.2. SLI

4.1.2.2.1. Service Level Indicator

4.1.2.2.2. Measure customer experience

4.1.2.3. SLO

4.1.2.3.1. Service Level Objective

4.1.2.3.2. Estimate the happiness threshold for most of the typical users

4.1.2.4. Error Budget Policy

4.1.2.4.1. Error means

4.1.2.4.2. Budget means

4.1.2.4.3. ErrBdg

4.1.2.4.4. Define WHAT HAPPEN WHEN

4.1.2.5. Benefits

4.1.2.5.1. Customer centric

4.1.2.5.2. Friction less

4.1.2.5.3. Context aware

4.1.2.5.4. Get rid of the meaning less 100% target

4.1.2.6. Beyond Error Budget

4.1.2.6.1. Risk on SLOs

4.1.2.6.2. Blameless postmortems

4.1.2.6.3. Engagement model

4.1.2.6.4. Wheel of misfortune

4.1.2.6.5. Incidents / on call / rotations

4.1.2.6.6. Toil reduction

4.1.2.6.7. Capacity management

4.1.2.6.8. Non Abstract Large System Design NALSD

4.2. Dev Ops Research Assessment

4.2.1. Balance

4.2.1.1. vs

4.2.1.1.1. throuput (dev velocity)

4.2.1.1.2. stability

4.2.1.2. implementing statistically proven DevOps good practices

4.2.2. DORA How ?

4.2.2.1. DORA reseach program

4.2.2.1.1. DevOps Research Assessment

4.2.2.1.2. Why

4.2.2.1.3. What

4.2.2.1.4. How

4.2.2.1.5. Where

4.2.2.2. Performance

4.2.2.2.1. 2 dimensions => 4 key metrics

4.2.2.2.2. Statistical perf references

4.2.2.3. Capabilities predict perf

4.2.2.3.1. Technical

4.2.2.3.2. Measurement

4.2.2.3.3. Process

4.2.2.3.4. Cultural