阿里云解决方案架构师张平：云原生数字化安全生产的体系建设

1.jpeg

关于今天的分享主题——“安全生产”，内容主要分为三大部分：

• 第一部分是安全生产的背景，以及我们对于安全生产这个领域的理解；

• 第二部分主要介绍阿里巴巴集团的安全生产工作到底是怎么开展的，借此给各位有作为参考和借鉴；

• 第三部分是我们提炼的安全生产整体方案，帮助在座的各位去到我们自身的企业或者环境下，去落地安全生产。

数字化安全生产背景

谈到安全生产，首先我们要看一个行业大背景，其实刚刚我的同事已经讲到了，就是现在各行各业都在做自身业务的数字化转型升级。我们的业务开始做上云、线上化，应用架构开始做云原生改造。当我们每一个业务都跑到线上去之后，我们就会发现，原来传统的安全生产理念及管理模式，也需要转变成线上化、数字化。

随着线上化的系统越来越复杂，业务故障无法避免。故障的发生，对我们企业的影响是巨大的，怎么样提升故障的定位、处理能力及恢复能力，是现阶段安全生产工作中最重要的目标。 在业务数字化转型升级的过程中，我们每个企业都应该同时去思考，怎样同步完成数字化安全生产体系的建设。

从业务视角的安全生产挑战说起

2.png

关于安全生产，从以上几个近期发生的故障可以看到，不仅仅是我们普通的企业，就算是在安全生产领域重度投入的国内外大型互联网公司，也会出现业务故障。故障发生之后不仅仅是业务中断、经济损失，舆情影响也会带来非常大的挑战。我们怎么样来帮助大家把安全生产工作体系建设好？就是今天我们讨论的核心主题。

在阿里巴巴集团内部，经过十多年的探索，我们沉淀了一系列的产品和服务体系，以及安全生产建设的方法论。我们总结出了“高可用、稳定压倒一切”，作为我们面对业务侧安全生产挑战的指导思想。

什么是数字化安全生产

3.png

今天我们讲数字化安全生产，大家可能第一印象想到的安全生产还是比较传统的。比如一些工厂、车间、煤矿或者建筑工地上，我们经常会看到一些标语、海报和一些相关的理念。传统的安全生产，是指在生产经营活动中，为了避免造成人员伤害和财产损失的事故而采取相应的事故预防和控制措施。

我们今天讨论的这个数字化安全生产，其实是跟我们的业务数字化转型升级是相结合的，主要解决企业业务连续性管理问题。 如发生预期或无预期的事故或灾害时，企业以合理的成本和资源保护重要的业务活动，确保在规定的时间内恢复持续运行，最大程度地减少灾害带来的冲击并将中断影响降至最低。

数字化安全生产，有以下几方面的特殊要求：

• 数字化赋能的安全生产。 业务从线下转移到线上之后，完成业务全生命周期触点的数字化改造。这时，安全生产的重心也会从线下转移到线上，同时安全生产工作本身也需要数字化赋能。

• 云原生加持的安全生产。 数字化转型带来了架构的升级，所有的系统都在云上，都是利用先进的云原生、微服务架构设计的。我们的安全生产平台也需要同步升级，去无缝衔接适配云原生的产品能力，以及面向未来架构的扩展能力。

• 最佳实践的安全生产。 安全生产体系建设需要经过实践的检验。在阿里巴巴集团内部，我们有个一百多人的团队，在安全生产建设方面持续探索，沉淀了一套非常适合各行各业的最佳实践，并且还在持续演进。

数字化安全生产建设内容

4.png

基于以上探讨，为了做好安全生产工作，核心内容我们拆解成三个部分，就是事前、事中、事后建设。

• 事前： 我们要有相关的组织架构保障，要有事前的制度流程体系、系统架构的建设，需要具备相关系统的水位监测、故障监测能力，以及与 SLA 匹配的防护、切流、变更管控管理能力。

• 事中： 我们要做到敏捷快速协同，让故障快速发现、快速定位、快速恢复。比如在阿里内部，双十一或者说大的故障场景，我们通常需要协同上百人、甚至是上千人的团队。在这样的一个背景下，首先我们需要统一的机制保证步调一致，以及上一位同事提到的全链路监测（可观测）的能力，保障快速发现。另外还需要系统化的能力做事件处理过程的自动化协同，依赖系统的 trace 及拓扑能力实现快速定位，以及需要依赖系统的防护能力及单元化容灾多活，真正实现故障的快速恢复。

