突破规模化运维瓶颈 SREWorks 云原生数智运维平台揭秘

作者：

钟炯恩——阿里云大数据基础工程技术团队运维专家

引言

突破规模化运维瓶颈是诸多 IT 规模增长的企业及组织当前遇到的比较棘手的问题。面对这些问题，多数人的第一反应是上云。但是上云之后我们会发现，即使云上的架构规模增大，也依然存在同样的问题，有时候甚至更严重，因为弹性扩容的云服务器远比买一台物理机更方便，从而导致集群规模也急剧增加。

那么，规模化运维为什么会遇到瓶颈？

总的来说，规模化运维遇到的瓶颈可以分为三类，分别为稳定性瓶颈、成本瓶颈以及效率瓶颈。

第一，稳定性瓶颈，这往往是我们最关注的点。对稳定性影响最大的因素是变更，由变更导致的故障占据 70%-80%。因此，我们一般会通过严管变更来减少故障时间，进而提升系统的稳定性。

这会导致出现一种微妙的平衡：如果限制变更的次数，则我们会选择将多个变更集中在一次变更里进行，而这会增加回滚的难度，从而导致单次的故障时间变长；而如果不限制变更次数来约束每个变更必须能够回滚，则我们可能会将一个变更分拆为多个变更，虽然出了问题可以立即回滚，影响小，但由于变更总量较大，最终系统的可用性会陷入瓶颈，无法提升。

除此之外，在大规模集群中，在成千上万的机器里总会出现一些性能存在问题的机器，可能是硬件问题，可能是内核问题，也可能无法明确问题。而这些机器使得整个系统在某些性能或功能上表现出不明原因的不稳定，如果无法在第一时间抓住它，则会持续产生影响。

以物理机为例，物理机的硬件日化故障率约 0.03%，而在所有硬件故障中，有 1%属于比疑难杂症，无法明确。如果机器保有量为 1 万台，则平均每月会碰到一例非典型的疑难杂症，影响业务。由此可见，在规模化的效应下，原本罕见的问题会变得常见。

第二，成本瓶颈。在过去的一段时间里，这类瓶颈可能不太被重视，但是在降本增效的今天，这些问题变得尤为突出。

热点机器是在分布式系统中常出现的问题，明明有大量可用资源，而流量却都打到一台机器上，导致整个集群性能低。而热点机器的成因非常复杂，可能是架构问题，可能是业务问题，也有可能是底层软件、硬件的问题。

成本瓶颈的另一方面包括从预算到执行的精细化管理。如果是物理机，则需要考虑采购周期；如果是云服务，则需要考虑区分包年、包月、按次计费等计价模型，还需考虑不同区域费用单价的差异。如果无法很好地对上述问题进行管理，则会导致弹性弹得越猛，成本越高。

资源使用的削峰填谷是成本方面需要解决的更高难度的问题。在空间维度上，可以用算法来计算如何减少跨地域依赖，从而节省成本；在时间维度上，可以通过白天运行应用服务，晚上运行离线计算来最大限度利用机器资源。

第三，效率瓶颈。该类问题往往发生在人机交互之中。

在全自动化的流程中，为了业务需要可能会配置特例化的人工干预节点，导致后续人工干预越来越频繁。那么，如何在业务定制和自动化的标准中保持中立、保持平衡？

一个管理平台往往有非常多的功能和配置，配置是直接暴露 YAML 或 json，还是提供可视化的人机交互，也是很大问题。如果提供很多可视化交互，可能会带来较高的开发成本；但如果直接暴露 YAML，会存在由改动引发的问题。

另外，某些小问题原本很好排查，但在大规模集群中可能需要串联上下游许多机器才能发现，导致排查小问题的时间开销也变得越来越大。

那么，如何解决上述瓶颈中涉及的问题？

经过大量实践，我们总结出了一套规模化运维的流水线。流水线里包含 6 大环节，分别是交付、监测、管理、控制、运营、服务。

有了全链路图之后，我们可以按图索骥进行查漏补缺。对于已经拥有的能力，可以演进增强；对于尚未拥有的能力，可以用成熟的开源方案进行补位。

上图展示了业界常见的开源方案对于上述 6 大环节中能力的支撑。

