AN APPROACH TO DEVOPS

A talk by Kamal Manglani

Why are we doing Devops? Co-create a vision!

Your story is unique to your company…

Single Operator, Stopped automatically if there was an error

1.SLA violations 2. Un-clear requirements/ poor quality delivery/ defects 3.Burnout of specific members 4.Almost no visibility 5.Constant escalations

PRE-DEVOPS

Devops mindset enables high-performing organizations(teams) to have a fast flow of features from dev to ops retaining high quality

reliability and stability.

The leadership team must be ready for a real change in Infrastructure operations and ensure organizational awareness that ops is an “Internal Customer” to dev, portfolio and product management. Organizations need to realize DevOps is where the value gets realized. Think of it as ValueOps not just DevOps.

Simplified Roadmap for Devops enablement

key metrics

Lead time: time to enable a feature from concept to release MTTR - average time required to repair a failed service/ component

Number of deployments (experiments) & outcomes Customer Satisfaction

Examples of monitoring and alerting to get ahead of the problem:

3 ways of Devops thinking

first way: look at the system as a whole. Do not optimize individual components.

This implies treat the next application or service using your data/ payload as a customer! (do not pass bad data/ bugs downstream)

Bring the downstream application owners/ infra owners to inceptions and sprint reviews

Integrate early and often via automation

Second way: Establish a valid fast feedback loop. Hire fearless members who can give quick feedback and fix things

faster.

Automate alerts and monitoring Enable small deployments with light weight processes

Deploy often AB testing

Third way: include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing

faults into the system to increase resilience.

Automation regression tests reward proactive alerting and monitoring

service resiliency e.g. chaos monkey

Stretch the definition of the DevOps term to fit Product Owners, without them it is just not effective enough.

In order to minimize the risk of deploying something broken As the team deploying the code

We want to spend a few days on an automated deployment system.

Verify that all web-based requests get thru the service layers and receive a reply within 2 seconds

Infrastructure Story

Shared tools across Dev & Operations

Stand ups and Big Visible Information radiators

DevOps needs stand ups not within infrastructure but within the value stream. It is tricky to give status to every development team hence a simple visible board to reflect backlog / in-progress (WIP LIMIT) / Review & DONE will go a long way in improving customer satisfaction and visibility.

Stand ups or a Daily Ops review

http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html

Information radiators and build failures & shared pipeline

we build quality inDevelopers and Infrastructure must start to talk in the same language through tools.Have a strategy for the deployment pipeline. Don’t just look at it as code line up but as a Value Stream right from Product Management to Deployment. Ensure every team and department managing a high quality deployment pipeline. Every time there is a code failure it must be fixed right then, validated and deployed in the respective environments, this will enable you to keep all your environments in sync with updated with code/bug fixes.

Remove excessive approval gates in terms of heavy bureaucratic change management meetings

optimize hand off - no one size fits allEnsure your organization has a decent portfolio management framework that uses the unit of capacity as team not as headcount only. Portfolios should look at whole teams servicing a market/ P&L rather than just headcount and ideally these product-centric teams will remain intact beyond the “project”. This is especially important when you are dealing with large scale. Enable and empower engineers on the team to pick up cross functional skills for example a Sys Admin must be able to work on cloud compute as well as physical hardware, and on various operating systems.

Change the performance review process and make it more team centric than individual performance.

Example of Infrastructure squads at spotify

Devops Health check

https://labs.spotify.com/2014/09/16/squad-health-check-model/

There will never be a perfect devops team! Constantly evolving!

Goal is to eliminate wait time & hand off.

Tranformative role - Agile coach:

As an Agile Coach you are passionate about communication, group dynamics and coaching and you are not afraid to raise issues and drive change to remove impediments from your team.

You should have an insatiable appetite for learning new things and improving existing ones, you pay attention to details and take great pride in your work.

Someone who can help management at all levels of the organization to understand the benefits of working agile

Someone who has brought the ideas from professional facilitation, coaching, conflict management, meditation, theater, and more, to help the team become a high-performance team - the way you always imagined a high-performance team could be when you allowed yourself to dream

One approach to enterprise Agile adoption that is gaining traction is to establish an Enterprise Agile Working Group (AWG), a group of

people dedicated solely to the implementation of Agile at the enterprise level. An AWG can greatly reduce risk, increase the speed

and establish a sustainable engine for growth of the enterprise transition of Agile in the enterprise.

What is an AWG? An AWG is a Scrum team whose product is the enterprise

implementation of Agile. Although it does not necessarily produce software (it certainly could if it helps add value to the product), it

works on a prioritized list of backlog items that is demonstrated to a set of stakeholders in a predictable, set cadence. Let’s have a look at

why establishing such a group can be so powerful when implementing Agile at the enterprise level.

http://www.slideshare.net/SherryChang/evolving-team-structure-in-devops http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262509 http://www.infoq.com/presentations/devops-culture-practices-flow http://continuousdelivery.com/wp-content/uploads/2011/04/deployment_production_line.pdf https://www.agilealliance.org/wp-content/uploads/2016/02/AWG.pdf http://www.slideshare.net/InstitutLeanFrance/leadership-spotify-by-kristian-lindwall-at-the-lean-it-summit-2014

References