• 事后： 我们需要去反思，总结根因，定义 action。每一个故障应急完成后，我们都需要做复盘，定级定责，产出系统改进项，保证我们的整个架构持续迭代提升。对于管理者，我们需要去分析故障的原因是什么，处理过程的团队配合效率怎么样，分团队分产品的稳定性数据统计，然后保证我们整个安全生产管理的体系是可度量、可考核、可管理的。最后通过可视化的能力，指标化、全局化把控业务安全生产。

阿里巴巴集团最佳实践

阿里巴巴集团全球运行指挥中心

5.png

首先在组织保障层，我们有一个组织叫全球运行指挥中心，也就是 GOC。在集团内部，有六十多个业务 BU 把所有安全生产相关的业务，接入 GOC 统一协同处理。

然后是我们刚刚说到的监测（可观测），这是非常重要的一个环节。我们会把所有的可观测，以及人工反馈（比如淘宝客服、阿里云客服收集的反馈），汇聚到统一的事件中心，利用系统化平台做管理。

最后所有的故障应急都汇聚到两岸三地的指挥中心，相应的应急值班同学，利用应急协同、故障定位、快恢工具进行故障应急与快恢处置，并且进行事后复盘与改进，通过机制运营等多种策略管控整个集团的安全生产风险事件。

安全生产体系大图

6.png

安全生产是一个完整的体系，借助这个架构图给大家做一个大致的介绍，集团的安全生产体系比较大，我们把整体工作拆分成一个个小的模块。

首先有平台的技术能力支撑。 通过前面的介绍，我们了解了安全生产工作涉及很多不同角色的人，来自不同业务系统的可观测数据，安全生产管理需要压测、故障应急协同、演练、定位、切流、复盘等能力，我们集团内部有相应的一个平台做有效的支撑。

在这个平台上，建设各个领域的系统，包括故障管理、多活、全链路压测、变更管控等这些能力都是在这个大的平台上面做统一的支撑，安全生产平台的建设， 本身也是安全生产工作的数字化转型。

在平台的上层，是相关的管理体系、数据运营、技术文化建设。 早期我们在做安全生产工作的时候，最大的体感就是无法度量，出了故障之后无法定位是哪里出了问题、谁的问题，经过故障等级定义、故障分、稳定性分等机制体系及运营活动的建设，可以实现安全生产工作的可度量可考核。

然后平台和体系建设需要配合相关的演练来做标准化的验收， 保证这些体系和产品能力能够有效的落地并发挥作用。

安全生产核心要素

7.png

人员 &组织

安全生产的核心主要有三部分，第一部分就是人员组织的架构建设，我们认为安全生产是企业的一把手工程，需要建立一个自上而下的统一组织，能够把所有安全生产能力协同起来。

在集团内部，我们是有这样一个垂直的组织架构，指挥中心是和每个业务 BU 平级的一个部门，然后下面有相应的支持各个业务 BU 的专业角色，横向的话有安全生产的值班长、仲裁委员会等这样的一些组织角色，保证我们的体系能够有效落地。

制度 &流程

第二部分主要是机制流程，集团经过十多年的建设，积累了非常多的制度流程。

• 全集团的统一的故障等级定义： 为应急过程的资源调度、决策提供了量化的标准；

• 标准化的应急流程： 让事件处理快捷、有序；故障分、稳定性分的考核标准，统一衡量安全生产的成果；

• 故障定级、定责、争议协商机制： 保证了安全生产工作的长效机制。

工具平台

最后一部分就是工具。集团的制度和流程不是仅仅停留在纸面，或者挂在墙上的。我们所有的机制流程都是有相应的系统平台做运行支撑，然后基于我们的系统能力、机器人、NLP 技术等，做到有效的落地，把所有的这些机制落到实际的每一天的工作，每一个执行环节当中。

故障等级定义

8.png

