|
ITIL for Sysadmins (why sysadmins should care, and what IT managers need to know) The IT Infrastructure Library is a European initiative to document and define IT processes in service management and provisioning. Like many standards, ITIL is very vague when it comes to implementation. Managers love it, and sysadmins are either allergic to it or claim complete ignorance. In actuality, both parties can learn from ITIL.
It doesn't help that most large organizations that have implemented ITIL standards have become completely Nazi about it. Most would describe the phenomenon as "zeal," but Nazi is more representative. Managers charge headstrong into a situation with a pre-determined solution, and fail to take into consideration the details of actual implementation. The single most common misconception about ITIL is that it completely and wholly describes processes. It does not, and sysadmins are the first to recognize that. The overweight, bearded Unix sysadmin that frequently swears in meetings should be given more credence at times. He probably knows, better than management, which processes will work and which will fail. ITIL clearly states that it is a set of "best practices," not a process definition. As Luke Kanies of Reductive Labs accurately and frequently reiterates, "The state of system administration is pitiful." Administrators lack a standard set of tools, real automation software, and standards implementations. ITIL tries to define standards and best practices, but the implementation usually fails. Lack of tools is probably the number one reason for ITIL irrelevance. Take, for example, the coveted CMDB, or configuration management database. The ITIL texts use the CMDB as a sort of burial ground for anything complex. They essentially push the difficult tasks into this mythical CMDB, and then completely avoid discussing it in any detail. In reality, a CMBD will be numerous applications, including configuration management software and monitoring software. On a related note, a change management database is another example of a mythical concept. The idea of change management is to document changes, likely resulting from a change management meeting, and then have the ability to reference said changes in the future. When something breaks, effective IT organizations first research "what changed" to figure out the problem. In an ideal world, your configuration management database, change management system, ticketing system, and hardware database will all interoperate. Wouldn't it be nice to search for all changes related to a particular service that resulted from a specific trouble ticket? Nothing remotely close exists in the real world. Brage is an infant piece of software designed to fill part of that role, but it's barely usable. This is due in large part to the lack of interest in the sysadmin community. Consultants will always tell you, "It depends on your processes" when you begin asking around for software to manage change or configurations. Well we have to start somewhere, and homegrown databases that never make it into the public domain are worse than useless: they're used for a very short time period within a single company. It was claimed in the beginning of this article that people can actually learn from ITIL. To really learn from ITIL, you mustn't gloss over the portion that talks about ITIL being a set of Best Practices. That's key. It's widely accepted that IT has evolved past the cowboy attitude of "change first, ask later," but what have we evolved to? Surprisingly, we've communicated better. We've possibly developed some standard processes within our own companies and begun to enforce them. As a profession, though, systems administrators haven't done much. Sysadmins can learn from ITIL, but there are so many more important things to do in a day. When the actual implementers of an infrastructure become interested in managing it well, wonderful things can happen. There's no need to warn sysadmins about ITIL's shortcomings; they will readily focus on the parts that make no sense. In a recent webcast about IT service management I mentioned that the Visible Ops Handbook by George Spafford was an excellent read. It's the most practical and well-written document about the realities of implementing ITIL. Unfortunately, it too refers to the CMBD as though there's a magical piece of software that will just make it happen for you. The ISO20000 standard was published in 2005, but it is basically a rehashing of the service management aspects of ITIL. We don't really need more standards, because the existing ones will work just fine. We need implementations of these standards, in the public domain, so that others can learn and benefit. Both software and processes need to become public. Remember, ITIL isn't a business process, and it certainly doesn't tell you how to implement the difficult parts. What if there was Open Source Management? What if managers did more than just communicate among their friends? Why isn't there a set of public processes that business can deploy? There aren't that many company-specific processes within the IT realm, if you think about it. The real problem with OSM is that, like ITIL (which isn't even a process), other managers adopt processes that sound good but have no practical application to their business. This is where your sysadmin will be able to help. A candid, open discussion about policy and process, with the implementers, always turns out well. The more unpolished and abrupt your technical staff is, the better your feedback will be. Automation is key. Configuration management is paramount. Change management is important. System administrators know this, even if they don't admit it. The ITIL texts talk about these needs in great detail and make some excellent points. We all do these things, to a degree, but there's still very little software available to really make any of them happen in an effective manner. This is where sysadmins can help to advance the IT field. Luke Kanies is the biggest proponent of this, so we'll delegate to his O'Reilly articles and blogs: here. |