Is it time that there was a patching team?

Is it time we had a team that patched your layered components and software

I was having a chat with colleagues last week about the growing complexity of IT, the number of layered components, compliance requirements that are now bundled in when it comes to server management.

In the olden days, I installed Windows NT4, plugged in the service pack 6 (for example), installed a driver pack, got it on the network, created the shares and handed it over to the application team/business line. There was typically local storage, (maybe a disk shelve), a modem or pci cards for specific requirements. My core area of expertise were: Service packs, anti virus software, of doing memory dump analysis and driver pack upgrades and reboots.

Compliance happened, the various virus alerts, security exploits happened and now we had to do more regular security patching. We had to know which servers had which service packs installed, which hot fixes installed. We had to have a schedule to know when we could take the servers down at what times so that we could apply them.

The infrastructure evolved. We gained clusters, we gained this SAN storage bringing with it layered software, layered firmware and drivers to think about. Known issues running Emulex on Windows 2000 SP4, you need this hot fix applied. Running it with this fibre switch, with these cards and Windows 2003 SP1? You’ll need kb…. otherwise the server will blue screen.

As the operating systems gains more complexity, more bits so to speak I wonder if patching, if system maintenance moving the infrastructure on is not becoming a more full time job. That’s not to say that your Windows or Unix server guys can’t do all this, but I wonder if we could be more pro-active. That I had a team dedicated to the following:

• Knowing the operating system installed with hot fixes/patches and the service pack level
• Understanding the model specifications and type of server – it’s a DL380G1 with PCI slots – what’s the impact if we want to upgrade to LP10000′s which servers are supported?
• Knowing the attached network/storage and other components – how many servers have lights out cards that need their firmware upgraded
• Knowing the driver pack for the operating system
• Knowing the storage software version, firmware of the fibre cards and the layered storage components

In effect being able to produce on demand an inventory that can be moved around the business reporting requirements. That the SAN team have bought a new switch, that we need to know which systems need to upgrade their san drivers and firmware need not be a thing. Oh there are different vendor tools that can tell you this. But to get the most of the infrastructure we need to evolve the platform, bring you to the latest software revisions and fixes to maintain in vendor support, to prevent unexpected behaviour and fix known issues. Having one team that focuses on that, that handles the Windows 2000 to 2003 upgrades, that can concentrate on upgrading all servers to SP1 and let the support guys get on with fixing issues, stabilizing ‘the core product’ might allow for service improvements and never let us get into the situation where changing operating systems becomes an expensive and scary concept.

It’s going to depend on the size of your server estate, the way your business work and the scale within which you operate. But consider that a patching team, that could take responsibility for your layered components might not only maintain your compliance (meeting vendor/IT Security requirements), but might also keep the platform evolving so we never move still; we never get to that ‘comfortable part of ownership’ from which we are too comfortable to move. Granted in a virtual world you might say, the instance, the grid or cloud does not care where the storage comes from, how it’s provided, but at some point, there will be a driver, a software pack doing something.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.