一分钟精华速览

互联网平台以业务为中心，以用户为中心，平台的功能服务、质量和用户体验等是关键的目标，仅仅关注后台系统的可用性是不够的，以传统运维的视角来解决故障、做监控会比较被动。

本文以阿里云 ECS 业务为例，探讨阿里云最核心、亚太地区业务规模最大的产品之一，在极高的稳定性和性能要求下，如何基于云构建可观测性并从客户视角建立观测能力，以及在推进体系建设中的成功经验和待改进之处。 file

作者介绍

file

阿里云高级技术专家——杨泽强（竹涧）

TakinTalks 社区专家团成员，多年云计算领域研发经验，在阿里先后参与集团 DevOps 平台、弹性计算核心管控以及 SRE 工程相关研发，当前在弹性计算团队从事研发工作，主要负责弹性计算稳定性架构与智能运维平台建设。

温馨提醒：本文约 8000 字，预计花费 15 分钟阅读。

「TakinTalks 微信公众号」后台回复 “交流” 进入读者交流群；回复“可观测”获取相关资料；

背景

正如大家所知的，云服务器是云厂商中最底层、最复杂的部分，而 ECS 弹性计算作为阿里云最核心、亚太地区业务规模最大的产品之一，其业务复杂度更是可见一斑——部署遍布国内海外的 30 多个地域，应用规模也达到了上百个，整体依赖复杂度可以说是阿里云云产品管控系统之最。同时，还面临着集团超级客户（如淘天集团）、OnECS 云产品（如容器、存储、函数计算等）、各行业大客户的极高稳定性和性能诉求。 file

那么，如此超大业务规模和业务复杂度、极高稳定性 &性能诉求，阿里云 ECS 是如何基于云构建可观测性的？以及阿里云 ECS 业务实践中，改善用户体验的可观测体系，是如何搭建起来的？这将是我本次分享的重点。

当然，在不同的业务和阶段，可观测性的做法可能不完全一样。这次分享的主要目的是以阿里云 ECS 的业务为例，分享我们在推进体系建设中的成功经验或者仍待改进的地方，以便大家在遇到类似问题时参考。

一、阿里云 ECS 业务带来了哪些观测挑战?

file

1.1 业务规模大导致运营难

建设可观测性并非最具挑战的部分，更具挑战的是如何持续运营和维护它。正如前文所述，随着系统规模、团队规模和业务复杂性的增长，当系统规模达到一定程度时，维护变得异常困难，甚至可能无法继续维护下去，从而导致系统逐渐腐化。这最终将影响研发体验和平台价值。

1.2 团队认知不足，观测能力缺失

很多人对于观测的理解仍停留在监控阶段，尤其是那些没有从事可靠性或运维工作的研发同学。在建设观测能力之初，我们团队中的大部分成员都只具备研发背景，大家普遍认为观测就是监控和告警。因此，在初期的建设中，我们的观测能力也较为薄弱，主要限于监控功能。然而，事实上，监控只是可观测能力的一小部分。

1.3 技术储备不足

作为业务研发团队，我们一直在探索如何在业务团队内部构建可观测性以解决问题。然而，这面临着巨大挑战，因为我们需要在最大限度地解决问题的同时，也要考虑业务团队的技术储备和成本因素。

二、可观测体系建设有哪些思路？

file

首先，团队提出了“Cloud First”的思路，即基于云产品构建可观测性。各个云平台上都提供类似的产品能力，而我们的服务部署在阿里云上，因此选择了阿里云的产品。上云的目的是为了利用云产品的能力来构建可观测性，而不是自行开发或使用其他开源/闭源内部产品。在接下来的部分，我将详细阐述这一点。

其次，可观测性不仅仅限于运营阶段，我们认为在软件生命周期的各个阶段都应考虑可观测性问题。

第三，我们采用平台化和产品化的思路来解决可观测性问题。稳定性领域的工作不是一次性地完成，而是需要通过平台化、自动化和智能化的方式来解决问题。我们的整体稳定性均遵循这一思路，在可观测性方面也不例外。

