直击阿里全球运行指挥中心双11的隐形战场

2016 年，Gartner 定义了一个新名词——AIOps，就是用基于算法来提升运维效率，其实在国内不少互联网公司早就已践行智能化运维了，并且在各个运维的场景都有了不同程度的应用。双 11 的到来，也将继续给各大相关互联网公司的运维团队带来流量和高并发的考验。

2017 年 12 月 8-11 日，由 InfoQ 举办的 ArchSummit 全球架构师峰会将于北京举行，大会与阿里巴巴合作策划了双 11 架构专场，并邀请了顶级技术专家担任出品人设置了“新一代 DevOps”、“人工智能与业务应用”、“架构升级与优化”等 17 个热门话题。

在新一代 DevOps 话题下，我们邀请了阿里巴巴高级技术专家 王肇刚 老师前来分享《故障治理领域的智能运维实践》，并借此机会采访了王肇刚老师，解读全球运行指挥中心背后的运转与实践，希望可以给大家带来启发。

如果读者想了解更多阿里电商技术、运维技术，欢迎报名参加 ArchSummit 北京站并与王肇刚老师进一步交流。

受访嘉宾介绍

王肇刚，阿里巴巴高级技术专家

阿里巴巴集团基础设施事业群 - 全球运行指挥中心 (GOC) 高级技术专家。负责阿里巴巴集团业务指标监控、业务故障管理工作。在时间序列异常检测、业务故障定位及影响面分析、运维数据仓库和其它相关的智能运维相关领域有丰富的技术经验积累和成果产出。

其中，业务指标异常检测算法，成功地将阿里巴巴集团核心业务指标监控的正确率从 40% 提升到 80%，极大地提升了集团业务故障发现的效率和自动化水平。

2017 年 5 月，受邀代表阿里巴巴集团参加国际运维领域顶级会议 SREcon17，并发表主题演讲，向国际同行介绍阿里巴巴集团在业务指标异常检测算法方面的实践和成果。

识别下方二维码，提前了解《阿里巴巴故障治理领域的智能运维实践》

全球运行指挥中心

全球运行指挥中心 (Global Operations Center，下文简称 GOC) 是阿里巴巴集团基础架构事业群下属的事业部，是阿里经济体业务稳定运行的核心团队，负责生产系统全局性应急决策与指挥。GOC 团队通过为电商、金融、云计算等各项业务提供及时准确的告警、生产环境故障的全生命周期管理、重大故障时的快速切换以及线上问题的升级支持，在缩短系统灾难时长和提升消费者体验等方面做出了贡献。

之所以称之为 全球运行指挥中心，是因为阿里经济体的业务中有很多国际化的业务（如 AliExpress 速卖通、国际支付、Lazada 等），业务的用户和受众遍布全球。

一直以来，GOC 从预防、快速恢复到复盘检验等环节全面推进业务连续性建设。

• 首先，GOC 持续推动系统的容灾和快速恢复的建设，确保各个机房都有同城或者异地容灾的方案，并通过日常演练来检验集群的容灾能力。

• 同时，经由与各个业务部门的密切合作，GOC 把各核心系统在极端情况下快速逃生的开关接入统一的平台，真正实现了快速恢复。

• 其次，在业务流量发生波动时，通过自建的嵌入机器学习模型的智能基线系统，GOC 能第一时间发现故障并判断处理方式。

如果该故障需要人工介入，则会迅速通知相关开发人员上线处理，并实时跟踪进展。在故障处理完毕后，GOC 会与业务团队一起进行深度复盘，制定明确的改进措施，并通过模拟故障来检验系统是否已经具备了对类似的问题的免疫能力。

经过长期的技术积累，今天的 GOC 已经拥有了从覆盖从故障管理、应急响应、容灾演练、变更管理等平台化产品，打造出了一整套业界领先的业务连续性建设解决方案。

挑战与背后团队

除了由于时差等造成的因素、全球化业务之间形态的差异、业务指标变化趋势的差异、以及各数据中心之间物理距离的加大，对我们准确地发现、判断、通告故障以及收集相关信息等工作带来了巨大的挑战。面对这种挑战，我们主要是通过智能化的手段，利用算法和数据提升故障发现和故障辅助定位等能力，提升服务的效率和准确率，以平台化的产品来支持我们提供的服务。

另一方面，我们也在美国的加州设立了子团队，实时响应和支持全球业务的监控发现和故障应急支持工作。

阿里集团一直倡导 DevOps 的理念，传统意义上的应用运维团队已经融入了各事业部的研发团队中，同时有专门的运维中台团队来负责研发通用的监控、部署等运维平台。

