蚂蚁集团技术风险代码化平台实践（MaaS）

文｜吴成辉（花名：清霄 蚂蚁集团高级技术专家)

校对｜陈真、庄晓丹、冯家纯

本文 6250 字 阅读 11 分钟

▼

我们一起回顾下监控上层业务曾经面临的问题：

• 烟囱式的监控分析重复建设

在技术风险领域，一度有超过 5 个系统在做监控分析的能力建设，大致逻辑基本都是拉监控的 Raw Data，做基础的聚合、分析处理后（类似同环比、阈值类的方式），根据一些当前的场景输入，结合一些算法能力，得出一个结论并触发一系列的 Action。类似这种烟囱式的监控分析场景，都是比较初级的重复建设，缺乏智能化、体系化。

• SRE 经验标准化沉淀的问题

在分析场景里也面临 SRE 经验无法标准化沉淀复用的问题，什么是 SRE 经验？拿交易付款下跌来举例，如果当前交易付款下跌 10%，SRE 通常有这么几个分析路径，首先看下淘宝交易是否下跌（来源），再看交易创建，收银台渲染是不是下跌等，这一类我们称为业务依赖。从全局看是否有大规模的压测、变更等动作，这一类称为变更关联，以及如何根据当前故障情况决策进行切流、限流等恢复措施，我们称为分析后置操作。

• 长尾需求

比如比较常见的，算多数据之间的成功率，流量损耗等等需求，通过产品化解决的成本非常高，而且用户不能快速修改、定制相关能力。

同时我们看到当前监控系统自身面临的问题：

• 监控的数据使用复杂

包含了几万张数据表、十几万张自定义数据表，数据类型超过 20+，以及跨站点、数据源异构等等问题。

• 监控服务不够开放

如何动态日志清洗计算、如何做分析后的时序存储、监控的时序检测能力如何复用等等。我们需要把监控的数据、能力完全服务化出来。

• 高效的可编程代码化平台缺失

没有一个高效平台帮助 SRE 先沉淀经验、再促进经验的标准化、复用，最后产品化。

基于上面问题，我们提出了 MaaS 的设想（Monitoring as a Service), 监控能力服务化，开放、融合监控能力到技术风险各个领域，快速完成 SRE 场景建设，沉淀可复用能力，主要包含以下 4 个阶段目标：

1.开放服务把监控的计算、存储、算法、视图等等能力开放出来。

2.核心共建几个重点的技术风险领域场景，比如变更防御、压测引流、无损注入、定位应急等等。

3.促进服务的标准化沉淀，让更多的场景可以复用、共同建设这部分的能力。

4.解决“监”与“控”之间的链接问题。

（我们的这里的 AIOPS 更多指的是

一系列专家经验的集合、沉淀、持续维护优化）

PART. 1 平台技术概览

能力服务化

监控的服务化能力整体包含这么几部分，数据服务化、配置服务化、计算、存储服务化、算法服务化、通知、云原生服务化等等，也包括一些外部能力集成比如消息缓存等等。

我简单举两个服务化的例子来介绍下什么是服务化：

比如视图服务，当某个变更发起后，这个变更关联的 100 个应用指标、20 个业务指标中的 10 个指标出现了问题，这个时候，我们需要动态为这个 10 个指标创建一个数据视图，来分析业务影响范围，这个时候就会用到我们的视图服务。

动态计算服务，比如我需要实时计算下某个应用在 A 机房（或某个 ZONE 如：GZXXX）的其中 5 台机器在 11:00~12:00 的接口方法调用情况，动态的计算服务就会派得上用场。

数据服务化

能力服务化中非常重要的一环就是数据服务化，因为数据是所有监控分析的基础，数据服务化主要分成两部分。

• 第一步是监控数据模型化

我们从数据的使用视角把数据抽象出数据虚拟表、虚拟表列定义、列关系。以及虚拟表的实现绑定，包含指标数据，也包含关系元数据，最后把这些物理实现映射到监控具体的数据指标或者底层的元数据服务上。

• 第二步是服务模板化

我们把一个数据服务抽象出三类：

实体查询，比如查询一个应用或者一个 Tbase 的集群；

数据查询，比如查询一个应用的 Sofa Service 在 APP 聚合维度上的数据；

