December 12, 2011, 4:30 AM PST
Takeaway: Configuration
management is one of the few processes that overarch all other process
and service lifecycle phases in ITIL V3. Wthout it, the effectiveness of
the rest of your processes will be in serious jeopardy.
Overview of Service Asset and Configuration Management
SACM is a combination of two processes that work on a common platform, and yet they can be handled as discrete processes - asset management and configuration management.Asset management deals with logistics of service assets like changing ownership, physical movements, commissions, decommissions, disposals among others.
Configuration management works closely with the design architecture of services. It draws relationship between configuration items (CI) which is vital for resolving incidents, tracking changes, releases, finding the root cause of problems and charting the technical service catalog.
As there is a dependency of configuration management across other processes, especially in service operations, it makes logical sense to implement it first. It is the foundation upon which we can build a stable IT service management environment.
The Configuration Management Plan (CMP)
Sometime back, I discussed the Service Management Plan - which is a document that contains all aspects of a service, and is drafted before the service is implemented. Similar, a plan is needed to run configuration management effectively before implementing the process.Configuration manager owns the configuration management process, and is accountable for drafting the plan as well.
Here are the basic components of a CMP:
1. Scope - Do not start any plan without a scope. It is important to know your boundaries. In the case of CMP, an organization might have hundreds of services and you might be in charge of a few dozens - jot down which services come under the purview of this plan, and those that don’t. It is good to put everything down in writing although many feel that it is implied.
2. References - A configuration manager will obtain information from service architects, service owners, team managers and just about anybody who can throw light on the service in scope. The data is compiled, verified and is reconstructed on a configuration management database (CMDB).
To ensure the validity, and highlight the rightful owners of the data source, a section on references listing the data source against the service is necessary. This will help the configuration manager point the finger at the right source, when questions are raised. I would go one step ahead, and attach the received data and the emails in my plan.
3. CI Nomenclature - Every service asset or CI must have a unique identification. A server can have something like SRV123 or just 123. Both do the job, but which one is effective? Can somebody just look at the CI name, and make a rough guess which technology it comes under with the latter? No. It makes logical sense to name CIs in a way that mere glancing can tell most of the story like what type of CI it is, location, complexity, and other attributes.
During one of my implementations, I named CIs this way -
<Type of CI - Server, Router etc>-<Location>-<Complexity>-<Running sequence>So, a router will have something like RTR-LOC-L3-12345.
A team like the service desk which is on the least level of capability can make decisions on their own. In the example above, they could just as easily decode the CI as a router, placed at a specific location and handled by L3 support team. So, in essence, outage is minimized as the L3 team is directly involved during resolution, and a couple of functional escalations can be thankfully avoided.
A fellow consultant went one step ahead and hard coded the CIs to contain the name of the team who own it. My only argument against it was what would happen to CI names if a different team took over the ownership - let’s say in an organizational rejig scenario. Would they start naming their CIs all over again?
4. Baselines - Regular baselining of CMDB must be scheduled at least one year in advance. A baseline is a benchmark drawn, for future reference to compare the deltas.
Most organizations call on two change freezes, one during Christmas and the other during Easter. I found it apt to take baselines during the change freeze period, and perform analyses if need be.
5. Change Control - Configuration management is strongly linked with the change management process. Without a valid change ticket, a CI cannot be touched - for modifying of course. In other words, change management controls the changes to CIs on the CMDB.
The CMP must specify how the change management process will interface with the configuration management process. And, at what point of the change activity will configuration management process be called upon.
6. Verifications and Audits - The accuracy of CI data is cardinal. To ensure that it stays accurate, a number of verification and audits are necessary.
Verification process is done by the configuration manager on a regular basis, and is mostly tool based. Modern tools are capable of providing reports that can help verify CI data. For example, if every CI has 10 fields, the CMDB tool can pull a report of those CIs that are not fully complete. Or, if CI1 states that it is the parent of CI2, but CI2 does not state that it is the child of CI1, its noted as a discrepancy, and comes through in one of reports that the configuration manager can use.
Audits on the other hand are generally performed by somebody other than the configuration manager or any of his team members. In an audit, a sample number of CIs are picked up, and are randomly verified against actuals.
Let’s say SRV-DC1-L2-234 is going under the scanner. The auditor will first check if this CI is a server in the first place, and whether it is located at data center DC1 in rack 121 as per the CMDB. The server is checked whether it is loaded with Windows 2003, and contains 2GB RAM among other attributes as per the database?
An audit report is prepared based on the findings, and the configuration manager gets a major or minor non-compliance (NC) depending on the degree of discrepancies (if any).
Well, this is how an audit works, but all the aspects of it, like how often it must be conducted, who does it, what degree of non-compliance will set a major tag, what actions are to be performed by
a configuration manager if a major NC is shoved in his face are to be noted in the CMP.Conclusion
According to me, these six sections are everything, the rest like introduction, purpose, roles and responsibilities, definitions, trainings etc. are merely page fillers, and should be done at one’s own discretion.It is critical that you think through the process, and visualize if the process plan is doing what the process is supposed to be doing. Does it meet the KPI requirements and most importantly, customer requirements?
If you have any questions on my suggestions, give me a shout. Glad to help!
http://www.techrepublic.com/blog/tech-manager/itil-what-goes-in-a-configuration-management-plan/7054?tag=nl.e106
Aucun commentaire:
Enregistrer un commentaire