07 第二章 ITIL V2 流程的革命 故障管理 Ver 1.0.1

什么是“故障”？非计划性导致“业务中断”的重大故障，当然是“故障”。但是，即便是暂时没有影响业务，或者是在一段时间以内都不会影响业务的隐患，也在“故障管理”的范围内。

故障的定义

什么是一个“故障”？

我们查看一下ITIL 4里的原文定义，“服务的计划外中断或服务质量的降低，是故障。”大家注意啊，这里有个或字。也就是说，有两种情况都属于是“故障”。

一种是“计划外的中断”，也就是，导致了业务中断的，被称为“重大故障”。

另一种是“质量的降低”，也就是，暂时还没有导致业务中断，但是已经有异常迹象，也被称为“故障”。

这两种“故障”都是负面的不良事件，只是量级不同。而由于量级不同，处理的方式和紧迫性自然也不同。

首先是“导致了业务中断的重大故障”。“重大故障管理”的目的是快速的恢复业务，你先不用了解“根本原因”，也不需要解决“根本原因”，而是应该尽快恢复业务。

比如，一个关键系统，由于带宽突然不足，导致交易中断。这个时候，是要去找为什么网络带宽会突然不足吗？

不是！这个时候应该先暂时关闭一些不关键的业务系统，优先保障核心系统的带宽，恢复关键业务。然后，再对“症状”和“原因”进行分析。

再比如，在一个关键的业务日期，就，双十一吧。莫名其妙的出现，订单系统的数据库无法连接。这个时候，要去排查是什么原因导致的吗？不是！应该先紧急扩容，先让业务能够开展。然后，再分析“原因”是什么。

而对于第二种故障，也就是“暂时没有导致业务中断的轻量级故障”。那么，一旦发现，也是应该启动“故障管理”。而不是等到计划外中断的时候，再被动的响应。

比如，服务器的硬盘坏了一块，这是不是计划外的？这算不算是“故障”？算是，但是咱们有RAID冗余机制，暂时没影响到业务中断。因此，这算是一个轻量级“故障”。当然如果不去处理，仍然会发展为影响很大的故障。

比如，一台前置机出现了异常，需要重新启动解决。这算不算是“故障”？肯定是“故障”。但假设该系统一共有6台前置机，其中一台出问题不会导致业务中断。因此，这也是一个“轻量级故障”。

很多人对“故障管理”存在一个误解“影响了业务的才是故障”。这个误解紧接着会带来另一个误解，“速度就是一切”。如果速度就是一切，那么对“故障”的记录和处理就是一个僵化的形式主义。

但是，“故障”管理的一个重点正是，管理那些暂时还没有导致业务中断的异常。这正是为了避免导致业务中断的“重大故障”的出现。

有一个可以让我们借鉴的航空业安全法则：一切不安全的事故都是可以避免的。具体来说：每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。

这个叫做海恩的法则，是在提示，我们不能只重视那些“影响了业务的故障”，而忽视了故障的“征兆”和“苗头”。

界定优先级

并不是只有影响了业务的才是“故障”，那些暂时还没有导致业务中断的异常也是“故障”，只是量级不同。

有一次，一个运维经理苦恼的跟我说，我们CIO要求，所有登记的故障都要在2小时内解决。那么，一个交换机的风扇坏了，这算不算是一个故障？该不该登记？不登记吧，如果遗忘了，今后真的引发了温度过高导致的断网就不好了。登记吧，这种事就不应该立刻去解决，更不应该在业务时段去解决，因为这反而会导致业务中断。

其实一个“故障”的量级，就是在定义这个“故障”对业务的影响会是一个什么样的程度。当然，这种界定是一个定性，不是定量。一定要说一个“故障”影响了多少人，多少钱，及不准确，也没必要。

一个比较好的做法是，“故障”的“优先级（Priority）”是根据其“影响度（Impact）”和“紧急度（Urgency）”两个维度来决定的。其实在咱们中文里面也是一样的，“凡事都分个轻重缓急”，其中“轻重”就是“影响度（Impact）”，“缓急”也就是“紧急度（Urgency）”。

在信息化领域里，最紧急的事情莫过于导致重要业务系统的中断，一旦发生这样的“重大故障”，应该立刻告知CIO，然后在CIO的指挥下采取预案，例如、通告业务部门，牺牲一些安全或边缘业务，保障关键业务的运行，以及故障的恢复通告，和故障复盘会；

