一分钟精髓速览
互联网平台以业务为核心，以用户为核心，平台的性能服务、品质和用户体验等是要害的指标，仅仅关注后盾零碎的可用性是不够的，以传统运维的视角来解决故障、做监控会比拟被动。
本文以阿里云 ECS 业务为例，探讨阿里云最外围、亚太地区业务规模最大的产品之一，在极高的稳定性和性能要求下，如何基于云构建可观测性并从客户视角建设观测能力，以及在推动体系建设中的成功经验和待改良之处。
作者介绍
阿里云高级技术专家——杨泽强（竹涧）
TakinTalks 社区专家团成员，多年云计算畛域研发教训，在阿里先后参加团体 DevOps 平台、弹性计算外围管控以及 SRE 工程相干研发，以后在弹性计算团队从事研发工作，次要负责弹性计算稳定性架构与智能运维平台建设。
舒适揭示：本文约 8000 字，预计破费 15 分钟浏览。
「TakinTalks 微信公众号」后盾回复“交换”进入读者交换群；回复“可观测”获取相干材料；
背景
正如大家所知的，云服务器是云厂商中最底层、最简单的局部，而 ECS 弹性计算作为阿里云最外围、亚太地区业务规模最大的产品之一，其业务复杂度更是可见一斑——部署遍布国内海内的 30 多个地区，利用规模也达到了上百个，整体依赖复杂度能够说是阿里云云产品管控零碎之最。同时，还面临着团体超级客户（如淘天团体）、OnECS 云产品（如容器、存储、函数计算等）、各行业大客户的极高稳定性和性能诉求。
那么，如此超大业务规模和业务复杂度、极高稳定性 & 性能诉求，阿里云 ECS 是如何基于云构建可观测性的？以及阿里云 ECS 业务实际中，改善用户体验的可观测体系，是如何搭建起来的？这将是我本次分享的重点。
当然，在不同的业务和阶段，可观测性的做法可能不齐全一样。这次分享的次要目标是以阿里云 ECS 的业务为例，分享咱们在推动体系建设中的成功经验或者仍待改良的中央，以便大家在遇到相似问题时参考。
一、阿里云 ECS 业务带来了哪些观测挑战?
1.1 业务规模大导致经营难
建设可观测性并非最具挑战的局部，更具挑战的是如何继续经营和保护它。正如前文所述，随着零碎规模、团队规模和业务复杂性的增长，当零碎规模达到肯定水平时，保护变得异样艰难，甚至可能无奈持续保护上来，从而导致系统逐步腐化。这最终将影响研发体验和平台价值。
1.2 团队认知有余，观测能力缺失
很多人对于观测的了解仍停留在监控阶段，尤其是那些没有从事可靠性或运维工作的研发同学。在建设观测能力之初，咱们团队中的大部分成员都只具备研发背景，大家普遍认为观测就是监控和告警。因而，在初期的建设中，咱们的观测能力也较为单薄，次要限于监控性能。然而，事实上，监控只是可观测能力的一小部分。
1.3 技术储备有余
作为业务研发团队，咱们始终在摸索如何在业务团队外部构建可观测性以解决问题。然而，这面临着微小挑战，因为咱们须要在最大限度地解决问题的同时，也要思考业务团队的技术储备和老本因素。
二、可观测体系建设有哪些思路？
首先，团队提出了“Cloud First”的思路，即基于云产品构建可观测性。各个云平台上都提供相似的产品能力，而咱们的服务部署在阿里云上，因而抉择了阿里云的产品。上云的目标是为了利用云产品的能力来构建可观测性，而不是自行开发或应用其余开源 / 闭源外部产品。在接下来的局部，我将具体论述这一点。
其次，可观测性不仅仅限于经营阶段，咱们认为在软件生命周期的各个阶段都应思考可观测性问题。
第三，咱们采纳平台化和产品化的思路来解决可观测性问题。稳定性畛域的工作不是一次性地实现，而是须要通过平台化、自动化和智能化的形式来解决问题。咱们的整体稳定性均遵循这一思路，在可观测性方面也不例外。
三、阿里云 ECS 可观测体系是如何落地的？
3.1 基于云构建可观测能力
3.1.1 ECS 观测上云背景
2016 年前后：阿里云 ECS 将一些业务侧的根底监控搬到了阿里自研的平台上进行了欠缺。
2019 年前后：随着业务规模的不断扩大，阿里云 ECS 面临着 30 多个部署地区和上百个利用的大规模分布式集群的治理挑战，仅依附资源平台已无奈实现制订的指标。因而，咱们决定将整个监控都迁徙到云上。这一决策基于以下起因：首先，咱们须要治理数千个数据库以及数百个研发人员，单纯依附自研平台无奈满足需要。其次，借助云上的凋谢集成能力，咱们可能与业务需要相结合，实现更深层次的倒退。同时，基于公共云能力构建可观测性可能取得最优良的产品和能力，并且与开源社区人造地紧密结合，具备更强的迁徙能力。另外，将监控组件托管到云上，从业务角度来看，咱们不须要过多关注组件自身的稳定性问题，如 Prometheus 集群的保护、数据存储、无损扩容和迁徙等，因为云平台会帮忙咱们屏蔽这些问题。综合思考，将可观测性迁徙到云上的形式老本最低，因而从 2019 年开始，咱们进行了这一革新。
2021 年前后：通过采纳云原生的形式，咱们可能对大规模和高复杂度的业务进行数据加工和转化，并通过服务化和平台化的形式提供给更多的研发团队应用。云原生的革新是一个长期的过程，咱们心愿通过工程化的形式逐步推广和解决问题。目前，阿里云 ECS 的云原生革新已实现外围局部，但还有一部分工作尚未实现。
2023 年前后：除了云原生革新，咱们还在推动 AIOps 方向的演进以及 IDP（平台工程）的建设。外围指标是解决业务研发团队规模较大时，自行开发服务的老本高和外部卷的问题。通过建设外部平台，咱们能够帮忙研发团队疾速获取反馈，并将通用能力扩大到业务中，同时也促成外部平台的建设，将这些能力最大化地利用于业务中。
回过头看，2019 年将可观测性上云的抉择，我集体认为还是比拟正确的。
3.1.2 确定可观测性模型
在上云之前，咱们必须解决一些关键问题，例如咱们须要观测什么、如何将观测能力迁徙到云上以及哪些技术能够反对咱们等等。换言之，咱们须要确定如何实现云上的可观测性。为此，我提出了一个形象的五层观测模型。
在这个模型中，从最基层的资源和平台到利用和产品，咱们都须要关注观测的指标和要点，这是大家都能达成共识的。然而，我想重点解说一下最下面的「客户视角」，因为咱们的最终目标是服务客户。无论咱们自认为的 SLO 或 SLA 有多高，或者零碎稳定性有多好，如果客户认为咱们不稳固，那就必然存在问题。因而，在建设可观测性时，咱们须要从客户的视角来看问题。
举个例子，我曾负责的外围零碎呈现了一个问题。所有的指标都显示失常，然而用户反馈说他们的访问速度不断地变慢。这时候咱们该如何判断呢？难道要通知客户咱们的可观测性指标都失常，这是客户的问题吗？显然不可能。实际上，咱们须要站在客户的视角来看问题，这要求咱们的观测理念须要更高级，即关注客户的业务连续性。咱们的 SLO 不仅仅要关注平均水平，还要关注长尾状况。不仅要关注咱们软件的链路，还要关注客户端的 E2E 体验。比方，当一个客户调用咱们的服务时，可能会逾越多个地区，网络链路不稳固可能会导致速度变慢。此时，咱们须要进行拨测，从用户的视角来察看是否是因为网络连接或速率问题导致。
另外，咱们也遇到过这样的状况，即单个 API 看起来都没有问题，然而当多个 API 组合起来应用时就会呈现问题。对于这种状况，如果可能从用户故事的视角来观测，那就意味着咱们的观测体系曾经十分欠缺，能够说是靠近完满了。然而，坦率来说，咱们目前还没有达到这种水平，因为这样的观测体系须要十分高的投入，咱们还在进一步加深这方面的工作。
因而，我想强调客户视角的重要性，尤其对于像咱们这样的 To B 业务来说，更须要关注客户视角。这样的做法会带来微小的价值。
3.1.3 依据模型抉择产品能力
在确定观测模型后，接下来就是思考如何将其落地，即应用哪些云产品来构建观测体系。各个云厂商和开源社区都提供了相应的能力。咱们的实际是基于阿里云来实现的，所以这里就以阿里云的云上能力为例来介绍。
首先是资源监测，咱们应用了阿里云的云监控来关注机器的指标。它对业务的侵入比拟小，一个 Agent 采集多个指标，整体开销也比拟小。
另外，可观测性还波及日志、指标和链路追踪的观测。咱们应用了阿里云的日志服务（SLS）来解决日志相干的工作。当然，也能够抉择 ELK 技术栈、AWS 的 CloudWatch、腾讯云的日志服务等产品来实现雷同的性能。
链路追踪方面，咱们抉择了 ARMS 来监控利用链路上的指标。ARMS 采纳无侵入的形式，可能采集云原生指标和辨认中间件流量，并且能够基于这些指标定义业务异样。当然，在选型时，除了开源产品如 SkyWalking 外，商业化产品也有其余抉择，比方 AWS 的 Insight 和腾讯云的 APM 工具。
总而言之，这些都是阿里云提供的云上能力，但其余云厂商和开源社区也提供了相似的产品和解决方案，能够依据理论需要抉择适宜本人的工具和技术。
3.1.4 云原生可观测计划
构建观测体系离不开三板斧：日志（Log）、追踪（Trace）、指标（Metric）。在这个根底上，我还补充了事件（Event）和告警（Alert）两个局部。之所以退出这两个方面，是因为它们与观测性密切相关，前面我会具体阐明。整个观测体系计划大抵如下图。
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 观测数据底座
数据底座在可观测性方面十分重要，我这里能够深刻一些分享。服务层蕴含了本身业务的 CMDB 数据，以及来自 Prometheus、SLS、DAS 和 ARMS 等平台的业务数据。这些数据在进入数据中心后，将造成一个五层观测模型。然而，仅仅依附这些档次的数据模型对于业务团队来说还不足够。因而，咱们还须要利用一些业务知识，例如业务知识图谱、故障知识库、阿里云 ECS 反对的畛域常识以及非敏感用户数据等。
这里重点介绍一下 Event。实际上，Event 是 ” 三板斧 ” 的补充。在宏大的集群中，会呈现各种各样的异动和事件，因而在故障巡检过程中很难定位到故障瓶颈。通过引入 Event，咱们能够将依赖的所有产品的变更数据、异动数据和配置数据等联合起来，并与指标等进行联动。这种联动形式既包含专家教训，也包含 AI 的利用。
值得特地提及的是，在实现数据层后，咱们可能提供标准化的服务能力，即以 API 的模式供阿里云 ECS 外部和内部集成应用。这种形式十分重要，因为仅有数据层是很难进行集成的，而 API 则是一种标准化的形式。
3.1.4.3 智能告警平台
传统的告警往往很简略，比方 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）。然而，我想和大家分享的观点是，可观测性应该贯通整个软件生命周期，并且可观测性向左移将成为将来的趋势。
在软件设计阶段，可观测性能够帮忙评估容量水位，特地是在须要对利用进行扩容等操作时。此外，在 CI/CD 阶段，可观测性简直能够笼罩 90% 的需要，对于实现研发品质管制和交付品质保障十分重要。此外，在 FinOps 中，可观测性在老本和平安方面也具备重要的利用，目前阿里云 ECS 正在积极探索这个方向。
通过全面利用可观测性，咱们能够在整个软件生命周期中取得更好的掌控和洞察。这将有助于进步利用的稳定性、品质和安全性，以及降低成本和危险。因而，将可观测性作为一个要害的思考因素，并将其融入到整个软件开发和运维过程中，是十分值得推崇的做法。
3.2.1 可观测性左移 – 故障预防
后面提到了可观测性须要更关注故障产生之前的预防。在故障畛域中，变更和编码是导致故障的次要起因，因而我将重点围绕这两个方面来分享阿里云 ECS 的故障预防措施。
首先，在编码过程中，咱们须要观测谬误。咱们采纳了一种实际办法叫做 CAD（Code Analysis and Deployment），通过红绿看板继续观测每次推送和代码评审（CR）的状况，并监控构建成功率、测试覆盖率以及平安合规度等指标。咱们还通过白盒扫描的形式观测代码状况，并在 Pipeline 中的 Code Check-in 设置卡点来进行监控。这些措施使得整体编码故障率显著降落。
在变更畛域，阿里云 ECS 建设了一个公布观测平台，用于观测公布过程中的异样指标并收回告警。咱们还初步实现了自动化的变更拦挡机制。如果在公布过程中检测到异样指标，零碎将阻止公布并主动回滚。除了公布变更，咱们还对其余类型的变更（如数据库变更、配置变更等）进行观测，并通过元数据辨认变更与异样指标的关联性。咱们会主动举荐与变更相干的信息给开发人员，以帮忙他们疾速辨认问题并进行回滚。这些实际在过来的历史中曾经胜利拦挡了许多潜在故障。
以上是阿里云 ECS 在 CI/CD 阶段采取的观测模型来升高编码故障率和公布故障率的两个思路。通过这些措施，咱们可能提前发现潜在的故障危险，并采取相应的预防和回滚措施，从而进步零碎的稳定性和可靠性。
3.2.2 可观测性利用于 XOps
除了在 DevOps 畛域中广泛应用的可观测性，还有许多其余畛域也须要关注可观测性的利用。
在老本畛域，咱们须要观测业务机器资源的利用率和日志利用率等指标，以便进行老本优化和升高开销。通过监控资源利用率，咱们能够及时发现资源节约或适度应用的状况，并采取相应的措施进行优化。
在平安畛域，咱们须要观测代码、变更和机器资源的安全性。阿里云 ECS 正在与云平安团队单干，构建平安的观测能力。目前，咱们曾经在编码阶段实现了通过扫描和观测来辨认代码库中存在的平安危险，并主动拦挡不平安的代码合并。
另外，在 AIOps 畛域，咱们正在构建运维畛域的常识图谱，并训练本人的模型，以实现根因定位和异样预测。可观测性在其中的价值次要体现在对立数据底座、数据洞察和运维生态买通等方面。通过建设欠缺的观测能力，咱们能够更好地理解零碎运行状态，及时发现异常情况，并采取相应的措施进行解决。
综上所述，可观测性不仅在 DevOps 畛域中施展重要作用，还在老本畛域、平安畛域和 AIOps 畛域等方面具备宽泛的利用前景。通过在这些畛域中利用可观测性，咱们可能进步业务的效率和安全性，并实现更好的运维治理。
3.3 Platform：观测平台化
我集体始终认为稳定性是一个平台化的事件，而观测作为稳定性的一个重要环节，也须要进行平台化的建设。
除了后面提到的数据底座，在数据丰盛度、准确度和标准化方面，咱们还将一直进行打磨。同时，咱们还将建设本人的运维大脑，利用人工智能和算法能力进行异样预测和诊断。之前提到的告警降噪和故障预测也须要智能化的反对。
回到业务撑持自身，当业务规模增长、业务复杂度进步以及业务团队增多时，显然无奈为每个业务配置一遍告警。而借助云上的对立平台，咱们提供通用的平台能力，使各团队能够自行进行运维管控和编排。例如，通过编写一个 SQL，就可能生成一个 Metric，并通过平台能力将该 Metric 散发到多个地区，并针对不同地区进行差异化配置告警。此外，咱们还能够通过给 Metric 打上标签的形式实现更高级别的性能，比方在异动场景下实现自愈能力。
当然，除了自建能力外，因为垂直畛域的观测所需的业余度十分高，因而咱们会借助第三方能力来实现这部分性能。这样能够更好地满足不同业务畛域的观测需要。
四、总结和瞻望
4.1 总结
4.2 集体瞻望
从业务视角来看，我认为标准化是一个重要的趋势。这种标准化不仅仅指某家厂商的规范，而是整个生态的标准化，防止反复造轮子。另外，之前提到的五层模型其实实用于每个畛域，都是互通互联的，只是不同的行业和应用领域会有一些差别。
面临大规模的业务问题时，智能化和平台化的思路是十分必要的。咱们须要采纳自助式的形式来解决问题，而不是像保姆式一样仅依赖于人力。通过智能化和平台化的伎俩，咱们能够更好地应答简单的业务场景，进步工作效率，同时也能够更好地实现业务的可观测性。（全文完）
！！重要告诉！！
TakinTalks 社区第二本印刷物《SRE 可靠性体系建设实战笔记》已正式启动，现公开征集共创作者，一起布道 SRE！
招募对象：运维负责人、SRE 负责人、架构师等稳定性相干职位，团队负责人 / 总监级以上
第一期参考：10 万字干货：《数字业务连续性晋升最佳实际》收费支付|TakinTalks 社区
若您无意成为本书作者之一，请您与咱们分割，获取本书目录。
更多具体内容，欢送点击“浏览全文”，观看完整版视频！
申明：本文由公众号「TakinTalks 稳定性社区」联结社区专家独特原创撰写，如需转载，请后盾回复“转载”取得受权。
本文由博客一文多发平台 OpenWrite 公布！