01
业务连续性与信息系统应急之间的关系
谈到业务连续性，相信大家并不陌生，业务连续性管理是保障企业业务持续运转的重要组成部分。通过字面意思来解读，无论业务连续性管理（BCM，Business Continuity Management）还是业务连续性管理体系（BCMS，BCM，Business Continuity Management System）都可认为是一套完整的业务连续性组织能力的管理框架，与其他许多管理领域都有着密切的关联，如下图所示：
其中的应急管理领域，顾名思义指的是面对突发事件时，快速响应并紧急采取有效措施，将损失降低到最小的相关活动。进一步延伸，可扩展到事前的预防与事后的复盘改进与持续优化。应急管理全过程概括如下：
早在2011年，《商业银行业务连续性监管指引》（银监发[2011]104号）中明确提出了“商业银行应当开展业务连续性风险评估，识别业务连续运营所需的关键资源，分析资源所面临的各类威胁以及资源自身的脆弱性，确定资源的风险敞口。关键资源应当包括关键信息系统及其运行环境，关键的人员、业务场地、业务办公设备、业务单据以及供应商等”。并且随着云原生、分布式等技术的快速发展，金融单位核心系统的不断升级和迭代，企业和组织对于IT系统的依赖程度越来越高，IT 风险与业务风险相互交叉，叠加发生的可能性不但存在而且有不断增强的趋势。一旦业务信息系统出现问题，将带来无法估量的严重影响：
服务中断
信息系统故障可能导致金融单位的服务中断，无法正常提供客户所需的金融服务，如转账、支付、查询账户余额等。这会给客户带来不便，并可能导致客户流失。
数据丢失或泄露
信息系统故障可能导致金融单位的数据丢失或泄露，包括客户的个人信息、账户信息、交易记录等。这会对客户的隐私和安全造成威胁，可能导致金融诈骗等问题。
业务延误和损失
信息系统故障可能导致金融单位的业务延误和损失。例如，无法及时处理交易请求、无法准确计算利息和费用等，这会影响金融单位的运营效率和盈利能力。
声誉损害
信息系统故障可能对金融单位的声誉造成损害。客户对金融单位的信任和满意度可能受到影响，而且媒体和公众对于信息系统故障的报道和评论可能进一步损害金融单位的声誉。
因此我们在此处主要谈论业务连续性管理和信息系统应急之间的关系。
1、关联性
业务连续性包含了信息系统应急。信息系统应急主要解决业务中断的重要事件应急和灾难级别的应急活动。而超出了业务业务连续性管理的部分事件，就是我们日常碰见的一些高频事件了。
2、管理对象
业务连续性关注整个组织的管理运营从而支撑业务的正常运转。而信息系统应急管理，主要关注围绕着“事前——事中——事后”的操作对象中。
02
企业信息系统应急成熟度等级
2023年5月23日国家市场监督管理总局与国家标准化管理委员会联合发布了重新修订发布了《信息技术服务数据中心业务连续性等级评级准则》。通过解读，我们认为落实在信息系统应急上的能力成熟度建设同样也分为几个等级，如下所示：
- 起始级：离线管理应急预案，运维管理领域各工具之间相互割裂；缺乏日常应急管理意识；
- 基础级：具备应急预案、场景、演练的初步线上化管理能力；初步具备应急组织架构和日常组织架构的体系建立；
- 发展级：应急执行流程的建设，并配套完成演练的执行、应急事中的执行，以及流程执行的过程展示，过程暂停、查看日志等管控能力。
- 稳健级：引入故障注入等能力，实现常态化演练和无损演练；预案、场景等经验沉淀，完善预案体系和覆盖率，提升处置效率；通过持续改进，强化整个运维能力的提升，包括变更管理能力、应用架构能力等；
- 卓越级：深度联动可观测体系，一体化建设故障的辅助定位和预案推荐能力，提升自愈率；以故障为核心，打通观测、运营、管理、操作等故障全流程管理、处置过程；全面评估应急体系能力水平，助力组织目标安全稳定高效的实现。
03
企业信息技术应急管理现状与影响
目前大部分企业的信息系统应急水平还处于起始级或基础级，在应急事中存在以下现状：
- 应急预案建设不完善；
- 预案的时效性难以保证，平时可用，真到事发时却发现用不成；
- 应急感知慢，可能从业务端反馈才知道；
- 应急时不同系统间来回切换查看数据，故障决策难；
- 应急依赖专家经验，预案选择难；
- “击鼓传花”式应急执行，跨组织之间协调机制差；
- 应急过程记录不全，缺少应急管理相关度量指标，导致无法形成应急管理运营体系无法形成闭环。
这些现状都可能导致我们应急事中的处置环节时间延长，轻则耽误了业务对外提供服务，影响了企业的正常运营。重则需要需要向监管单位进行述职并接受严厉的大额罚单，甚至还需要处理不断发酵的舆情。例如今年年中，某地证监局就对某券商公司的业务中断事件开具罚单，并要求于3个月内完成整改工作并向某地证监局报送整改报告，同时对信息技术中心行政负责人采取出具警示函的行政监管措施。
04
企业需要如何管理应急
事实上，事情的本质就是我们能够通过工具体系和管理规范，确保专家经验沉淀的预案保持良好的时效性，工具能力的有效联动并辅以管理规范的有效驱动，就能大大缩短我们的应急处置时长，保障业务的连续性。
*注释*：
MTBF：平均无故障时间
MTTI：平均调查时间
MTTK：平均故障定位时长
MTTF：平均故障处理时长
MTTV：平均故障确认时间
MTTR：平均响应时间
通过提升MTBF时间，降低MTTR时间，就可以有效的管理应急全流程。这里我们总结了以下“1-2-3-4”设计原则：
- 一个目标，快速止血，第一时间回复生产。
- 两大场景，“事件应急”和“灾备应急”。
- 三个一体，“技术平台一体”，实现底层能力平台PaaS化；“管理操作一体”，实现应急管理思想和自动化操作的同和；“数据融合一体化”，实现应急决策所需配置数据、执行数据、性能数据的统一管理和展示。
- 四个全面，应急过程全对象管理；应急过程全周期贯通，应急全场景覆盖以及应急组织不同的角色，无论这个组织在企业内是虚拟的还是真正存在的。
基于这个设计原则，我们可以更好的理解应急管理的建设目标，也明白支撑应急系统事中快速的响应，决策需要的数据来源，从而通过逐步迭代，小步快跑的模式，建设一套完整应急框架体系、应急管理综合解决方案。通过常态化的应急演练及运营优化思想，进而形成高时效性的应急预案库， 保障在重大突发事件出现时，应急处置及时有效，缩短故障历时，降低业务影响，有效防范和化解业务风险，最大程度减少该事件带来的损失。
展望未来，希望在大数据和AIOps人工智能的能力加持下，真正实现根因快速定位，进一步提升不同部门和专业间的协作和配合能力，以应对更复杂的问题和事件，使整个数据中心的应急能力更上一层楼，为业务提供更好的保驾护航能力。
每个企业应当考虑哪些因素可以使我们建设信息系统应急的“事前——事中——事后”环节卓有成效，又当在每个环节开展哪些活动，我们的微信公众号下一篇连载：应急灾备管理系列文章（二）——信息系统应急灾备管理的关键业务价值流和活动，敬请期待！