其次是暂时没有影响业务，但是危险性很大，例如、虽然有负载均衡，但其中一个前置机的关键进程丢失了，那么虽然是在业务时段，也应该，尽快处理。

对于没有影响业务，而且危险性不高的“故障”，可以允许在非业务时段去处理。

而对于一段时间内度不会影响业务的“隐患”，应考虑是接受风险呢？还是制定一个可行的改进计划。

为什么要进行“故障管理”？

首先就是避免被忽略，最容易被忽略的是那些暂时还没有导致业务中断的“故障”，被忽略的原因就是，没有记录，也无法跟进，每个人都以为其他人在管理，最终真的导致业务中断。

有人说，监测系统有报警呀。但报警仅仅是一个停留在某几个人手里的消息提示，比如手机短信。并没有形成一份，事中可以被跟踪，事后可以被核实的“故障记录单”。

有一次服务器的一块硬盘坏了，信息部门也发现了，但发现是发现了，并没有形成一个具体的工作。谁在找公司来更换硬盘？什么时间来更换？谁在跟进？反正有RAID的冗余。所以大家都没太当回事。结果，结果就是由于几块做RAID的硬盘是同一时间购买的，另一块硬盘在三天后也坏了，导致关键业务中断。

讲到这里，就有人表示不认可。你说的这种情况，我们这可没有。都已经发现异常了，怎么还能没人管呢？我们这没有这么没责任心的人。

可问题的关键，不完全是责任心的事。很多排错过程是一个跨岗位，跨部门协调的事。

因为，信息系统是一个由若干业务系统共同构成的有机整体。一个系统的异常，其原因可能是另一个系统导致的，这就涉及到需要协调多个系统团队的排查工作。但一个技术人员往往很难去协调多个其他岗位，而很多问题就在这些协调过程中被耽误了。

如果仅仅是解决了一个表象性的异常，则可能掩盖了真正的原因。一些重要的隐患也会形成，最终导致业务中断的“重大故障”。而只有具备了正式的“故障记录”，完整的“故障”管理才有可能，使得监测系统发挥效益，使得隐患得到控制。

故障的记录

无论是对“故障”处理进度的跟踪，还是事后的核实，登记“故障记录”都是一个重要的开始。

那么，哪些信息是“故障记录”最必要的登记内容呢？这，没有标准答案。但，我的建议是，应该记录三个基本信息，和，四个处理内容。

三个基本信息是这个故障的：优先级，大类和子类，系统和设备。

四个处理内容：谁参与了本次“故障”的处理，这个“故障”的“症状”是什么，我们最终确定的“原因”是什么，怎么解决的本次“故障”。

首先说三个基本信息。

第一个为什么要界定这个“故障”的优先级？前文提到过，优先级是这个“故障”对业务影响程度的一个定性，这个定性决定后续的处理过程和目标时间。

那我们再来说说第二个，为什么要记录这个“故障”的大类和子类？就是因为，对故障的“分类”其实是在试图理解和识别，是哪类软件或硬件导致的故障，比如，大类是数据库，子类是Oracle或者SQL。大类是服务器硬件，子类是联想，还是DELL。因为，很多“故障”在一开始难以确定具体的“技术类别”。所以，在刚刚登记“故障记录”的时候，这个大类和子类可以不填写。在需要经过了一定的排查后，圈定了可能的范围，填写了“技术类别”，然后就应该看到该“类别”中的“已知问题”，并把以前沉淀的“知识”带出来，这有可能帮助到本次的排错。而且，更重要的是，这有利于识别“重复性错误”的再次发生。

第三个基本信息，为什么要记录这个“故障”实际对应的“系统”和“设备”。首先我们得知道，故障的排查是一个调查过程。

一个“故障”的现象可能体现在订单系统上，但其实根源也许在ERP系统；

可能业务系统不能正常使用，但也许根源在网络丢包；

因此，真的确定到是哪一个“业务系统”，哪一个“设备”的“故障”是需要一个诊断过程才能确认的。咱们前文说过，如果是导致业务中断的重大故障。那么，这个“调查”是在事后再开展的。

不论是“重大故障”的事后调查，还是轻量级故障的排查，在“故障”解决后，我们应该得到一个完整的“故障单”。

也就是，什么业务，什么系统受到了影响，是什么设备导致的，属于哪一个技术类别，谁参与了本次“故障”的处理，这个“故障”的“症状”是什么，我们最终确定的“原因”是什么，怎么解决的本次“故障”。

故障的过程和测量