三、阿里云 ECS 可观测体系是如何落地的？

3.1 基于云构建可观测能力

3.1.1 ECS 观测上云背景

file

2016 年前后：阿里云 ECS 将一些业务侧的基础监控搬到了阿里自研的平台上进行了完善。

2019 年前后：随着业务规模的不断扩大，阿里云 ECS 面临着 30 多个部署地域和上百个应用的大规模分布式集群的管理挑战，仅依靠资源平台已无法实现制定的目标。因此，我们决定将整个监控都迁移到云上。这一决策基于以下原因：首先，我们需要管理数千个数据库以及数百个研发人员，单纯依靠自研平台无法满足需求。其次，借助云上的开放集成能力，我们能够与业务需求相结合，实现更深层次的发展。同时，基于公共云能力构建可观测性能够获得最优秀的产品和能力，并且与开源社区天然地紧密结合，具备更强的迁移能力。另外，将监控组件托管到云上，从业务角度来看，我们不需要过多关注组件本身的稳定性问题，如 Prometheus 集群的维护、数据存储、无损扩容和迁移等，因为云平台会帮助我们屏蔽这些问题。综合考虑，将可观测性迁移到云上的方式成本最低，因此从 2019 年开始，我们进行了这一改造。

2021 年前后：通过采用云原生的方式，我们能够对大规模和高复杂度的业务进行数据加工和转化，并通过服务化和平台化的方式提供给更多的研发团队使用。云原生的改造是一个长期的过程，我们希望通过工程化的方式逐步推广和解决问题。目前，阿里云 ECS 的云原生改造已完成核心部分，但还有一部分工作尚未完成。

2023 年前后：除了云原生改造，我们还在推进 AIOps 方向的演进以及 IDP（平台工程）的建设。核心目标是解决业务研发团队规模较大时，自行开发服务的成本高和内部卷的问题。通过建立内部平台，我们可以帮助研发团队快速获取反馈，并将通用能力扩展到业务中，同时也促进内部平台的建设，将这些能力最大化地应用于业务中。

回过头看，2019 年将可观测性上云的选择，我个人认为还是比较正确的。

3.1.2 确定可观测性模型

在上云之前，我们必须解决一些关键问题，例如我们需要观测什么、如何将观测能力迁移到云上以及哪些技术可以支持我们等等。换言之，我们需要确定如何实现云上的可观测性。为此，我提出了一个抽象的五层观测模型。

file 在这个模型中，从最基层的资源和平台到应用和产品，我们都需要关注观测的指标和要点，这是大家都能达成共识的。然而，我想重点讲解一下最上面的「客户视角」，因为我们的最终目标是服务客户。无论我们自认为的 SLO 或 SLA 有多高，或者系统稳定性有多好，如果客户认为我们不稳定，那就必然存在问题。因此，在建设可观测性时，我们需要从客户的视角来看问题。

举个例子，我曾负责的核心系统出现了一个问题。所有的指标都显示正常，然而用户反馈说他们的访问速度不时地变慢。这时候我们该如何判断呢？难道要告诉客户我们的可观测性指标都正常，这是客户的问题吗？显然不可能。实际上，我们需要站在客户的视角来看问题，这要求我们的观测理念需要更高级，即关注客户的业务连续性。我们的 SLO 不仅仅要关注平均水平，还要关注长尾情况。不仅要关注我们软件的链路，还要关注客户端的 E2E 体验。比如，当一个客户调用我们的服务时，可能会跨越多个地域，网络链路不稳定可能会导致速度变慢。此时，我们需要进行拨测，从用户的视角来观察是否是由于网络连接或速率问题导致。

另外，我们也遇到过这样的情况，即单个 API 看起来都没有问题，但是当多个 API 组合起来使用时就会出现问题。对于这种情况，如果能够从用户故事的视角来观测，那就意味着我们的观测体系已经非常完善，可以说是接近完美了。然而，坦白来说，我们目前还没有达到这种程度，因为这样的观测体系需要非常高的投入，我们还在进一步加深这方面的工作。

