事中故障处理（4）故障定位
故障恢复指恢复业务连续性的应急操作，很多故障是在不断尝试验证解决恢复的动作，所以故障恢复环节与故障定位环节有一定的交叠，或在这两个环节之间不断试错的循环，即故障恢复操作可能和故障诊断是同时，也可能是诊断之后或诊断之前。在故障恢复中我们通常采用已知预案下的恢复三把斧：“重启、回切、切换”、自动或手动触发系统架构高可用策略、临时决断的恢复动作，以及恢复后的信息传递。
1.已知预案下的恢复三把斧
在故障管理过程中，通常大部分故障有一些明确的故障恢复预案，比如基础设施、服务器、网络设备、网络线路，以及应用系统层中关于服务可用性等故障因素，以及基于历史故障经验积累的方案。在实践中，不管是简单的故障，还是疑难杂症，基于已知预案都是应急恢复的重要手段。在预案中的操作步骤中“重启、回切、切换”是当之无愧的使用最频繁的手段。以一个复杂故障应急场景中，很多时候故障处置的决策人员通常一方面协调人员现场分析问题，另一方面指挥启动已知预案的应急。比如，如果性能下降，或个别服务异常等表现，采用重启恢复手段；如果前一日有变更，评估是否回切软件版本；如果主机异常暂时无法恢复，评估是否切换备机或容灾节点。
基于“重启、回切、切换”三把斧使用频率极高，围绕这个操作建立更为标准化、通用的工具是很有必要的工具建设步骤。
重启。建立线上化的重启工具是一个很有必要的工具，尤其是是当集群节点越来越多的背景下，能够快速对某个或某组节点服务进行重启、关闭、启动是一个有效的应急手段。同时，对于7*24的部分服务或进程数进行监听，并针对异常情况进行自动化的重启也是当前自愈的一个常用解决方案。
回切。大部分故障都是变更带来的，一方要将涉及变更的软件发布、数据维护、参数维护等行为线上化或自动化，提供针对变更的回切工具；另一方面要将变更行为数字化，当故障时能够让运维专家快速获知变更行为，并针对变更行为进行线上化回切。
切换。切换建立在高可用架构基础上，有热切换，冷切换，前者是无需人工干预的自动化切换，后者是需要人工干预的切换。从基础角度，切换又包括同数据中心内，或跨数据中心的切换，跨数据中心通常容灾切换。为了提升切换效率，除了建立切换工具，还要定期进行切换演练，确保切换操作正确性、时效性、可靠性
2.启用架构高可用策略
架构高可用性通常指系统架构通过专门的设计，从而减少停工时间，而保持其服务的高度可用性。站在故障恢复角度看架构高可用，我们可以简单的将生产环境的架构高可用分为不可修复系统与可修复系统。不可修复系统的平均寿命指系统发生失效前的平均工作时间或工作次数， 也称为系统在失效前的平均时间，比如基础设施层面的环控、服务器、存储、负载均衡设备、网络设备、专线等通常是不可修复系统，这类系统需要在初始阶段进行可靠性设计，使之不发性故障或难以发生故障，对于运维来说重点考验部署架构的高可用性，系统的技术选型，以及持续坚持架构的风险评估与优化。可修复系统，重点是基于系统恢复的速度和由发生故障恢复到正常状态所需要的时间，对于运维来说重点是保障系统可靠地、稳定地、不停机的连续工作，当出现故障时要尽快缩短恢复时间。
在具体的架构高可用性上，我认为对于核心与重要业务的平台或业务系统应该首先基于“不可修复系统”的思路，强调在设计、部署层面即要高可靠，比如在网络、安全、存储、硬件、数据库等层面的保证高可用，以及在负载均衡、集群、主从、主备、哨兵等流量或服务层面的高可用，确保无单点风险是这类系统的底线。其次，对于核心系统的功能、数据，以及非核心的业务系统，还要依赖降级、过载限流保护等更加细化的优化。另外，对于应用服务拆分、逻辑解耦、减少总线依赖、增加异常访问机制、必要的缓存、数据库层面的分库分表、前端限流与削峰、服务降级等架构优化，也能提升故障恢复能力。
3.临时决断恢复
虽然有不少故障可以基于已知预案、架构高可用与可靠性方面的设计提升故障恢复的时间，但是随着运维复杂性以及企业以客户体验为中心的建设，运维对可用性的要求在服务层的业务连续性基础上，增加了业务功能逻辑、数据完整性的故障恢复，这些故障恢复通常需要现场临时决断恢复。这些临时决断的恢复操作包括：
- 软件程序补丁优化，或部分变更功能回退。
- 采用数据脚本维护数据
- 采用调整业务或技术参数
- 手工启用备份系统或节点
- 针对故障节点，临时决定启动隔离、限流、降级的恢复策略
- 针对数据库运行状况，决定应急构建索引、杀掉执行中SQL等恢复策略
当然，临断型故障恢复也可以有优化方案来提升恢复效率，比如围绕CD构建的软件发布与回退功能提升软件发布层面的应急恢复，提供数据维护、参数配置工具、切换场景工具，以及高效的跨团队协同等自动化或线上化工具。另外，这类临断型的故障恢复中，有部分可能不能马上恢复解决，建议将这类故障的恢复以线上化的方式进行跟进。
4.恢复后信息传递
虽然从MTTR角度看，恢复通常以技术指标的恢复为判断条件，但是在实际的故障处置过程中，恢复结束的判断条件通常是验证与信息通报。
验证包括技术验证与业务验证。技术验证指从技术角度验证故障的恢复情况，比如基于日志、服务状态、数据库流水等方式，理想情况下建议围绕系统建立关键的运行指标，借助关键指标辅助技术验证。业务验证指联系业务人员、客户、同业等角度，从功能层面进行验证。技术验证对于运维来说更加可控，且可以全局性的角度观测故障恢复状况，而业务验证有助于辅助确认业务层面的恢复情况。理想情况下，故障恢复操作后，能同时进行技术与业务验证是最好的，如果无法找到业务验证，通过交易流水的执行状态变化、主动拨测、业务日志等方式也可以作为模拟业务验证的手段。
信息通报包括服务台、业务与客户、技术关联方、监管机构。故障恢复后，还要及时、有效的将恢复动作执行与恢复状况信息通报出去。其中，服务台重点是基于故障处置中的协同沟通的渠道，做好解释与反馈收集性的职责；业务与客户的通报是提升IT服务质量、客户体验的必要环节；技术关联方，包括与此故障相关的上下游的运维、研发、测试、安全等团队；监管机构重点是针对已经达到上报监管的重大故障，在恢复后的及时报告。
结束
注：“3.4 事中处置”另外3个环节内容链接：
腾讯云开发者
