阿里巴巴稳定性指标1-5-10调研

指标定义：1 分钟发现、5 分钟处置、10 分钟恢复

关于 1-5-10 的定义，是阿里巴巴合伙人、双 11 新零售技术负责人范禹在 2020 年 11 月的宣传片中提到的

时长计算：1-5-10

关于时长，度量的方式有两种

• 一种是分段统计，1-5-10 的总时长就是 16min

• 一种是累计统计，1-5-10 的总时长就是 10min（该统计方式下，还有一种口径，1-10，共计 11 分钟，发现1分钟，恢复10分钟）

从能力建设角度，我个人倾向于分段计算，通过 1-5-10 将每段的时长进行清晰描述，谁负责哪块，目标是什么，一目了然。至于具体值，可以根据实际情况自行定义。而累计计算的方式，1-5-10 实际上是 1-4-5、或者1-5-5，在效果上，没有分段统计更加的直观明了，因此从口径上，我认为分段计算更加合理。

关于故障发现的时间点，也有两种口径

• 第一种，业务指标开始异常就视为故障发生的时间点

• 第二种，业务指标开始异常并持续 N 分钟达到定级标准的时间点，视为故障发生的时间点，也就是将指标异常后N分钟的时间作为故障发生的时间

我个人倾向于第一种，业务指标开始异常就视为故障发生的时间点，因为故障确实在那一刻发生了。所谓的持续 N 分钟是一种识别方法，因为不确定这个指标异常是瞬时的还是持续恶化的，所以需要持续 N 分钟的方式来判断。但识别方法本身不应该影响故障真实发生的时间点。持续 N 分钟毕竟只是一种判别手段，其判断的准确性、实效性会受制于当下的能力，但能力是可以持续建设和优化的。

举例来说，如果我具有『未卜先知』的能力，知道这次指标异常会持续100分钟，那么在指标异常的那一刻开始，我是否需要立即采取手段，还是说依然需要等待N分钟后再进行处置呢？答案是显而易见的，既然我都知道了这次是故障而非抖动，死等N分钟，除去增加故障时长外，没其他价值。

时长度量：1-5-10

各时长阶段定义

发现时长：统计从业务指标开始异常的时间点，到业务发现该故障的时间点

• 以监控报警的故障为例，报警接收人查看报警或者接听报警电话视为发现故障。业务是否查看报警，不同公司的判断方式会有不同，笔者在公司推动报警消息增加消息回执功能，用户只要在 IM 工具上查看报警消息，IM 会自动上报该消息被查看的时间点。

处置时长：统计从业务发现该故障的时间点，到业务开始执行止损操作的时间点

• 以变更导致的故障为例，业务最后的决策是执行回滚操作，那么需要看他是什么时间点点击的回滚按钮

恢复时长：统计从业务开始执行止损操作的时间，到业务指标恢复正常的时间点

• 如果止损完成，业务指标立即恢复，那么恢复时长是止损开始时间到止损完成时间

• 如果止损完成，业务指标没有恢复，那么恢复时长是止损开始时间到故障恢复时间

指标分歧

定位还是处置？

阿里在 2020 年之前的宣传文档中，曾经使用过 1 分钟发现，5 分钟定位，10 分钟恢复的说法，在 2020 年范禹的版本中，将定位改成了处置。我个人认为是：发现-处置-恢复而非发现-定位-恢复，原因有如下几点

• 发现-定位-止损中的定位，也叫做根因初判。从历次 GOC 团队的公开资料看，定位主要是辅助定位，推荐可疑事件和历史故障，他的目标并非是根因定位，既然如此，叫定位还是会有一些歧义，下图是阿里在两次外部会议上两个同学讲述的内容，在定位环节，话术都使用了故障辅助定位。从时间线来看，这些公开资料主要集中在 2018 年，那时 1-5-10 的概念可能还在孵化中，因此还没有严格匹配。

• 止损优先原则，日常的故障处理，我们都推荐先止损，后定位。因此，如果 1-5-10 的解释是发现-定位-恢复，可能会对大家产生误导，认为必须要把根本原因找出来，才能止损，这样也不利于故障的快速恢复。

• 处置包含根因初判以及处理决策环节，如果将该环节直接定义为定位，那么处理决策等环节就不好放置了。毕竟，即使定位出了根本原因，也依然需要有处理决策环节（人工或者智能化），才会开启止损操作。举例来说，一个系统进行了大版本的发布，涉及了较多的模块和功能点，其中有小部分功能上线后出现了问题（不一定是不能用了，可能效果上不符合预期，或者其他原因），平台即使能快速定位出是发布的原因导致，也需要团队成员进行决策，到底是回滚该版本，还是快速进行 bugfix。这个环节绝不是用定位能够准确描述的，因此用处置更为恰当

止损还是恢复？

这个地方的分歧小于前者，我认为应该是恢复而非止损。当然了，阿里历次的版本中也一直都叫做恢复。

止损和恢复的区别，止损后，业务的核心指标可能直接恢复，也可能只是不再恶化而已。而恢复则是指业务 SLA 指标恢复正常，因此叫恢复更为合适，也是强调紧急故障处置的终点是恢复而非止损。

99.99%和 1-5-10 的关系

SLA = MTTR（平均故障恢复时长，目标：1-5-10） *  统计周期/MTBF（平均无故障时长，目标：减少故障次数）

SLA 等于 99.99%是一个结果指标，是指全年系统实际的可用时长达到 99.99%，而 MTTR 则是指平均故障恢复时长，因此设定 1-5-10 的目标来进行建设，让每一次故障的处置都满足标准和要求。MTBF 则是指平均无故障时长/故障间隔，主要是通过降低故障数量来进行建设。

因此，单一看 1-5-10，是很难直接和 SLA 挂钩。因为会有一个统计周期的问题，

阿里建设思路分析

召回率：通过对业务SLA指标的异常检测发现所有问题

阿里 GOC 团队的逻辑比较直接，业务故障的定级标准是业务指标出现了异常，例如订单量、GMV 等，因此，GOC 就针对业务指标进行监控能力的建设并安排人员进行 7x24 的盯盘。

告警时长：通过秒级监控将告警时间降低到 1 分钟内

1s/5s/10s/20s/30s 都可以视为秒级监控，SLA指标采用1s的采集频率，核心指标采用10-30s的采集频率，通用指标采用60s的采集频率

接手时长：通过智能定级提升响应速度

备注：阿里的故障自动化通报，都是直接电话通知的，如果不接电话，直接进行组织架构升级，从而确保及时响应。

通过自动化故障通过，大幅降低通告延时，让大家在第一时间能够重视起来，协调资源处理问题

初判时长：通过智能分析推荐故障可能的原因

关键还是看有没有最基本的全链路分析能力，可以想象一个场景，发生故障时监控系统报了一千条报警，同期还有上百个变更事件，你是否需要全链路的拓扑或者 trace 来帮你确定问题发生在哪个环节？

决策时长：通过决策推荐提升决策效率

决策推荐主要解决因为决策错误而导致的故障时长增加以及秋后算账的问题。所谓的秋收算账，是因为止损决策缺乏标准，强依赖实际处理人的经验，如果止损决策错误，那么执行人会承担很大的责任，因此该环节大家被迫各种确认和请示，都是为了事后免责，避免被秋收算账。

这块没有找到阿里分层决策推荐的具体资料，下图仅供参考

应急处置平台：流程合规性保障

阿里巴巴安全生产委员会的成立

在 2018 年成立了安全生产委员会之后，1-5-10 的效果逐步提升。由此可以想到，稳定性建设，还是需要顶层设计才能有效的开展起来。