运维左移系列（二）：工作范围分析（1）

上一篇提到运维左移围绕“提高业务连续性保障、提升业务交付速度、辅助提升客户体验、提升IT运营服务质量”4个价值分析运维左移，本篇围绕“提高业务连续性保障能力”这个运维价值分析运维左移的范围。

传统BCM提出的业务连续性管理是指为有效应对重要业务运营中断事件，建设应急响应、恢复机制和管理能力框架，保障重要业务持续运营的一整套管理过程。影响业务连续性管理因素比较多，比如自然灾害、外部服务中断、人为攻击破坏、信息系统相关软硬件设施故障，通常关注在高优先级的业务中断事件的保障。此处的业务连续性保障聚焦在信息系统相关软硬件设施故障的事前、事中、事后管理，是整个运维，乃至IT最基本的工作，业务连续性问题事关IT是否能“活下去”。

1.业务连续性保障能力分析

前面我提出过故障管理闭环“故障预防、故障发现、故障响应、故障定位、复盘改进”5个密切协作的环节，并据此闭环制定了数字化故障管理的解决方案。相比业务连续性保障，故障管理闭环更强调故障应急过程管理，业务连续性保障在事前涉及的面更广，是为了最小化业务中断事件对公司造成的影响，减小损失风险和增强公司对于意外事件造成的业务中断的恢复能力。从这个角度看，可以将业务连续性管理分为：应对准备、规避预防、加固保护、全面监测、应急响应、恢复处置、故障定位、事后重建8个环节。

（1）应对准备

应对准备是为了达到业务连续性管理目标而对业务连续性能力进行管理而开展的各种工作。比如：建立和维护应急准备体系、应急科技支撑、风险评估、业务连续性计划、完善规划体系及沟通协调机制（规划、组织协调、沟通与信息共享）、建立和维护应急能力（资源配置与管理、人员培训）、验证和更新应急能力（应急演练、应急评估、联络方式更新）、设备冗余等持续改进的能力建设。分析上可以围绕规避预防、加固保护、全面监测、应急响应、恢复处置、故障定位、事后重建分析而分析，通过持续改进的准备过程建立保持完成各类任务所需要的能力。

（2）规避预防

规避预防为了避免业务运营中断事件的发生而开展的各种保障工作，目标是要降低事件发生的可能性，尽可能避免事件发生，减少启动应急响应和业务恢复等任务，比如两地三中心、容灾、架构高可用等举措。

要确定运维组织需要预防哪些事件，需要对潜在的风险源和威胁、保护目标及相关风险有一个全面了解。组织需要进行业务影响分析、识别危险源、开展风险评估，以确定有什么措施可以降低事件发生的可能性或减轻事件带来的损失，然后根据业务影响分析和风险评估情况选择相应的控制策略和措施。

（3）加固保护

加固保护为了保护关键对象，减少运营中断的损失而开展的各种工作，是针对保障对象与增强活动，降低保障对象的脆弱性，其最终效果是为了提高保障对象的韧性。

随着技术架构越来越复杂，影响信息系统风险事件的因素越来越多，比如：技术成熟度、应用逻辑复杂、频繁的变更迭代、海量的连接、外部依赖环境不可用、操作风险、协同机制等。这些因素都可能引发保障对象的脆弱性，从而带来企业的损失和破坏。提升信息系统在面对风险事件时的韧性是加固保护的重要手段，比如故障恢复、性能扩展性、数据完整性、数据备份、自动化及灰度发布、可观察等方面的能力加固。

（4）全面监测

全面监测是综合运用监控、人工、告警等手段监测保障对象，以更快地发现异常并采取行动，以阻止随着时间推移引发更大的损失。监控重点关注自动化手段在线感知异常事件，监控重点关注“不漏报、少误报”，是一个持续丰富完善的过程。人工是综合组织内外部的信息源，对所有可能发展成事件的威胁和危险源进行监测，以便进行预警和警报并采取措施。

告警是在监控或人工发现异常的基础上，为尽可能阻止事态恶化或防止更大损失而开展的风险事件识别、响应的过程。运维组织在事发前需要分析业务连续性事件的发展趋势、影响分析，梳理事发后事件可能演化路径，进行态势研判。

（5）应急响应

应急响应在指在事件即将发生、发生期间或发生后，为减少故障影响而开展的保障、指挥、危机沟通、应急协调等工作，可以围绕应急协同、告警触达、影响分析3方面进行建设。对故障影响初步判断是一个难点，考验运维人员的故障识别能力，不仅要求有基本的应急技能，还要对系统有深刻的理解，以及工具层面对于关键KPI指标的数字化水平。在故障响应过程中，系统故障受理人，关联上下游系统运维人员，值班经理等各个角色的作用都尤其重要，需要不断练习或实战来提升协同顺畅性。运维左移有利于建立故障影响管理体系，比如影响指标、业务识别（业务影响对象及关联）、恢复目标确定（各业务最小业务连续性目标）、资源需求分析、业务影响分析报告等。

（6）恢复处置

恢复处置指业务中断事件发生后为在可接受的时间范围内将业务恢复到预定水平而开展的各类工作，比如已知预案处置、未知尝试性处置、自动恢复三类活动。很多故障是在不断尝试执行解决恢复的动作，所以故障恢复环节与故障定位环节有一定的交叠，或在这两个环节之间不断试错的循环，循环次数与运维专家经验与平台能力相关，即故障恢复操作可能和故障诊断是并行执行，也可能是诊断之后或诊断之前。在故障恢复中运维组织通常采用已知预案下的恢复“三把斧”：重启、回切、切换自动或手动触发系统架构韧性策略、临时决断的恢复动作，以及恢复后的信息传递。

（7）故障定位