关系查询，查询一个实体的关联实体，比如 cif 关联的 Tbase 集群等。

• 最后，我们实现了 5w+ 数据服务自动生成，分钟级别 SDK 更新的能力，我们可以通过非常语义化的访问方式来访问监控的所有数据，我们可以做到只要是监控体系内的数据，都可以通过我们这套能力访问到对应的数据服务，从而达到整个监控数据的服务化开放。

研发效能

• 大库管理，我们设计了一种可以支持服务沉淀、权限隔离（可以独立按目录管理 CR）、逻辑复用的代码结构，比如缓存 Tbase 的研发 + SRE 可以共同在 cache 目录里面定义缓存问题的发现、分析、恢复。同时可以复用到 core-service 里面的比如容器是否健康，网络是否异常等标准服务。平台能够提供一致的多环境调试能力，方便监控分析逻辑可以直接运行在本地 IDE 环境中，我们通过动态代理的模式把本地访问的数据、函数服务代理到服务端，从而达到了本地跟线上完全一致的研发体验。这项能力极大地提高了研发效率，研发过程中可以直接 debug 线上数据，比传统的日志模式的调试方式有非常大的效率提升，一个基础的分析函数基本可以在小时级别内完成。

• 一站式发布运维，传统的 Serverless 发布模式大致要经历这么几个阶段，从工程打包到 Jar 文件，耗时 1min，大概在 100-300MB，从 Jar 文件打包 Build 出镜像，大致 10min，最后做镜像化发布整体耗时约 20min, 整体流程大概耗费半个小时。我们研发了一套基于函数粒度的发布运维模式，以 MaaSFunction 为入口，做跨文件 Linker，如何做 Linker，看这个示意图，我们从 MaasFunction 入口开始解析本类依赖的文件，比如这边依赖的其他函数，到下面的 service，再到 util 层的相互依赖，从而通过这种方式解析出业务代码片段，通过动态编译完 Jar 大小目前最大在 500KB 左右，根据代码大小一般在 5s 内，再通过热加载到目标机器上，整体可以做到 5s 级发布，1s 回滚，其他还有配套的日志、监控等等能力。

多语言 Runtime

我们在初期建设的时候函数是都运行在一个集群里面，经常会遇到例如：死循环、OOM、线程频繁创建等等性能问题，因为业务代码不可控，CR 不能完全杜绝这类问题，这样我们就需要完全隔离的函数运行环境，从图中可以看到，每个函数至少具备 2 个独立的容器（容灾的需要），函数 1OOM（Out Of Memory），不会影响到函数 2。这样我们就可以基本做到函数级别的执行层隔离，我们通过 SLO 的度量，平台稳定性有了非常大的提升。

当我们按照函数级别隔离的模式大规模上线的时候遇到了成本问题，底层 sigma 支持的 pod 调度的最小规模是 0.5c（底层物理网卡等等限制），如果 2 台容灾，基本上一个函数至少占用 1c 的物理资源，随着函数业务的大规模使用，这块成本是很难持续的。通过我们的观察，绝大多数函数占用实际的 CPU10% 不到，甚至更低。我们同 Serverless Paas 团队一起共建了函数的高密度部署模式，通过 0.5c 的 pod 中隔离 5 个 0.1c 的容器，然后通过容器 IP + 端口的方式绑定到函数的执行上去，这样整体的资源成本可以从 1c 降低到 0.2c，成本降低到 1/5。

最近我们还支持了 Python 语言，下图是简易的代码 Demo。

PART. 2 应用场景

变更监控

蚂蚁变更故障占比是整体故障占比的三分之一，而监控是变更过程中非常重要的一环，当前面临很多问题，当一个变更发起的时候，我们拿到根据变更的范围，自动化的生成核心的系统、业务指标比如应用的 gc 、CPU 、服务成功率，错误数据等等，解决第一个不知道变更看什么指标的问题。我们的 MaaS 计算服务会根据变更范围动态生成一组指标的实时计算，（变更前、变更后，变更组、非变更组）等等，因为是根据变更范围动态生成的计算，所以解决了监控粒度粗的问题，这些数据产出后，根据我们的异常检测算法，得出本次变更过程是否有指标异常，解决不知道怎么看的问题，我们通过函数编排的方式同变更核心流程打通，整个过程无需用户参与，如果变更监控发现异常会自动触发拦截阻塞异常。

