面对不断复杂的生产环境，如何围绕“故障发现、故障响应、故障定位、故障恢复”四个关键环节，进行多方面统筹建设，从而达到增加TBF和缩短TTR的目标？

TBF（无故障时长）和TTR（故障修复时长）是业务连续性管理两个重要指标，故障处置管理的目标就是为了最大限度的增加TBF和缩短TTR。在具体管理中，我们通常会根据故障应急处置时间轴扩展以下指标：MTBF（无故障时长）、MTTI（平均故障发现时长）、MTTK（故障定位时长）、MTTF（平均故障处理时长）、MTTR(平均故障响应时长)，MTTF(平均故障恢复时长)的思路，从故障发生时间、发现时间、响应时间、尝试处置时间、诊断时间、生效应急处置开始时间、故障恢复时间等梳理应急处置的关键节点。通常，MTTI=发现时间-发生时间；MTTR =响应时间-发现时间；MTTK =定位时间-发现时间；MTTF =恢复时间-定位时间。

面对不断复杂的生产环境， 要增加 TBF和缩短TTR的目标，需要围绕“故障发现、故障响应、故障定位、故障恢复”四个关键环节，在人员技能、协同机制、工具平台、数字化感知等方面进行统筹建设。

一、故障发现

故障发现指生产故障或潜在风险被监控等机器或运维人员发现的过程，重点关注发现及时性。从故障发现角度看，主要包括监控发现、协同发现、数据运营三个方式。良好运维组织的故障发现应该大部分来自监控等自动化手段，甚至对一些确定性很强的故障进行自愈行为。其次，当前故障处置过程是一个多角色协同的场景，构建在线协同网络有助于提升协同效率，基于协同网络建立高效的信息传递是当前提升故障发现能力的重要手段。另外，随着系统复杂性不断提高，运维组织也在推动数据运营分析工作，主动的基于数据运营推动故障发现将是一个有力补充。

1.监控发现

从人机协同角度看运维管理，监控相当于给运维团队分配了成千上万机器人，这些机器人驻扎在硬件、平台软件等对象中， 7*24不 间断的采集指标数据，并将指标的异常情况实时推送出来。监控已经是发现潜在风险或异常的源头，推动监控发现的覆盖面、准确率、告警触达能力的提升，是缩短故障发现时长的关键举措。以下从被动监控、上帝视角、主动拨测三个角度分析如何提升监控发现能力。

1） 被动监控

此处强调 “被动”监控是为了区别主动监控，指代传统在基础设施、硬件资源、平台软件、应用可用性、客户体验多个层级的监控管理，以及统一的监控 告警管理。这类监控方案通常是针对已知异常环节，采集指标数据，配置监控策略，以及触发策略后将监控告警统一推送到统一告警系统。

对于源端监控端强调 “不漏报、少误报”，实施上关注平台能力建设与工具运营两点：监控平台方面采用乐高式组合提升能力，比如缺性能监控补充APM、NPM ，提升监控覆盖面；工具运营方面采用数据与机制运营推动，监控策略需要运维人员在工作过程中，结合企业系统的实际特点，在平台通用监控策略上持续的丰富针对性策略，运维组织需要建立事件或任务触发机制，比如事件复盘对监控发现能力的分析，并通过主动的监控评审、监控告警数据分析等运营工作发现哪些系统监控监控的覆盖面与误报情况。

2） 上帝视角

传统被动性的监控管理是针对已知异常，进行补丁式的增强监控的方式持续完善的过程。但运维面临三个困难，一是随着架构复杂性越来越高，运维组织面临越来越多的的未知的故障；二是数据量与风险触发因素增强后，单维指标监控监控能力不足，而多维指标让人配置又面临无法穷举的问题；三是运维对于故障发现已经在可用性故障基础上，增加了功能逻辑、数据类故障的发现要求，对于日志、链路的监控发现能力要求越来越高。

提出上帝视角是运维组织需要借助算法、海量数据、平台能力，构建一个全数字化监控感知的能力。这种感知能力需要尽量减少运维打补丁式的增加细化的指标策略，利用算法能力加深感知监控深度，利用海量数据加大感知监控广度，利用平台加快感知监控的速度与穷举的能力。当然，当前这种上帝视角对监控发现的准确率、覆盖面仍需要一个提升的过程，应该作为传统监控的一个补充手段，而非替代。

