How to do devops wrong
26
DEVOPS CARDIFF Organisers Sponsors October ‘14 With James Betteley
-
Upload
james-smith -
Category
Technology
-
view
904 -
download
10
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 of How to do devops wrong
DEVOPS CARDIFF
Organisers Sponsors
October ‘14
With James Betteley
DevOps
Doing it wrong since 2009
…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
