Drift management overview
CMDB represents the correct or current states of your data center configuration items. Sometimes, however, real-world issues appear in the form of new releases, upgrades, new equipment, and unauthorized changes. After using your discovery mechanism for scanning your environment and updating CMDB, use drift management to monitor and detect changes in the state of your CIs.
Drift management is a consumer of, and works entirely from, the data in CMDB. Drift management is not a discovery tool. It relies upon a discovery application to update CMDB.
Drift management and ITIL
Drift management supports verification and audit activities of configuration management as defined by the IT Infrastructure Library ® (ITIL ® ).
According to ITIL, you must conduct periodic audits of your IT environment to verify that the BMC Helix CMDB is up to date. The reverse is also true. You must conduct periodic audits of your IT environment to verify that the physical environment has the correct and approved CIs as defined in BMC Helix CMDB.
For example, you want to verify that all security servers have similar CIs and configuration attributes. With drift management, you can establish a baseline by using a known security server in CMDB having the configuration as per the business requirement. You can then compare all other security servers, that are the target, with the baseline to detect whether any changes have occurred. The drift might occur due to addition, removal, or modification of CIs or attributes on your target servers.
With drift management, you can perform the audit and verification processes as needed or on a regular audit schedule. For example, you might want to audit the servers most critical to your business on a daily or weekly basis and the less critical servers on a monthly basis. If drift is detected, drift management enables you to take corrective action after proper research for the root cause either by using a change request or correcting the target computer by using an incident request.
ITIL makes the following recommendations for when you should do a configuration audit in your IT environment:
- Shortly after implementing a new configuration management system.
- Before and after major changes to the IT infrastructure.
- Before a software release or installation.
- At random intervals.
- At regular intervals.
- When all is back to normal after a disaster recovery.
- When any unauthorized CIs are detected.
Basic concepts of drift management
The following table highlights some key concepts and terms in drift management:
Concept | Description |
|---|---|
Comparison job | You detect drift by creating and running a comparison job. A comparison job compares a baseline set of CIs, a target set of CIs in CMDB, and identifies differences between the sets.
|
Baseline | A baseline is a set of CIs and their associated attributes, having a known state, used as the basis for comparison. You can view a baseline within drift management as a saved CMDB query that identifies the CIs that you want to use as your baseline CIs
|
Target | A target is a set of CIs that you compare with the baseline. These CIs are the items in your IT environment, as they currently exist, that you want to audit to verify that they are at the correct state of configuration.
|
Source dataset | The source dataset is the location of the CIs that you want to use for your baseline or target.
|
Snapshot | A snapshot is a copy of a subset of CIs from a source dataset to another dataset that is the destination dataset.
You can create multiple snapshots of a particular set of CIs and use these snapshots to determine whether the configuration of the CIs has changed. |
Qualification set | A qualification set is a query used to select the specific CIs that you want to use in your baselines, targets, or snapshot jobs. A qualification set is required when you create a snapshot, a baseline, or a target. |
Include set | An include set defines CI attributes that you want to include in a comparison job to determine whether the CI attribute value has changed or is not set at the correct value. An include set can provide greater granularity during comparison because of its variety of comparison operators such as EQ, GT, LT, LE and the ability to specify attribute values such as a standard value to compare against. Using an include set is optional. |
Exclude set | An exclude set defines CI attributes that you want to exclude or ignore in a comparison. Using an exclude set is optional. |
Drift workflow
Data from a discovery application is reconciled by Reconciliation and placed in the BMC Asset dataset. This discovered data is then used by drift management.
The following image is a representation of a drift workflow:
- A snapshot of the initial state of the dataset is captured by the snapshot job and is used as a baseline for comparison later.
- Discovery updates the dataset with CIs that may have changed and this is used as the target for comparison with the baseline.
- The comparison job compares the baseline snapshot to the target dataset.
- The output of the comparison job can be either used for change management or incident management depending on the use case.
The data on the compared CIs can also be used by a comparison service. - The list of detected CIs can be either displayed or exported to the drift report.
Common scenarios for using drift management
Following are some scenarios for using drift management:
- Comparison of the current state of BMC CMDB with a snapshot
You want to determine whether drift has occurred over a period of time. You make a snapshot of BMC Atrium CMDB at a given point in time (this becomes your baseline) and later (a day, a week, or a month. Compare the current state (target) with the baseline.
For more information about using drift management for this scenario, see End-to-end-drift-management-example to become familiar with the drift management workflow when creating a comparison job. - Comparison with a standard state of CMDB
You compare the state of BMC CMDB with a baseline to ensure that the physical state is not drifting from the declared standard.
This scenario is commonly called the golden server or golden CI. Within BMC CMDB, you have the CIs for a crucial business service (for example, security) configured exactly as needed. The golden CIs are the baseline with which the other security servers (targets) are compared to verify that they are configured to match the declared standard (the baseline).
A golden CI is configured exactly as needed and is used as a basis of comparison with your target CIs. - Comparison between a test dataset and BMC CMDB
You want to define a test or sandbox dataset on top of another dataset to determine the impact of potential modifications in the test dataset on BMC CMDB. In this scenario, BMC CMDB is the baseline and the test dataset is the target. The comparison uses the BMC CMDB API to view the equivalent of a merge between the two datasets.