故障等级定义是安全生产体系的运行基础。我们把生产环境中，无论什么原因造成的服务中断或者服务品质下降及体验下降统一定义为故障。大家注意这是基于业务视角去定义的故障，它的好处就是能够先于用户发现，相比传统的监测准确度更高。

然后再往下层的话，我们会有很多支撑平台，如中间件、数据库、云平台、网络、服务器等等，下层的指标及故障定义，我们会根据各个业务的特点来针对性的做定义。但是总体原则还是以业务影响为主，从上往下，只是下层系统的业务，通常就变成了上层系统的业务依赖。

基于故障等级定义的基础，实际落地的时候，在集团内部有非常多细分种类。这里简单列举几个常用类别：P 序列表示通用等级定义、D 序列代表数据质量等级、S 序列代表影响重要客户程度、E 序列代表舆情等级、 I 序列基础设施相关等级。

每一个序列我们通常有 4 个级别，4 代表普通故障，1 代表严重故障，数字越小紧急程度越高、重要性越高。

在实际落地过程中，首先我们要把所有的业务纳入管理范围，对全量业务做故障等级定义。故障等级定义需要协同各个角色，包括开发、测试、产品、运维、业务依赖方等一起来做等级定义评审，保证提前达成一致。故障等级定义正式发布之后，大家就会按照这个等级去做投入和配套后端资源，一旦发生故障，就可以根据等级发起不同的应急流程，协调对等的资源参与应急。

每个业务场景故障等级的确定，主要参考业务重要性、影响面、持续时长来做综合的判断。确定好的故障等级定义要确保是结构化可度量的，要跟全链路可观测做统一的协同，实现故障自动发现。

一旦发生故障之后，我们会根据可观测指标，定义规则，自动试算故障等级，达到故障标准后通过机器人的方式自动发送故障通告，同时结合全链路可观测的拓扑能力、trace 能力提供初步定位辅助。

1-5-10 机制

9.png

有了故障等级定义我们就可以精准识别业务的故障风险，及时发现并处置。那么，如何度量故障处置的效率？这就涉及到数字化安全生产中一个最核心的一个机制，故障 1-5-10 机制。

在集团内部，所有的故障发生之后，我们定了一个考核目标，要求业务故障 1 分钟发现并通告，相关人员 5 分钟内做出响应和初步定位，10 分钟完成故障快速恢复。然后基于这样的一个核心指导机制，我们再去向下做二级拆分，建设整个安全生产体系。

1-5-10 策略分解

10.png

1-5-10 主要关注“发现、定位、快恢”三大环节，再细分开来就会涉及架构、开发、运维的多环节。 每个环节都有自身的业务规则、相关的机制，以及有相应需要我们建设的系统。

比如“1”部分主要是涉及全链路可观测，也包括我们平时比较关注的像智能基线、全链路监测，这些都是我们在这个环节需要去做的。

然后第二部分的话，关于 5 分钟响应和定位，通常情况下我们都是基于移动化的方式做通告，包括短信、电话、钉钉。然后还有协同的工具，我们会基于钉钉机器人去做协同，利用 NLP 机器人技术做签到、应急过程交互，实现 ChatOps。

关于定位的话，我们需要有可观测系统、预案系统、变更管控这样一些能力。通常情况下在平台内发生一个故障的话，我们首先会收到一个故障通告，然后的话我们会收到故障前相关的一些变更信息，系统会推送这个场景相关的预案，应急人员会基于可观测能力实现辅助定位。

关于 10 分钟快恢部分，我们最大的一个大招，就是单元化的切流，只有系统判定出故障的影响面及预估恢复时长不可接受，我们可以基于单元化多活能力，做分单元切流，先恢复后判断。另外小规模故障也可以基于预案系统做局部的快恢。

最后的话就是我们相关的运营机制建设与演练验收，运营机制也是安全上非常重要的一部分，它可以保证相关安全生产的能力能够持续的迭代。演练可以实时利用线上环境模拟故障注入，检验系统及流程。

可考核的度量标准

11.png

安全生产工作有一个很大的痛点就是无法度量，通常我们不知道哪个产品稳定性好，哪个团队做得好，更不知道未来的改进方向。基于以上的产品技术体系建设，我们设计了很多运营标准。

