How to do devops wrong

Post on 22-Apr-2015

904 views 10 download

description

This months talk from DevOps.Net's James Betteley, gives us an experience report on how easy it is to get it wrong when key individuals don't get "on message". What's interesting is the differences in the behaviour and the language used by the teams who don't get it compared to the teams that do. About James Betteley Many years ago, someone decided to put me in charge of doing builds and releases of software. I can't remember why, I think everyone else was out at lunch. I inherited a system of batch files, shell scripts and all sorts of weird and wonderful things which, to this very day, I still don't understand. Since then I've made it my job to debunk complicated software systems, automate as much as possible and just try to make things more sensible. My main driver is bringing real business value through great Development & Operations processes, whether that be by using tools or implementing a new process or culture. For more information about me and what I get up to, check out my blog at: http://devopsnet.com/

transcript

DEVOPS CARDIFF

Organisers Sponsors

October ‘14

With James Betteley

DevOps

Doing it wrong since 2009

Who, What, Where…

@jamesbetteleyjames@devopsnet.com

…Why?

What Will I Get From This Talk?

• Free beer!• Insight into how to make an enterprise

scale balls-up• Free pen!• Eternal wisdom (if we have time)

WTF *is* DevOps?

“Getting people to care about stuff that they don’t normally really care about that much, and then doing that stuff until it becomes natural”

IT’S A CULTURE!

Examples of a DevOps Culture

• Deployability as a feature

• Maintainability

• Software Operability

• Everyone deploys to Prod

How to Screw it Up

The DevOps Team

• Do all the “devops” yourself• Talent drain• Another silo

Build it & They Will Come…

• 1-click deployments• Continuous Integration• Continuous Delivery• “The Cloud” – self service environments• Automated Infrastructure

The DevOps Cargo Cult

Tools• Install *all* the tools• Don’t tell others about the tools• Use them within your team

Roles & Responsibilities

• It’s somebody else’s responsibility• Call that person a devops

engineer/manager• Don’t expect others to change

Devops by Stealth

• Don’t get buy-in!• Ostracise as many people as possible• Make sure management don’t have a

clue• Maximise the potential for people

getting the wrong ideas

Rebranding

• Call yourself a devops engineer• Make it seem like you can do

devops just by changing your job title

How to Get it Right(Sorry, there’s no silver bullet)

What is the Problem You’re Trying To Solve?

Things are going to be different from now on…

• Can you get people to change?• Is it the right environment?– Does the org recognise the need for devops?

• Do you have the support you need?• Do management understand what DevOps is?

Helping People To Change:

What Makes People Tick?

Identify the Barriers

• Technical debt/Architecture• People/Attitudes• Org structure• Legislation/compliance etc• Location/Language

Easy Peasy

• Automate, use the cool tools• Reduce the barrier to entry• Make it achievable

As a Developer…

• “Eat your own dog food”– How does it deploy?– How does it perform under load?– What happens if it dies?• Chaos Monkey

• Understand the Live environment• Own your system– In production, not dev– Fast feedback loops

As a Sysadmin…

• Share your knowledge– Help the devs understand your pains– If you can’t take the developer to production, take

Production to the developer• Become part of the team– Share your cool new toys with everyone– Chef/puppet/vagrant/serverspec– Self service for devs

• Never be a bottleneck– Devolve power!

As a Manager…

• Give people time to change– Not a zero cost operation

• Set expectations– It can take a while– Learning curve– Not everyone will like it– We are committed– Evangelise

Are you too busy to improve?

• “Improving” shouldn’t be optional• You HAVE to make time

In Summary

• Work out what’s got to change• Know your audience. Work out what they need. Don’t

do it by the book.• Make everyone aware of their new role – things ARE

going to change, for everyone• Include everyone• Make sure management understand• Coach people• Understand why we use the tools– It’s not about automation – it’s about culture