故障定位指在业务中断事件处置过程中，对引发故障的直接原因、根因的诊断工作，故障定位有助于故障恢复动作更加有效。由于故障处置是以快速恢复业务连续性为目标，很多故障定位又以故障定界为目标，而非寻找问题根因。实际过程中，很多可用性故障借助运维专家经验的假设判断或已知预案的执行可以得到解决，但仍有部分性能、应用逻辑、数据正确性引发的故障需要多方协同与可观测相关工具支持。故障定位的方法通常包括专家经验驱动的假设尝试、测试复现、预案启动、代码分析四种，这个过程涉及对日志、链路、监控、数据感知、知识管理五类工具。随着系统复杂性不断提升，依靠专家经验驱动的假设尝试准确率会下降，如何将数字化手段结合专家经验，融入协同机制，考验故障定位场景的设计水平。

（8）事后重建

事后重建是指在将业务中断恢复后，将业务彻底恢复或恢复到更高水平而开展的改进性工作。事后重建通常结合故障复盘机制推动相应改进性工作，比如硬件设施涉及的高可用、备份、扩容等，软件技术架构韧性涉及的高可用、降级、限流等，应急能力涉及的专家技能、应急预案等，应急协同涉及的跨团队沟通、信息传递、应急指挥等，应急机制涉及的onCall值守、应急信息扩散、危机升级等，应急工具涉及的监控、日志、链路、数据等。

2.业务连续性保障左移

在“应对准备、规避预防、加固保护、全面监测、应急响应、恢复处置、故障定位、事后重建”8个步骤的分析中，可以考虑反思以下30个问题来分析应对措施：

1)是否建立持续完善业务连续性风险评估与影响评估工作？

2)是否针对关键组件异常制定业务连续性计划？

3)是否落实常态化的应急演练,并推动混沌工程发现未知风险？

4)是否建立容灾、高可用、安全、可靠、稳定、弹性伸缩能力的基础设施？

5)是否针对故障恢复推动软件架构韧性（故障隔离、服务降级、前端限流与削峰等）设计？

6)是否具备弹性或快速执行的性能扩展性？

7)是否建立可靠的数据完整性与数据备份？

8)是否落实冗余资源的准备？

9)是否建立差异化的交付能力，以应对敏态运维涉及的快速迭代需求？

10)是否在软件交付的评审、新系统上线、变更迭代、系统退出等环节中涉及的相关文档交付与更新、风险评估等机制？

11)是否提前推动可运维性涉及的日志、监控、拨测、终端体验、服务性能、重要状态、极限值等数据埋点？

12)是否建立信息系统的自动化及灰度发布能力？

13)是否建立闭环的配置更新机制？

14)是否建立互联网终端版本管理，终端版本向下兼容？

15)是否确保信息系统关键组件异常监控覆盖面？

16)是否持续提升信息系统关键组件异常、软件有效期、极限值班、性能、容量等潜在风险的监控发现及时性？

17)是否持续提高监控告警后的故障识别与响应效率？

18)是否在线感知客户行为、体验、反馈状况，并建立故障发现的业务、客服、客户等问题的感知与协同能力？

19)是否建立信息系统关键KPI指标体系，并针对体系进行在线感知？

20)是否建立上帝视角的系统稳定性的感知能力？

21)是否建立主动的运行数据分析推动应用架构的健壮性、性能评估、容量评估等工作机制？

22)是否建立信息系统关键业务影响评估模型？

23)是否建立事中高效的应急协同网络，能够快速按需拉动或主动加入协同，实现透明的应急信息共享，并建立高效的应急指挥管理？

24)是否建立学习型的运维组织，持续推动运维人员主动熟悉信息系统相关知识？

25)是否建立完备、准确、可实战的应急预案管理？

26)是否提供必要的应急操作处置工具，比如重启、回切、切换自动或手动触发系统架构韧性策略等？

27)是否建立故障定位涉及的日志、链路、指标、仿真环境等设施？

28)是否与研发、测试、供应商建立联合故障定位的协同机制？

29)是否能够将故障过程信息留痕，并为后续的故障复盘提供数据支撑？

30)是否建立闭环的事件复盘、问题跟踪揭示机制？

运维左移重点指从软件交付的时间线上的左移，结合上述问题的反思可以考虑设计以下运维左移的工作：

1)左移到软件交付前

l【可运维性】可运维性涉及的日志、监控、拨测、终端体验、服务性能、重要状态、极限值等数据埋点

l【技术评审】新建系统、重大变更、系统组件退出环节涉及的架构韧性、性能及容量伸缩、可运维性的技术评审

l【软件交付】持续交付涉及的版本、配置、数据库、程序发布

l【混沌工程】生产及准生产环境的常态化混沌工程

l【应急方案】系统重要知识、应急预案，以及其他文档，能让专家技能的管理

2)左移到故障前

l【业务连续性评估】持续的专项业务连续性评估，包括：风险评估、影响分析、业务连续性计划、应急演练的准备性工作

l【稳定性评估】基础设施稳定性与弹性能力，在用信息系统容灾、高可用、软件架构韧性、性能、容量评估与管理等主动评估工作

l【终端管理】互联网应用的灰度、终端管理

l【混沌工程】生产及准生产环境的常态化混沌工程

l【在线感知】监控覆盖面、准确性、响应效率，以及运行及业务智能感知

l【业务影响指标】业务影响关键KPI指标体系

l【多团队协作】OnCall值班、应急在线应急协作、应急指挥、危机升级

l【应急方案】系统重要知识、应急预案管理，以及其他文档，以及专家技能的持续提升

l【排障工具】围绕“日志、链路、指标”综合性可观测能力的应急中心建设

l【恢复工具】应急环境、工具建设