3） 主动拨测

主动拨测监控是采用模拟用户访问终端、域名、页面 URL、 功能、 API等， 从客户视角监测功能可用性、感知用户端体验、检测网络链路质量，系统事务可用性，领先一步发现问题，提升客户体验。在企业推动以客户体验为中心的数字化转型中，拨测是监控发现的一种有力补充。借助机器不间断、自动化执行，提前设计好拨测执行的脚本步骤，可帮助运维执行更细粒度的功能操作，主动获取应用运行的性能体验指标，更准确地了解客户访问业务功能级的体验，以及应用层及网络层性能。同时，站在故障处置角度看拨测，当发生异常时将执行过程进行截图留痕，还可以辅助快速定位问题。

在拨测的解决方案中，通常包括公有云或私有化拨测方案，前者是通过拨测运营商提供部署在世界或全国各地的拨测源进行测试，用户不需要管理拨测终端，只要根据 SLA 明确的时效性、次数等付费，就可以获得拨测结果。私有化部署的拨测方案则运维组织管理拨测涉及的服务器、终端设备等环境。运维组织可以根据政策、风险、成本等维度考虑选择不同的解决方案。

2.协同反馈

虽然我们希望故障尽量由机器自动化发现，但是随着基础架构、应用逻辑、业务逻辑越来越复杂，系统一个小模块异常都可能导致系统自身甚至关联系统的业务连续性故障，建立一个在线的协同网络，提升协同节点中业务、客户、同业、开发、测试等团队的反馈的效率，仍然是故障发现的有力手段。

1） 业务、客户、同业反馈

理想情况下，应尽量减少由业务与客户侧反馈的故障发现占比。但是现实中仍有部分故障，当前监控或运营分析比较难实时发现，比如功能逻辑性、数据准确性等类别，这些故障虽然不会带来全局性的可用性故障，但是站在以客户为中心角度，此类故障对个别或部分客户属于可用性故障，尤其是对公重要客户或权益类交易故障。针对这类故障，运维要提前建立一个高效的信息反馈的渠道，基于用户旅程梳理并建立全线上化的问题反馈是一个好的选择，比如：将问题反馈整合在业务系统中，系统可以获得快速获知用户反馈问题的热点信息，并通知运维处理；建立全线上化的服务台、一线、二线的问题处理流程，问题反馈的业务人员可以在线获知问题处理进度，机器可以根据问题反馈时长进行线上督办。另外，在企业内部建立必要的信息系统即时通讯沟通群，方便公司内业务人员的即时反馈，安排相应的问题服务岗位正在被很多运维组织接受。

同业反馈是针对同类业务事故的一个比较好的方法。比如，银行里涉及人行结算中心、银联、第三方支付、通信运营商等；券商里涉及的交易所、银行、通信运营商、重点厂商等，通常事故会有一定的共性，如能建立实时的故障信息互通互联的渠道，将有助于故障发现、定位、恢复决策与执行。参考前面提到的企业内容信息系统问题反馈的即时通讯群，提前建立行业间的即时通讯沟通群也很有必要，在预案中提前确定关注、咨询的沟通预案步骤与责任人是一个有效的方法。

2） 开发或测试发现

开发或测试发现的故障是一个边界比较难界定，但又不可忽视的故障发现方式。边界难界定，有一些客观原因，比如很多系统或变更是带缺陷上线，这些缺陷本身在生产运行中会触发故障条件；很多线上的问题，如果是业务反馈，可能会先到达开发人员，由于故障通常在组织内会被用于质量考核，部分开发人员可能延迟问题的反馈。不可忽视，前面已经提到开发与测试反馈的故障，由于个体的重视程度或主观因素，可能导致故障处置的及时性。