• Prometheus：能够进行时序数据的存储、监控和告警，能够满足规模化运维的指标监控需求，但是只针对“监测”技能点。

• Grafana：能够接入各种数据源，进行图表、仪表盘的可视化展示。虽然无法与专业的 BI 工具抗衡，但是应对规模化运维的管理和运营已经绰绰有余。

• Ansible：基于 SSH 的配置管理工具，在物理机时代特别适用。但是在云原生时代，配置和部署都已转移到 K8S 上，因此已经不太使用。

• Docker：以一己之力开启了容器的技术革命，真正意义上实现了构建一次、随处运行。基于 Docker 可以完成小规模的交付管理和控制，但尚且无法应对大规模。

• Elasticsearch：作为分布式的搜索和分析存储引擎，通过 query，它能够提供各种数据来满足运营和服务的需求，其生态制完善，用户接入以及使用体验非常好。

• Kubernetes：云原生领域的既定标准，被广泛用于解决大规模云计算环境中的管理问题，可以基于 K8S 完成所需要的任何事情。

飞天 5K 项目是中国计云计算领域里程碑式的项目，我们团队承担了其中的运维工作。超大规模集群的运维保障工程使我们沉淀了一个运维平台，在内部被称为 ABM（Apsara Big Data Manager），飞天大数据运维平台。

云原生时代的架构变革

云原生为什么能够带来巨大的变革？我们从没有被注意过的角度来聊一聊云原生时代的变革。

1830 年，英国铁路上出现了箱式运煤的容器。受限于火车车厢数量，集装箱对于铁路货而言提升非常有限。但集装箱到了海运的货船上立马出现了质的飞跃，世界上第一艘集装箱船装了 200 个集装箱，相比较同货运量的船，卸货时间从 7 天压缩至 15 小时。

这让我们感受到了标准化的威力，它没有让船开得更快、变得更大，但却彻彻底底地改变了全球贸易的形态，不同国家的消费者和买家被紧紧地连接在一起。而如果没有集装箱，这一切都不会发生。

从某种意义上来说，全球物流改变的关键点不是船只的大小，不是飞机的时速，也不是铁路的里程数，而是集装箱。

而 Docker 的出现也像集装箱一样，为软件的开发以及部署带来了标准化。

在 Docker 出现之前，研发和运维都面临着诸多挑战，我们常常为环境差异引起的部署问题焦头烂额。Docker 出现之后，几乎是一锤定音，大家结束了争吵，不约而同地选择了这个方案。

在对容器进行标准化之后，业界又对容器的部署方案有了各自的想法。Docker 推出了 swarm，谷歌开源了 K8S，最终 K8S 的 Pod 方案脱颖而出，既解决了隔离的问题，又满足了共享的需要。

云原生上标准化的容器以及运行时被统一之后，会发生什么？没有人知道，但我们也许会见证历史。

Kubernetes 如何改变运维体系？

在 K8S 之前，运维的主要工作是在每台机器上部署 agent，然后将其中的信息采集上来，汇总到中心，同时中心也能下发指令给 agent 做很多工作。更新迭代的原因可能是 agent 不够稳定、不够强大，也可能是 server 不够强大。

但是 K8S 出现之后，它强大的 api server 能力顿时使所有 server 相形见绌。只需掌握一到两个接口的用法，便可以推算出几乎所有的接口，非常强大且非常优雅。

另外一端，在基础设施之上，在 kubernetes 上暴露了 CRI（运行时）、CSI（存储）和 CNI（网络）三种接口，满足了容器的所有部署需求。

该设计牢牢地将基础设施和应用负载区分开来。关注基础设施，则关注 node 往下部分；关注应用，则关注 Pod 向上部分。应用层的部署以及维护的逻辑到 Pod 即结束，基础设施的维护只在 node 之下，原则上不会与任何 Pod 有关，而且 Pod 无状态，如果 node 要重启，Pod 会飘到其他 node 上。

基础设施是不可变的，如果在设计时将基础设施信息掺杂到应用中，则会为后续带来极大的不便。基础设施不变，但应用要变，此时往往需要订正数据。因此，我们会思考，有什么办法能将应用和基础设施区分开。

K8S 很好地实现了这一点。很多运维工具或平台并非无法实现此能力，而是在功能复杂之后，由于一开始设计不够完善导致有些定位会变形，最终导致很多基础设施层的信息和应用层的信息被揉到一块。

