DevOps success patterns - Lessons learned

PDF with speakers comments

Transcript

1. DevOps – Successful Patterns Alex Vinyar Enterprise Architect; CHEF Software
2. Who am I? Alex Vinyar Enterprise Architect with Chef alex@chef.io 18 years automation experience
3. What do I do? • Mostly on-site engagements • Enterprise Assessment & Design • Infrastructure & Workflow Assessment • Hands-on Training • Implementations
4. Companies I’ve worked with • Alaska Air Group • Bloomberg • Bridgewater • CenturyLink • Chef • Cycle30 • Delta Dental Insurance • Expeditors International • Fred Hutchinson Cancer Research Center • GE Capital • General Electric • HP Support • IBM • Microsoft - Office 365 • Microsoft - Security • Ooyala • Rakuten • Samtec • Walgreens • Yahoo
5. Lessons I’ve learned about “starting to DevOps” These are not mandatory to success, however companies that have these are more successful and go through adoption quicker.
6. Best if there is an Executive sponsor. • Will help give you budget • Will help give you freedom • Will help give you protection • Will help give you visibility. • DevOps is about bringing teams together Budget - new laptop Mention a company where dev team had laptops with 1 gig of memory. People need machines capable of running VMs Freedom - docker, vagrant, azure, lxc, … Protection - you cant succeed if you cant fail. you will experiment & you will fail. Visibility - celebrate success - raises for everyone
7. Pick a small but meaningful first project • Resist business “recommending” a specific project - usually bad idea • Pick a small project • Don’t be afraid to change if it’s a wrong project. • Greenfield is great but almost never. • Pick something that you can succeed in! 1) Dont start with something that has a large bucket of problem. 2) Simple web app that has a dependency on web logic (no-no) 2) teams - If another team has to manage your dependency, that becomes the bottleneck and limits your speed. Can’t force them to change until you show success. -You want people involved, you want different perspectives as well, but you don’t want to introduce so many of either that you then have a communication problem to manage. 2) Be mindful of the number of folks and technologies involved 2) Select a small, visible problem that can be completed in 8 weeks 3) GE went through 3 applications before they found one acceptable.
8. Control the blast radius • …but not the size of the explosion
9. Have a Champion! • Find a champion inside your company • or build a champion • Excitement has to come from more than one person • Often it’s someone who is very grumpy (and too honest) When you’re trying to create change, it’ll have to come from more than one person
10. Metrics, Metrics, Metrics, Metrics • Helps prove your case • Helps demonstrate value • Celebrate successes • “exploit compelling events” • 2’200 server + 1 person + chef = 15 minutes • 60’000 servers + 156 people + lots of typing = 9 days “6 months ago we only wished we had problems we do today” - Justin Arbuckle Exploit - Heartbleed / Shellshock - 2 teams
11. Take care of your people! • When you ask people to do the impossible, you can’t treat them like everyone else. • Stack rating superstars does not work • Good people will leave once they see “the light” • Good people will leave if you make them bored Performance review example. 2013 Microsoft Killed it. We hire a lot of incredibly talented people who were not appreciated at their old job.
12. DevOps takes time • Typical org takes around 2 years • 6-10 months to establish SME Establishment of SME is a good benchmark
13. You will NOT be automated out of the job • Nobody wants to perform the same task over and over ….and over • Automation gives you freedom to innovate • or to go home early • Computers get together at night and laugh when a human manually does what a computer can do automatically
14. Demo! Demo! Demo • Build an internal community. • Demo Successes • Demo Failures • Invite EVERYONE! • Let EVERYONE demo! • Demo every week, even if you’re the only one in the room! • Demo IS part of your job
15. Technical Demo suggestions • 5 minutes max. • Business people have little patience for technical mumbo jumbo • Practice at least once before. • Video of your code running is OK • Time box debuging during demo - 30 seconds max! • Remember that no one can see your mouse, use mouse locator to point. 1-2 minute demo is totally ok.
16. Thank You – Questions? Alex Vinyar alex@chef.io