目前，阿里集团的各个运维团队也已经在向智能化的无人值守运维方向演进。GOC 团队作为横向团队，整体负责所有团队的业务指标异常发现，故障级别确定和故障通告。对于符合快速切换条件的故障，由 GOC 团队通过平台化产品进行服务快速切换来恢复服务。

对于其它类型的故障，由 GOC 通过平台化产品来进行故障恢复过程中的信息流转和应急指挥。故障定位和恢复之后，由 GOC 团队通过工具和平台协同故障相关的同学进行故障的复盘。

故障在 GOC

GOC 负责管理全集团所有生产环境的故障。故障一词，在阿里集团内部有着明确的定义和分级，根据不同事业部的业务范围和特征，我们有上千条明确的故障等级定义。这些等级定义精确地界定了故障的现象、波及范围和相应的故障级别。

例如，淘宝交易量下跌 %X 且 Y 分钟未恢复，会被定级为 Pn 故障（n=1~4）。P1 故障最为严重，而 P4 故障相对较为轻微。我们会根据故障的等级来决定我们的处理顺序和优先级。这些故障等级定义可以和我们的业务监控项（通过实时数据采集、流式计算得出的代表业务指标的时间序列数据）建立关联，方便后续的故障自动化和智能化的处理过程。

故障的处理包括几个环节：故障发现，故障定级，故障快恢，故障定位，故障复盘。

• 在 故障发现 环节，接近 一半 的故障可以被我们的智能化异常检查算法自动化地发现（其它不能自动化发现的故障主要是业务故障的现象不能直接反应在某个时间序列数据上，比如淘宝首页乱码之类）。

• 在 故障定级 环节，所有可以表征为时间序列的故障等级定义对应的故障都可以自动化地进行定级。

• 在 故障快恢 环节，目前符合快速恢切换条件的故障场景主要集中在阿里集团核心的交易链路相关的故障上。

• 在 故障定位 环节，我们能够自动化地推荐可能与故障原因相关的系统 / 应用层面的各类事件（如可疑变更、系统 / 应用的指标突变、网络抖动等）以辅助相关人员进行故障定位。

• 故障复盘 环节仍然是一个需要相关负责同学人工参与的环节，我们可以通过平台和工具自动化地收集故障发生过程中的相关信息，方便相关人员进行故障复盘。

正确率从 40% 提升到 80% 的背后

首先需要明确的是，我们对于业务指标监控的正确率的评测是在开放数据集上持续进行的，其判别标准主要基于上面提到的故障等级定义（但不是完全和故障等级定义相同，因为我们往往要在故障还没有严重到构成故障时就要检测出异常）。这和我们去判断一个集群的 CPU、IO 或一个微服务的 QPS 这样的指标是否异常，其尺度和标准是不同的。

由于业务指标时间序列数据本身具有周期性、趋势性规律，同时会受到内部系统层面和外部用户层面的多重影响进而存在很多噪声，因此基于静态阈值（或分段阈值）或同、环比的监控策略的正确率仅有 40% 左右。经过项目团队的努力，我们通过引用异常检测算法，把监控的正确率从 40% 提升到了 80% 左右。这相关于我们利用智能化的力量，每周为团队节省了 29 小时（因误报警而造成的）操作时间。

在这个过程中，我们主要在算法、工程框架和运营三个层面进行了优化和提升。

一、在算法层面，我们的主要优化集中在三个方面：

• 通过数据预处理以降低输入数据中的噪声；

• 通过时序分解来进行正常值的预测；

• 通过复合的异常判别方法和自适应的参数学习来提升报警的有效性。

二、在工程框架层面，我们支持对不同类型的曲线（甚至同一个曲线的不同时间片段）可以存储和更新不同的算法参数。

三、在运营层面，我们通过对于标注数据的分析，发现制约算法效果的若干因素，并制定针对性的策略来解决。

关于未来的 20% 如何攻克的问题：一方面我们会持续针对算法仍然存在的长尾的误报情况研发针对性的算法策略，另一方面我们也在通过与高校进行合作，探索利用深度学习等算法来解决业务指标异常检测问题的方案。目前，相关工作正在进展之中，让我们拭目以待。

随着算法优化工作的推进，特别是利用人的反馈（标准）来进行自动化反馈算法的研发过程中，我们也发现人对于什么是异常的标准也并非完全清晰。因此，我们也会加强对人工标注质量的定量统计和评估，厘清判断标准中模糊的部分，让算法专注于解决应该由算法解决的问题。

算法如何对比、选型，以及应用？

在算法应用的业务场景确定的情况下，决定同类算法选型中最重要的因素或许是算法输入数据的特性和质量。