这里暂不探讨故障涉及的考核方式，但是建议在流程中建立线上化的问题反馈闭环，比如在变更环节，制定紧急变更类型，这类变更与一般需求变更区别，紧急变更的变更 ID 由线上化的运维问题单分配，紧急变更支持更高优先级的上线支持。再比如建立线上存量缺陷的管理，包括缺陷触发条件、缺陷影响、缺陷计划修复时间，将部分中高风险的缺陷转为生产问题管理，并定期对线上存量缺陷问题进行复盘管理。

3.数据运营

数据运营强调主动的运行分析。主动是当前运维组织转型的一个重点方向，对应的是当前被动响应服务请求、需求工单、监控告警、生产故障的工作模式。数智万物的运维世界为主动分析提供了数据原材料与平台赋能支持。

1） 常规巡检

本节的巡检针对常规的例行巡检，在监控不断完善的今天，经常会引发“是否还需要巡检”或“巡检是否可以被监控替代”的话题。监控能代替巡检，主要思路是因为覆盖面与机器执行力更强角度出发，由于监控覆盖面越来越广，且很多巡检的指标数据也来源于监控系统，且监控执行力更好、实时性更强，认为监控将代替巡检。认为巡检仍是一个必要手段的主要思路是监控的覆盖面与可靠性角度出发，覆盖面是指仍有一些重要的点监控无法发现，引入专家经验进行巡检可以发现一些疑难杂症。我的观点是，要区分运维组织的职能，对于一些以设备或服务可用性为保障的组织，随着监控与自动化巡检手段的覆盖，巡检将慢慢被机器代替。但如果是需要对业务层进行保障的团队，巡检仍将与监控等自动化手段并存，是一个重要手段，一方面是因为监控对于业务层的问题发现覆盖面有待提升，另一方面由于业务层的保障要求运维人员要持续深入的学习系统，巡检是运维人员保持必要的学习力、关注度一个手段，尤其像证券行业这种重点保障开盘、银行业的批次清算等时点。

总体来说，巡检的常规操作性工作是一个被自动化替代的过程，巡检内容则需要运维专家不断深入，巡检的管理机制则需要不断的固化为巡检规则、任务、报告、数据感知等解决方案。从技术角度看巡检，在巡场上可以分为定时巡检与基于事件驱动的临时巡检，实现上通常需要数据采集与执行的代理（或复用现在的自动化能力），巡检策略规则，巡检任务，巡检报告、值班管理几块内容。

2） 深度巡检/分析

深度巡检 / 分析，我更倾于命名为深度巡检，因为巡检意味着例行工作任务，对于运维数据例行的深度分析将是主动运营工作一个转变。一个潜在问题的触发，通常触发三种策略：诊断误报并取消，潜在风险挂起，发起故障响应流程。与常规巡检针对线上问题的即时反馈并发起故障响应流程，深度巡检主要是针对潜在风险的发现或预测。深度巡检通常从分析牵头方看，通常可能包括两类，一类是由运维组织内专家发起的主动性的运行分析；另一类是通常商务合同要求供应商定时执行的深度巡检。

深度巡检分析的主题应该关注影响业务连续性的风险点，比如应用及数据库等平台软件性能容量、容灾 /应用架构高可用、应用逻辑缺陷、数据质量、高可用有效性、应急方案、技术保障方案、数据备份、数据丢失、监控发现及时性 等。在实施上，要区别于常规巡检，更加深入分析。同时，深度巡检最好是一项联合运维组织硬件及系统软件运维人员、第三方软硬件厂商、应用系统维护人员等人员协同进行的深度分析工作，要建立线上化的协同机制，确保各环节的衔接紧密与落实。

3） 运行感知

此处指的运行感知与监控与巡检有一些区别，监控与巡检都是根据已经制定的策略或任务发现问题并触发故障流程，是针对一个个细分点的分析，运行感知是一个面的分析。运行感知是从运维专家视角，感知运维对象的运行状况，需要从感知面与感知策略制定感知方案。在感知面上，要广泛使用运行数据，将影响运维对象运行的数据指标化，比如基础设施层的网络链路延时、丢包率等，平台软件层的响应时间、资源负载等，应用系统层的端口监听、 JVM 内存利率等，业务及体验层的交易成功率、页面加载错误率等，也就是说只要与运行对象相关的关键运行状况的数据都要指标化。在感知策略上，要善用基线的策略，比如偏离度，制定同比、环比、首笔出现等，或引入一些 AIOps的算法获得更加有效的基线。

在实现上，运行感知不仅仅独立存在的实时运行看板，还应该与当前主干的运维流程结合在一起，才能不断的加深感知面与感知策略的深度。比如，将运行感知与巡检的定时任务结合在一起，要求每天都分析感知数据；将运行感知的异常数据推送到监控告警系统，融入到监控处理的流程中；将运行感知融入到故障诊断的环节，作为问题诊断、影响分析的一个工具。随着运行数据分析能力的提升，运行感知在故障发现环节中将起到越来越重要的角色。

二、故障响应

故障响应指故障发现后机器或运维人员介入应急处理的过程。相比故障发现、定位、恢复，故障响应环节对协同的顺畅要求更高，通常可以围绕应急协同、告警触达、影响分析 3 方面进行建设。其中对故障影响初步判断是一个难点，考验运维人员的故障识别能力，不仅要求有基本的应急技能，还要对系统有深刻的理解。另外，在故障响应过程中，系统故障受理人，关联上下游系统运维人员，值班经理等各个角色的作用都尤其重要，需要不断的练习、实战来提升协同顺畅性。

1. 应急协同

在降低故障处置过程中 TTR 时间过程中，故障响应是最容易被忽视，但又可以占用最长时间的环节。很多运维组织会制定 “故障先报告后处理的”要求，其中一个考虑因素就是要加快故障的响应速度，以免延误战机。应急协同的管理是故障响应的关键举措，以下从ECC 管理、信息在线、服务台三点对应急协同进行介绍。

1） ECC管理

ECC又叫总控中心，或监控指挥中心，是成熟运维组织对运行监控、现场值 班、联络调度、事件处置等职责的日常工作场所。从人看， ECC 主包括：值班经理、流程经理、一线运维、二三线条线专家、服务台（也可以将服务台归到一线运维）等岗位。从 ECC 形态看， ECC 通常是一个独立的房间，里面有值班与应急需要的设备。在对于单个主数据中心的运维组织中， ECC 里面值班的人员包括所有运维团队的值班人员，是公司最核心的应急处置场所， 做 好 ECC 管理是加快应急协同的最重要措施。

从故障响应看， ECC 定位应急指挥中心的角色，需要制定一些工作机制。比如制定一线值班的工作职责，处理监控事件、应急响应与处置、问题咨询的解答、变更工单处理等，明确的工作职责有助于值班人员专注最重要的工作，提升故障响应的及时性。再比如落实好应急环境准备，里面要有运行情况的大屏，一线运维需要的办公终端，二线现场支持时需要的终端，用于应急使用的日志、运行数据、监控报警的工具系统，用于对故障临时决策讨论的房间，以及一些联络的通讯设备，故障定级、分析、联络人员的文档。

2） 信息在线

由于信息的复杂性越来越高，一个业务关联的设备与系统越来越多，应急管理是一个多团队协同的工作，充分保持故障过程中的信息在线是一个重要举措。从故障响应角度看信息在线，又可以分解为协同在线、数据在线、工具在线。

协同在线指故障处置过程的线上化，比如故障处置过程中涉及监控报警或工单转化故障、故障通报、故障升级、故障定位、故障恢复、应急集结等环节线上化。从故障响应角度看协同在线，重点关注面的转化故障、故障通报、应急集结、故障升级几个步骤。其中故障集结是对故障关联人员的即时触达，或要求相关人员到达 ECC 现场参与应急，可以借助全自动化手段或半自动的手段。要做好以上协同在线，需要提前做好协同机制，并进行演练，减少实际故障过程中的沟通成本。

数据在线指将故障处置过程需要的数据在线化，让参与故障响应的人员可以方便的获取数据，提升并发处理故障的能力。数据在线关注要提前准备哪些数据，数据如何让参与处理故障的专家方便看，如何方便专家获得数据，如何获得故障进度。在数据方面，关注与故障涉及对象的故障数据，比如运行对象负载、性能、关键运行指标、服务状态与数据、近期变更、监控告警、上游系统状况等。要让专家方便看数据，要提前将相关数据以服务化方式提供给运维以外的团队，或进行桌面演练与混沌工程工作。要方便获取数据，则需要建立线上化的运维数据服务门户，一站式开放数据。要即时获知故障处理进度，则要让故障进度及时通告，并线上化触达关联人员。