因此，我想强调客户视角的重要性，尤其对于像我们这样的 To B 业务来说，更需要关注客户视角。这样的做法会带来巨大的价值。

3.1.3 根据模型选择产品能力

在确定观测模型后，接下来就是思考如何将其落地，即使用哪些云产品来构建观测体系。各个云厂商和开源社区都提供了相应的能力。我们的实践是基于阿里云来实现的，所以这里就以阿里云的云上能力为例来介绍。 file

首先是资源监测，我们使用了阿里云的云监控来关注机器的指标。它对业务的侵入比较小，一个 Agent 采集多个指标，整体开销也比较小。

另外，可观测性还涉及日志、指标和链路追踪的观测。我们使用了阿里云的日志服务（SLS）来处理日志相关的工作。当然，也可以选择 ELK 技术栈、AWS 的 CloudWatch、腾讯云的日志服务等产品来实现相同的功能。

链路追踪方面，我们选择了 ARMS 来监控应用链路上的指标。ARMS 采用无侵入的方式，能够采集云原生指标和识别中间件流量，并且可以基于这些指标定义业务异常。当然，在选型时，除了开源产品如 SkyWalking 外，商业化产品也有其他选择，比如 AWS 的 Insight 和腾讯云的 APM 工具。

总而言之，这些都是阿里云提供的云上能力，但其他云厂商和开源社区也提供了类似的产品和解决方案，可以根据实际需求选择适合自己的工具和技术。

3.1.4 云原生可观测方案

构建观测体系离不开三板斧：日志（Log）、追踪（Trace）、指标（Metric）。在这个基础上，我还补充了事件（Event）和告警（Alert）两个部分。之所以加入这两个方面，是因为它们与观测性密切相关，后面我会详细说明。整个观测体系方案大致如下图。

file

3.1.4.1 数据采集到告警的闭环

Log:

在日志的统一性方面，我们选择将所有的日志统一存储到阿里云的日志服务（SLS）中。与此同时，我们还采取了另外一个策略，即统一日志格式。我们都知道不同的业务或团队可能有自己的日志格式体系。为了解决这个问题，我们开发了一个统一框架层，用于规范整个团队的日志格式。这样做的好处是显而易见的，因为在后续的工作中，我们可以基于统一的日志格式进行指标计算和其他处理。如果没有这个统一框架层，我们想要通过流式计算来处理日志将会非常昂贵，而且维护起来也会很困难。因此，在阿里云 ECS 中我们选择自行开发了一个抽象的统一框架来处理日志。

另外，为了解决多地域复杂性的问题，我们采用了基于开放能力的 SLS 的 OpenAPI 进行处理。如果日志平台本身没有提供开放能力，我们将无法解决多地域的复杂性。通过利用 SLS 的 OpenAPI，我们能够实现日志的多地域复制和一致性巡检，比如确保索引的正确性和保存时长的准确性等，同时也能解决与成本相关的问题。

Trace:

在基于标准日志框架的基础上，我们使用了阿里云的一款 APM 工具——ARMS，来实现全链路的 Trace ID 串联。这意味着我们可以将异步线程池（例如 Spring 的异步线程池）和中间件的线程池等都串联起来。同时，我们在框架中插入相应的代码进行连接，这也是通过 SDK 的集成来实现的，如果以后想要更换方案，成本也较低。

Trace 的最终目的是为了方便研发人员和工单处理人员进行故障排查和性能优化。为了更好地支持这些服务，我们自行研发了一个编排引擎，将阿里云 ECS 自身的几千个日志存储、CMDB 和应用 APP 模型等连接在一起。为什么要自行研发这个编排引擎，而不使用开源方案呢？因为开源方案的扩展性有限，而自行研发的编排引擎可以更好地解决这些问题。举个例子，开源平台无法集成自己的代码，而自行研发则可以实现。当某个错误码报出某个关键字时，我们可以快速定位是哪个业务、哪个应用、哪个责任人等，帮助业务团队更快地解决问题。

