故障自愈——游戏运维的终极福音

腾讯与CSDN再次携手主办的第二届游戏运营技术论坛将于7月30日上海浦东喜来登由由酒店隆重举办！本届主题为【云时代的游戏运营】。腾讯大讲堂将独家推出一系列游戏运营技术干货文章供大家讨论学习，敬请期待！报名请点击【阅读原文】

Chapter 1 【故障自愈的思路及解决方案】

故障自愈对运维意味着什么

在游戏运维领域，各种专业化解决方案越来越成熟和丰富，各类自动化工具不断涌现，包含发布变更、容量伸缩等多种运维场景的游戏云服务也在逐步优化和推广中……随着四化建设（专业化，标准化，自动化，服务化）的不断深入，游戏运维的操作方式正在发生着潜移默化甚至日新月异的变化，这些都会让运维人员可以越来越轻松起来。但运维最怕的其实还不是操作繁杂、工作琐碎，最怕的绝对是业务出问题！

从运维团队核心价值来看，个人认为，相比起对各种运维操作的需求，业务侧更需要运维提供的是全面而高水平的业务质量保障服务，包括对业务架构及部署的优化服务，包括专业而精细化的游戏健康度管理，以及快速的故障处理服务等。

我们通过不断提供更具服务化概念的运维工具，可以把很多操作移交给一线操作人员甚至可以移交给产品侧或研发侧人员。但对业务质量的保障，需要运维人员展现出自己真正的专业素质。

故障自愈服务尚未出现时，运维在故障自动恢复方面的处理一般是这样的：在运营服务器上部署监控脚本和异常处理脚本。当监控脚本发现业务任何异常时，调用处理脚本进行自动恢复。这只是最简单的一种情况，也是目前运维常用的方式。事实是，这种方式的局限性和缺点是很明显的：

1) 因宕机等原因导致的监控脚本自身不可用的情况，会导致故障出现后无法快速发现。如果采用类似网管这种具备中央感应的告警系统，则处理脚本对告警的获取又变成了一个比较困难的事情。也就是说，外部系统检测产生的告警是更稳定可靠的，但大大增加了处理脚本获取告警的成本。

2) 如果恢复服务过程非常复杂（如涉及到多个节点的恢复操作、或需要重启、甚至需要切换备机这样的较大工程等），需要调用作业系统及其他相关支撑系统才能完成，则无法通过这种方法简单实现。

3) 无法对集中产生的大量告警进行收敛和综合分析，无法应对复杂的异常场景并给于正确的处理。

4) 方案涉及的所有环节都需要业务运维自己实现，没有平台团队帮助运维实现公共的、基础的功能和服务。当涉及的业务很多、异常场景很多的时候，运维投入成本极高，而收效却往往不明显，性价比很低。

5) 整个过程中的通知和确认机制很难做到人性化的程度，又需要较高的实现成本。有了故障自愈服务，上述这些问题基本都很好的解决了。自愈服务本身已经实现了告警发现、对各种系统和作业的调用组件、告警收敛分析、基础告警的自愈套餐、人性化的通知和审核确认机制，还有公众账户提供全天候自愈服务！运维可以很轻松的接入到自愈中。

故障自愈能够帮助业务运维第一时间查明问题原因、并马上恢复故障，后续还能帮助运维输出阶段性待优化问题形成闭环管理。

从最终收益角度可以说，故障自愈，是对玩家利益、公司利益的最高保障，也可以说是运维的终极福音。

理想很丰满，现实很骨感

首先，我们需要先来看一下自愈服务所面对的是怎样一个复杂状况。业务出现问题的原因有很多，我们可以大致分为如下几大类：

1) 网络或IDC异常导致业务异常

2) 关键模块性能问题或bug导致业务异常

3) 主机硬件或系统异常导致业务异常

4) 无效误告引发的伪业务异常

其中，第1、2两类是告警最多的，也是最不好明确原因的，属于花很大力气还往往砸不出一点声响的那种类型。第4类是最让人纠结的，会让各种故障场景分析复杂很多。第3类相对最简单，也是我们目前处于服务试验阶段中接入最多的。

由于监控告警机制普遍存在于微观层面，类似于体检报告中每一个指标的阀值和检测值对比引发的异常点。我们可以很容易的做到检测出跟生命体征有关的所有指标的结果，但从一堆异常指标很难直接准确的推测出宏观层面的人体健康状况，还需要医生的经验分析。

