CFIA in 4 Easy Pieces Adelanto CA

provided by: 
Originally published at Internet.com

You may have read about component failure impact analysis (CFIA) if you are IT Infrastructure Library (ITIL) certified. Many know that somehow CFIA is related to problem and availability management, yet it remains at best a fuzzy concept for most.

CFIA is a very effective tool for understanding how configuration items (CI) can impact the availability of an IT service, customer or user group. CFIA is an important tool for improving quality as well.

CFIA is a structured way of working that avoids the common pitfalls of off-the-cuff or processes-less way of working so common in most IT shops. CFIA helps you avoid focusing on what you and your team already know and thus stopping short of getting to the true root cause of a failure.

While CFIA is impressive sounding, it is really just a way of evaluating (and predicting) the impact of failures, and locating single points of failure (SPOF).

CFIA can:

* Identify CIs that can cause an outage; * Locate CIs that have no backup; * Evaluate the risk of failure for each CI; * Justify future investments; and * Assist in CMDB creation and maintenance.

All it takes to gain these benefits is an Excel spreadsheet or some graph paper. Following are the three steps to success with CFIA:

Select an IT service, and get the list of CIs, hopefully from configuration management, upon which the IT service depends. If there is no formal configuration management database CMDB, then ask around IT for documentation, paper diagrams and general knowledge.

Using a spread sheet or graph paper, list CIs in one column and the IT service(s) across the top row. Then, for each CI, under each service: a.) Mark "X" in the column if a CI failure causes an outage; b.) Mark "A" when the CI has an immediate backup (a.k.a "hot-start"); and c.) Mark "B" when the CI has an intermediate backup (a.k.a. "warm-start")

You now have a basic CFIA matrix. Every "X" and "B" is a potential liability. Every "A" is an opportunity to improve responsiveness.

The final step is to develop a request for change (RFC) to address the improvements identified. Examine first the "X's", then the "B's", by asking the following questions:

* Is this CI a SPOF? * What is the business/customer impact of this CI failing? How many users would be impacted? What would be the cost to the business? * What is the probability of failure? Is there anything we can do differently to avoid this impact? * Are there design changes that could prevent this impact? Should we propose redundancy or some form of resiliency? What would redundancy cost?

As you get good at CFIA, consider expanding your CFIA matrix to include the procedure used to recover from a CI failure as a row across the bottom of your CFIA matrix. (Of course, this requires that you are mature enough to have written procedures.) Adding documented response procedures to your CFIA matrix lets you examine the organization as well as infrastructure.

For each entry in your table ask yourself: