一提到CIFA这个概念，很多人都会说：

"哦，这是一种问题定位与分析方法吧“

然而大多数人对概念本身并不是特别清晰，基本上停留在”耳熟而不详“的阶段。那么我们现在就对CIFA进行一番简单的讨论。

CIFA的全称是Component Failure Impact Analysis （组件故障影响力分析）。早在1970年代，IBM首先提出了这个概念及相关操作流程。它可以帮助我们解答这样一个问题：

一旦独立组件发生故障，我们的IT服务将会受到什么样的影响？

总体上说，CIFA是一种过程方法。它本质上不要求你采购任何系统就能实现。当然，现在有很多的基础运维软件声称他们实现了CIFA，其实这个过程你在纸上也能完成，步骤如下：

1、找到你的IT基础架构当中的那些关键配置项，并找到与这些配置项相关联的服务。如果你有CMDB系统，这很简单（前提是CMDB的信息是最新的，我见过很多CMDB数据库里面还是若干年前的配置信息，与当前IT环境已经大相径庭）。如果没有CMDB，找一找纸质资料，或者问问信息部门的其他同事。他们多半会知道的。

2、在纸上画一个矩阵表格，最左侧一列是配置项信息，最上面一行是服务名称。然后填表。对于每一个配置项，如果这个配置项故障导致服务故障，那么画一个“X”；如果这个配置项故障，服务会切换到另外一个配置项，标记“A”；如果这个配置项需要人工重启，标记“B”。

好了，基础的CIFA分析表创建完成。每一个标记“X”和“B"的地方，都是你需要重点关注的。接下来就需要看着这个CIFA分析表，然后回答如下问题：

1、这个CI（配置项）是单点故障吗？（系统中一点失效，就会让整个系统无法运作）

2、一旦故障发生，IT服务会受到什么影响？多少人会受到影响？（具体到哪些功能或哪些部门）

3、在故障期间，要产生多少费用支出？（包括但不限于更换备件、售后支持等）

4、什么样的报错会产生？

5、我们能够承担服务宕机所带来的风险吗？

6、我们如何对这个薄弱点进行防护？

7、我们是否应该提供配置项冗余？成本是多少？成本支出是否合理？

8、如果建立预案机制，是否能有效规避这些风险？

把这些东西搞清楚，有什么意义吗？

当然有意义。

首先，在没有任何IT风险或故障发生时，它为IT安全生产运维提供了先机。当某个业务系统宕机时，你拿着这张表，会优先检查哪些标记为“X”或“B”的地方。这很有助于故障恢复。对于标记X的故障，尽快划拨费用进行备件采购或安排技术支持；对于标记”B“的故障，你对这个配置进行人工的重置或重启。这都会大大缩减业务系统故障发生的时间。

其次，这是IT投资规划的基础。对于那些CI（配置项），在故障未发生时进行适当的投资或预案，甚至通过IT系统重构来去除这些潜在风险，都会防止企业或组织在信息化架构上遭遇更大的风险，进而避免难以估量的损失。

当然，辛辛苦苦做出来的表格，千万不要扔了。你要把它归档为“风险日志”，以待日后备查。

下面一张图采集自IBM的《IT Architecture-Component Failure Impact Analysis (CFIA)》文档。从中可以大致了解CFIA的规范流程。