Mixing oil and water: devops in an ITSM world

Mixing oil and water: devops in an ITSM world

Devops and ITSM are viewed as mutually exclusive approaches to service delivery.

Worse still, each camp is highly skeptical of the other: devops organisations cowboy changes to production. ITSM organisations crush their people with paperwork and CABs.

But they’re driving for the same outcomes: delivering a quality service to our users, while managing capacity and risk.

Both approaches are compatible, and it's easier to get started and get benefits quickly with devops approaches than you think.

In this talk we will learn:

* What the benefits and risks are for experimenting with devops in your organisation.
* Where to apply devops methodologies in your organisation to manage risk and maximise success.
* How devops can be applied in highly regulated environments.

Fad1e9ed293fc5b3ec7d4abdffeb636f?s=128

Lindsay Holmwood

August 24, 2017
Tweet

Transcript

  1. Mixing oil + water devops in an ITSM world Lindsay

    Holmwood @auxesis
  2. High-performing IT organisations report experiencing: 46x more frequent deployments

  3. High-performing IT organisations report experiencing: 96x faster recovery from failures

  4. High-performing IT organisations report experiencing: 5x lower change failure rate

  5. High-performing IT organisations report experiencing: 440x shorter lead times

  6. High-performing IT organisations report experiencing: 21% less time on unplanned

    work and rework
  7. High-performing IT organisations report experiencing: 44% more time on new

    work
  8. Sponsored by: + Presented by:

  9. High-performing organisations decisively outperform their lower- performing peers in terms

    of throughput.
  10. Let’s demystify

  11. What is not devops

  12. It’s not cowboying changes into production

  13. It’s not tools or Technology

  14. It’s not something you buy s/devops/agile/i

  15. It’s not a team* *cross-functional, multidisciplinary teams are a good

    blueprint
  16. dev + ops == devops team We’re doing devops!

  17. dev & ops & design & UX & product &

  18. Diversity & inclusion

  19. It’s not a silver bullet

  20. How does DevOps map to ITSM?

  21. None
  22. None
  23. Service design Service transition Service operation Service catalogue management Change

    management Service desk Service level management Release management Application management Availability management Deployment management Operations management Capacity management Service testing & validation Technical management Continuity management Configuration management Event management Security management Incident management Supplier management Request fulfillment Problem management Identity management
  24. Service design Service transition Service operation Service catalogue management Change

    management Service desk Service level management Release management Application management Availability management Deployment management Operations management Capacity management Service testing & validation Technical management Continuity management Configuration management Event management Security management Incident management Supplier management Request fulfillment Problem management Identity management
  25. What are the benefits?

  26. Faster time to market

  27. Improved resiliency

  28. MTTD + MTTR trending down

  29. Improved customer satisfaction

  30. Less friction

  31. What are the risks?

  32. Risk: No executive sponsorship? Don’t bother.

  33. There’s a champion somewhere in your organisation.

  34. People in the executive 
 ❤ it because: • it’s

    new and exciting • it delivers value faster • it brings them closer to the customer
  35. People at the coalface 
 ❤ it because: • it’s

    new and exciting • it keeps their skills relevant • it brings them closer to the customer
  36. Once you’ve got commitment

  37. Be the umbrella you want to see in the world.

  38. Risk: You have to change culture

  39. Culture change is hard

  40. What is culture?

  41. Schein’s three levels of culture

  42. Artifacts Values Assumptions

  43. National ↩︎ Organisational ↩︎ Team ↩︎ Occupational

  44. Artifacts

  45. physical manifestations of culture

  46. ceremonies

  47. ways of working

  48. org charts

  49. desk layout

  50. processes

  51. software

  52. most visible parts of an org’s culture

  53. easiest part of a culture to adopt

  54. Values

  55. conscious goals, strategies, and philosophies

  56. rules that guide how we interact with people

  57. rules that guide how we do our work

  58. “we manage risk proactively”

  59. “management is available, and listen to our concerns”

  60. “we value quality over delivery speed”

  61. “nobody will be fired for making an honest mistake”

  62. values: lived vs aspirational

  63. Communication We have an obligation to communicate.

  64. Respect We treat others as we would like to be

    treated.
  65. Integrity We work with customers and prospects openly, honestly, and

    sincerely.
  66. Excellence We are satisfied with nothing less than the very

    best in everything we do.
  67. Ethical We conduct business affairs in accordance with all applicable

    laws and in a moral and honest manner.
  68. None
  69. Work as imagined vs Work as done

  70. Be clear about what values are what

  71. Systems + processes Values Assumptions

  72. Artifacts Values Assumptions

  73. They’re a snapshot of our org’s culture

  74. They’re a snapshot of our org’s values and assumptions

  75. Artifacts influence behaviour

  76. Change your org’s values by changing your artifacts

  77. Artifact: Make deployment fast and safe

  78. Value: “We improve quality by going fast”

  79. Artifact: Work happens in cross functional teams

  80. Value: “We work together to achieve a shared goal”

  81. Artifact: Give autonomy. Eliminate signoff. Grant access. Log everything.

  82. Value: “Ask forgiveness, not permission”

  83. Artifact: Run post incident reviews Run pre accident investigations

  84. Value: “Failure is an opportunity for learning”

  85. Risk: You do it and you fail

  86. Reputational risk

  87. Burn political capital

  88. Risk: You don’t do it and you become obsolete

  89. “It is not necessary to change. Survival is not mandatory.”

    – Deming
  90. Where can we experiment with devops?

  91. Application space is the easiest

  92. infrastructure (network, compute, storage) application

  93. Take what you learn apply it to infrastructure

  94. Variety of options

  95. Greenfields Brownfields Blended

  96. Greenfields New initiatives

  97. Greenfields Digital transformation

  98. Greenfield benefits Less baggage

  99. Greenfield benefits Buy in from your people

  100. Greenfield risks Blow your innovation budget

  101. Don’t change what technology you use

  102. Change how you use that technology

  103. Change how you consume that technology

  104. Greenfield risks Create a division between new and old

  105. Greenfield risks How does new get absorbed into the old?

  106. Disband the team?

  107. Throw it over the wall?

  108. Build systems to mirror the org structure?

  109. Brownfields Existing processes

  110. Well defined outputs

  111. Something you can refactor piecemeal

  112. Brownfields Reboot an existing system or process

  113. Brownfield benefits Less experimentation required

  114. Brownfield risks Thinking constrained by existing systems

  115. Brownfield risks Changing a thing to work in a way

    it wasn’t designed
  116. Brownfield risks Incremental improvements at best

  117. Blended Start with

  118. Get confidence with new technology approach

  119. Get confidence with new delivery approach

  120. Blended Then apply to

  121. Have exemplars you can point to

  122. Take what you learn apply it to infrastructure

  123. 1. Build the smallest, simplest thing that meets a user

    need
  124. Look at failure demand in your organisation

  125. “Shadow IT” is failure demand being met

  126. Set delivery constraints

  127. ⏰ Time Budget Scope (pick 2)

  128. 2. Start with Continuous Delivery

  129. Technical manifestation of devops

  130. Align release processes around an outcome

  131. NOT

  132. Align outcome around a release process

  133. Spend tech innovation budget on delivery engineering

  134. All changes go through a Continuous Delivery pipeline

  135. deploy to production acceptance tests integrate unit tests code done

    Continuous Delivery Manual Auto Auto Auto
  136. shipping multiple times a day

  137. Decrease batch size

  138. Increase frequency

  139. “You build it, you run it” – Vogels, AWS

  140. High-performing IT organisations report experiencing: 46x more frequent deployments

  141. Code doesn’t create value until it is running in front

    of a user
  142. Nail your automated delivery pipeline from the start

  143. Spend tech innovation budget on delivery engineering

  144. Write high level acceptance tests (like Cucumber)

  145. An executable specification

  146. Feature: Refund item Scenario: Jeff returns a faulty microwave Given

    Jeff has bought a microwave for $100 And he has a receipt When he returns the microwave Then Jeff should be refunded $100
  147. 3. Use commodity

  148. Don’t change what technology you use

  149. Change how you use that technology

  150. Change how you consume that technology

  151. Move innovation up the stack

  152. Don’t experiment with IaaS

  153. Don’t experiment with Private clouds

  154. Don’t experiment with Anything on-prem

  155. Experiment with PaaS

  156. Experiment with SaaS

  157. Experiment with Open Source

  158. 4. Build in measurement

  159. # deploys a day

  160. Time to failure detection

  161. Deployment lead time

  162. Error rates

  163. Throughput per class of work

  164. Really easy when you buy into PaaS + SaaS

  165. Sponsored by: + Presented by:

  166. “People with targets […] will probably meet the targets -

    even if they have to destroy the enterprise to do it.” – Deming
  167. 5. Build and listen to feedback loops

  168. If you’re experimenting you need to learn from it

  169. Construct feedback loops on what works

  170. Construct feedback loops on what doesn’t work

  171. Construct feedback loops on what is puzzling

  172. Activities: Fortnightly retros

  173. Activities: PIRs

  174. Activities: Failure Fridays

  175. “Chaos engineering means experiencing failure on your terms” – Bruce

    Wong, Twilio
  176. What about highly regulated environments?

  177. “You can’t do this because of the rules”

  178. Policy as a weapon vs Policy as a tool

  179. Read the policy yourself

  180. Find subject matter experts

  181. Document what works and what doesn’t

  182. Security

  183. “Everyone has a plan until they get punched in the

    mouth” – Mike Tyson
  184. Detection, not prevention

  185. Credentials in source control

  186. Automated vulnerability detection

  187. Automated config validation

  188. Hooked into monitoring

  189. * CAB as a blocker

  190. CABs and CD are incongruous

  191. Or are they?

  192. Why do we have CABs?

  193. Understand what is happening

  194. Understand why it’s happening

  195. Understand who is affected

  196. Ensure due diligence on changes

  197. Co-ordinate complex multi-step changes across multiple teams

  198. They are a control that mitigates risk

  199. ITSM as a model for managing change

  200. ITSM as a model for managing complexity

  201. Prove to your CAB: your automation gives them the same

    assurances they’re looking for
  202. Submit to your CAB: use a CD pipeline to deploy

    all future changes
  203. Make doing the right thing easy

  204. CABs are preventative controls

  205. We put all our energy into prevention

  206. We have no energy left for detection or response

  207. High-performing IT organisations report experiencing: 46x more frequent deployments

  208. High-performing IT organisations report experiencing: 96x faster recovery from failures

  209. High-performing IT organisations report experiencing: 5x lower change failure rate

  210. High-performing IT organisations report experiencing: 440x shorter lead times

  211. Fail fast and recover quickly

  212. Fail fast and recover quickly

  213. Mixing oil + water devops in an ITSM world

  214. How does ITSM relate to DevOps?

  215. Striving for the same outcomes

  216. Compatible, not incongruous

  217. DevOps as a conversation starter on risk

  218. DevOps, Agile ITSM, Waterfall: models for managing risk

  219. Pick and choose models based on context

  220. I’m Lindsay

  221. Thank you! ❤ the talk? Let @auxesis know.