• 故障分： 每一个故障发生之后，系统会自动评判一个分值，基本的计算逻辑就是影响面、持续时长、设定权重。它是一个结果指标，用来衡量产品和应急效率，通过持续的运营，我们可以制定团队的故障分 quota 值，进而来设定安全生产相关的未来目标。

• 稳定性分： 由工程设计、架构、运维等领域的 14 个指标构成。我们会去抓每一个业务开发团队，设计环节的 cover review，运行环节的可观测覆盖率，发布过程中的灰度的能力以及事后的 action 完成率等指标，通过系统化的方式生成评判指标。稳定性分是过程指标，考核安全生产相关的投入情况。

故障分和稳定性分基本上是最核心的两大指标， 是用来评判一个团队在安全生产领域做得是不是合格的重要标准。此外还有很多业务可用性、熔断、变更管控等等一系列机制，这些机制都会跑到各自相关的系统平台里面，实现自动化管理。

应急流程

12.png

对于应急流程，我们会把所有的事件都归集到 GOC。事件接入主要有两种类型，一个是用户侧反馈，这块是人工的部分，基于智能客服对接；另一部分是可观测告警，我们对接了集团业务 BU 数十个监测系统。大量的告警数据进来之后，就涉及到收敛、抑制和智能算法处理，再结合后台的机器人处理过滤，最后会融合到统一的平台做故障等级判定，事件或故障会走钉群做协同，普通非紧急事件走工单，系统之间会有相应的协同，处理过程通过知识库做有效的沉淀，全流程数据通过大屏做统一可视化展示。

处理过程全部在钉群里完成，故障通过之后，相关人员需要群里签到，应急过程都会通过群里面来做统一呈现。一旦有重大故障的话，我们会升级到我们的高管群，协同更多的人。

机制运营

13.png

除了刚刚讲到的产品能力和相关的组织架构以外，机制运营也是安全生产工作非常重要的组成部分。我们会有非常丰富的运营活动，各种各样的评奖，表现优秀的团队的经验能够得到分享，做得不好的团队可以去总结改进，以此来保证安全生产的长效机制。

数字化安全生产体系建设方案

数字化安全大图

14.png

企业要做安全生产建设的话，核心分为两大部分 ：一部分是技术体系建设，一部分是服务体系建设。

技术体系部分，我们需要形成统一的平台。刚刚其实有个同学已经提到了，说现在企业里面监测系统非常多，各个业务都有。然后从应用层、中间层、数据库、云平台、网络都有各自的系统。如果说我们按照这样一个分散的方式去建的话，其实很难形成统一的应急指挥中心的效果。我们建议是建一个统一平台，然后这个平台具备安全生产的各种可操作的能力，把各系统的业务能力整合起来，形成统一的指挥中心。

在服务这块的话，我们要保证机制文化、组织架构能够有效支持安全生产工作的落地。

数字化安全生产平台

15.png

关于数字化安全生产平台，我们设计了一个框架，通过各个领域的组装，整合现有能力，比如说可观测能力、预案、工单、事件管理，把它抽象成一个整体的平台，人员及事件全生命周期统一管理。然后通过平台我们形成相应的业务领域，支撑我们各种各样不同的业务场景，服务于上层各种各样的业务，这个是统一的安全生产平台建设的整体架构思路。

数字化安全生产体系建设-全生命周期服务设计

16.png

事前

企业需要在做远期规划的时候，把安全生产相关的产品架构、业务架构设计清晰，需要有相应的业务管理的思考。

事中

运行过程中，我们要考虑系统能力建设，比如说演练、压测、限流、多活等等，保证我们能够有效地评估和防范风险。

这里介绍一个案例，就是这段时间大家比较熟悉的一个业务应用，疫情防控系统，如健康码、场所码、核酸检测。前期我们会去给整个系统做压测，评估线上的容量水位。

评估的结果是线上生产系统的容量上线是 1 万 QPS，我们即按这个流量准备系统资源，这个时候如果说峰值流量超过 1 万 QPS，那我们会通过配置流量防护的能力，保证系统在极端情况下也不至于说整个崩掉。

然后再往上一层，如果系统对于 SLA 要求更高，那我们还需要建设系统的双活能力，这是安全生产的一个大招。我们要保证这个业务系统在极端情况下，整体崩掉的时候，我们有相应的双活的站点可以接管业务。所有这些能力，都需要在统一的平台里面来做相应的统一调度管理。

