Patch management automation is often positioned as if it is a real possibility. And, when selling a software solution to C-Level executives, this positioning sounds fantastic. What manager wouldn’t love to automate a process that has taken a huge investment of time and money in the past? In this period of tight budgets, automation sounds like the answer …
But for the actual IT professionals who are down in the trenches doing the work, these words are the butt of many server room jokes.
We completely agree that patch management is vitally important to any organization and is only getting worse with the growth of custom and third-party application updates; however, automation is not the answer. Let’s also make sure we are on the same page on what automation means. To us this means there is some defined intelligence which does things without human intervention -- the ability to schedule a task is not automation. What consumes a large chunk of engineers’ time is watching for when new patches are released, and then researching what are the various data points needed for a patch: e.g., where are the installers/updates? What are the dependencies with other applications or previous versions? How do I determine which machines are applicable, etc.?
The problem historically with many patch management solutions is that they are hard to use and require custom scripting and packaging of updates. They are better than nothing, but just barely. What IT professionals need is a product that is extremely easy to use and provides them a starting point for managing third party updates and content. They need software to notify them when new updates are out and to do much of the leg-work on packaging this content and delivering it to them so they can test, tweak and deploy it in their environment.
The reason why automation has no place in real-life patch management is very simple and two fold -- every environment is different and engineers just don’t trust automation. Now we are not saying automation does not have any place in IT; however, in the scope of configuration management (which includes patch management), to an engineer, this is just a marketing buzz word. The primary challenge that affects patch management operations is dealing with exceptions and unanticipated dysfunctions, and that mandates extensive testing on any machines that are not what we might call “stock”.
That is, they have line-of-business apps not tested by the patch builder, or they have custom configurations, or they’re simply too critical to be offline for any more than the absolute minimum time required to apply the patch and successfully restart the system.
And don’t get us started on trying to deliver this type of a service in a SaaS based fashion, which in itself is ripe with tons of other issues.
 ShareThis
Tags: Applications |
