说明：本文根据付来文老师在 GOPS 全球运维大会 2021 · 深圳站的演讲速记整理而成。
作者简介
付来文，花名“郁松”，2013年加入阿里巴巴，多年来专注于业务连续性管理领域，见证了服务于阿里经济体的业务连续性管理体系发展。现负责阿里云一站式服务管理平台（AIOS)产品及服务，帮助云上企业解决数字化转型所需的实时运营及管理问题，保障业务连续性，降低服务成本。
本文介绍更偏业务连续性管理领域的事情，将从两大块进行介绍：
- 一是业务连续性管理的逻辑，不止是业务连续性，而是业务连续性管理，是最佳实践，包括背景及定义；
- 二是阐述一下我理解的业务连续性管理，也是我们在实践中沉淀下来的体系，包括实践经验和实践案例。
1、背景
去年由于疫情所催发的社会现象，相信大家或多或少都有一些感受。我是从杭州过来，昨晚看到新闻说深圳又发现一例，我还担心回不去杭州了：）
健康码也好，直播教学等等，都是疫情所催生的非常典型的业务应用场景。我不知道今天在座有多少同学真正参与到这个业务过程中去？疫情孵化的机会很短暂，但是如果抓住这个机会，对企业的发展有非常大的帮助，最典型是直播带货和在线教育。
我个人认为，之前在线教育发展趋势可能会趋于平缓（整体来说），但是疫情把它又带起来了。有一个典型的例子，去年在疫情的时候，因为直播教学非常火，有一家公司原来服务非常多的学校，有很多的高中生、中学生、小学生在学校上学，现在由于疫情需要转移到线上。他的系统假设只能承载X万人同时在线，疫情带来了业务增长10倍的机会，但是生产环境在IDC里面怎么来快速承载？今天都在提数字化转型，包括疫情这样的突发事件带来的机会，但当机会真的来临时，在座的同学是否准备好相关的能力去迎接好这样的机会？从X万的最高承载量忽然提升10倍，今天我们的经验和能力是否足够？尤其是从运维角度，是否能够帮助公司业务支撑好这个增长规模？这给运维带来非常大的挑战。直播带货也是一样，很多电商公司想抓住这个风口，今天我们能否在很短的时间内利用成熟的商业化技术及产品快速搭建一套直播系统，5天搭建和50天自研是两回事。数字化转型带来了非常多的挑战，今天举手说用到公有云的公司只有一小部分，我相信上云趋势一定会越来越突出。另一个层面，怎么在数字化转型的过程中保障好业务连续性。所以每次社会变革都孕育着一些机会，在每次变革过程中，例如第一次工业革命在英国，第二次在美国，都对世界格局带来很大的变化。那在这次数字化变革过程中，也一定有很大的机会。
在转型的背后，我个人所看到的业务连续性管理的机会。
另一个层面，刚才提问环节两位同学提到了一个很有意思的事情，就是中间件是否上云。这里有几个数据，第一是公有云IT基础设施支出首次超过传统IT基础设施。第二是Business DrivenIT。包括我这次来的时候路过机场，也发现华为云、腾讯云、阿里云都有对应的公有云广告，不知道大家是否观察到这个现象？我核心想表达的，是技术基础设施越来越完善，创业创新的成本一定会越来越低，企业一定会越来越专注于业务发展。包括这次疫情有多少家企业基于微信小程序直播带货很快速的把生意做起来，这是一个典型的基于云化的基础设施所带来的便利。在这个便利过程中，我想说业务连续性一定会成为快速发展过程当中企业的生命线。我认为业务连续性管理将会成为运维的核心职责之一。
2、什么是业务连续性管理
接下来谈什么是业务连续性管理，管理这个词我更喜欢用它的英语：Operations。
在讲这个概念之前，先解一下题。业务大家容易理解一些，今天对于典型的电商场景，什么是它的业务？对于电商来说是订单、成交额，对于在线教育来说是线上教学直播的时长。什么是连续性？也很好理解，可用性、稳定性、MTTR、SLA等都是表示连续性的量化术语。管理即运营，管理需要实时运营。
下方是一些国外机构，我不知道大家对业务连续性的理解有多少，这背后表达是国外已经有一些组织对业务连续性已经有了非常成熟的体系。国外有这些成熟标准体系对标我们国内能做到什么程度，我们在支持云上客户的实践过程中，也有一些可落地的最佳实践的经验。这有个X轴和Y轴，代表随着技术的发展和业务体量的扩大，对于业务连续性管理的诉求会发生变化。
今天大家来听我这个场次，什么概念要印象深刻？这一页大家可以快速形成一个基本的认知，刷新一下大家对于业务连续性管理的认知（有概念）。
接下来这是我为了大家便于理解，整理的业务连续性管理的1234（概念是什么）。
我先从最中间的管理范畴讲起。管理所有资源，包括基础设施、IOT设备、对应的一些业务和应用。包括管理所有的问题，工单报警、事件、故障。包括这两天开会时很多公司起到的变更管控。变更是一定会有，如果不变更企业产品迭代就没办法持续。左侧的组织资源保障非常重要，我们实践过程中，和一线运维服务人员聊的时候，他们会担心增加工作量，但我认为更多是需要思考背后带来的业务价值，再去寻求组织的资源保障。最右边的是流程机制把控质量，本质上是流程化的改进。下面的产品支撑高效管理，对应的有哪些最佳实践的产品，以及度量和可视我会在接下来的章节展开介绍。业务连续性管理最终目的是提升业务连续性，降低运维成本。
什么时候需要业务员连续性管理？有这么几个场景大家一定要记住（如何运用概念）。
第一是企业突然发生一个重大故障，例如核心业务中断两三个小时，这个时候领导一定很关心今天这个问题发生之后我们有什么体系或者措施保证下次不发生这样的故障，或者下次再发生这样的故障我们有什么措施能快速解决？
第二，今天我们运维做的很多工作，运维团队如果要有更大的边界去拓展，可以尝试运营业务连续性管理，这可以扩展运维的职责分工和业务范围。
第三，对于运维职能扩展和职业发展方向上的建议，毕竟运维一线的工作会有越来越多的工具，运维同学在某个领域做了这么长时间之后一定会有自己更高阶的发展，而业务连续性管理在阿里已经证实其可行性。阿里对应团队非常大，已经证明了这是一个成熟的职业路径，从运维管理向整个业务连续性管理去考虑。这是几个场景，对大家有一定的收益，帮助大家快速建立认知的场景。
但今天这个最佳实践不代表是业务连续性的全部，还有很多可扩展的空间，这里只是最基本的框架，我希望各位能够基于它，并结合自身企业的情况能够做相应的扩展，不一定那么多，也不一定那么少，大家可以根据自己企业的情况有一个最基本的框架化的认知，做业务连续性管理要有成体系化的认知，知道要做哪些事情。这是我们最佳实践的经验。
3、最佳实践经验
第三部分会展开讲，说说我们最佳实践经验的来源（概念的落地经验）。最左边是阿里巴巴安全生产的实践经验，右边是我们支撑一些云上客户的三年时间的实践经验，既有阿里巴巴自身实践经验的标准化和客制化，也是我们三年多自己所沉淀的最佳实践，在这个过程中，我们也发现大型的经济体业务、国计民生尤其需要体系化的业务连续性管理方案，需要将每次的故障影响控制到最低。我们也发现，越来越多中小企业需要开箱即用、按需付费的轻量化运维管理产品。
这是一站式管理流程图，刚才讲到整体框架，还有非常多的部分。但是那些怎么串联起来，这是一个流程式的指引。它会分四部分，包括业务CMDB配置、发现问题、处理问题、复盘改进。
大家做业务一定会有一些经历，即今天新接手一个业务，一定要梳理得很清楚。今天做业务连续性管理，需要把整个公司的业务做从上到下的梳理，公司的核心产品、核心业务有哪些核心模块，对应的核心指标有哪些。本质上需要运维同学跳过原本基础设施层面更往上看这个事情。它会有很多业务场景。
故障定义是阿里内部的定义，它的核心价值、核心功能、核心作用是定义好业务的优先级。业务故障并行发生时，要有一个优先级的共识。还有干系人、订阅关系、服务组都是管理人的资源。
这个流程里面，上面是通过监控来收集系统的问题，下面是通过工单来收集人工的问题，两者相关联才能做整体的业务连续性管理。事件是跟进的机制，确保的是线上每一个发生的异常都能够及时处理、能够有人处理、并且处理时有相应的机制。
对于故障，是更重的管理模式，每个故障一定会有一个根因，故障找到原因之后，一定要弄清楚这个故障到底技术问题还是流程问题，还是其他的问题，或者是第三方不可抗拒的因素导致的一问题，只有这样深根究底并制定对应的改进措施，才能形成业务连续性改进的闭环，它持续运营下去才会对线上生产环境会有越来越大的帮助。最后有一个管理者视角的数据报告，业务连续性管理的是业务，是需要面向管理来做运营的，需要借助管理的力量去推进改进事项落地，通过流程的方式来协同相关的干系人。
这是产品的实践经验，我这里面没有太多的产品截图，更多是讲产品体系怎么来支撑这个事情。这是一个产品的实践，每个颜色对应的产品功能或者模块，有CMDB模块、故障等等。做业务连续性管理，管理工作一定非常多，只有基于产品的基础上，规范、数据等等才能落地，才能做更高效的运营。
产品的方式有非常多种，你可以选择自己研发，也可以选择搭建开源的系统，也可以选择用相应成熟的商业化产品。
这里是监控，大家都已经非常熟悉，昨天我听到有提到今天时序数据库是整个数据库中增长最快的模块，情理之中。今天万物皆可时序数据化、皆可数字化管理，包括对应的IOT的监控。我相信其他的基础监控、业务监控、应用监控大家都已经比较了解。
为什么提到IoT监控与下面集成监控系统的对接？因为今天的监控系统实在太多，这些监控系统有存在的意义，也非常重要，但还有一个核心的工作要去做，就是把多监控系统能力做一个整合，不管是把数据统一汇聚到TSDB，还是外部所有的记录做一个汇聚整合，否则监控系统那么多会带来非常多的管理成本。基于监控收敛后可以做后续的报警、事件管理等等。如果大家有自研的监控系统需求，可以关注 Prometheus，基于 Prometheus 做一些上层的定制化改造，因为我觉得 Prometheus 在云原生领域的能力非常全面。当然也可以根据自己企业的需求采用第三方的产品。
这是公共云，前面开场调查环节大家举手很少，我不展开讲了，这是对应阿里公共云的能力，想表达的意思是今天各位如果要做监控相关的事情，不管是云上还是开源，已经有非常多的监控产品来做。
监控非常有必要，业务连续性管理的触手或者抓手是监控。监控加的越多，触角才更加细，更加实时。这里的监控层次概念都比较类似，之所以有这个层次，是希望大家有一个框架式的概念。这里面这么多层的监控，如果问我哪一层最重要，答案一定业务监控。我们做了很多客户，有个客户在帮他把业务监控完善之后，他才知道今天的业务核心峰值是在哪一刻，之前他都没有这个体感。
阿里内部的业务监控已经做得非常完善及成熟，当然做业务监控也有挑战，尤其是很多同学在做业务监控的时候选择的方式想的是直接从数据库里面写一个SQL弄出来，这个方式风险非常多，可能会造成线上故障。
业务监控的最佳实践手段一定是日志监控。包括我们自己在阿里内部实践那么多年下来之后，做到秒级交易订单也是基于日志监控。这是一个最基本的日志格式，这五个标准指标google SRE运维解密、阿里云、友商云都提过：总量、成功量、成功率、失败量和耗时。
这是IM工具协同能力。今天IM厂商在这方面的能力已经足够开放。为什么提消息碎片即生产力？因为它能很便捷的提升工作效率。大家工作过程中一定会有非常多琐碎的事务性工作，可以和它结合。大家看功能这么多，其实它并不复杂，不会耗费太多的研发精力。
这是变更管控，线上变更带来故障是难以避免的，变更管控到底从哪里入手？审批入手大家都知道了。阿里内部的经验是变更集成对接。今天一个企业工具发展到一定阶段，它能在生产环境做变更的工具一定越来越多，确保线上每发生一个变更一定会有一个集中的变更中后台的地方能做统一管理，并跟事件、故障做相应的数据联动查询，结合之后才能做更好的管控。
这是知识库。知识库的经验更适用于有一定业务规模的场景，我们在和一些客户实践过程中，业务连续性管理相关的业务问题场景，通过知识库来降低一线人员的处理成本，发挥着非常重要的作用。
而为什么提到要把工单和报警事件做结合？很典型的场景，很多运维同学在做限流的时候，不知道大家是否去关注过一线客服是否有反馈？很可能已经有一些用户反馈过来，只是大家不知道。通过工单和报警事件的结合，运维可以站在更高的业务层面去看已经带来的用户体验的影响，可以在限流手段上更精细化，或者时段避开。
怎么样的运维才能是好运维？大家都是说运维是空气，平时感受不到，只有出了故障才能感觉到。通过可视化，有一个非常关键的作用是将运维工作的业绩通过可视化的方式统一展示，给管理层向上管理、主动刷存在感。这非常重要。包括感知，更多是向上的感知，能够让上层知道你今天做了这么多工作，除了有故障的时候，平常没有故障的时候，到底运维做了哪些事情，通过可视化的手段做更好的向上管理运营，越实时效果越好。
4、最佳实践案例
这是我们给一个高校做的实践案例（概念的具体实践），有很多业务化的场景，包括常见的学校教室、教学、教务。这次疫情对学校的影响非常大，很多学生都是在线教学，在线教学的直播延时、人数等都是非常关键的指标，IOT设备整体管控、应急、策略都非常关键。这是我们在教育行业所做的案例，更多想表达的是今天我们能够跳出各自的固化思维，能够上升到业务层面去关心企业发展核心关注的指标是什么，以及站在运维角度怎么更好的服务这些用户。
最后浅谈下发展趋势，这是第一次讲，我不想给太多的未来定义，我觉得今天业务连续性管理可以交给在座的各位去定义（概念可以不断拓展）。我为什么讲开发是建造业务，是builder，我前面讲的逻辑是今天基础设施越来越完善，企业越来越关注业务开发，但谁来负责deliver业务？应该是运维，就像送外卖一样，克服各种困难、利用好工具，将做好的产品传递给最终客户。第二，我今天讲的是业务连续性管理，但更长远来看运维应该主导业务连续性的建设，只不过业务连续性管理是抓手。所以我觉得运维背后的逻辑一定在于更好的保障业务连续性，业务履约的事情应由运维来完成。