而在 SREWorks 数智运维平台中，我们严格遵循“区分不变的基础设施和灵活的无状态部署应用”原则。

规模化运维工程实践

Too Big to Fail（大而不能倒）是我们时常面临的架构困境。IT 设施愈发庞大之后，会出现各种流程和接口，为了收敛问题以及提升效率，通常会将它们收敛到统一的平台，平台的功能增多之后，重要的功能会被独立为几个子平台来承载。

而不同的平台会由于各种原因衍生出不同的研发流程，有些底层模块在停止迭代一段时间之后，已经无法运行构建和发布流程，从而导致我们不得不维护某些特别慢且低效的模块，有些无法修复的 bug 只能通过不断在外围加辅助逻辑的方式解决。这种情况类似于经济学领域的 Too Big to Fail：具有关键地位的大公司破产会影响到整个社会，于是要不断将人民的血汗钱投入进去，以维持这些公司的运作。

很多平台都会陷入困境，即便投入很多精力在维护，稳定性和可靠性依然很差。此时可能有人会选择重构，但是如果没有优秀的顶层设计，过了几年之后平台依然会陷入类似的困境。

我们可以将目光转到移动互联网领域，看看它从功能到平台演进历程。

众所周知，iPhone 的推出引领了移动互联网的革命。原本在诺基亚手机中的功能块都演进成了应用，用户可以根据自己的需求在 appstore 中下载和安装应用，这种应用模式极大满足了用户各方面的需求。久而久之，某些应用也变得特别庞大，功能众多，变得像一个平台，包含了各种功能，比如微信、支付宝。

于是，在这些应用中演化出了应用生态。这些不同于手机应用的应用，可以称为小程序（微信小程序或支付宝小程序）。优秀的平台会有应用生态来支撑其功能，里面的应用亦是如此，像一层又一层的应用套娃。

回到架构之上，理想的平台架构应该是怎么样的？

如果将应用作为功能载体，平台负责应用管理，则可以较好地管理这些功能。对于复杂或重要的功能，引入平台化的应用管理可以继续深入展开。但是做一个应用平台需要考虑很多方面的因素。

它需要有标准的应用模型，用户能在改应用模型之下开发出各种应用，满足业务需求。应用需要有一套健全的开发部署体系，实现快速迭代、快速交付。同时，应用开始运营后需要有监控，有运维来保障稳定性。针对这些经验的结论，我们给出了标准的应用模型，一套包含 6 大环节交付、监测、管理、控制、运营服务的工程实践，使得我们可以工程化地实现规模化运营。

云原生下的应用模型 Open Application Model 是由阿里云和微软共同推出的开放的应用模型，旨在为云原生应用提供开放的标准，解决应用开发和部署的挑战。

OAM 的核心概念包括应用 application、组件 component 以及运维特征 traits，其主要特征包括：

• 应用为先：应用的交付与部署都为自包含，其中各类操作行为都应该作为应用定义的一部分，这些内容与实际的基础设施无关。

• 清晰和可扩展性：定义一套开放标准，可以模块化整个应用交付流程，根据个人需要将这些模块自由组装，满足业务需求。

• 云服务供应商无关：自定义的开放标准应该是一套更高级别的抽象，可以跨本地集群、跨云服务供应商，不会被锁定到任何厂商的底座。

OAM 通过一系列的概念定义，完成了对应用的抽象，实现了角色职责分离，将应用交付与底座解耦，开发无需关心底座实现的细节，只需关心自己的应用模型。同时，应用运维再也无需担心应用内部与底座相关的各种问题，只需提供应有的 component 和 traits，应用即可运行。

基于应用引擎，可以按照 application 和 component 的模式逐层垒起应用积木。

我们先在应用引擎之上实现了运维应用管理 swadmin，其中含有一套前端的低代码引擎，能快速开发后端接口，编排前端页面，快速落地整个运维应用。运维应用便可在应用市场里上线各种功能，争奇斗艳。

大数据应用管理的运维应用来自于阿里内部，用以支持阿里内部的大数据产品需求，实现阿里云上所有大数据产品的交付、售卖以及管控能力，它也是基于 AppManager 和 OAM 实现的应用工厂。