在异常序列的预测（拟合）这个环节，我们调研了时序序列分析算法中的 ARIMA，Holt-Winters 以及 STL 方法。最后，由于我们的输入数据本身间距周期性和趋势性，根据实验的结果我们选择了 Holt-Winters 算法和 STL 算法。又由于我们输入数据中有较多的噪声，而 STL 算法的鲁棒性更好，因此我们根据实验结果又选择了以 STL 算法为主作为我们的时序分解算法。

当然，对于不同的业务数据，这个选择也不相同。我们的业务数据有上千条，因此我们也设计了一套基于分类的算法，来自动选择具体的分解算法及算法分解之后具体的参数。

我们在算法中采用的自适应的异常判定的技术主要是指我们能够通过对于数据本身特征的分析，以及人对算法结果的标注这两个因素共同动态地决定异常检测的参数。这其中的难点一方面在算法需要根据不同数据的不同特征，以及相同数据不同时间段的特征来大致确定初始的算法参数。一方面在于需要根据人对算法输出的评价来动态调整并最终稳定收敛出一组确定的反馈参数，并将初始参数和反馈参数组合起来，共同决定算法最后的输出。

最终算法策略实现层面的难度并不大，更多工作的是我们在理论上分析出这两类因素的作用，然后在工程框架上予以支持。然后就是不断地利用开放地实际业务的曲线进行验证和迭代，对算法的策略进行微调，最终让算法的效果达到预期的水平。

大   促

从故障本身对应的时间序列指标的角度看，平时工作时、平时节假日、法定节假日、大促日（双 11，双 12 等）这四类日期的时间序列的趋势特征都各不相同。因此，在实践上，我们采用四组不同的策略来分别对这四类日期的数据进行拟合和异常判定。

在此之外，GOC 团队也会利用平台化的工具产品，支持集团业务团队为备站双 11 而进行容量验证、故障演练等相关工作。

实际上，智能运维产品的功能和价值更多地体现在日常的运维工作中，而双 11 则是检验一切线上业务和运维产品的一次大考。很多基于智能算法的容量预估和弹性调度策略会在双 11 发挥巨大的作用。

对于很多基于时序分析或机器学习的智能监控系统来说，往往需要将从历史数据中学习到趋势规律用于对当前数据进行监控和调度。而双 11 的特殊之处就在于，几乎每次双 11 都不同于往年。双 11 的数据一定不是往年历史的简单重复，而是对历史的突破和创新。因此，如何在双 11 期间保持智能监控策略本身的有效性仍然是一个巨大的挑战。

今年双 11，阿里 GOC 团队和阿里监控中台团队合作，基于异常检测算法和运维数据仓库，共同设计和研发了双 11 事件大屏幕功能。我们希望能够在双 11 及以后的工作中，当研发及运维同学发现自己的应用存在异常时，我们的产品能够自动化地找到最显著的异常趋势（不依赖于人为配置的监控策略），并且推荐最可能导致这种异常的可疑事件，帮助大家快速定位业务运行时遇到的问题。

另一层面，双 11 是全体阿里技术体系的一场战役，GOC 团队也专门为类似双 11 这样的重大活动保障而设计和研发了专门的产品，保障和支持双 11 期间阿里内部各团队之间信息和问题的流转。

身在百度与阿里

在加入阿里巴巴之前，我曾作为百度智能运维团队的架构师及核心项目负责人，其实从技术本身的层面来看，百度的运维和阿里的运维对技术的要求没有本质的区别。而两家公司文化、技术架构层面的差异也决定了运维技术团队在发展理念和过程上的差异。

从近年来运维技术发展来看，运维技术在微观上向基础架构（基础软件、中间件）领域延伸，宏观上向智能化方向发展，则是包括阿里、百度在内的互联网运维团队共同的技术发展趋势。

在智能运维的方向，百度和阿里的运维团队都在进行不断的实践和探索：

• 百度智能运维团队在异常检测、容量预测、流量调度等智能运维领域有非常多优秀的实践；

• 阿里集团各运维团队的同学，也在不同细分领域由自动化向智能化演进。

阿里巴巴集团内的各个业务的形态差异较大，业务之间的关联也相对较为复杂，这也给基于数据、算法的智能运维的效果提出了更高的要求，同时也为智能化运维产品提供了广阔的发展空间。阿里集团在智能运维中的业务指标异常检测、容量管理、异常关联分析、智能调度、硬件优化等层面也取得了很多优秀的成果。

我们相信，追求自动化、智能化是互联网运维从业人员的普适价值观和发展方向。我们也希望能够通过 InfoQ 组织的各种线下、线上场合和活动，更多地加强互联网企业间在智能运维领域的技术交流，互相学习，共同推进智能运维技术的发展，为业务带来更多可见的价值。

InfoQ：感谢王肇刚老师接受我们的采访，期待王肇刚老师在 ArchSummit 全球架构师峰会分享的《阿里巴巴故障治理领域的智能运维实践》。