工具在线与数据在线类似，只是数据关注提前落地好关键指标的数据，工具则关注提供一个更灵活的功能集合，比如日志查询工具、数据库查询工具等。

3） 服务台

ITIL对服务台定位是连接用户和IT 部门的唯一信息交换平台，它起双向信息反馈作用，并且与多个服务管理流程密切相关，为用户提供与问题、变更、服务级别、发布、配置、IT 服务持续等管理流程的接口。基于此，IT 服务台承担了故障发现、故障响应、故障解释等工作，方便用户方便快速地获得故障处理进度，让运维应急专家专注应急响应，减少沟通解释的工作。

在不同行业中， IT 服务台的能力起到的作用不同，比如一些大型制造业，服务台一天可能会受理成千上万的服务工单，这些企业的服务在故障响应过程中起来极为关键的作用。要更好的支持服务台能力的提升，服务台应该提供快速响应 IT 部门内部呼叫涉及的渠道工具、在线的工单分派、工单级别升级等工具，让服务台工单处理全在线。比如一个涉及故障的工 单 的过程：请求登记、故障匹配（知识库或经验）、故障分派、跟踪状态与反馈故障处理状况、故障与应急方案解释、故障解决、客户或业务沟通。要提升故障响应效率，服务台是一个很关键的角色，需要通过提升线上化与自动化能力为服务台赋能。

2. 告警触达

对于告警触达，强调 “统一、高响应”。统一指全公司的监控的监控 告警需要实时汇总于一个告警系统，由这个告警系统进行告警的整合、收敛、丰富、升级、触达处理人或机器。高响应则需要推动告警触达人或机器后，针对告警能得到快速的应急动作，要实现高响应需要即时知道哪些告警处理发生后没有响应，或响应了但是长时间未关闭，对这类告警实时进行再次触达或升级，并定期对低响应的运维对象（人、系统、机器等）进行排名公示。

1） 统一告警

下面这个统一告警归纳图是我几年前整理，现在看起来仍然是一个比较完整的产品功能图。站在故障响应角度看 统 一告警，需要关注是否所有监控告警都进行了集中，是否从告警风暴角度对告警进行收敛，是否从告警定位角度看对告警进行丰富关联，监控告警是否与故障处置线上化系统线上化打通等。

2） 告警描述

从我的个人经历看，告警描述是一个很重要的环节，尤其是对于 ECC 值班的工作。但遗憾的事，好像对于告警描述，大家关注得不太够。我引用一段之前写过的内容：
完善的监控策略需要有清晰的监控告警提示，值班人员要以根据监控告警即可作出简单的问题定位与应急处理方案。比如类似以下的监控短信：22时，【理财应用系统】中【应用服务器LC_APPsvrA 10.2.111.111】的【前置应用模块】出现【应用端口：9080】不存在，该端口作用【提供理财应用处理（负载均衡部署）】，原因可能为【SERVER1服务异常停止】，监控系统己进行以下应急处理【自动执行端口进程启动】，该事件紧急程度【高】。管理员可以通过短信内容看到哪个系统、哪个应用、哪个模块出了什么问题，可能是什么原因，对业务有什么影响，是否需要马上处理（比如凌晨出现此预警是否可以延迟到次日处理）等信息。

3） 告警升级

告警已经成为最为关键的故障发现渠道，提升故障响应需要提升监控告警的升级机制。要升级，要先分级，运维组织可能根据实际情况对级别进行划分，我建议告警的分级应该结合应急响应机制进行分级，如果组织的精细化程度还没那么高不要分太多级，比如分为三级：一级对应高响应的告警，二级是对客户或业务有影响的告警，三级是潜在风险但未对客户产生影响。制定了告警分级，下一步是将告警响应线上化，系统可以针对告警响应的时长，进行升级。对于高风险的告警，升级可以通过触达方式的升级，比如先用短信通知，不及时用电话通知，或通过大屏的色彩，或触达处理人上司与值班经理，或按级别推送到团队的IM群中进行公示。对于低风险级别的告警，长时间不响应的低级别告警，可以升级为高风险级别的事件，并根据高风险级别告警进行告警触达。

