Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How trust enables faster technology change

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.


Gareth Rushgrove

May 21, 2015


  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

  18. CAMS - Culture, Automation, Measurement and Sharing Gareth Rushgrove John

  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

  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

  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

  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