1-5-10 快恢在数字化安全生产平台 DPS 中的设计与落地

背景

11 月 5 日，在 2022 杭州 · 云栖大会上，数字化安全生产平台 DPS 重磅发布，助力传统运维向 SRE 转型，在数字化安全生产平台 DPS 重磅发布中提到了 DPS 诞生的背景，希望解决的企业问题以及核心的功能点，其中提到了 DPS 目前的两大业务场景:"1-5-10"故障快恢和"变更三板斧"故障预防，本文将阐述 “1-5-10”故障快恢场景的背后的设计与实现。

1-5-10 介绍

1-5-10 对应故障的“1 分钟发现-5 分钟响应-10 分钟恢复”，是定义故障处理的时效性目标。在阿里巴巴内部经过多年的实践，1-5-10 早已成为各个业务稳定性、基础设施稳定性以及大促保障的重要牵引指标，目的是缩短故障恢复时长(MTTR)，降低故障影响。DPS 通过将阿里云高可用产品体系与阿里巴巴安全生产理论体系相结合，实现了 1-5-10 的产品化落地。

下图是 1-5-10 的产品架构图：

1-5-10 场景包括事前稳定性分析，事中应急处理，事后持续运营三个步骤。

事前稳定性分析是 1-5-10 的前提，包括业务分析，风险分析以及组织分析三个维度。DPS 通过专家咨询服务加产品线，服务组，业务场景拓扑等产品功能相结合的方式来实现。
事中应急处理是 1-5-10 的核心，包括以下几个部分：
- 故障发现：通过建立围绕业务应用的全链路监控能力，能够实时监控业务健康度，如发现稳定性问题通报至应急保障服务组进行排查，降低故障发生的可能性。
- 故障响应：通过建立应急响应渠道和全链路故障定位能力，能够快速拉通故障排查人员，基于 AIOps 智能故障定位和基于 ChatOps 进行故障状态更新和通知流转，提升故障处理效率。
- 故障快恢：通过建立完善的故障快恢体系，基于方案内置丰富的快恢能力，能够根据不同的故障类型智能化推荐合适的快恢预案，缩短故障恢复时长。
事后的持续运营是 1-5-10 的效果度量，包括以下几个部分：
- 结果指标：用来衡量稳定性保障的结果，核心是业务可用率，重大故障收敛数目以及无重大故障时长。
- 能力指标：从提升稳定性能力的角度来分析，核心就是 1-5-10 的达标率，并且支持从故障，事件，组织，人员，团队等多维度来进行分析。

以上是 1-5-10 场景的整体产品能力介绍，下面展开介绍 1 分钟发现，5 分钟响应以及 10 分钟快恢是如何设计与落地。

1 分钟发现

要做到故障的一分钟发现，首先需要有完善的监控/告警体系，其次需要有明确的故障结构化定义。在实际应用中，会遇到如下的一些问题：

面临问题

业务监控的复杂性导致问题的淹没

一个生产业务监控，涵盖了各式各样的指标，从业务层面、应用层面、服务层面、系统层面,基础设施层面等等，比如下面：