此外，我们的平台还提供了许多扩展性能力，例如 OpenAPI 和白屏化编排等。我们为不同的业务团队提供了这些能力，使他们可以基于这些能力进行自己的编排。同时，除了阿里云 ECS 团队之外的其他团队也可以使用这些能力，这也是我们在平台工程方面的一个重要思路。

Metric:

在处理指标方面，我们最初的做法是通过日志解析每次进行计算，这既耗时又消耗资源，成本较高。此外，得到的数据也并非统一标准化的格式，无法进一步进行服务化处理。为了解决这个问题，我们选择了标准化的开源方案 Prometheus 来进行云原生改造。我们使用开源的 Prometheus SDK 生成 Metric，并将其统一存储托管在 SLS 的 Metric Store 中。

对于业务团队来说，只需要获得足够标准的数据，以便能够控制和使用即可。同时，我们基于 Metric 构建了后续的告警和监控大盘等，它也是我们做 AIOps 中重要的数据底座。

综上，我们的整体可观测性围绕着 Log、Trace 和 Metric 展开。通过采集业务日志，我们可以在可观测大盘上观测链路异常，当发生异动时则触发告警。根据告警的 Trace 等信息，我们可以快速定位到责任人，并按照 SOP 响应，从而实现从数据采集到告警处理的闭环。

3.1.4.2 观测数据底座

file

数据底座在可观测性方面非常重要，我这里可以深入一些分享。服务层包含了自身业务的 CMDB 数据，以及来自 Prometheus、SLS、DAS 和 ARMS 等平台的业务数据。这些数据在进入数据中心后，将形成一个五层观测模型。然而，仅仅依靠这些层次的数据模型对于业务团队来说还不足够。因此，我们还需要利用一些业务知识，例如业务知识图谱、故障知识库、阿里云 ECS 支持的领域知识以及非敏感用户数据等。

这里重点介绍一下 Event。实际上，Event 是"三板斧"的补充。在庞大的集群中，会出现各种各样的异动和事件，因此在故障巡检过程中很难定位到故障瓶颈。通过引入 Event，我们可以将依赖的所有产品的变更数据、异动数据和配置数据等结合起来，并与指标等进行联动。这种联动方式既包括专家经验，也包括 AI 的应用。

值得特别提及的是，在完成数据层后，我们能够提供标准化的服务能力，即以 API 的形式供阿里云 ECS 内部和外部集成使用。这种方式非常重要，因为仅有数据层是很难进行集成的，而 API 则是一种标准化的方式。

3.1.4.3 智能告警平台

file

传统的告警往往很简单，比如 CPU 占用率过高或可用率下降。然而，对于研发团队来说，这些告警并没有太大用处，只是让他们知道系统有问题，但并不清楚问题出在哪里或是什么问题。在阿里云 ECS 中，我们也遇到了很多类似的问题，收到了大量的告警，但是告警中的信息量少，无法帮助快速排查问题。这样的告警能力，显然无法支撑业务规模化后的观测需求。

因此，我们改变了思路，统一了告警平台，将所有平台的告警集中起来。之前提到的业务侧、平台侧、应用侧的告警也全部整合到一起。我们拥有自己的网关，通过对告警进行一系列的数据层和业务层处理，来解决诸如告警信息不足、告警关联度低和告警风暴等问题。

举个例子，如果单机发生异常，会直接导致上层 API 抖动，我们曾经遇到过这个问题。传统的告警只会告诉你 API 抖动了，然后可能一大堆告警全都爆出来，很容易引发告警风暴。然而，现在我们的告警能做到什么程度呢？我们可以知道有多少个告警正在发生，告警信息归属于哪个应用，链路信息如何，告警触发后的影响面是怎样的（可以判断告警的紧急程度）。只有当告警真正能够基于数据支撑给出结果时，我们才能更快速地定位问题。