• 有效：全年累计拦截真实故障 163 笔，变更监控拦截 75 笔，占总体拦截数的 46.01%。

• 通用：变更监控核心防御服务统一，覆盖全站 87.74% 主要运维场景。

• 规模：日均 1.2w 次变更防御，30w 动态监控创建。

业务链路报警分析

常态情况下业务告警噪音的比例达到了 66%，对日常研发、SRE 同学的打扰非常高，不利于业务的应急流程、稳定性建设。其实 SRE 同学有非常多的噪音判定经验，但是降噪逻辑没法自定义，导致降噪非常困难。

我们通过与国际 SRE 团队深度共建，建设了一套告警分析服务，流程可以简单概括为：

1. 构建业务链，拉数据

2. 做异常检测

3. 定位分析

4. 推送异常、构建分析视图

通过这个场景，我们可以看到 SRE 经验是什么，什么是来源下跌、如何处理小流量业务，如何处理业务过程中正常的服务损耗，以及如何做业务的分析定位等等。

• 告警有效率从 34.68% 提升到 91.15%。

• 国际 GOC P1、P2 业务告警覆盖率 85%， S2 大规模推广到全站。

• SRE 从整体构思到第一个 Poc 实现只花了 2 周时间。

配置代码化

这个场景主要是要解决批量化覆盖的效率问题，比如仿真建站，应用监控规则自动覆盖等场景，我们通过服务化的方式把这些能力暴露出来达到一个提效的效果。简单拿应用监控规则覆盖来说，代码逻辑是通过先配置好模板，然后经过一些配置替换，最后批量大规模覆盖。在仿真环境建设过程中，做到了根据流量实时调整阈值，0 人工配置，重庆消金建站，5 人天的配置工作降低到 0 人工监控配置。应用规则自动化覆盖也是从往年 527 的几十人日，降低到 1 小时。

（中间件 SRE 同学的代码化案例：）

• 应用规则自动化覆盖：

全站应用规则覆盖降低到 1 小时，527 国际应用告警 0 人工配置。

• xx 业务建站：

中间件 10+ 产品 降低到 0 人工监控配置。

• 仿真环境建设：

仿真规则自动化覆盖、阈值动态调整，0 人工配置。

后续我们会有更多的系列文章来详尽的介绍如何通过 MaaS 来做更多技术风险能力建设（尽请期待），这里先不展开叙述了。

PART. 3 写在最后

MaaS 未来规划主要分三部分：

• 平台能力建设，把监控的服务化路径复制到技术风险更多场景，动态弹性、以及研发流程标准化。

• 代码生态化建设、社区化建设，建设监控分析领域的服务目录（比如说容器 CPU 如何分析、热点方法是什么等等），函数服务、应用市场的建设，来让更多 SRE 合作在一个领域里面进行持续建设，最后是社区化的运营能力。

• 监控 + X（跨技术风险领域）探索，从我们这两年的经验来看，监控 + 变更 = 变更监控、监控 + 演练 = 无损注入、监控 + 压测 = 性能分析 等等，我们看到了这些领域一些质的变化，我们希望挖掘出更多这样的场景，比如监控 + 限流 + 容量，做精细化的限流能力建设等等。

如上图，MaaS 的 Logo 看起来像一个木头搭成的房子，象征着我们希望业务能够像积木一样快速建设，M 又是两个小三角形，三角形象征着稳定，我们希望 MaaS 平台能够非常稳定地支持上面的业务。M 中还融合了曲别针的图形，象征着连接。

平台的目标与梦想：有一天我们分析操作系统不再找系统部同学，分析中间件不再依赖中间件同学，分析缓存不再等着同学（支付宝一位负责缓存的 SRE 专家）给排查结论，进程起不来，配置中心连不上，都可以通过代码在线诊断的方式一键分析，而不是冗长低效、口口相传的文档，让技术风险知识可以真正通过代码的方式共享。

我们梦想整个技术风险能力都可以通过 MaaS 平台实现 Auto 化。有一天，秒级压测熔断、变更防御、流量精细化调拨、预案决策、自愈等等可以真正做到 Auto，真正的无人值守。

