Demystifying DevOps for Ops

Including Findings from the 2015 State of DevOps Report

Presenters

Alanna BrownSr. Product Marketing Manager

Carl CaumTechnical Marketing Manager

Agenda

• Building the Case• Current State vs. Desired State• Challenges• Team Structure• Technical Practices• Resources• Q&A

Building the Case

People don’t buy what you do, they buy why you do it.

Simon Sinekhttp://bit.ly/sinektedtalk

Reliability

Agility

Opposing Forces

High-performing IT orgs are more agile

30xMore frequent deployments

200xFaster lead times than their peers

Source: Puppet Labs 2015 State of DevOps Report

High-performing IT orgs are more reliable

60xChange success rate

168xFaster mean time to recover (MTTR)

Source: Puppet Labs 2015 State of DevOps Report

High-performing IT orgs are winning

1.5xMore likely to exceed profitability, market share & productivity goals

50%Higher market capitalization growth over 3 years.*Source: Puppet Labs 2015 State of DevOps Report

Learning is not compulsory, but neither is survival.

Edward W. Deminghttp://bit.ly/deming14pts

Current Statevs

Desired State

Organization

Low trust culture High trust culture

Siloed teams Cross-functional teams

Lack of alignment Aligned around business goals

Processes

Lots of manual work Mostly automated work

Long cycle times Short cycle times

Poor visibility Fast feedback & insight

People

High burnout High job satisfaction

Stagnant Able to grow

Checking boxes Creative innovation

Continuous Delivery Practices

Lean Management Practices

Challenges

“Trying to effect process, people, technology and cultural changes across the entire application

portfolio, in a globally dispersed team and with a lot of associated technical debt, is an epic challenge.”

Jonathan Fletcher Enterprise Architect and Lead for Technology,

Platform and DevOps at Hiscox http://bit.ly/devopshiscox

Conflicting Incentives

Business Delivering value to customers

Dev teams Delivering new features

Ops teams Ensuring stability of systems

Quality teams

Ensuring quality of software releases

Everyone is responsible for quality and we’re all trying to

deliver the best solution for our customers.

Reena Mathew, Principle Architect Quality Engineering, Salesforce

http://bit.ly/sfdevops

Aligned Incentives

Delivering value to

customers

Business

Ops teams

Quality teams

Dev

teams

We can’t do DevOps because our application is

________________________.

Team Structure

Typical Enterprise Org StructureIT Operations

NOC

Commercial Banking

Business Units

Credit Cards

Mortgages

Investment Banking

Systems Engineers

Network Engineers

Storage Admins

DBAs

InfosecDev teams reside in BU

Type 1: Smooth Operations

Dev Ops

Recommended Reading: http://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/

Type 2: Cross Functional Teams

Delivering value to

customers

Business

Ops teams

Quality teams

Dev

teams

Type 3: Dedicated DevOps Team

Dev OpsDevOps

Roles & ResponsibilitiesRoles Responsibilities

“The Business” Understand market trends and identify customer needs

IT Manager Build trust with counterparts on other teams; create culture of learning and continuous improvement; delegate authority; remove roadblocks

Dev Manager Build trust with Ops counterpart; bring Ops into the planning process early

Systems Engineer Automate the things that are painful; help devs get feedback

QE Provide input into scale and performance; provide feedback on staging environments

Devs Plan for deployment as you’re planning new features; get feedback from ops and work with them on deployment process

Technical Practices

Version Control

Configuration Management

Continuous Integration

DeploymentTools

Monitoring

And others…

DevOps Toolchain

Infrastructure as Code

Infrastructure as Code

Version Control

Peer Review

Continuous Delivery

Collaboration IterationFast

FeedbackVisibility

Version Control

Source: Puppet Labs 2014 State of DevOps Report

Peer-Reviewed Change Process

• Code can be contributed by anyone

• Code changes can be reviewed by anyone

• Code can be worked on as a team

Continuous Delivery

• Code is repeatable

• Code is sharable

• Code is promotable

• Code is testable

Measuring Results

• Ask your team: “How painful are your deployments?”

• Deployment frequency• Downtime• Change lead time (from dev’s laptop to

production)• Change fail rate• Mean time to recover

Q&A

Resources• The 2015 State of DevOps Report is here! puppetlabs.com

/2015-devops-report

• The Phoenix Project by Gene Kim

• Continuous Delivery by Jez Humble

• PuppetConf 2015: http://2015.puppetconf.com/

• DevOps Enterprise Summit: http://devopsenterprise.io/