事后

最后一部分是事后相关的改进。这部分内容其实涉及面也非常广，比如说我们的应急协同能力的改进，产品架构的改进，整个管理机制的改进。改进是否按时完成，落地效果是否理想也是一个非常重要的闭环。我们需要有平台做相应的支撑。

数字化安全生产-全息可观测平台

17.png

关于平台能力建设，我们把每一个重要环节拆开来看。首先是可观测，这部分的话其实就是刚刚我们讲的 acos 的全链路监测，再补充一点就是我们的可观测不一定要依赖于某一个平台，而是要把业务现场所有监测能力做有效整合。acos 实现兼容专有云 arms 应用监测，并且增强了业务、日志、异构监测系统的接入能力，通过可视化能力的提升，实现快速定位。

数字化安全生产-全链路压测

18.png

第二部分是全链路压测。我们在做安全生产的过程中，最核心的内容之一是要先了解我们的平台到底是怎样的一个处理能力，我们要摸清楚系统的水位，极限的承载能力。这样的话，真实业务的峰值流量到来时，我们才能做到心中有数，轻松应对。

全链路压测在集团内的各种大促活动中都属于至关重要的环节，每次全链路压测都是在生产系统进行的，这样可以保证所有压测出来的数据是真实的，相应的短板和系统问题，跟线上的问题是一模一样的，准确找到短板，提升业务系统整体的压力水位。

数字化安全生产-“1-5-10”应急协调

19.png

这里主要介绍 1-5-10 应急协同，安全生产体系在实际的建设过程中，首先我们需要把人工反馈的这个事件和告警统一的接入，然后从业务角度进行故障等级定义，保证故障的 1 分钟快速发现，准确及时的通告。

在应急过程中，我们会有相应的横向支撑能力，包括资源的拉通，跨团队、跨厂商的人员协同，devops 能力， Chatops 能力的植入，保证系统能够自动找到接口人，并且辅助完成快速定位。

在建设初期，主要依赖于我们自己的现有能力做有效整合。当然成熟的方案我们都有，但不一定是说我们起步要完全改版、重新开始，通常企业更需要基于我们现有的现状来做。然后快恢部分包括相关的预案、容灾双活等相关的规则能力。1-5-10 是安全生产建设中，最容易落地和最快速能够看到效果的部分。

数字化安全生产-流量防护

20.png

关于流量防护的能力，刚刚已经大概提到了一部分。

在现实环境中，为了应对突发流量峰值，我们需要准备额外的资源。这个其实是一个成本和效率的一个折中方案。有些业务可能我们在建的时候就会评估一个业务的峰值，基于这个峰值，我们可能不会无限量的来准备计算资源、存储资源，但是业务峰值来了之后，我们又不可能让我们的系统停止服务。

所以我们就需要系统的限流能力，保证极端情况下业务可用，并且给运维操作预留扩容时间。通常情况下，我们再配合刚刚介绍的全链路压测，可以通过流量防护能力，配合我们云原生容器化相关的弹性能力，来保证相关的流量洪峰能够平稳过渡，最大限度地支撑整体业务的稳定性。

数字化安全生产-容灾多活解决方案

21.png

容灾多活是安全生产的一个终极大招，当出现大面积故障的时候，如果我们依赖独立的定位和恢复能力，可能无法满足重要系统的 SLA，这个时候我们就需要建设业务级的容灾多活。

在我们高阶的容灾方案中，整体架构都是单元化的，也就是业务级异地多活的方案。但是很多企业通常主导方案还是灾备，通过做数据库同步，存储复制，每个应用自己管自己的那一部分，来获得相关的容灾能力。

容灾多活系统中有一个总的管控平台，把流量接入层，中间件以及数据库，做协同管理。可以理解为我们是一个大的流量调度系统，然后保证在业务发生故障之后，它可以自动地去做单个应用的流量调度，单个应用的相关业务切流可以自助化执行，切换过程平台自动化完成，不需要应用做手工调整。

多活建设在资源利用率、切换成功率、自动化程度方面都有明显的优势，也是个企业安全生产建设的终极目标。