How trust enables faster technology change

Talk given at #ipexpo in Manchester, all about the intersection of traditional IT service management and devops, and in particular the important part trust plays in devops.

Transcript

1. How Trust Enables Faster Technology Change Puppet Labs Gareth Rushgrove and infrastructure as code
2. @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. All still the future for the majority Gareth Rushgrove
10. The gap between the leading edge and every-one-else is growing Gareth Rushgrove
11. Moving quickly Gareth Rushgrove Stability and security VS
12. Gareth Rushgrove Then Move fast and break things
13. Move fast with stable infra Gareth Rushgrove Now
14. Dev Gareth Rushgrove Ops VS
15. Common Solutions What is this talk all about?
16. - The importance of trust - Service management and devops - Learning to trust computers Gareth Rushgrove
17. In Devops we Trust How trust relates to this doves thing
18. CAMS - Culture, Automation, Measurement and Sharing Gareth Rushgrove John Willis
19. Trust helps build culture Gareth Rushgrove
20. Trust makes measurement actionable Gareth Rushgrove
21. If you can’t trust your measurements, or where they come from, why act on them? Gareth Rushgrove
22. Trust allows for autonomous automation Gareth Rushgrove
23. Trust permits sharing Gareth Rushgrove
24. Trust and Change Control How trust underpins a culture of continuous delivery
25. Devops Gareth Rushgrove IT Service Management VS
26. Gareth Rushgrove
27. Whether you use the ITIL framework or not you’re likely doing many of the component parts of ITSM Gareth Rushgrove
28. Change management, configuration management, supplier management, capacity management, request fulfilment, problem management, access management, etc. Gareth Rushgrove
29. Continuous delivery Gareth Rushgrove Change control VS
30. 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
31. Standard Changes are pre- approved changes that are considered relatively low risk, are performed frequently, and follow a documented process Gareth Rushgrove Standard Change is defined in ITIL version 3
32. 0 25 50 75 100 Standard Normal Emergency Gareth Rushgrove You probably do lots of standard changes
33. 0 25 50 75 100 Standard Normal Emergency Gareth Rushgrove But are most application deployments standard changes?
34. 0 25 50 75 100 Standard Normal Emergency Gareth Rushgrove But are most infrastructure updates standard changes?
35. 0 250 500 750 1000 Standard Normal Emergency Gareth Rushgrove Endeavour to make everything a standard change
36. Endeavour to make all deployments use the change same mechanism Gareth Rushgrove
37. Gareth Rushgrove Because you can’t trust snowflakes
38. Gareth Rushgrove Because you can’t trust snowflakes
39. “We went from all-hands-on- deck, war-room sort of deployments to non-events” Gareth Rushgrove Jez Miller, Heartland Payment Systems
40. Gareth Rushgrove Regular releases reduce risk
41. When deployments are the same they can be automated Gareth Rushgrove
42. Which means we need to trust our automation Gareth Rushgrove
43. Trust in Automation Using computers to do the boring work
44. Because you can’t keep the spreadsheet up to date Gareth Rushgrove
45. Because if you don’t know the state of your system how can you trust a given change will work? Gareth Rushgrove
46. Доверяй, но проверяй Trust but verify
47. - An unambiguous model - A production line for changes - Constant positive feedback Gareth Rushgrove
48. Infrastructure as code Gareth Rushgrove Unambiguous model
49. Gareth Rushgrove Unambiguous model
50. Gareth Rushgrove Unambiguous model
51. Gareth Rushgrove Unambiguous model
52. Source code can be checked into version control, so clear understanding of who changed what and when Gareth Rushgrove Unambiguous model
53. Trust comes from a shared resource between development and operations… Gareth Rushgrove Unambiguous model
54. …and between IT policy, auditors, security colleagues Gareth Rushgrove Unambiguous model
55. Applying software development practices to infrastructure Gareth Rushgrove Production line
56. Gareth Rushgrove Production line Login to a server Make change
57. Gareth Rushgrove Production line Write the code Check syntax Check style Unit tests Acceptance tests Code review Deploy
58. One way to make changes, nothing is adhoc Gareth Rushgrove Production line
59. Extensive metrics from applying the model to you infrastructure Gareth Rushgrove Positive feedback
60. By default Puppet runs everywhere every half an hour Gareth Rushgrove Positive feedback
61. Gareth Rushgrove Run status Positive feedback
62. Gareth Rushgrove Report on changes Positive feedback
63. Profile performance Positive feedback
64. Trust comes from running all the time Gareth Rushgrove
65. Conclusions
66. Adopting the latest technology Gareth Rushgrove Long term planning and
67. Moving quickly Gareth Rushgrove Stability and security and
68. Continuous delivery Gareth Rushgrove Change control and
69. Devops Gareth Rushgrove IT Service Management and
70. Dev Gareth Rushgrove Ops and
71. Gareth Rushgrove puppetlabs.com/download-learning-vm
72. Gareth Rushgrove puppetlabs.com/community/participate
73. Gareth Rushgrove
74. Questions? And thanks for listening