Day to day devops

Practices of effective teams, and reasons for adopting devops

Transcript

1. Day to Day Devops Puppet Labs Gareth Rushgrove From cultural movement to useful practices
2. Gareth Rushgrove @garethr
3. Gareth Rushgrove
4. Common Problems Whether you’re in software development or enterprise IT
5. Adopting the latest technology Gareth Rushgrove Long term planning VS
6. Why does this matter? An increasing rate of technology change Gareth Rushgrove
7. Gareth Rushgrove
8. Gareth Rushgrove
9. The gap between the leading edge and every-one-else is growing Gareth Rushgrove
10. Moving quickly Gareth Rushgrove Stability and security VS
11. Gareth Rushgrove Then Move fast and break things
12. Move fast with stable infra Gareth Rushgrove Now
13. Dev Gareth Rushgrove Ops VS
14. * Gareth Rushgrove Ops VS
15. Devops and this talk An introduction to some common practices
16. Devops is a cultural and professional movement Gareth Rushgrove
17. CAMS - Culture, Automation, Measurement and Sharing Gareth Rushgrove
18. Everything as code Teams over individuals Do hard things more often Gareth Rushgrove - - -
19. Teams over individuals The problem with single points of failure and dependencies
20. Low trust culture Gareth Rushgrove High trust culture
21. Siloed teams Gareth Rushgrove Cross-functional teams
22. Long cycle times Gareth Rushgrove Short cycle times
23. Poor visibility Gareth Rushgrove Fast feedback
24. Specialist Gareth Rushgrove Generalist
25. Push Gareth Rushgrove Pull
26. 30x Gareth Rushgrove More frequent deployments Faster lead times than their peers 200x 2015 State of DevOps Report
27. 60x Gareth Rushgrove Change success rate Faster mean time to recover 168x 2015 State of DevOps Report
28. Everything as code Why software is eating the world
29. Change management, configuration management, supplier management, capacity management, request fulfilment, problem management, access management, etc. Gareth Rushgrove
30. Доверяй, но проверяй Trust but verify
31. Avoiding spreadsheets as the source of truth Gareth Rushgrove
32. If you don’t know the state of your system how can you trust a given change will work? Gareth Rushgrove
33. The best source of truth for the network is the network itself Gareth Rushgrove
34. Infrastructure as code Gareth Rushgrove
35. Gareth Rushgrove
36. Gareth Rushgrove
37. Gareth Rushgrove
38. Applying software development practices to infrastructure Gareth Rushgrove
39. Source code can be checked into version control, so clear understanding of who changed what and when Gareth Rushgrove
40. Changes can be made through a pipeline, everything is visible and nothing is adhoc Gareth Rushgrove
41. Gareth Rushgrove Login to a server Make change
42. Gareth Rushgrove Write the code Check syntax Check style Unit tests Acceptance tests Code review Deploy
43. Do hard things more often Building up organisational muscles
44. Q. If Amazon release to production every 11.6 seconds, how often does the Change Approval Board meet? Gareth Rushgrove http://assets.en.oreilly.com/1/event/60/Velocity%20Culture%20Presentation.pdf
45. Gareth Rushgrove
46. “We went from all-hands-on- deck, war-room sort of deployments to non-events” Gareth Rushgrove Jez Miller, Heartland Payment Systems
47. Gareth Rushgrove Regular releases reduce risk
48. Gareth Rushgrove Chaos Engineering introduces failure
49. Conclusions Embracing devops practices means…
50. Everyone embracing change Gareth Rushgrove
51. Learning new skills Gareth Rushgrove
52. Changing your team and organisational structure Gareth Rushgrove
53. Changing your organisation Gareth Rushgrove
54. Questions? And thanks for listening