• END -

2019 年双十一之后，我们开始了 MaaS，一晃近两年了。到目前为止，MaaS 有效研发用户近 200 人，函数服务超过 1000+，日函数调用达到 1000w，分析近 200 亿数据点。我们的 MaaSHub（社区化产品） 、多语言支持等等也在快速迭代中。

• 质疑

MaaS 在最早期推广的时候（包括现在仍然存在），为什么要用这个平台？其实大多数同学是带着质疑的，最常见的几个反问：我的代码为什么要写在你的平台；你们平台现在还不成熟，我的业务很重要；我只是想拉个数据而已，还要学你这么复杂的东西等等。这个过程比较艰难，但是通过我们的引导和支持，用户已经可以自助地在平台上做各种函数研发，并且用户之间开始自发推广传播，不是我们平台牛逼，而是我们有监控坚实的数据、计算、存储、算法能力，有整个 Antmonitor 40 人团队作为我们最坚定的后盾。

• 获客成本

代码化的产品是天然区别于产品化产品的，在早期时候，服务化能力匮乏，单个用户的转化留存，至少要花费 2 人/周的研发成本，可以想象这样高昂的付出促使我们会多么珍惜现有的 200+ 用户，需求基本都是当天研发到预发，次日上线。让用户有了安全感、信任感，才能留存。

• 平台生态

生态这个词比较大，比较空。用写实一点的话来描述，如何建设 MaaS 生态，需要回答好下面几个问题：

1. 如何让用户的代码慢慢转换为平台的沉淀，缓存的诊断代码到底什么时候能够做到标准化、快速复用（缓存是我们合作比较久，相对已经是比较成熟的领域），这个很难，但是需要去做，或者说我们需要建立一种机制让这个通道变得可能、简单。

2. 平台的沉淀如何再反向促进平台用户的发展，平台有了非常多的分析能力，如果快速推介到用户，让用户感知到，使用起来，让用户构建场景更加简单、快速。

3. 如何复用用户场景，用户解决的问题是一个特例问题，还是一个通用问题？如果是通用问题，是不是可以直接通过复用用户场景，达到通用问题解决方案的逻辑复用。

当然整个服务化的过程是非常乏味、枯燥的。未来我们想从监控跨越到技术风险，那么更多技术风险平台的服务化集成是条必经之路。但是如何快速集成外部系统的服务化能力，这块我们也正在做一些探索，并且已取得了一些成果。

• 大库模式 & FaaS 模式的生产实践

为什么采用大库，大库主要解决代码透明性的问题，透明性的目标是为了促进代码沉淀、更高层次的复用，所以我们摒弃了传统 FaaS 平台的单函数单库模式，因为我们的首要目标是代码的沉淀复用，其次是高效的函数研发平台。

FaaS 模式还是太超前了，绝大多数同学还是习惯于传统的 Project 模式，各种三方包、TR 、反射满天飞，不太适应函数的研发模式，在这个过程中我们也做了非常多的兼容，让函数也能像传统应用一样使用各种功能，但是在 Serverless 还没有普及的今天， FaaS 未来的路是还需要更多的探索与实践创新。

• 分析型 DSL

我们曾经花费大力气尝试设计了一套自己的分析 DSL，如下图一个支付宝交易异常的分析 case：

虽然我们一直想尽量拔高分析的层次，但是可以看到还是无法避免地暴露了很多细节出来（如检测的阈值、时间、对比操作符，返回值类型等等），一旦暴露细节之后，离我们的初衷就会有比较大的偏差。

DSL 之所以无法落地推行的原因，其实就是上图的层次结构理解问题。DSL 不适合描述细节，DSL 的擅长领域是有限的表达能力，而我们现在真正缺失的是大楼的地基（也就是一二三层），远远没达到 DSL 的层次。

• 代码化 VS 产品化

代码化的尽头是产品化，两者是不矛盾的。

特别是监控领域的各种分析能力，分析能力还没有就着急落地相关的分析、定位产品是非常危险的，我们在这个上面也吃过亏。现在我们的路径是先落地代码分析能力，再把这个代码化函数服务抽象成一个 Controller，把必须的参数抽象为产品化的输入，反向行之。最后变成一个稳定、牛逼的分析产品。