例如，当计算出某个告警可能会引起 P1 事故或影响核心客户时，我们可以发出高优先级的告警。同时，会基于 Trace 和 Metric 来探测异常点，并通过事件中心进行关联，查看此时 ECS 和相关网络是否发生了变更。将这些信息串联起来进行预警诊断后，我们会告诉相关方，已经抑制了多少条预警，然后推送出一条预警，告知可能是哪个链路出了问题，影响了哪些方面，应该由谁来处理，故障等级是多少，以及应该采取什么样的 SOP 流程。这样就帮助业务解决了告警信息度、影响面判断和告警风暴等问题。

在日常操作中，一些抖动和告警是不可避免的，即使使用了强大的算法也无法完全解决这个问题。因此，在这种情况下，我们需要进行一些流程管理的工作。具体而言，我们会对整个告警流程进行管控和标准化，例如通过 Pipeline 和 SOP 来定义流程。根据前面技术层面的判断，我们会采取不同的流程。

举个例子，对于一些日常工单的告警，我们的响应时间可能被定义为 24 小时，在这个时间范围内进行处理即可。而对于一些紧急的告警，例如 P1 级别的告警，我们会通过不同的渠道进行响应，比如电话、短信等。根据告警的等级，我们会有不同的响应方式，并根据 SOP 进行自动化处理。

通常情况下，对于一个应用来说，每天的告警最好不要超过三个。如果超过了这个数量，就需要进行治理，否则运营性能会逐步变差。特别是电话告警，频次一定要控制得很低，只有在客户真正受到影响的情况下，我们才会通过电话告警。对于其他情况，我们会通过钉钉、短信等方式进行告警推送，而且短信的使用也非常有限，一天可能只有两三条。大部分情况下，我们会通过工单来处理告警。

总之，支撑阿里云 ECS 数千级监控的告警平台落地后，我们发现内部研发侧监控发现率有了显著提升。

3.1.4.4 智能告警样例

变更发布是导致故障的最主要因素之一。下面以去年一个应用变更的故障场景为例说明。通过智能告警平台，我们能够及时发现异常情况，触发相应的告警并提供相关信息，包括影响面计算、Trace 链路计算、运维操作和标准操作等。这些信息在应用发布期间会自动推送给发布负责人，以便快速响应和回滚。

这个功能是我们在去年版本的智能告警平台中实现的。而今年的新版本中，我们将进一步加强智能工程能力和自动化自愈的布局。

3.1.4.5 多场景观测大盘

相信有一定规模的企业一定都有自己的观测大盘，这里只分享阿里云 ECS 做观测大盘的两个核心。一个是开源，即把大盘迁移到 Grafana 上去。另一个是观测大盘需要分维度，例如全局观测大盘、重保大盘、应用观测大盘、业务观测大盘等。

3.2 SDLC：全生命周期可观测

在大多数公司中，可观测性通常用于解决稳定性领域的问题，即缩短故障发现时间（MTTR）。然而，我想和大家分享的观点是，可观测性应该贯穿整个软件生命周期，并且可观测性向左移将成为未来的趋势。 file

在软件设计阶段，可观测性可以帮助评估容量水位，特别是在需要对应用进行扩容等操作时。此外，在 CI/CD 阶段，可观测性几乎可以覆盖 90%的需求，对于实现研发质量控制和交付质量保障非常重要。此外，在 FinOps 中，可观测性在成本和安全方面也具有重要的应用，目前阿里云 ECS 正在积极探索这个方向。

通过全面应用可观测性，我们可以在整个软件生命周期中获得更好的掌控和洞察。这将有助于提高应用的稳定性、质量和安全性，以及降低成本和风险。因此，将可观测性作为一个关键的考虑因素，并将其融入到整个软件开发和运维过程中，是非常值得推崇的做法。

3.2.1 可观测性左移 – 故障预防

