There is a lot of discussion going on about ITIL VS DevOps – are the two compatible? Can a nimble DevOps organization coexist with an ITIL based Service Desk? Can ITIL keep up with DevOps or will DevOps leave ITIL in the dust due to the new methodologies that abound for it? Is there a way that the Service Desk can work better with DevOps?
The Service Desk is still the one stop shop for IT customers to contact when something is not working correctly for them. Whenever an incident is raised where something no longer works, Service Desk 101 says to ask – “So what was changed?” After all, it worked before and now it doesn’t so something must have changed to cause it to break! That’s the Change Management -> Incident Management cycle of life.
It stands to reason that the Service Desk needs to know what has been changed in the infrastructure so that they are able to respond quickly to incidents that are raised. The challenge with today’s DevOps is to not place onerous demands on them from a Change Management perspective so that their velocity is not adversely impacted. The Change Management process requirements that the DevOps team needs to adhere to should be just enough to allow Incident Management and Problem Management to function. The best implementation would be to open (and close) Change Requests automatically as part of the DevOps deployment tool set. This can be done using web service calls in most ITSM tools and should provide the Service Desk with what is needed.
With DevOps using agile processes with continuous delivery and automated build, test, and deployment tools – shouldn’t every change that the team makes be bug free? Unfortunately, that’s not the case. Bugs will still be released. Incidents will still be opened. It’s up to everyone – from both the Service Desk and DevOps groups to continually improve the process. When a change has unintended side effects (or even a bug), the Incident Management process need to accurately document the issue, in as much detail as possible so the Problem Manager can accurately assign the resulting problem to the correct group for final remediation. This may include:
- Symptoms of the incident
- Diagnostics and the results that were run to resolve the incident
- Any workarounds used – both workarounds attempted that didn’t resolve the incident as well as the workaround that did resolve it
- Program dumps if available for crashes
- Links to the change request tickets or release package
By including all of this information in the Incident, it will also assist anyone else in the Service Desk that may be working on a similar Incident with potentially the same root cause. DevOps can also use this detailed information to accurately resolve the problem (the first time) and update the automated test cases so the issue will not sneak through into production again. The DevOps team should also be able to learn from this bug and not cause a similar issue in the future.
Like any process improvements, it’s up to the organization how far to go with them. Whether the organization leans towards an agile environment with minimal Change Management requirements on the DevOps team or it leans toward a more prescriptive approach towards Change Management is totally up to the teams involved. Both the Service Desk and DevOps teams need the ability to complete their assigned responsibilities and it’s up to the organization as a whole to determine the best way to accommodate each of these teams as well as the overall business.