类似的，我们几乎完全可以做到让告警毫无遗漏的发出来，但从一堆“自说自话”的告警中同样很难直接准确的推导出业务真正的问题及原因，比如应对一个进程告警的情况，恢复进程即可，但应对一堆进程告警的情况，就需要考虑很多可能的原因：进程配置错误、运维操作前未屏蔽告警、程序bug等。

对这类模糊性分析场景，人脑比电脑，从性价比角度大概可以说，不知道强多少倍。—— 好在，虽然很难，还是有办法的。

• 自愈系统自动发现所有告警信息，模拟并代替真人处理告警。

• 智能告警收敛分析：自愈系统对接收到的所有告警，必需要进行收敛分析，分析后进行正确的处理。简单粗暴的自愈处理是危险的。可以说，告警收敛分析是故障自愈服务的关键部分。分析会有几大类情况：

单一告警可直接自愈； 多个关联告警可收敛为同一个事件，需要对事件中涉及的关键告警执行自愈； 发现异常告警状况：需要运维人工确认后决定是否自愈；发现极端异常告警状况默认拒绝自愈。

• 流程闭环：

自愈成功：无人值守，触发告警处理单自动结单。 自愈失败/自愈超时：转运维或职能化团队人工处理。 未接入自愈的告警：兼容原告警处理流程不变。 后自愈分析：除了上述即时性的故障自愈处理之外，针对一段时间内的大量告警的整合分析，还将形成需要持续跟踪的待优化问题。

故障自愈总体实现方案

故障自愈是一整套严谨的故障自动化处理服务，通过和网平、作业调度平台、配置管理中心、告警单据系统等诸多周边系统自顶至下的全流程打通，轻松的实现了发现告警、关联配置信息、智能告警收敛分析、自动执行恢复操作、自动流程结单等功能。

自愈套餐的处理代码运行在分布式任务引擎上，可以调用大量封装好的周边系统接口，并支持并行、异步等诸多高级功能。处理逻辑可以只是简单的调用一下作业脚本，也可以实现复杂的分析逻辑。

Chapter 2 【故障自愈的应用场景】

故障自愈暨收敛分析服务说明

故障自愈所输出的服务，可以用一句话来概况——全自动的发现告警、分析告警、恢复故障。

其中，故障恢复是相对较简单和明确的，只要问题原因没搞错，故障恢复基本是水到渠成的事情，不能完全体现自愈服务的能力。对于复杂情况下的批量告警的分析和决策才是我们面对的真正挑战。下图列出了我们目前已实现的收敛分析策略，我们还会持续的在收敛分析策略方面进行积累和优化。

下面用几则典型案例，来说明自愈服务在告警分析收敛和故障自动恢复等方面的能力：

【案例一】

自愈收到了多条进程告警，经自愈分析后推定是发布变更未屏蔽告警导致的批量进程端口告警，自愈将这些告警收敛成一个“疑似告警未屏蔽事件”。并通知运维进行审核确认。后来经证实属实。

这个场景的难度在于，故障自愈的基本思想依赖于“告警本身是准确的”、进而才能“分析这些告警并做出决策和恢复动作”。所以当某种原因导致一大堆误告警袭来的时候，是对这种基本思想的很大挑战。

当然，自愈服务也并非完全听信告警所言。事实情况往往是，误告警多、“时过境迁”的告警也有，所以在关键的恢复操作之前，我们会有double check操作，避免误恢复。这些故障恢复操作之前的double check操作不是一成不变的，所以不是固化在自愈服务核心内的，而是固化在各个自愈套餐中的。如果是使用完全自己编写的自愈套餐，就要自己留意操作逻辑的周密性了。

【案例二】

七雄争霸业务日志中出现了异常信息、需要重启多个相关节点进程的场景。

没有自愈服务之前，运维不仅需要写监控脚本、以便发出这样的告警“wolf OutOfMemoryError”，还需要实现故障恢复脚本供监控脚本自动调用。

一方面，当这个恢复过程较为复杂时（如需要重新拉起多个节点的进程），需要调用作业（或其他方式）进行恢复，用shell脚本实现这些会比较困难。同时，监控和自动处理完全做到了本地，告警分析收敛等功能实现起来更复杂，需要运维投入的成本也会高很多。

使用自愈服务，运维可以非常轻松的实现这种故障的自动恢复。

Chapter 3 【小结】

故障自愈服务，本质上是一个无人值守引擎，实现了面向无人值守模式的一整套解决方案。目前自愈已经在很多个业务的故障自动恢复方面发挥出了不小的价值，后续还会有很大的想象空间，和智能告警等周边项目一起更深层面联动，实现更大的价值。