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.

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?
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.
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.