网络传输监控(丢包,延迟)
服务器系统状态(CPU、load)
虚拟机，容器监控
应用运行状态(成功率、qps)
业务运行状态(订单创建量…)
用户体验(白屏、内容错误）

当故障发生的时候，可能上述任何一层的指标都会出现异常，如果不能对指标进行合理的分层和针对性的建设，就会被淹没在一堆指标告警监控里面，不但可能忽略真正的问题，还有可能使得运维人员难以应付。

监控数据和故障不能有效关联

什么是故障? 在日常运营中，无论什么原因导致服务中断、服务品质下降或用户服务体验下降的现象，称为故障。只有清楚定义业务故障，并且将故障监控进行关联才能做到真正故障的快速发现。然而在生产业务中，往往只聚焦于监控治理，而忽略了故障定义的重要性。

解决思路

监控指标分类

可以将指标能否直接反馈业务功能是否可用，将指标分为如下类别：

业务指标：业务指标可以直观的反馈业务或者系统功能是否正常可用，常用的指标有业务请求吞吐量、业务成功率、业务错误率、业务性能；另外对于金融类的业务来说，数据正确性也是要观测的指标，比如资金对账、数据一致性等。业务指标的监控方式优先采用日志监控，通过对业务日志的加工，识别出成功率、响应率、业务身份等等因素，因此需要业务日志有比较好的格式化，对于资损类的故障监控可以通过订阅 binlog、业务消息的方式来进行对账。
服务指标：服务指标是指能够反馈业务依赖的接口服务是否可用的指标，统计的指标类型类似于业务指标，只不过一个接口维度，同样可以分为吞吐率、成功率、错误率以及性能。比如对于一个数据库服务，对于一个查询服务来说，它的几个指标如下:

环境指标：环境指标又可以是资源指标，用来反馈底层基础设施或者依赖服务可用率，对于资源类的指标可以分为四个类型
- 使用率是资源繁忙的时间百分比，或正在使用的资源容量的百分比。
- 饱和度是资源无法服务（通常已排队）的请求工作量的度量。
- 错误表示资源产生的工作中可能无法观察到的内部错误。
- 可用性表示资源响应请求的时间百分比。此指标仅针对可以主动定期检查可用性的资源定义。
异常事件：监控指标相对是连续的，对于一些离散的，不频繁的异常可以通过事件(Event)监控来进行获取，并且相对于单一的监控指标，事件还提供了一些上下文的信息，事件举例：

以上要求 DPS 不但需要支持不同类型数据采集，还需要针对数据根据应用维度、业务维度分类处理。

故障结构化定义

发现体系建设的对象是故障，怎么去快速发现已经发生的故障以及潜在可能变成故障的风险，因此对于能够直接反映系统功能是否可用的指标要重点建设，所以监控指标的处理优先级就是：核心指标监控 → 非核心监控（业务，服务）→ 系统监控（环境指标）。

核心指标监控

核心指标监控就是能够直接反馈功能是否可用，核心指标的下跌或者其他异常一定会导致不同程度的故障，因此对于核心指标要通过故障场景的方式来定义应急平台上，所谓的故障场景包含了以下几个方面：

核心指标监控
故障等级定义
负责的产品线
负责的处理人员
可能的影响面
出现问题之后的预案

比如对于交易下单业务下跌这一应急场景来说，可以有如下例子：

这里重点是故障等级怎么来定义? 故障等级定义可以考虑影响点以及影响面联合来定义：

影响点：可以是用户体验，资金损失以及社会舆情。
影响面：变化服务，持续时间，投诉数量，资损金额等。
非核心监控：因为故障一旦发生，后面会有一连串的应急制度，所以对于故障要谨慎定义并且收敛，那么对于非核心监控的变化，我们可以采用风险预警的方式，风险预警就是对可能会导致故障的因素做出预警，同样也会涉及到产品线，处理人员，预案等信息，同时预警会有一个升级成故障的机制，比如预警多次或者影响面扩大。上面的核心监控和非核心监控都需要有横向的监控值班人员来进行统一关注，特别是故障发生之后需要有技术支持类的角色来进行组织和响应处理。
系统监控：因为系统监控异常的概率非常高，特别是大规模集群下，部分机器的 CPU，内存等资源发生变化是常有的事情，对于这些系统级别的告警，只需要配置普通的告警规则即可，由各个应用系统人员独自去处理即可；如果是大规模的机器故障，必然会导致核心或者非核心监控的告警，这些系统监控指标可以作为定位的数据来源。

以上要求 DPS 不但需要确立故障模型，以便故障的结构化定义，还需要基于监控数据的故障定级以及通告能力。

产品落地

DPS 在发现体系产品化上具备全链路监控、故障场景结构化，以及智能告警三个能力。

应用全链路监控

通过与阿里云可观测体系深度集成，DPS 实现了从用户体验端到基础设施端的全链路监控，包括业务日志监控、APM 监控、前端监控、基础设施监控等。

故障场景结构化

监控数据本身不具备业务含义，以单条 Trace 调用链路为例，能够知晓它经过了哪些应用和接口，但是无法了解代表的业务，很难做到业务维度的精准监控。

DPS 提供了全息业务链路治理功能，可通过请求参数、cookie 等上下文标记对调用链路进行染色形成业务链路，对染色后的链路按照业务维度进行聚合生成业务活动，构建从产品线->业务活动->业务链路->故障场景的治理体系。
DPS 支持按照业务受损程度，数据影响面以及舆情影响面来划分不同的故障等级，并且支持按照故障的持续时间和影响面来自动对故障进行升降级。

智能告警

当事件/故障产生以后，需要通过告警触达到处理人员。在一个重大业务故障的持续时间内，不光已有的告警事件会继续发送，由于爆炸半径的不断扩大也会产生新的告警事件，DPS 会对告警事件进行过滤，降噪聚合等操作，根据事件的时间，影响面，业务特征等归纳到相同的故障下，避免告警的持续通告。

5 分钟响应

要做到故障的 5 分钟响应，首先需要有一套标准的应急响应流程，其次需要能够快速定位问题，作出恢复决策。在实际应用中，会遇到如下的一些问题：

面临问题

应急协同缺乏标准流程驱动
- 故障发生后的应急操作，往往需要多个技术团队和技术工种协作完成，涉及到研发，运维，测试等不同角色，谁来组织应急，谁来处理，谁来做决策，需要有一定的应急机制，来确保相关人员能够快速响应和高效协作。
- 故障应急需要从故障源采集环境信息，关联不同的环境信息，分析故障原因，采取行动（展示、推送、处理、通知。但是当处理故障的规模放大，面对着多系统、多团队的软件组织，如何能够高效地完成信息的采集、传递和处理？
无法快速定位问题

导致故障产生的原因有很多，比如流量问题、网络问题、编码问题、依赖服务问题，基础设置问题，还有配置变更问题，牵一发而动全身，在复杂的系统架构和业务链路下，如何能够有效地查询到故障的上下文信息，快速定位问题？

解决思路

应急协同流程标准化

可以将故障处理流程中的人员角色分为三类：负责协调的技术支持人员，负责应急的处理人员以及负责决策的指挥人员。

技术支持人员

技术支持在应集中起到了非常关键的作用，对内，要有效组织直接处理人员的集中和协作；对外，负责对接业务部门同步信息，同时屏蔽各方对技术团队和故障处理人员的干扰。当出现一个严重故障后，技术支持通常要做如下关键事项：

确定故障影响面以及定级。当故障产生之后，需要根据故障定级标准，快速做出初步判断，确认影响面，以及故障等级。
组织应急。对于无法马上恢复或需要定位排查的故障，需要将相关技术团队主管和开发人员召集在一起，可以是线下会议室的形式，也可以是线上即时通讯拉群的方式，同时确认故障处理主要指挥者。
信息通报。组织应急之后，需要每隔一段时间，对故障进展做一次信息同步。同时，如果等级和故障信息变化，也要同步出来，直至故障排除，业务恢复。并且技术支持要确保处理故障人员能够相对地专注在故障处理上，而不是响应来自各方的询问。
处理人员

处理人员由一线研发负责，要遵循“先签到，再止血，后恢复”的原则，即在技术支持进行故障通告后，研发在处理前需要进行签到通告，以防止多人处理引发的冲突问题。在处理中要优先止血，防止故障影响面的扩大，这就需要能够快速判断故障的初因以及执行合理的预案。最后是故障的彻底恢复，包括根因定位以及影响面的消除。

决策指挥人员

指挥人员用于重大故障恢复时候的决策，当严重故障涉及到了多个业务影响面，无法由研发人员独立做出决策，就需要上升。

以上要求 DPS 不但需要将应急流程通过平台流程来驱动，并且需要为不同的角色人员提供特定的功能以帮助其更好地进行故障处理。

故障初因与根因定位

在进行故障定位需要从初因和根因两个方面来处理。初因即导致故障的直接因素，需要能够快速给出结论，以便于故障的快速止血，根因即导致故障的根本原因，在复杂的系统中要彻底定位问题往往耗费许久，因此根因定位一般用于故障的恢复以及复盘改进。

初因定位包括全局变更诊断，比如故障发生前的发布变更，配置变更或者是数据变更，像在阿里有 80%的故障是由于变更导致，因此需要能够快速的收集并且查询到指定时间的变更操作，对可疑变更进行回滚操作。此外也可从业务链路维度进行初因定位，查看当前故障业务的上下游业务是否异常，如果是因为上下游业务影响导致，则需要对上下游业务进行降级之类的处理。

根因定位包括代码 BUG 类定位，进程内资源不足，基础设施异常等方面。

产品落地

DPS 在响应体系上包含了故障单，ChatOps 以及智能定位三块能力。

故障单

当故障产生以后，便会自动生成故障单，故障单上规定了故障的处理流程，并且自动绑定当前故障的技术支持人员，应急处理人员，相关人员只需要通过 DPS 按照流程进行故障处理即可。

面向技术支持人员，DPS 提供了故障通告，等级变更，故障时间线，故障影响面管理等功能，帮助其更好地进行组织协调
面向应急处理人员，DPS 会自动根据故障场景定义推荐合适的快恢预案，为了保证执行安全预案不会自动执行，处理人员可根据推荐建议选择
面向指挥决策人员，DPS 提供了安全生产大盘，提供了全局的业务影响面视角以及故障处理视角，帮助其了解故障影响面和不同人员的处理状态

ChatOps

ChatOps 能够给故障处理流程带来更好的透明度，实现信息共享的同时提升应急效率和便捷性。像钉钉，企业微信都是作为 ChatOps 承载平台的好选择，基于这些平台的开放能力，DPS 打造了一个应急机器人，通过应急机器人可以直接在手机端进行故障处理，包括签到，进展更新，快恢执行等，获取和 PC 控制台一样的使用体验。

智能定位

DPS 在定位上能力包括：

基于故障场景拓扑的初因定位，借助于人工配置的故障场景拓扑关系来作出推断。举个例子，比如购物车和下单是两个上下游的业务，两个业务分处于不同团队，当购物车故障产生导致了下单业务故障，DPS 会自动向双方的故障应急群发送通告，告知故障原因以及影响面，并且在两个群同步故障进展。
基于全息业务链路的初因定位，一旦开启全息业务功能，则无需手动创建拓扑关系，DPS 会自动识别出业务链路上下游节点的异常，关联到故障单上。
基于阿里云可观测 Insight 技术的根因定位，通过 Insight 技术可精准定位到具体哪一台机器，哪一条调用链路的异常。

10 分钟快恢

1-5-10 场景的核心是快恢，发现体系和响应体系建设都是为了快速的恢复故障。要建设快恢体系首先需要建立起快恢能力，其次要针对故障特征合理使用快恢能力。

面临问题

故障恢复的手段有很多，比如应用重启，系统回滚，机器下线，重新发布，扩容限流等等，但是这些快恢能力分散在不同的系统里面，难以管控。
在云原生下各类平台框架爆发式增长，开发者可以很便捷地引入各类技术，但是存在概念和使用方式差异化的问题，比如限流能力多个框架都可提供，但是不同框架间的定义却不相同，增加了认知和配置成本。
由于缺乏快恢能力的标准化建设，导致快恢能力缺乏统一的度量标准，能力间难以组合和复用，新的快恢能力难以快速集成到平台。
快恢能力的使用不存在银弹一说，能力选择上要考虑实施成本以及时效性等多方面因素，同时一些严重故障可能需要多种快恢能力的组合，比如应用集群里面某台机器出现了异常，重启以及下线隔离都可解决问题，很明显隔离相比重启有更好的时效性。

解决思路

通过定义快恢的公共抽象模型以及每个能力分类的抽象模型，实现快恢能力标准化，来降低不同产品间的认知成本和配置成本。
快恢能力声明式设计，即对于使用方来说只需要知晓快恢的最终成功与否，而不需要关心中间过程，但是往往快恢系统本身是不提供这样面向终态的能力，而是命令式的原子能力，这就需要有个中间层来对这些能力进行封装。比如企业使用了阿里云 ECS，需要通过 API 来执行 ECS 重启，但是 ECS 的重启 API 是异步执行，即执行重启之后，返回成功并不代表重启成功，需要调用查询 API 来不断的轮询。这段重启后再轮询的逻辑实现由于不属于业务正常逻辑，而是为快恢做的封装，因此这段逻辑在承担快恢平台角色的 DPS 里是最合适的。类似这样的案例还有很多，因此平台需要支持快恢能力的扩展。
快恢能力推荐，即根据故障的特征以及快恢执行时效性来推荐适合的快恢能力，以阿里电商架构的业务故障为例，每一层的快恢手段都会有所差异，比如：
- 单元级故障，采用切流
- 机房级故障，采用隔离切流
- 接入层故障，采用切流
- 链路级故障，采用降级依赖
- 应用层故障，采用切流，重启，降低
- 数据层故障，采用主备切换

产品落地

DPS 在快恢体系建设上包括快恢能力标准化定义，云原生化的快恢产品接入以及快恢预案三块能力。

快恢能力标准化定义

通过对阿里快恢的数据分析，DPS 将快恢分为重启，回滚，扩容，切流，限流以及降级六板斧六个类别，并且已经完成重启和切流的快恢能力模型设计。拿切流举例，切流本质上是将流经某个地址的流量进行再分配的过程，因此 DPS 设计切流模型时分为流量地址，流量筛选以及流量路由三个部分，对于网关组件(ApiSix、Ingress...)等，流量地址即入口域名，流量筛选即根据 Http、Tcp 等方式对流量进行筛选，流量路由即不同地址的流量分配。数据库的主备切换也可以抽象成写流量的调度，主变成备的过程，即写流量从主 100%，备 0% 到主 0%，备 100% 的过程。

需要注意的是 DPS 定位故障快恢，在模型定义要简易清晰，因此只抽象出不同快恢产品的通用模型，不会去兼容快恢产品的所有配置规则。

云原生的接入方式

DPS 定义了快恢产品的 CRD 模型，在 CRD 里面针对不同快恢能力做了模型规范，开发者只需提供快恢产品的 CR，就可完成快恢系统的接入，流程如下图所示：

其中 CR 里面包含了快恢执行的镜像，镜像由开发者实现，镜像的创建，扩容以及版本管理都由 DPS 平台负责。容器镜像需暴露一下接口：

快恢执行接口，用于执行快恢能力
快恢连接测试接口，用于验证快恢系统可用性
快恢查询接口，用于异常情况下的结果查询
快恢参数提供接口，用于获取参数的可选项，方便使用者进行填写

快恢预案

快恢能力要通过快恢预案来执行，快恢预案定义了快恢能力的执行策略，主要包括以下内容：

触发策略，可与故障场景以及监控告警做关联，当命中触发条件，自动推荐快恢预案。
审批策略，对于高危的预案设置不同层级的审批策略，保证预案执行的安全性。
运行策略，可对多个不同类型快恢能力进行组合执行。
通知策略，可通过多种方式对预案的全生命周期进行通知推送，保证预案执行的透明。
可观测策略，借助于 DPS 的可观测能力，实现执行过程中受损业务的监控。

总结

数字化转型下如何保证业务连续性？1. 首先思想观念要转变，从被动运维向主动运维再到持续改。2. 协作方式的转变，必须要有业务思维，从业务场景出发，打破团队边界，让普通业务人员也参与到安全生产的运维保障中。3. 技术方式的转变，要不断提升自动化运维水平，通过打造一体化平台，为业务保障人员提供统一的工作界面和空间，统一能力标准，统一实现接口，实现能力复用和组合，并且加强数据化运营。

1-5-10 场景作为 DPS 推出的首个业务场景，在阿里安全生产最佳实践的基础上，结合外部企业客户诉求持续性的改进优化，以帮助企业更好建设故障应急响应机制，提升业务连续性。受限于篇幅，本文中还存在很多未展开的讨论细节，后续也会陆续更新。

作者：银桑

原文链接

本文为阿里云原创内容，未经允许不得转载。