对于“轻量级故障”管理的流程，我们建议，将故障的处理过程分为，处理中，已解决和已关闭三个大致阶段。

在轻量级故障的处理过程中，需要将“监测系统”自动发现的或者是人为发现的异常，登记为“故障”，并且在故障排查或应急响应的时候，运维人员需要与研发部门和外部供应商之间展开协作。

·      因为，有很多故障或者隐患是需要运维岗位和研发岗位以及外部供应商之间研究讨论的；

·      很多维护类工作需要派工给外部服务商执行的；

对于“故障”处理，这样一个涉及多个岗位，多个部门，多个机构之间的“协作”（Collaboration），就需要有一个约定，什么级别的事情，需要以什么样的时间要求去响应和处理。而这就是“服务级别约定”，简称SLA。

·      对各个级别的故障，约定在多长时间内解决，这就是SLA；

·      可是，仅仅对解决时间有要求是不够的。需要对对处理过程中每个环节，每个岗位的时间有要求，才能确保达到解决时间。这就是OLA；

·      还有，涉及外部服务商协助解决的环节，同样需要有约定，这就是UC；

在故障已解决阶段，意味着这个故障已经被暂时解决了。这是，我们有时间可以对“故障”处理的信息，进行补充和完善。也就是前文提到的三个基本信息，四个处理过程信息。然后对轻量级故障的解决进行核实，对重大故障要进行“故障复盘会”。

建立对“故障”的管理制度是开始，后续需要持续的对这个流程进行管理。但是，我们无法管理我们看不见的事情。所以，就需要通过“数据”辨识这个流程的效果和效率。

比如，我们需要知道：

§ 从监测系统发现异常，到受理为“故障记录”的时长；

§ 二线处理人员的处理时长；

§ 目前有多少“故障”的处理已经超时；

§ 有多少超时未解决的“故障”，在一段时间以来毫无进展；

故障的核实（Post Incident Review）

将“故障管理”的制度通过流程进行固化有很多好处，可以固化处理过程和对应的岗位职责，可以让我们跟踪进度，但最重要的是固化管控点！

我个人认为，一个没有固化管控点的流程，等于一个没有起到控制作用的管理机制。

那么，在“故障管理”中最重要的“管控点”是什么？是事后的核实，业界俗称（Post Incident Review）。

大家可以这样想象一下，这就像是一个足球队，比赛后大家做在一起重新回顾一下比赛的录像，目的是一起找到下一次比赛时可以改进的地方。

信息部门也是一样，随着信息系统的规模和复杂性的增长，“故障”是避免不了的。那么，就把每一次“故障”当成是一个学习机会。通过一个“故障回顾会”的机制，把这个故障的发生和处理过程进行一次回顾，讲明这个故障的“症状”、“原因”和“解决过程”。识别故障的前兆症状和原因，目的就是消除根源，防止故障再次出现。嗯，即便是再次出现了，那么我们对这个“故障”也已经有一定的认识了，这会缩短下一次故障的处理时间。

有些人在确定了一个“故障”的原因，并且消除了这个“根源”的时候，就不想再开“故障回顾会”了，认为这是浪费时间。比如，一个软件缺陷，导致的“故障”，通过升级已经消除了，这个“故障”不会再次出现了。

虽然这个“故障”也许不会再次出现了。但是，团队中的其他人，可能并不真的知道发生了什么，也没有机会学习到处理的方法和技术，更没有机会贡献自己的知识。

每一个列明了“症状”、“原因”、“解决办法”的“故障记录”，也消除了业务部门，高层领导对信息部门的猜测，提高了对信息部门的信任。

重要的是，“故障回顾会”不是追责会，而是一个从故障中学习，并将问题转化为改进。因此，“故障回顾会”这个环节，一定要根植在“故障管理流程”之中，准确的说是流程的最后一步。

故障的回顾会 的建议内容：

§  高级摘要：哪些系统和业务受到影响？故障持续了多久？谁参与了处理工作？最终是如何解决的？

§  根本原因分析：故障的根源是什么？为什么这里是根源？

§  诊断、评估和解决的步骤：为了解决故障，采取了哪些措施？有效还是无效？

§  下一步工作：如何防止再次发生？

最后，我们总结一下“故障管理”的观点：

·      观点一：故障是不可避免的，因为创造系统的人就不是完美的，也就没有完美的系统。

·      观点二：每一次故障都是一个学习的机会，可以促进我们的改善和能力的提高。

·      观点三：追究责任只会适得其反。