另一运维应用——企业应用管理，已经被放在开源的 SREWorks 之中，作为通用的应用管理，用于支撑开源场景的通用应用需求。很多公司已经基于企业应用管理开发出自己的业务应用，同时在此之上定制了很多自己需要的运维能力。

上图为 SREworks 运维桌面，桌面上按照交付、监测、管理、控制、运营、服务 6 大场景分别内置了很多应用。

下方为运维应用开发演示，请点击查看视频。

https://www.bilibili.com/video/BV1tV4y1Q7jD/?spm_id_from=333.999.0.0

AI+大数据的数智运维实践

AIOps 是人工智能在运维领域的常见运作框架。其主要流程如下：

首先，观测（Observe）时序数据和文本数据流，然后用算法对其做分析和洞察，发现其中的问题。其次，参与（Engage），将上一步发现的问题以及结果共享给团队中的成员，共同对结果进行讨论、分析以及优化，将人工干预的结果进一步反馈，喂给算法。最后，通过一步步打磨，将原先由人类完成的事情全部赋能于机器，从而实现全自动的运维，比如自动弹性扩缩容、故障自愈等。

AIOps 具体落地的应对策略在于内核、场景和需求。

我们抽象了交、监、管、控、营、服 6 大场景，基于数据化和智能化的内核向外扩散落地四大需求——质量（稳定性）、成本、安全、效率。

数智内核实现了四大需求，为什么还需要六大场景？

这是为了解决大工程下的功能复用问题，如果没有以上场景做收敛，很多功能会发散。比如异常检测可能会由于业务的细微差异，出现多个工程实现。

足够的通用和抽象，也是落地工程中的重要考量原则，在同一个场景下，会尽量使用同一套方案实现。

观测通常可以分为两类，一类是以 metric 为代表的时序数据，另一类是以日志为代表的文本数据。

Metric 的异常检测——无阈值监控，指让机器自己发现指标中的不正常数值，并且进行报警。它与人为设置的阈值不一样，异常检测讲究的是无阈值监控，在大规模集群的指标监测中常常能够发挥较大作用。

异常指标的检测一般包括均值的变化、方差的变化、尖峰探测、断崖式的跌落和趋势预测，基本涵盖了人类认知中判断异常的方法。

在大规模使用异常检测时，建议可以先对顶层的运营指标进行异常检测，这类指标通常会配有运营报表，可视化程度高，针对异常点的排查也非常方便。即使没有检测出异常，对于出错的容忍度也较高。运营指标接入异常检测之后，可以逐步向底层渗透，替换生产环境的固定阈值报警。

异常检测能力已经在 SREWorks 中开源。

日志聚类——面向日志的异常告警也即将开源。

在日志数据中，我们常常关注的焦点是日志中的报错堆栈，久而久之，经验丰富的运维同学可能会直接写脚本监控日志报错堆栈里的关键字。但这种监控方案存在问题，软件版本更新可能会导致报错堆栈变化，关键字随即不管用，因此需要调整脚本。

而日志聚类是一劳永逸的办法，报错堆栈在算法眼里都属于文本模式，日志数据进来之后，可以用日志聚类将这些报错堆栈聚成若干个文本模式，从而使一份文本数据变为指标数据，只需要关注某些文本模式计数值的突增，即可感知到异常。

文本数值配合异常检测，即可实现 AIOps 完整的一条龙服务，涵盖了日志的聚类分析、模式计数、异常检测以及报警。

当前开源版本的日志聚类基于 Flink ML 构建，我们会将这份构建代码合并到近期即将发布的 V1.5 源码上。

上图为数智运维的分层图，经过 IaaS、PaaS、SaaS 三层的分层之后，面向交、监、管、控、营、服六大场景，内部的数据运维平台衍生出了非常多功能来满足业务的需要。不少基于 SREWorks 做能力构筑的公司也在逐渐点亮图中的各个功能点。

数智运维体系无法一蹴而就，我们无法通过简单地点击鼠标，就得到数智运维的整个体系。我们希望 SREWorks 提供给用户一个用户工厂、大量工程实践的样例以及丰富的数智运维经验。希望用户在使用 SREWorks 之后，能够基于这些工程实践和应用工厂构筑出满足自己业务需求的数智运维体系。