3.影响分析

在故障处理过程中，运维人员很容易钻进故障定位与恢复环节，但要加强故障响应的协同效率，让应急协同中的决策者、值班经理、上下游系统运维、开发、测试、业务、服务台共同参与到应急中，对故障现象与影响面的描述必不可少。同时 在处理故障前，故障现象直接决定故障应急方案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度 ，清晰的故障影响面描述，有助于资源的准确调配。

1）关键指标

遗憾的是故障影响面有时很难判断，尤其是在应急的那个争分夺秒的时刻，要准确判断故障影响面需要具备对应用架构、业务功能等有综合能力的专家。针对短时间很难快速判断影响面的问题，提前做好准确性工作是一个比较好的方向。比如提前对影响业务系统、平台软件、基础设施等层面的运维对象进行分析，对影响这些对象的关键 KPI 指标进行提前定义。所谓的关键指标，是指衡量系统运行情况的可量化的数据，比如性能管理中常提到的交易量、成功率、延时等指标数据。这类指标数字不要求很多，但要求指标能能反映故障产生的影响面，可参考故障定级、业务影响程度、上下游依赖等角度去定义指标。制定了关键指标后，接下来要解决的是让关键指标在线、可观察，要让应急协同的参与人都能快速的获知关键指标的实时运行的数字。关键指标能够让运维专家，尤其是故障协调的决策层快速判断故障级别，并针对级别进行资源的调配。

2）具体影响

关键指标的获知可以更加准确的调配应急资源，判断是否启动应急集结的响应机制，具体影响面的分析则通常需要故障处理现场的临时分析决策。在故障响应环节赋能具体影响的分析，通常需要提前提升运维专家技能，让运维专家加深对系统的理解，比如：系统架构、上下游关系、应用服务、应用日志、关键数据库表、关键参数配置、主要的业务流程等信息。为专家提供方便的工具也是提升影响分析的赋能手段，比如：日志、感知等工具。另外，建立在线的协同机制，让应急协同的各方在线将各环节（上下游系统、开发代码排查、测试复现、业务分析等）的分析信息同步出来也是提升具体影响的方法。

三、故障定位

故障定位指诊断故障直接原因或根因，故障定位有助于故障恢复动作更加有效。故障定位通常是整个故障过程中耗时最长的环节，故障定位的目的强调快速恢复的基础上，而非寻找问题根因，后者由问题管理负责。通常大部分可用性故障，要借助运维专家经验的假设判断或已知预案的执行得到解决，但仍有部分故障，尤其是性能、应用逻辑、数据故障需要多方协同与工具支持。故障定位的方法通常包括 专家经验驱动的假设尝试、测试复现、预案启动、代码分析四种，这个过程涉及对日志、链路、监控、数据感知、知识管理五类工具。随着系统复杂性不断提升，依靠专家经验驱动的假设尝试准确率会下降，如何将数字化手段结合专家经验，融入到协同机制中，这考验故障定位场景的设计水平。

1.定位方法： 

1）专家经验驱动的假设尝试

2）已知预案启动

3）测试复现

4）代码分析

2.定位工具： 

1）日志

2）链路

3）监控

4）数据感知

5）知识管理

四、故障恢复

故障恢复指恢复业务连续性的应急操作，很多故障是在不断尝试验证解决恢复的动作，所以故障恢复环节与故障定位环节有一定的交叠，或在这两个环节之间不断试错的循环，即故障恢复操作可能和故障诊断是同时，也可能是诊断之后或诊断之前。在故障恢复中我们通常采用已知预案下的恢复三把斧：“重启、回切、切换” 、自动或手动触发系统架构高可用策略、临时决断的恢复动作，以及恢复后的信息传递。

1.已知预案下的恢复三把斧

（重启，回切，切换）

2.启用架构高可用策略

（隔离，限流，降级，熔断）

3.临时决断恢复

（发布、调参、修数）

4.恢复后信息传递

（验证、信息通报）