Overview – or, why do I care about unexpected CIs anyways?
Many CMDB administrators focus their time on ensuring that discovery is functioning as it should, looking for issues reported through the CMDB health dashboard and working to ensure processes are running smoothly to detect duplicates, stale CIs, etc. However, one of the areas in the CMDB that gets very little attention is the concept of unexpected CIs. While the existence of unexpected CIs isn’t reported on the CMDB health dashboard (today at least), it is also a very important indicator of CMDB health and can highlight areas where things may not be running smoothly.
What is an unexpected CI? Before we go there, let’s do a quick review of how inheritance works in the CMDB.
CMDB Inheritance and the "container" classes
Remember that the CMDB classes work in an inheritance model, like a tree with cmdb_ci at the top. As you start moving down the branches of the tree, the different classes in the middle (we will call these “container” classes) are useful as aggregation points for CI classes. A good example of this is cmdb_ci_server, which is the branch point for cmdb_ci_linux_server, cmdb_ci_win_server, etc. As a result, the inheritance structure (tree) looks something like this:
Fig 1. Sample inheritance tree for cmdb_ci_linux_server
In the CMDB inheritance model, attributes defined at one level are inherited by all classes below that definition point. So for example, defining an attribute at cmdb_ci_computer makes it visible to cmdb_ci_server and cmdb_ci_linux_server. Using the tree above as a guideline, the CMDB administrator can carefully plan out CI attributes so that they are inherited correctly by subclasses but do not appear in classes where they do not make sense (such as having “Service Pack” as an attribute for a network adapter). The “container” classes such as cmdb_ci_server are very useful for providing aggregation points for defining attributes that apply to multiple child classes.
If we’re doing things correctly, we find that as we move down the tree and start getting more specific, classes start to have more attributes. Those attributes are only visible at the definition point and below; so for example, kernel_release (defined in cmdb_ci_linux_server) is not visible at cmdb_ci_hardware.
Where we get into issues – Unexpected CIs
As we’ve seen above, the “container” classes are very useful in building the inheritance model, for defining parent-child relationships, and are key to instrumenting attribute inheritance. However, while these are useful classes for CMDB schema definition, they generally are not a good place to store actual CIs, as they do not directly represent an object in the technology environment (you didn’t deploy a “hardware”, you deployed a “Linux server”). Where we get into trouble is when we start finding CIs show up in the container classes like cmdb_ci_hardware. So when we start seeing CIs showing up as being based in a “container” class, we call those unexpected CIs.
Why we care about unexpected CIs
They may seem benign, but unexpected CIs can really mess up a lot of what should be working with the CMDB. Some reasons why unexpected CIs are something to be concerned with include:
Regardless of how they got there, unexpected CIs are an important indicator of CMDB health and should be on the CMDB administrator’s list of items to watch out for and remediate.
Commit to doing the work
Make sure you set aside the time and resources to stay on top of the unexpected, and that includes planning to catch and remediate unexpected CIs. Unexpected CIs are not just one-off anomalies, but are an important indicator of CMDB process effectiveness and CMDB health.
And remember that repatriating unexpected CIs to their rightful home isn’t necessarily as simple as just reclassifying the CI; you want to make sure that the resulting attributes for the CI are populated correctly and that you don’t create new problems due to missing attributes in the new class, etc.
Or even better, let us help you!
But what if you don’t have the time or resources or expertise to dig into and manage your unexpected CIs? And let’s face it, the CMDB is not fun and exciting, people would rather be rolling out Virtual Agent.
Speak to our experts at AJUVO about CI Watch, a comprehensive solution by AJUVO to get your CMDB back on track and help keep it there. We use our own custom applications, dedicated CMDB experts, and consultative approach to help (re)design your CMDB to support your desired business outcomes, align your existing data to achieve that value, and then provide a managed service to keep your CMDB humming along smoothly at a fraction of your normal full-time resource costs.