When not everything in the data centre is your responsibility it can can be easy to loose track of what’s actually in there. If that happens what can you do to get back control?
I’ve been sent on a fact finding mission. Like one of those poor saps from the U.N. sent into some war-torn hell hole, I’ve been tasked with determining exactly what systems a client of ours has. This is not as simple as just asking their Systems Administrator what they look after as, and this may or may not shock you depending on your experience, just like many of our clients they haven’t a clue what systems they have.
Fact-Finding, U.N. Style
While it might seem odd that an administrator doesn’t know all the details of the systems under their care when you factor in a Managed Services agreement this isn’t actually so unusual. If that admin was the last line of support for that system and had to look after any and all issues with it themselves then you can sure that they’d quickly learn that they need to know as much about it as possible. The benefit of a Managed Services agreement is that the systems covered by that agreement should turn into “black boxes” in the server room that should just work, as the Managed Services Provider (MSP) is caring for them.
Where Managed Services agreements are commonly found is in the support of enterprise grade applications, like a Finance suite or ERP system, that requires specialised, often proprietary skills not commonly found in smaller IT departments that are by their nature more geared towards core infrastructure. Those service agreements can spread out over time to include other systems and slowly but surely the internal details of those systems are lost to the local administrators, often only surfacing in periodic service management meetings.
When there are other elements in the mix, like bespoke development for example, that’s managed directly by a vendors department other than Managed Services, it becomes possible that there is no single definitive overview of all the technical components a client has (though you can rest assured that the account manager knows exactly what they have but may not know the technical details), and so this is where fact-finding missions like mine one today come in to play.
Finding out the details of a client system (performing an enumeration as some security professionals would call it) can be a simple high-level exercise along the lines of dialling in and collecting the names an IP addresses of servers along with the installation details of the applications, or it can be a far more detailed effort involving specialised enumeration tools to capture configuration and other details for storage and analysis. For my mission, which relates to preparing a service management report, a more high-level approach is sufficient.
The first draft of my “Client X’s Network, Server, Database, and Application Systems” report is delivered
Once the flashy, picture-heavy, well written, and properly formatted report is complete, the obvious next question will be how to avoid this type of situation in the future and so avoid having to dedicate time to fact finding?
Firstly, if you’re wondering where ITIL is in all this, then here it is. The ITIL framework provides for configuration management and any ITIL compliant IT Service Management system should facilitate the collection of information about a client’s systems configuration. Like any system of this nature, an accepted business process needs to be defined for the collection, updating, and verification of this information and responsibility for its management needs to be assigned. Where this might fall down is when departments not traditionally considered related to service (like a development team) aren’t familiar with the ITIL system or don’t have access to the software to record and update their changes, though this can be addressed by either including them in the process or by tightening controls around change management and systems access.
If those providing the managed service are to be considered the true administrators of a given system then they need to be the ones ultimately controlling that system in order to maintain stability as well as an accurate idea of what’s happening with the system under management. Ideally, all access to a customers system should pass through the managed services department so if development teams have material that needs to go to a client, it should be deployed through managed services as well as following the ITIL process for change management.
Getting everyone on board with ITIL or breaking the habit of developers (or others) going straight into a client’s system may not be an easy process and might even seem a little too “perfect world” for some shops, but it would save a lot of time wondering around a client’s servers every few years asking “what does that do?” while trying hard not to step on any active processes.
Martin Minnock 