前面提到了可观测性需要更关注故障发生之前的预防。在故障领域中，变更和编码是导致故障的主要原因，因此我将重点围绕这两个方面来分享阿里云 ECS 的故障预防措施。 file

首先，在编码过程中，我们需要观测错误。我们采用了一种实践方法叫做 CAD（Code Analysis and Deployment），通过红绿看板持续观测每次推送和代码评审（CR）的情况，并监控构建成功率、测试覆盖率以及安全合规度等指标。我们还通过白盒扫描的方式观测代码情况，并在 Pipeline 中的 Code Check-in 设置卡点来进行监控。这些措施使得整体编码故障率显著下降。

在变更领域，阿里云 ECS 建立了一个发布观测平台，用于观测发布过程中的异常指标并发出告警。我们还初步实现了自动化的变更拦截机制。如果在发布过程中检测到异常指标，系统将阻止发布并自动回滚。除了发布变更，我们还对其他类型的变更（如数据库变更、配置变更等）进行观测，并通过元数据识别变更与异常指标的关联性。我们会自动推荐与变更相关的信息给开发人员，以帮助他们快速识别问题并进行回滚。这些实践在过去的历史中已经成功拦截了许多潜在故障。

以上是阿里云 ECS 在 CI/CD 阶段采取的观测模型来降低编码故障率和发布故障率的两个思路。通过这些措施，我们能够提前发现潜在的故障风险，并采取相应的预防和回滚措施，从而提高系统的稳定性和可靠性。

3.2.2 可观测性应用于 XOps

file

除了在 DevOps 领域中广泛应用的可观测性，还有许多其他领域也需要关注可观测性的应用。

在成本领域，我们需要观测业务机器资源的利用率和日志利用率等指标，以便进行成本优化和降低开销。通过监控资源利用率，我们可以及时发现资源浪费或过度使用的情况，并采取相应的措施进行优化。

在安全领域，我们需要观测代码、变更和机器资源的安全性。阿里云 ECS 正在与云安全团队合作，构建安全的观测能力。目前，我们已经在编码阶段实现了通过扫描和观测来识别代码库中存在的安全风险，并自动拦截不安全的代码合并。

另外，在 AIOps 领域，我们正在构建运维领域的知识图谱，并训练自己的模型，以实现根因定位和异常预测。可观测性在其中的价值主要体现在统一数据底座、数据洞察和运维生态打通等方面。通过建立完善的观测能力，我们可以更好地了解系统运行状态，及时发现异常情况，并采取相应的措施进行处理。

综上所述，可观测性不仅在 DevOps 领域中发挥重要作用，还在成本领域、安全领域和 AIOps 领域等方面具有广泛的应用前景。通过在这些领域中应用可观测性，我们能够提高业务的效率和安全性，并实现更好的运维管理。

3.3 Platform：观测平台化

我个人始终认为稳定性是一个平台化的事情，而观测作为稳定性的一个重要环节，也需要进行平台化的建设。 file

除了前面提到的数据底座，在数据丰富度、准确度和标准化方面，我们还将不断进行打磨。同时，我们还将建立自己的运维大脑，利用人工智能和算法能力进行异常预测和诊断。之前提到的告警降噪和故障预测也需要智能化的支持。

回到业务支撑本身，当业务规模增长、业务复杂度提高以及业务团队增多时，显然无法为每个业务配置一遍告警。而借助云上的统一平台，我们提供通用的平台能力，使各团队可以自行进行运维管控和编排。例如，通过编写一个 SQL，就能够生成一个 Metric，并通过平台能力将该 Metric 分发到多个地域，并针对不同地域进行差异化配置告警。此外，我们还可以通过给 Metric 打上标签的方式实现更高级别的功能，比如在异动场景下实现自愈能力。

当然，除了自建能力外，由于垂直领域的观测所需的专业度非常高，因此我们会借助第三方能力来实现这部分功能。这样可以更好地满足不同业务领域的观测需求。