What’s that all about, and why ? Read on !

The purpose of the CAB is to assess the impact of this change (the CAB is supposed to have a clear vision of the “big picture” of the IT / Business relationship) and to give a go / no-go answer.

This, of course, is supposed to prevent multiple changes that might collide. For example applying a security fix to close a security breach might stop an application from working, so finding out a solution to make this application work with the patch first might be a good idea.

In case the CAB give a go for this change, it still has to fit in the FSC (Forward Schedule of Changes) which is, as the name implies, a planning to ensure changes implementation won’t collide in each of their time frames. It might be a good idea to keep a bit of time in between changes which might overlap, to avoid unexpected side effects.

The RFC which is submitted to the CAB is supposed to contain related information so that an appropriate decision can be taken. For example all the items which will be impacted by the change, the steps of the operation, how long it will take, if there will be service disruption, and so on. And of course, as no IT operation always happen as planned, the RFC must include a back out plan to go back to the initial situation should the implementation of the RFC fail.

This might seem as a lot of useless work, but this is to prevent side effects and minimize service disruption. After all, ITIL methodology is all about IT giving the best service to the Business…

ITIL: What is the CAB ? is a post from: Tech@Sakana - A sysadmin's blog

But what is a CMDB ?

It’s a database which stores all the information you need to manage your IT infrastructure. The objects which are stored in the CMDB are known as Configuration Items (or CIs).Typical CIs are computers, servers, screens, and so on. Going further, you can store users, their credentials, teams, and so on and so forth.

The information stored needs to be as specific as you need to know to efficiently support your IT. For example, no need to store hard disks information if the lowest hardware unit you deal with is the server.

The CMDB doesn’t only store the CIs but the relationships that link them all together. With the example above, you could tell what computer a user uses. Or on which particular switch a server is connected. Or in which building they are hosted. And so on and so forth. Again, you decide how specific you want need to be.

A properly filled and managed CMDB is a wonderful tool for efficiently supporting an IT infrastructure. I can help you to answer questions such as : “I’m going to upgrade the firmware of a network switch. Which servers are going to be unreachable, and who are the users I should inform ?”. Another one : “The hard disk of the server broke. Which part number should I order ? Was there a RAID configuration ?” And so on … and so fort !

As you might now understand, this is a central tool much needed to any IT support. But this does come with a cost : this CMDB is only as efficient as it is accurate, and this kind of database has a tendency to drift away from reality. Partly because of errors when typing in the information, partly because there are sometimes when we’ll forget to modify a CI after a change will have been implemented, … Even with the best will, people do make mistakes too. Sometimes commitment is just not enough.

So of course, a CMDB is nothing without a process which will ensure that it will stay accurate. This process can be just a set of rules which will ensure that no change will be implemented without modifying the CIs in the CMDB, or periodic auditing, or automatic audit (this one is my favorite).

(Stay tuned, I plan to post few other ITIL articles soon)

ITIL : What is a CMDB ? is a post from: Tech@Sakana - A sysadmin's blog