DevOps. The next saviour of the world. A combination of agile delivery and super-effective provisioning scripts with a sprinkling of software-defined (virtual) infrastructure. Whilst ITIL v3 and 2011 seem (on the surface at least) to […]
I recently discussed service support / operations on twitter with someone frustrated at being asked to provide support for a public cloud service he had very little ability to. Not technical capability, because he seemed capable enough, but access to the systems to do more fundamental fixes. We didn’t get far into the details, but it seemed he was being asked to deal with something which hadn’t been thought about when the service was provisioned.
This is sadly not an uncommon situation among support teams who often have no say in the choice of system/service, no time to get familiar with it, and no means of pushing back on critical gaps even if they do get a chance to see it beforehand. These are often gaps that a 5 year old could often spot, let alone experienced engineers but which seem to be frequently ignored by people whose shopping list only has one thing on it: functionality.
Most change requests get raised, authorised and implemented.
When I’ve had occasion to post-mortem a failed change for a new client, I’d usually expect to hear one of the following phrases:
- I didn’t know what I was supposed to be doing
- It shouldn’t have broken that, it was supposed to be totally unrelated…
- How was I to know the backups were running at the same time?
- Wait….I thought John was doing that reboot?
- We only overran because we had to back it out…
…all of which are avoidable.