AI 原生时代的可观测性——ACME 金融服务：AIOps 实施实践

既然我们已经讲过了一些基础内容，接下来我们将通过一家虚构公司的实际运作，来看看如何应用其中的一些概念。这家公司在完成云迁移之后，当前的可观测性实践开始暴露出问题。它是一家大型组织，业务覆盖多个市场，其中有些市场受到高度监管。这家公司的复杂性、所处监管环境，以及它在可观测性方面遇到的问题，都很好地凸显了我们到目前为止讨论过的概念，并且这些概念将被应用到一个具体的业务案例中。我们将讨论该公司当前面临的问题、它是如何发现这些问题的根因的、它如何找到解决方案并加以落地，以及这些改变最终为它带来了哪些收益。

本章将涵盖以下内容：

• 什么是 ACME Financial Services？
• 在企业范围内实施可观测性的挑战
• 通过 AIOps 自动化事故响应
• 识别并衡量结果

技术要求

本章没有技术要求。

我们的虚构公司

下面介绍 ACME Financial Services——一家虚构公司，我们将用它把本书中的概念应用到真实世界场景中。ACME Financial Services 是一家大型金融机构，在多个行业提供服务，包括个人投资与储蓄、雇主提供的退休计划管理、企业投资以及保险。凭借这样多样化的产品组合，该公司在不同业务领域运行着数百个相互独立、但彼此交互以提供客户服务的应用。

身处金融服务行业，意味着 ACME Financial Services 非常重视自身声誉，并且会极其严肃地对待任何可能损害公司声誉的事情。毕竟，谁会愿意把自己的毕生积蓄，或者自己的企业，托付给一家在安全性、可靠性或客户服务方面声誉不佳的公司呢？

然而，声誉并不是 ACME Financial Services 唯一关心的事情。该公司提供的很多服务都处在高度受监管的行业中。要满足一项监管要求，远不只是落实若干控制措施或流程来确保合规这么简单。公司还必须就与该项监管相关的政策和流程形成完善文档，以便能够向监管机构证明：公司不仅在合规，而且在持续、主动地确保合规。如果未能满足某项监管要求，而监管机构又进一步认定公司的文化、政策或流程不足以维持合规，那问题就会更加严重。如果你是大学体育赛事的粉丝，可能会熟悉类似的情形：某所学校可能因为未能建立足够的控制机制来满足某项规定，而遭受经济处罚、失去奖学金名额，甚至有人因此丢掉工作。这意味着，某种公开失败不仅会损害 ACME Financial Services 的声誉，还可能带来巨额经济处罚、诉讼，甚至有人失去工作。

伟大的云迁移之后

ACME Financial Services 刚刚完成其向云端迁移的旅程。由于公司服务的市场种类繁多、数据量巨大，以及公司内部对于如何最佳确保监管合规所做出的决策，它最终形成了一个混合环境。前端应用被重新架构，以全面拥抱云原生设计原则，并全部迁移到了云服务提供商上的 Kubernetes 集群中运行。然而，并不是所有后端系统或应用数据都能迁移到云上。尽管公司很希望把一切都迁到云端，但最后认定这在多个方面都不现实。有些情况下，云服务商没有合适的产品可供使用；另一些情况下，需要迁移的数据量过于庞大，难以在云上承载；最后，一些市场中的监管规定也阻止了这些工作在云端进行。

最终结果，是新旧设计原则并存。迁移到云上的应用按照云原生设计原则进行了重构。他们把单体应用改造成了数百甚至上千个微服务。除此之外，ACME Financial Services 还通过在多个区域、多个 Kubernetes 集群中运行这些应用，提高了系统韧性。除了韧性提升之外，他们也获得了更好的扩展性，因为他们对微服务进行了恰当设计，使其在需要时能够进行水平扩展。公司也已经认识到，在大多数情况下，增加 Pod 数量，也就是进行水平扩展，所带来的效果优于他们过去的做法——即通过增加单个应用可用资源来进行垂直扩展。一些云原生应用还必须与本地部署的旧单体应用通信。然而，在规划云迁移时，他们并没有意识到云原生架构与混合云环境会对其可观测性实践产生什么影响，因此，他们并没有对原本用于本地单体应用的可观测性实践作出任何改变。结果就是：尽管系统韧性和可靠性得到了提升，但事故处理时长却增加了，而且越来越多的事故是由客户先发现的。

旧有的可观测性实践对于运行在本地的单体应用来说是有效的。举个例子，在迁移之前，某个单一产品的服务大概是这样的：

应用数量	数据中心数量	应用总数
10	1	10

表 4.1 —— 本地环境中的可观测性复杂度

然而，当这个服务按照云原生原则重构并迁移上云之后，它变得更像下面这样：

Pod 数量	云区域数量	Pod 总数
200	3	600

表 4.2 —— 云环境中的可观测性复杂度

在这个例子中，ACME Financial Services 某一块服务领域，已经从一个数据中心中的 10 个单体应用，演变成了分布在 3 个不同云区域中的 600 多个 Pod。当它们迁移到云上时，所有服务都经历了类似的增长比例，有些甚至更大，这导致公司如今需要管理和监控的组件数量，是所有应用还运行在本地时的 80 倍。

除了组件数量增加之外，在像下面这样运行于混合模式的应用中，他们还面临额外复杂性：

图 4.1 —— 混合网络环境

在迁移之前，所有网络与安全问题都由本地环境负责处理；但在混合环境下，他们现在还必须担心本地组件与云端部署组件之间的网络配置、安全性、吞吐量和时延。吞吐量尤其具有挑战性，因为他们不仅要管理应用或组件之间的流量，还必须考虑发送到可观测性工具中的可观测性数据流量。他们当前的监控能力根本无法很好地处理这种混合部署。

ACME Financial Services 当前的可观测性现状

ACME Financial Services 在事故管理上采用的是一种非常依赖人工的方式。他们有一个运维团队，负责接收并处理公司所服务的多个市场中所有应用产生的事件。他们还会监控社交媒体，以发现用户可能正在经历问题的迹象。这个运维团队了解公司所提供的各类业务功能，但对各个应用之间相互连接的复杂性只有较浅的理解。由于该团队成员并不是软件开发者，因此当他们需要应用团队介入时，会去查找公司内部各个应用的联系人信息。然而，因为他们对应用之间如何相互连接的理解有限，所以这个运维团队在事故管理上采取的是一种“广撒网”式的方法。他们会为某个事故建立实时沟通机制，把他们觉得可能提供信息、或者可能受到影响的尽可能多的应用团队都拉进来，然后一路推动事故直到结束。这导致许多应用团队的联络人被无谓地卷入那些实际上与他们无关的事故中，而某个应用团队若想被认定“不需要参与这次事故”，唯一的办法就是证明自己的应用没有参与当前事故。其结果是，大量应用团队都要为事故相关工作付出代价：要么因为他们确实参与其中而直接投入排障工作，要么为了证明自己并未参与、好被排除在事故之外。即便有这个专门的运维团队，有些事故依然只有在用户直接向公司投诉，或者在社交媒体上抱怨时，才会被发现。

他们的可观测性实践是如何变得不可管理的

当一切都运行在本地、并且处理都封装在单体应用中时，ACME Financial Services 的可观测性实践是足够用的。但一旦服务迁移到云上，公司就注意到事故响应与解决时间都在恶化。于是，他们组织了一个团队来研究这为什么会发生，以及它带来了什么影响，最终得出了如下结论：

告警数量增加

该团队首先得出的结论之一是：与云迁移之前相比，现在产生了大量更多的指标数据，而这直接导致了显著更多的告警。进一步深入后，团队发现这主要由以下几个原因导致：

运行中的服务更多了

当应用团队把单体应用拆分成微服务时，他们通常会把原先为单体应用配置的告警规则，复制到每一个执行具体任务的微服务上。这导致在类似情形下会生成更多告警。例如，如果原来有一个用于检测可疑流量突发、以识别可能 DDoS 攻击的告警，在迁云前它只会由一个单体应用触发；而现在，它会由承担同样功能的 100 个微服务中的每一个分别触发。

静态告警

他们原来的扩展策略依赖于监控应用消耗的资源，并在达到某些水位线（例如高 CPU 或高内存）时生成告警，然后由运维团队评估应用是否需要扩容。如今，当一个单体应用被多个微服务替代之后，这套同样的策略已经变得无法管理。基础设施团队一直在努力改善这种状况，他们已经通过使用云服务商提供的自动扩缩容能力，以及调整告警级别来进行改进。虽然这确实改善了一些情况，但由静态定义产生的告警数量仍然远高于云迁移之前。

可追踪性丢失

当应用运行在本地时，它们是单体的，并且通常被隔离在单一任务之中。而现在，应用经过面向云的重构后，一个单独的应用可能由多个微服务组成，而且这些微服务中的某些还会运行多个实例以提供冗余或扩展能力。在他们的微服务架构中，还创建了跨多个应用共享的服务，这让人很难判断：一个共享服务出问题时，究竟哪些应用会受到风险影响。这给从告警或事故反向追踪其影响范围带来了问题，因为通信关系图变得复杂得多。

告警疲劳

由于告警更多了，响应团队更难判断哪些告警需要响应，哪些只是噪声。告警数量的增加不仅导致了告警疲劳，也导致响应团队成员出现倦怠。响应团队在处理事故时变得更低效，也更慢。

更多事故由用户发现

团队还发现，有更多事故从系统中“漏”了出去，只有在用户投诉时才被发现。这看起来并没有一个单一明确的根因，团队认为这很可能是他们前面发现的其他问题的综合结果。然而，由于越来越多问题是用户先报告的，公司声誉正在受到打击。高层管理甚至要求创建新的指标来跟踪事故最初是如何被发现的，而这无疑让现有监控系统显得非常尴尬。

缺乏归属关系

这并不是说应用在没有开发团队负责的情况下运行。这里的意思是：当事故发生、响应团队定位到出问题的应用，甚至定位到出问题的 Pod 时，他们却不知道该联系哪个应用团队来协助缓解问题。虽然这长期以来一直就是如此，但云迁移和对云原生设计原则的拥抱，使这个问题被进一步放大。现在，一个应用由更多组成部分构成，而谁负责什么并不清晰。

运维成本的爆炸式增长

除了用户体验下降及其对 ACME Financial Services 声誉带来的负面影响之外，公司的运维成本也显著上升。ACME Financial Services 过去的运维预算与竞争对手大致相当，但在云迁移之后，成本不断上升，现在它在运维上的支出已经高于竞争对手。更糟糕的是，增加的运维成本还在影响公司的其他领域。运维成本的增加正在挤压新功能开发以及其他对公司保持竞争力至关重要领域的资金。ACME Financial Services 的高层已经向全公司明确传达：运维成本持续上升的趋势必须被扭转，成本必须重新回落到与竞争对手持平的水平。

那监管怎么办？

作为一家金融行业公司，ACME Financial Services 必须遵守大量监管要求。他们不仅要担心保护客户隐私和金融信息，还必须遵守金融行业特有的法规，例如检测和防范欺诈交易，以及检测和报告可疑活动。

遵守这类监管要求，远不像某些其他类型的合规要求那样直观和清晰。公司必须能够检测可疑活动，并且要么阻止它，要么向政府监管机构报告。例如，如果某个账户在短时间内发起了数百笔小额交易，那就可能是可疑的，特别是如果这个账户此前并没有这类交易历史。有时，一笔交易表面上看完全正常，只不过它发起自某个外国，而政府已经规定该国家不允许与本国金融服务机构发生交易。然而，仅仅因为某个国家的政府与监管 ACME Financial Services 的国家存在冲突，也并不意味着公司就可以一刀切地拒绝来自该国的交易。该笔交易完全可能是由 ACME Financial Services 的客户发起的，因此不太可能是敌对政府的行为。事情很快就会变得非常复杂。如果你曾经去过国外旅行，并在进行看似简单的金融交易时遭遇问题，那么这种关于监管合规的顾虑，很可能正是原因之一。

当然，防止欺诈交易并不仅仅是为了满足监管。如今，大多数——如果不是全部——金融服务机构都制定了保护客户免受欺诈侵害的政策。这不仅有助于增强客户信任，同时也是一种成本节约措施。若资金被欺诈性地盗走，金融机构可能会赔偿客户，但没有人会来赔偿公司本身。这笔钱最终来自公司的收入。

为了应对这类情况，ACME Financial Services 已经开发了许多系统，以满足与可疑活动相关的监管要求。公司面临的问题在于：欺诈手段的演化从未停止。他们可以开发某种工具去检测特定模式，但一旦这套工具上线并成功阻止了这种模式的欺诈，犯罪分子就会开始设计下一个新模式。当犯罪分子开始使用新的欺诈模式时，ACME Financial Services 就必须做到以下几点：

• 检测新的欺诈模式：这取决于具体模式、涉及金额大小，以及现有检测系统是否会给出某种线索。检测这类欺诈可能几乎是瞬时的，也可能需要几天。
• 分析欺诈模式：发现出了问题只是第一步。一旦知道有问题，他们接下来还得诊断哪些系统被利用了、利用方式是什么，以便设计对策。
• 阻止欺诈：他们必须实施某种措施，以阻止当前和今后的类似尝试。具体需要多久，取决于手法复杂度；如果涉及多个应用或多个服务行业，开发和测试可能尤其耗时。

在公司诊断新型欺诈活动的这段时间里，他们正在持续亏钱。犯罪分子正利用 ACME Financial Services 的弱点，在对策上线之前尽可能多地攫取资金。根据整个流程耗时——无论是欺诈模式的检测，还是 ACME Financial Services 对策的实施——都可能轻易造成数百万甚至数亿美元的损失。他们甚至还面临一些非金融类欺诈问题，涉及云服务提供商的资源：攻击者试图攻陷系统，并利用这些资源进行诸如加密货币挖矿之类的活动。

由于欺诈带来的巨额损失，以及监管不合规的危险，监管合规为何对 ACME Financial Services 至关重要，也就不难理解了。这不仅仅是为了避免政府监管机构的处罚；更是为了降低公司的成本，并维持客户信任。

受控部署

除了推进云迁移之外，ACME Financial Services 还一直在努力提升其开发速度。推出新功能、改善用户体验以及修复缺陷，都是赢得和留住客户的重要方式。然而，由于前面提到的种种顾虑，例如监管合规与声誉风险，这件事绝不只是简单调整一下应用开发团队流程就能实现的。

旧的部署流程

在应用开发团队采用更迭代式的方法之前，他们通常会先开发功能，然后把这些功能打包在一起，作为一个新的应用版本发布。不过，他们并不能在一天中的任意时刻部署这个新版本。股市交易时段中打断重要业务的风险实在太高了，因此，ACME Financial Services 建立了一套相当繁琐的部署流程：

• 应用部署只能在非工作时间进行，除非存在必须修复的关键缺陷。
• 开发团队必须制定部署计划，其中包括要部署什么、预计部署需要多长时间，以及如何保证功能正确。
• 部署计划必须由其业务单元的一位领导签字批准。
• 一个应用版本要想获得部署资格，必须先通过质量检查。

通常，新版本大约每个业务季度部署一次。虽然部署流程相当繁重，但一年也就执行几次。然而，随着他们转向更快速、更加迭代的开发方式，部署次数大幅增加，这套部署流程就逐渐成了阻碍。更糟糕的是，应用团队往往直到部署计划流程已经推进到很后面，才发现部署上的问题。

从持续交付到持续事故

ACME Financial Services 已经通过寻找部署审批自动化方式，以及把部署问题的发现前移，解决了其中一部分问题。例如，他们已经实现了标准的 CI/CD 实践，把新构建部署到非生产 Kubernetes 集群，并且开发了一套内部工具，可以根据应用测试覆盖率和测试自动化程度，支持更高水平的部署自动化。这减轻了新版本部署的负担，有些应用甚至已经实现了最高级别的部署自动化——一旦非生产环境验证通过，就会自动部署到生产环境。然而，现在应用部署更多了，自然也带来了更多事故。这并不是因为质量下降了，而只是因为应用的复杂度增长得更快，而复杂度的增加会带来更多事故。随着一套规模庞大且复杂的应用群不断演进，且一些新功能需要跨多个应用协同变更，事故响应团队正在被淹没在一片“变化的海洋”之中。

新功能增加带来的压力

随着他们推出的新功能数量增加，他们对这些新功能究竟被使用得如何、甚至是否被用户喜欢的理解，反而在减弱。他们依然会把重大变更或新功能放在配置开关后面发布，但现在受这些配置开关控制的变更数量已经显著增加。因此，无论是事故团队，还是应用开发团队，都很难知道在 ACME Financial Services 那套复杂应用系统里，某一时刻究竟有哪些功能正在被实际使用。正如你所预料的，这已经导致了内部摩擦：大家努力试图弄清楚某项功能是否被使用、用户是否喜欢它，以及它究竟应该继续开发还是被移除。

技术栈

在云迁移过程中，ACME Financial Services 也整合并调整了自己的可观测性技术栈。在迁移之前，他们的可观测性栈由一些自研方案和一些专有方案组成。出于各种原因，他们没能彻底摆脱所有专有方案，但只要有可能，他们都会朝着开放标准的方向迁移。这也让他们在云迁移过程中拥有了更大的工具选择空间。

使用云服务商的一大好处，是它们通常会提供大量托管服务。不仅为 Kubernetes 集群提供自动化和管理工具，还通常至少会提供一些监控工具。对于 ACME Financial Services 而言，他们的云服务商提供托管式可观测性工具，而这正是公司为其新可观测性技术栈所选择的路径。

他们的云服务商以合理价格提供托管版 Prometheus 和 Grafana。ACME Financial Services 认定，使用这些工具比自己运行同类工具更具成本效益。这个迁移本身就是一个项目，因为不仅应用开发团队必须改变生成可观测性信息的方式，所有人还都必须接受如何使用这些新工具的培训。这里说的“所有人”，不仅包括应用开发团队，还包括事故响应团队、管理者和业务负责人。整个过程是一项相当大的工程。

在日志方面，他们从一个本地方案迁移到了云端方案。即便是本地部署的应用，也会把日志发送到云端日志采集器中。不过，这个云端日志采集器不只是存储日志，它还支持基于日志创建仪表板和告警。这一开始看起来是个很棒的主意，但很快，这个方案的一些缺陷就暴露出来了。允许应用团队基于日志自行创建告警这一做法，带来了几个意想不到的问题：

• 告警有延迟：日志采集服务需要时间去消费和处理日志。这导致告警通常在问题发生 15 分钟甚至更久之后才出现。对某些用例来说，这不算问题；但对另一些用例而言，这意味着客户受影响的时间会更长。
• 由应用团队负责创建告警：出于多种原因，这导致这些告警成了告警疲劳的重要来源。

在一片选项海洋中决定先改进什么

ACME Financial Services 面前有很多问题要解决，而且都不是小问题。公司不可能一下子解决所有问题，尽管他们很想这样做，因此他们必须先给不同领域排出优先级。

在高层“必须降低成本”的指示下，项目负责人定期开会讨论、辩论，甚至争论到底应该先解决什么。他们决定先建立一个决策框架来指导这件事。

决策的第一个、也是最重要的因素，是某项变更能够在多大程度上降低成本，以及它通过什么方式降低成本。为此，他们决定先从当前工具和流程中最大的缺口入手。一旦识别出这些缺口，他们就需要确定：每个缺口在多大程度上导致了运营支出上升。有了这些数据之后，他们就能进一步研究各种解决方案，并比较不同方案能降低多少成本。在选定解决方案之后，他们还必须决定先做哪些改进、后做哪些改进。很可能他们既做不到、也不会被允许在第一轮迭代里把所有事情都做完。有些改进可能需要引入新工具，而这又可能意味着漫长的供应商评估和入场流程。当然，在推进这些降低运营成本的改进时，应用开发团队仍然需要持续交付新功能和缺陷修复。尽管高层已经明确要求控制成本，但要让任何改进真正成功，仍然必须把这些部分全部协调起来。这绝非易事。

着手解决这些问题

首先，团队按规模和复杂度对问题进行了划分。他们认为最简单、也是最容易先拿下的“低垂果实”，是归属关系缺失的问题。公司内部所有部署机制都支持某种形式的元数据，因此他们判断：为每个部署单元补充由哪个团队负责的信息，应当是相对容易的。然后，他们可以在部署审批流程中增加相应步骤，并辅以培训，以确保今后所有新部署都必须提供这些元数据。看起来这件事既不需要大量工作，也不会对应用时间线造成太大扰动，同时又会带来显著改进。只要所有部署都包含各部分的归属元数据，运维团队在事故中就会清楚该拉哪些团队参与。这也会在一定程度上帮助缓解告警疲劳问题，因为它能够帮助确保：只有真正和事故相关的应用团队，才会进入事故处理流程。

他们还认为，更多问题被用户先发现，很可能是前述其他问题的症状。目前来看，并没有一组非常明确、且会直接影响这一问题的行动，因此他们决定暂时把这个问题放一放，先观察其他改进会怎样影响它。

被认定为“中等投入”的问题

下一组问题被认定为需要中等投入，而且会对应用团队的交付节奏带来一定影响。其中第一个就是公司范围内缺乏可追踪性。不仅在单一业务市场中的多个应用之间，很难追踪一个问题；一旦牵涉到多个业务市场的应用，几乎就不可能追踪清楚了。然而，工作组现有知识并没有明显可行的解决方案，因此还需要继续调研行业方案，甚至可能需要进行工具评估。

着眼于辅助欺诈防范

尽管这并不直接属于可观测性工作的范畴，但工作组开始思考：他们正在研究的某些改进，是否也能够帮助欺诈检测。他们认为，如果后续确实要评估新工具，那么值得把“是否有助于欺诈防范”也加入评估标准。如果能够找到一套既能提升可观测性、又能帮助防欺诈的工具，那对公司来说将是双赢，也会让任何许可证成本更容易说服高层接受。

跟踪功能使用情况

这一中等优先级改进中的最后一个问题，是关于应用功能使用情况的。毫无疑问，这也是推动运营成本上升的因素之一。应用团队被要求不断增加功能，但任何东西都不是没有成本的。随着应用不断添加功能，复杂度也在增加，而复杂度的增加会带来大量意外交互，从而导致用户体验不佳，甚至在某些情况下引发服务中断。因此，找到一种方法来确定哪些功能正在被使用、使用得有多少，似乎是一项非常值得推进的工作。这些数据不仅能帮助做规划，还可能促成对无人使用功能的下线，从而降低应用复杂度。围绕生成这些数据的想法看起来也相当简单：围绕每个功能加上指标，然后基于这些使用数据创建新的报表。他们也认为，可能还需要一些培训。虽然概念看起来很简单，但他们仍需要研究：究竟想收集哪些数据，以及如何设计一套方案，使其能够跨众多应用团队实施。

处理告警疲劳的计划

他们识别出的最后一个、也是最大的议题，是支持团队已经深受其害的告警疲劳。大家把它视为一个非常大的问题，而且它的根源部分来自前面发现的那些较小问题。然而，仅仅解决那些问题，还不足以在有意义的程度上改善这一问题。

他们过去使用的静态告警，正在压垮他们的告警处理流程。团队认定，仅这一项就需要采取多项改进行动。一个思路是逐步摆脱静态告警。这是个很直观的想法，但他们并不确定应当转向什么。他们知道，这将是一项大工程，并且需要大量培训和标准化工作，才能真正成功。

即便从静态告警转向别的方式可以带来一些改进，系统中组件数量增加的问题依旧存在。工作组还不知道该怎么解决这一点，而且他们现有工具也没有提供任何选项。因此，他们得出结论：必须研究额外的工具，看看是否有办法帮助他们应对这场告警洪流。

处理这一问题的另一个方向，是评估当前日志服务用于告警的方式。为什么它会产生这么多告警？是培训问题，还是别的原因？15 分钟的告警延迟是否是个可以改进的问题？它有必要被改进吗？这部分工作与其说是实施，不如说更多是探索与数据收集。潜在解决方案似乎也与他们已经计划要处理的其他问题相互呼应。

最后，他们还必须确保生成出来的告警是可执行的，并且能提供有用信息。这与“归属关系”问题紧密相关：不仅要确保告警中包含生成它的应用元数据，还应包含可能导致问题的原因信息，例如 runbook，或者最近一次部署中变更内容的部署数据。仅仅减少告警数量是不够的；他们还必须让告警变得更有用。

这是一大摊工作。更重要的是，工作组对其中一些问题还并不知道答案。他们已经有了方向和计划，现在就必须开始调查。

新工具，新可能性

项目负责人已经梳理出了需要调查的方向，以及需要开发的解决方案，但接下来该做什么？抽象地谈论解决方案是一回事，真正把它们找出来并落地则完全是另一回事。他们有一点是确定的：现有工具已经不足以满足他们当前的需求，更不用说那些新的设想了。

项目负责人决定从工具入手。他们知道自己很可能需要新工具——不论是替换现有工具中的一些，还是增强现有工具提供的能力。他们制作了一张能力矩阵，用来突出展示当前工具具备哪些功能，以及这些功能在多大程度上满足了当前和未来的需求。他们还把缺失的功能加入进去，包括可追踪性、告警管理和欺诈检测等内容。他们的简化矩阵如下：

应用	指标	告警	仪表板/可视化	可追踪性	欺诈检测	告警管理
Prometheus	Y	Y	N	N	N	N
Grafana	Y	N	Y	N	N	N

表 4.3 —— 能力矩阵

像很多公司一样，ACME Financial Services 的做法一直是先选定可观测性工具，然后再去实施它们。一旦工具跑起来了，他们就不会持续关注可观测性工具本身的演进，因此他们并不了解那些利用 AI 和机器学习的新工具，正在如何改变常见的可观测性实践。

某种程度上，ACME Financial Services 还算幸运，因为他们遇到的问题并不是独一无二的。团队发现，自从他们上一次认真评估可选方案以来，可观测性工具已经发生了显著演进。很多工具已经融入了 AI 和机器学习能力，这使得应对他们当前所面对的问题变得更容易。在 ACME Financial Services，获批引入一款新工具并不是件简单的事，通常必须是当前工具能力存在明确缺口，并且能够带来显著成本节省，才有机会获批。团队最终认为，他们面临的可观测性挑战已经严重到足以“闯关”去争取新工具获批的程度。如果有必要，他们甚至愿意为不止一款工具这么做。

工具选型这场游戏

ACME Financial Services 已经迈出了改善其可观测性现状的第一步，也是最容易的一步：他们决定需要评估新的工具，加入到应用技术栈中。困难的部分在于，接下来要确定究竟是哪一款或哪几款工具，可以帮助他们应对这些挑战。除此之外，ACME Financial Services 一向不愿引入会把自己锁定在某家单一供应商上的新工具。虽然这种工具并非绝对无法获批，但如果确实必须引入，那么审批门槛会比其他情况高得多。这项政策是逐渐演化形成的，其背景是：几家与 ACME Financial Services 有现有合同关系的供应商曾试图大幅提高许可证费用。于是，公司又进一步形成了另一项政策：自建还是采购（build versus buy） 。相比购买第三方工具，公司更倾向于自建定制化工具以满足自身需求。因此，任何“采购工具”的论证，都还必须拿来与“自己构建”的方案作比较。

项目负责人最终提出了以下几个方向，用于评估供应商工具：

• 无供应商锁定（No vendor lock-in） ：这是公司政策，因此必须尽一切努力实现。
• 采购前可完整评估（Pre-purchase evaluation） ：该工具必须允许在正式购买前，对其付费版的全部功能进行评估。
• 使用开放标准（Use open standards） ：这不是硬性要求，但却是一个非常强烈的加分项。它不仅有助于避免供应商锁定，也能保留 ACME Financial Services 在需要时自行开发工具的能力。任何能满足这一点的工具，都会更容易获得批准。
• 开源（Open source） ：这也不是硬性要求，但同样是一个非常理想的特性。
• 合理的许可证成本（Reasonable licensing） ：这一项其实相当模糊，因为他们并不清楚最终可能遇到的供应商报价范围。工具是否能够获批，将取决于预期收益与成本之间的微妙平衡，因此必须始终关注许可证成本。

一旦他们找到了感兴趣、可能购买的工具，项目负责人就还必须再做一次与“内部自建同类功能”的对比。他们对这个流程已经很熟悉了，也明白必须考虑的不仅仅是许可证费用和运行时成本。他们已经通过亲身经历学会了：看起来更便宜地“自己造”，并不意味着那就是更好的选择。

自建还是采购

在继续往下之前，我们先稍微岔开一下，讨论几个经济学原理，这些原理可以帮助我们理解：为什么有时候即使账面上看来自建更便宜，购买工具仍然可能是更好的选择。这里我们不会展开得太深：

• 机会成本（Opportunity cost） ：简单来说，这是没有被选择的那个方案所付出的代价。在“自建工具 versus 购买工具”的场景下，如果你选择自建，那么你就必须投入资源去设计、开发和维护这套内部工具。这个项目还需要像其他项目一样，有路线图，并消耗项目管理资源。当这些资源都投入在这个工具上时，它们就无法再去做那些可能对公司更直接有益的功能了。比如，如果一个工具预计需要两年时间、10 名开发者、一名技术负责人、部分项目经理时间、部分架构师时间等等，那么这些资源花在工具上的时间，就不能再用于打造一个能为公司吸引更多客户的“杀手级功能”，或去修复那些长期存在、令人沮丧的顽固缺陷。
• 专业化（Specialization） ：这基本意味着某个群体专注于生产有限范围内的产品或服务，因此能够以更快、更低成本的方式交付它。在我们的例子中，供应商深耕于自己所解决的问题空间，并已经积累了解决这些问题所需的专业能力。而对于 ACME Financial Services 来说，他们的专长在金融行业，而不是可观测性工具，更不用说 AI 或机器学习了。

即便亲身经历过这些经济学原理，公司内部仍然存在一种倾向：偏向自建而非采购，而这必须被正视。这个过程中首先要考虑的是：开源社区里是否存在可以用作内部方案基础的工具，以及这些工具本身能为完整方案提供多少功能。

下一点要考虑的，是 ACME Financial Services 当前处境的紧迫程度。情况是否已经严重到必须尽快得到解决？如果是，那么“采购”的吸引力就会大幅增加，但这里有个前提：即便现在必须先用第三方工具，也并不意味着以后就不能开发内部工具。第三方工具可能有助于缓解眼前的紧急问题，但内部自建工具仍可能是理想的最终方案，即便把未来的迁移成本也算进去，依然如此。

最后，他们还必须考虑：部署第三方工具究竟需要多久。这个工具是否复杂到会花费大量时间去规划和部署？ACME Financial Services 的部署环境非常复杂，任何工具要进到他们的系统中都不容易。即便是一个已经提供 Kubernetes 部署文件的开源项目，在 ACME Financial Services 这种高度受限的部署环境中，也依然可能需要数周甚至数月才能真正跑起来。因此，即便某个第三方工具看起来能“立刻解决问题”，一旦把部署时间算进去，内部开发一套工具反而可能更快。

该开始调查了

在评估方向和功能缺口都明确之后，项目负责人开始着手研究：究竟什么样的工具能帮助他们解决这些问题。他们把调研工作分成了四个小组：

• 可追踪性（Traceability）
• 告警（Alerts）
• 欺诈（Fraud）
• 功能使用（Feature usage）

每个小组都将并行推进自己负责的领域，并定期碰头，分享进展与发现。

可追踪性小组

负责解决可追踪性问题的小组，希望解决团队对于“应用内部发生了什么”以及“跨多个业务领域的应用之间发生了什么”缺乏理解的难题。当前，要追踪一次事故并发现其根因几乎是不可能的，往往需要多个开发者团队协调起来，分别检查多个应用中的日志条目。大多数时候，应用团队必须进入同一个会议里一起排查，试图搞清楚应用之间是如何交互的，以及究竟哪里出了问题。这个过程非常耗时，也非常费力。

该小组首先从寻找可能改善跨应用信息流动的工具入手。他们很快发现了 OpenTelemetry（opentelemetry.io）——一个支持多种编程语言的开源项目。这个方案看起来非常有前景，于是小组决定重点对它进行评估。

在评估 OpenTelemetry，也就是 OTel 的过程中，他们了解到一个名为 trace（追踪） 的概念。trace 本质上可以看作是带有额外上下文信息的结构化日志。它们包含所谓的 span ID，这使得人们可以跨多个容器，甚至跨多个应用去追踪一次通信过程。借助上下文传播（context propagation），支持团队和应用团队就可以沿着一个请求，贯穿整个系统的所有部分，准确理解它在什么时间、什么位置发生了什么。于是他们认定，这听起来正是解决当前可追踪性问题所需要的东西。更进一步，他们还发现，OTel 远不止于此。

OTel 还支持指标和日志。虽然这两项原本并不在该小组的评估范围之内，但随着评估深入，采用 OTel 来统一处理这两类数据的好处也变得非常明显。OTel 本身并不规定日志的具体记录方式，但它会给日志包上一层信息，使日志能够与 trace 建立关联。这看起来是一个非常大的收益，因为它可以帮助结合 trace 来诊断问题。用 OTel 来做指标采集也能让他们把可观测性数据整合起来。与其继续用 Prometheus 处理指标、用 OTel 处理追踪，不如两者都用 OTel，从而获得一致性，并降低工具复杂度。

最棒的是，OTel 是开源的。当然，OTel 并不是在真空中独立提供这些能力。应用经过 OTel 埋点后所产生的数据，仍然需要被采集并发送到某个地方进行可视化，因为 OTel 本质上是一个数据采集标准。通过使用 OTel Collector，他们可以把这些数据传输到现有的 Prometheus 和 Grafana 安装环境中。团队认为，对 OTel 的支持应该成为后续其他工具评估中的重要标准之一。因此，在下一次进展汇报会上，这个小组把他们关于 OTel 的发现介绍给了其他人。大家一致认为，它看起来不仅能够解决可追踪性问题，而且任何接下来可能被考虑的新工具，都应该支持 OTel。他们也一致同意：任何新工具还必须支持遗留系统，因为对某些旧应用来说，使用 OTel 进行埋点既不现实，也不可能。

功能使用小组

负责应用功能使用情况的小组，希望帮助开发团队理解：他们应用中的功能究竟是如何被使用的，以及开发期间的资源应如何投入。例如，如果某个缺陷只影响到一个极少有人使用的功能，而同时还有更高影响力的改动亟需完成，那么优先投入开发时间去修这个缺陷，可能并不是最好的选择。在缺乏这类信息的情况下，应用团队往往只能凭借投诉数量、问题在 backlog 中存在多久等因素，尽力去判断优先级。

表面上看，这似乎不是一个特别难解决的问题。该小组初步判断，他们可以制定一项政策：所有新功能都必须由外部开关控制，并且开启该功能的同时，也开启一些关于该功能如何、何时被使用的指标采集。然而，这种思路也引发了一些担忧。其一是标准化问题。即便进行了培训，他们也确信每个开发团队最终还是会以略有不同的方式去实现。其二是如何管理每个应用的开关配置，更不用说那些跨多个应用或多个业务域的功能了。因此，他们决定先去做一些研究，看看是否已有其他人应对过类似问题。

他们的搜索把他们带到了 OpenFeature 项目（openfeature.dev）。他们发现，这个项目提供了一种标准化功能开关实现的方法，甚至还支持对 OTel 的自动支持。这一项目兼容多种远程开关管理工具——这对该小组来说是一个全新概念。更棒的是，该项目还提供了一个名为 flagd 的远程开关管理服务器，他们可以部署它来统一管理全部配置。从理论上讲，即使未来因为某些原因 flagd 不合适，他们也可以比较轻松地切换到其他开关管理服务器。

OpenFeature 同时支持多种客户端和服务端语言。多语言支持加上远程开关管理服务器，意味着他们将能够跨多个应用域来统一管理功能，甚至还能够把功能可用性协调到移动 App 中去，这已经超出了他们最初方案设想的范围。

由于 flagd 支持从一个或多个远程资源中拉取配置，而这个来源甚至可以是一个 Git 仓库，因此他们能够获得一种非常灵活的开关配置管理模式。使用 Git 还意味着他们天然获得了围绕开关配置的变更管理和审计能力——这是他们一开始根本没有想到的。考虑到他们所处的是高度受控环境，这看起来反而成了一项他们原本不知道自己需要、但实际上非常必要的要求。

OpenFeature 同样也是开源的，因此这看起来会是一套很容易获批的方案。当然，他们仍需要围绕 flagd 服务器做一些设计和架构工作，也需要为开发团队提供一些培训，但整体来看，这几乎是一次明显的胜利。

欺诈小组

负责寻找有助于对抗欺诈工具的那个小组，在某种程度上和负责告警问题的小组有些相似。不过，告警小组是在寻找能处理更广泛问题的方案，而这个小组则聚焦于：一个可观测性工具究竟如何帮助处理欺诈问题。为此，他们决定先列出一份功能愿望清单——列出那些可能有助于检测和防止欺诈的能力，然后再看看是否有可观测性工具能够提供这种功能。

在开始真正研究工具之前，这个小组先回顾了过去一年里已经处理过的欺诈模式、这些模式是如何被发现的，以及公司是如何进行应对的。他们希望从中提炼出一些通用模式，把它们转化为一组“愿望清单式能力”，用于后续评估潜在的新工具。

ACME Financial Services 其实已经在使用基于网络流量异常的检测，而且它确实帮助发现过某些类型的欺诈。例如，它可以在流量超出公司通常经历范围时发出告警。虽然这已经提供了帮助，但仍然有大量可疑活动需要靠人工检测。

在分析过往欺诈事件之后，该团队识别出几个模式：

• 一个已经登录的用户，开始在公司网站上随机尝试不同 URL 端点
• 同一个 IP 地址发起了多个账户登录
• 同一个账户从多个 IP 地址登录
• 新开账户发生了存款和取款操作

ACME Financial Services 已经围绕所有这些事件建立了指标，事实上，公司正是依靠这些指标，来理解某种新的欺诈方式是如何运作的。既然这些指标已经存在，小组便认为：如果这些数据能够驱动主动性的措施，用于调查或缓解可疑模式，那将非常有价值。于是，小组决定：在评估工具时，应该把“能够检测并对上述每一种模式发出告警的能力”列为愿望清单中的重要项。

在明确了希望达成的目标之后，这个小组开始研究现代可观测性工具，以及它们能如何提供帮助。他们发现：只要对现有指标补上合适的元数据，现代可观测性工具就能够做到他们原本所期望的一切——检测并对异常操作模式发出告警。他们还了解到，这类能力在现代可观测性工具中已经相当常见，这对他们来说非常理想，因为推动新工具引入的主要力量，其实正是那个想要改进告警问题的小组。

该小组在下一次进展会议上分享了研究结果。他们确信：任何能够解决告警问题的新型可观测性工具，也都能够覆盖他们关于欺诈检测的用例。因此，他们把所发现的信息同步给了整个工作组。

到这里，四个小组中已经有三个找到了开源方案，或者找到了在许多现代可观测性工具中都很常见的能力。这样一来，真正需要承担“评估并选定工具”重任的，主要就落在负责告警问题的小组身上了。其他小组更多地会扮演顾问角色，因为他们已经基本找到了自己问题的方向性解法。

由于可观测性数据能够告诉我们：某些 IP、某些用户账户等是否存在异常行为，因此我们可以从日志或 trace 中提取数据，并从中检测出模式与异常。

告警小组

试图解决公司告警疲劳问题的小组，面对的是最大、也最困难的问题。他们不仅要找到一种方式来减少告警数量，还希望想出办法，让现有告警变得更具可执行性。带着这个目标，他们首先开始研究已知问题的成因，以及可能的解决方式。

一团糟的 SLO

长期以来，ACME Financial Services 的惯例一直是由应用自己创建、监控并对 SLO 发出告警。随着跨多个业务领域的应用数量不断增加，产生告警的 SLO 数量也随之爆炸式增长。从那些极其重要、直接面向客户的接口，到那些只在非工作时间执行处理任务的应用，只要 SLO 被违反，都会产生告警。他们知道应用数量还会继续增长，因此，这项政策已经不可能继续可行。

知道这项政策不可行是一回事，知道该怎么办则是另一回事。于是他们开始研究 SLO 的最佳实践，并发现他们必须改变自己看待 SLO 的方式。他们决定评估一种“从外向内看 SLO”的做法，也就是说，从客户直接交互的服务与接口出发，再看那些用于支撑这些操作的系统。这种实践将聚焦于用户会实际感知到的事件，而对 ACME Financial Services 来说，这些正是最重要的事件。考虑到他们对公司声誉的高度重视，这项政策将有助于使响应团队的行动，与公司最关心的原则保持一致。

实施这种 SLO 实践后，将极大减少需要跟踪并产生告警的 SLO 数量。这将要求变更公司长期以来一直沿用的指导方针，但工作组非常有信心，相信他们已经拥有一套足够有说服力的信息，可以拿去说服高级管理层。

静态告警

告警疲劳的另一个驱动因素，是应用团队普遍使用静态告警的做法。当应用数量还比较少，并且以单体为主时，这种做法的问题并不太大。如果某个应用 CPU、内存或磁盘资源不足，支持团队当然希望知道，以便在故障发生之前采取行动。如今，随着应用团队完成现代化改造、采用云原生设计原则，同样的这些告警却由数量庞大得多的应用 Pod 发出来。更糟糕的是，这些相同的数据有时还会被用于自动扩缩容 Kubernetes 集群或应用 Pod，这就意味着这些告警彻头彻尾成了噪声。

很显然，减少这类告警噪声的第一步，是去掉所有那些围绕“已被用作自动扩缩容依据的指标”所产生的告警。虽然这是个不错的开始，但离真正解决问题还远远不够。能够发出这些告警的 Pod 数量庞大无比，而且还在持续增加。与此同时，这些告警本身的价值也远不如过去。过去，如果单体应用发出 CPU、内存或磁盘不足的告警，确实值得重视；而现在，如果 100 个 Pod 里有 1 个资源不足，问题的严重性就远没有那么高。

于是，他们决定研究：除了静态告警之外，还有什么其他告警实践可选。工作组发现，这正是机器学习 / AI 可以发挥作用的一个问题场景。与其为每个 Pod 设定静态阈值，并艰难地维护它们，利用机器学习 / AI 的工具能够自动为应用建立基线，并理解它独有的使用模式。这将显著减少生成的告警数量。这类工具还带来一些其他潜在收益，例如自动发现关系与异常，甚至自动执行某些响应动作。

这个方向上的改进，不仅取决于选择正确的工具，也取决于 ACME Financial Services 是否能改变应用开发团队的文化与指导方式。

数据孤岛

在和响应团队与应用团队沟通之后，他们发现当前流程还受困于一种叫作 数据孤岛（siloed data） 的问题。问题在于：当一个告警被触发时，它只会提供一个单点信息。例如，“CPU 利用率超过了 90%”。然而，一旦收到这个告警，就没有进一步的信息来说明是什么导致了它。Prometheus 与应用日志、源代码仓库之间没有任何连接，因此响应团队和应用团队只能自己去翻日志和变更历史，试图找出告警背后的原因。一旦告警出现，调查团队根本无从知道：这个告警究竟是由正常流量激增、欺诈行为、长期存在的缺陷，还是最近引入的新功能所导致的。告警缺乏上下文，意味着缓解问题的调查根本没有一个明确的起点。有些事故之所以能够较快处理，是因为团队内部积累了某种“部落知识（tribal knowledge）”，知道某个应用是怎么工作的、过去类似问题可能是什么原因造成的。但这种知识非常脆弱：如果某个人在休假，或者离开了公司，那么在调查告警时，这种知识就不可用了。有些团队试图把这类知识记录进自己的 runbook 中，虽然确实有帮助，但它仍然无法替代那些真正排查过问题的人所积累的经验。

随着工作组继续研究解决方案，他们发现：这又是一个 AI / 机器学习型可观测性工具能够提供帮助的领域。将这类 AI / ML 可观测性工具与 OTel trace 和日志，以及源码仓库的提交历史结合起来，就能为正在调查告警的响应团队提供丰富的上下文。恰恰就是这种上下文数据，在当前公司所使用的工具下，响应团队必须靠人工自己去一点点找出来。

基于日志的告警

甚至在云迁移启动之前，ACME Financial Services 就已经在推进公司内部告警能力的改进。这个过程的第一阶段，是从“完全没有告警”过渡到“使用日志聚合服务来产生告警”。虽然这总比完全没有强，但最终它却成了应用团队和响应团队的一大噩梦。公司允许应用团队自由决定：要对什么发告警，以及阈值设在哪里。应用开发团队并没有足够勤勉地在非生产环境中处理这些告警的根因，于是这些告警通知塞满了邮件收件箱，而且大多被忽略掉了——即便是在生产环境下也是如此。大多数应用开发团队都会配置邮件过滤规则，避免告警把收件箱塞满。这正是告警疲劳的典型定义。

更糟糕的是，这些基于日志的告警还有延迟——通常至少会在事件发生 15 分钟之后才出现。这使得响应团队在降低 MTTR（平均恢复时间）方面天然处于劣势。某些类型的告警，延迟 15 分钟也许无关紧要；但对于任何面向客户的场景来说，这几乎意味着客户一定会至少感受到 15 分钟的问题，甚至更久。

正因为如此，ACME Financial Services 已经开始鼓励各团队从基于日志的告警迁移到基于指标的告警。然而，这个迁移进展缓慢，因为前提是应用中必须先存在这些指标，才能基于它们创建告警。到目前为止，给应用加上指标埋点的工作一直是由应用团队自行负责，因此，从日志告警迁移出去的进展一直很慢。

这个团队看不出来，如果仍然允许面向客户的服务继续使用基于日志的告警，那么项目的一些目标要如何可能达成。虽然这类告警的迁移工作推进缓慢，但团队一致认为，他们必须想办法去吸引或强制应用团队做出必要改变。把这项变更的范围限制住，应有助于争取高级管理层对这项工作的支持，但具体工作仍必须被纳入应用团队的 backlog，并与其他工作一起参与优先级排序。最终，他们决定向高层提交一份计划，要求在一年之内，仅对面向客户的应用完成这项迁移工作。

把一切整合起来

各个小组继续定期开会，分享信息并讨论进展。随着时间推移，大家越来越明显地看出：这些问题彼此之间关联极深。最早由可追踪性小组提出的 OTel，不仅与可追踪性问题有关，也与告警小组正在研究的告警疲劳问题有关。那些有助于欺诈处理的方案，也同样会帮助功能使用、可追踪性和告警疲劳问题。各个小组对这些联系感到惊讶，但同时也松了一口气，因为这意味着最终的解决方案不必是“多个工具 + 多套新流程”的组合。它还意味着，工具选型可以基于一套相当标准化的需求集合来进行，这无疑是一个额外的好处。

整个工作组最终整理出了以下用于评估新工具的要求：

• 必须能够基于日志、代码变更、trace 和异常，为告警提供上下文
• 必须支持摄取 OTel 数据
• 必须支持遗留系统的可观测性，可以通过 agent、日志采集或其他方式实现
• 必须支持应用级异常检测
• 必须利用 AI / 机器学习能力帮助检测异常
• 必须能够与他们现有的监控方案（Prometheus / Grafana）协同工作
• 必须支持基线建模和动态告警
• 供应商必须允许使用完整功能进行评估
• 工具必须能够与公司用于事故响应的工具集成

有了这份需求列表之后，他们终于可以开始寻找可选工具了。他们很快意识到，这些需求并不特别，现代可观测性工具其实已经围绕这些问题努力了很长时间。许多工具也已经开始融入 AI / ML 功能。基于调研，他们列出了一份由 6 家供应商组成的候选清单，并开始评估：

• TraceMagic
• Logcat
• CloudObserve
• DataDash
• GraphResearch
• ACME Observability

在设计出用于评估各类工具的用例之后，他们联系了这些供应商，并安排了产品评估。工作组针对用例列表，对每一款工具进行了评估，并记录了每个用例是如何实现的，同时收集与工具相关的信息，例如资源要求和价格。经过这一番极其详尽的评估流程之后，工作组最终选择了 ACME Observability，作为要引入 ACME Financial Services 的可观测性工具。

行动计划

围绕评估并改进 ACME Financial Services 可观测性实践所发起的这项计划，最终形成了一长串改动项，其中有些很小，有些则非常庞大。工作组整理出了一份行动摘要，列出了他们认定必须采取的措施：

• 在应用部署中补充元数据，以解决已部署制品归属关系不清的问题。这将通过在部署审批流程中增加检查项，以及对应用团队进行培训来落实。
• 在公司内部推动 OTel，以解决公司范围内的可追踪性问题。这将需要为应用团队制定一些标准并开展培训，同时设计和实施 OTel Collector，把数据路由到 Prometheus 和新的 ACME Observability 工具中。
• 使用 ACME Observability 工具中的 AI / ML 能力，对应用级异常进行监控和检测，从而增强欺诈检测能力。
• 使用 OpenFeature 跟踪功能使用情况，并控制已部署应用中的功能可用性。然后利用收集到的数据，帮助应用团队理解应用是如何被使用的、哪些功能最受欢迎，并把这些信息作为优先级规划的输入。这将需要开发一套新的开关管理系统、流程和标准，并为应用团队制作培训材料。
• 评估现有 SLO，并只保留与客户影响相关的应用的 SLO。除了评估现状之外，还需要制定新的指导方针，并向应用团队提供培训。
• 彻底淘汰所有面向客户应用中的基于日志的告警。需要为应用团队建立新的标准与培训。
• 利用 ACME Observability 的 AI / ML 能力，把静态告警迁移为动态告警。需要为应用团队建立新的培训和指导。
• 通过使用 ACME Observability 的工具，把 OTel 数据、遗留可观测性数据、源码变更、部署数据和异常检测整合起来，为告警提供上下文，从而解决数据孤岛问题。

这是一长串工作，工作组也很清楚，不可能在所有方向上同时推进。有些工作将依赖于新的基础设施部署，而在应用团队真正能够使用这些能力之前，基础设施本身还需要先经历规划、部署和测试。

而在这一切发生之前，工作组还必须先获得高层管理对这份计划的批准，以及对 ACME Observability 额外许可证成本的批准。拿到批准之后，他们还必须决定：哪些部分应该优先实施，哪些部分可以并行推进，以及这些工作之间存在什么依赖关系。最后，在制定交付目标时，他们还必须把应用团队现有的排期考虑进去。

有了“做什么”，还要决定“怎么做”

对于 ACME Financial Services 这个试图改善公司可观测性实践的工作组来说，这是一段漫长而富有教育意义的旅程。现在，他们已经知道自己要做什么，也已经获得了高层管理对整套计划的全面批准。接下来，他们要弄清楚的是：究竟如何完成这些改进。

ACME Financial Services 是一家大公司，而大公司做任何事都不快。过去那些涉及全公司的大型计划，往往都需要几年时间才能完成。因为再怎么说，高层管理虽然希望某些事情尽快做成，但他们同样仍然希望新功能、新产品和缺陷修复持续交付。任何要求应用开发团队承担的工作，都必须与他们已经在做的其他工作一起协调管理。考虑到这些改进的性质和重要性，以及高层管理层对其支持的力度和紧迫性，这项工作会被应用开发团队赋予很高优先级，但这并不意味着它一定会以惊人的速度完成。

团队知道，当他们向应用开发团队提出这些工作要求时，必须给出一个定义清晰、边界明确的目标，让团队可以朝它推进。由于这项工作牵涉到太多技术和改动，他们意识到：在真正与应用开发团队展开协作之前，自己必须先制定一些培训材料和标准。这让第一步显得非常明显：先创建培训和标准。但即便是这项工作本身，也必须有组织地开展。因为在 OTel Collector 或 ACME Observability 还没有可供使用之前，应用开发团队其实并没有什么事情可围绕这些内容立即着手。因此，工作组决定，先围绕那些应用开发团队可以立刻开始推进的事项制定培训和标准：

• 归属元数据（Ownership metadata）
• 面向应用部署审批人的培训与标准制定
• 什么应该拥有 SLO，以及移除其他所有 SLO
• 公司愿景的高层视图
• 基于日志告警的终止日期

一旦围绕这些主题的培训和标准建立起来，他们就可以开始培训应用开发团队，并为这些事项设定完成期限。与此同时，他们还可以并行改进部署审批工具，使其能够强制检查归属元数据。即便这些事项已经可以立即执行，要让所有应用都达到合规状态，仍然会花费很长时间。即便如此，这些工作也会在推动 ACME Financial Services 可观测性现代化的过程中，带来非常大的初始影响。

第一阶段不可能很快完成，其实反而是件好事，因为支撑后续计划的新基础设施还需要被开发和部署出来。这部分工作包括设计和部署 OTel Collector、一个集中式功能开关管理系统或流程，以及一个能够支撑全公司规模的 ACME Observability 平台。他们将不得不研究 OTel Collector 的架构并为可扩展性进行设计。一旦这部分完成，下一组培训和标准也必须被建立：

• OTel trace、日志和指标
• 使用 OpenFeature 进行功能开关管理和使用量指标采集
• 从静态告警迁移到动态告警

这组工作将对应用开发团队的排期产生最大影响。采用 OTel 和 OpenFeature，将要求应用团队投入工作，而这些工作将不得不与新功能开发和缺陷修复竞争资源。

与此同时，公司还需要与 ACME Observability 一起，就如何设计和架构部署这套新工具展开合作，使其能够支撑整个 ACME Financial Services 的规模。这一阶段，是观察工作组与应用开发团队此前所有努力真正汇合在一起的阶段，也是在这里，收益开始成形。一旦 ACME Observability 部署完成并可供使用，最后一组培训与标准就必须建立起来：

• 如何利用应用异常检测来发现欺诈
• 如何使用 trace 数据，并借助 ACME Observability 提升可追踪性
• 演示告警中新增的上下文
• 如何使用 ACME Observability 的培训

这一部分工作主要是向团队展示如何使用新工具，以及这些工具所带来的好处。它对应用开发排期的影响会较小。然而，也正是在这里，ACME Financial Services 需要发生文化转变：无论应用交互有多复杂，都应当能够被追踪；告警应当具备有用且可执行的上下文；生成的告警应当真正有价值，因此不应被忽略。

来看看 AIOps 如何增强欺诈检测与响应

接下来，让我们看看，借助 AIOps，欺诈检测与响应将如何得到增强。通过这个 AIOps 用户故事，我们将识别出：ACME Financial Services 中的社会技术因素，可能会如何影响方案实施及其成功。

用例：作为一名欺诈专员，我希望对潜在欺诈活动实现自动告警、自动事故响应，以及自动补充工单信息。

完成定义（Definition of done） ：

• 一个 AI 代理利用可观测性数据标记潜在欺诈

• 为欺诈部门创建一个事故

• AI 代理用相关数据样本补充事故详情

• 执行相应的标准操作流程（SOP），其中可能包括：

  • 通知账户所有者，并要求其打电话进来确认
  • 禁用在线访问或强制修改密码并进行身份验证

这就是欺诈团队为了表达其需求而写下的用户故事。其中每一项请求都依赖于其他团队和现有系统。AI 代理将不得不把自己的独特能力，与现有系统的能力结合起来，才能真正满足这个用户故事的完成定义。

这里还有一些其他要求，可能并不像表面上那样显而易见。大多数金融公司都会使用 Gordon-Loeb 模型来确定应该在安全方面投入多少资金才合适。该模型把最优最大投资门槛设定为：一次安全事件预期损失的 37%（en.wikipedia.org/wiki/Gordon…）。

这意味着，实施该方案的团队必须设法确保：方案本身不要贵得离谱，而且能够明确节省人工时间，以帮助抵消其成本。

首先，团队需要澄清几个关键要求：

• 触发欺诈事故的指标阈值是什么？
• 哪些类型的异常表示潜在欺诈？
• 工单补充所需的必要数据是什么？
• 把这些数据写入工单系统时，安全和合规要求是什么？
• SOP 存放在哪里？又该如何识别出正确的那一个？

对于这个用例来说，AIOps 系统会对终端客户产生直接且可衡量的影响。尽管他们可能并不知道，是这套系统在可疑登录后锁定了他们的账户；但如果系统误判锁了他们的账户，他们就会受到实实在在的负面影响。因此，这件事必须做好，而且应当采取 crawl, walk, run 的方式循序渐进地推进。

第一步，是与所有依赖团队合作，确保欺诈部门能拿到它所需要、并且经过正确增强的数据。这不是一件容易、也绝非一夜之间就能完成的事情。因此，这一步可能直到“run”阶段很后面才真正完成。也正因如此，团队必须在公司内部流程之下推动这项工作，确保它被正确优先级化。若能证明其潜在成本节约和其他价值，就更有可能在功能优先级谈判中争取到足够资源来完成它。

在这些数据增强能力尚未存在时，他们仍然可以在现有条件约束下，开始逐步满足“完成定义”。现有自动化其实已经完成了其中很多动作：它能够检测欺诈、创建事故、锁定账户并发送通知。这些能力并不需要被重写，但它们最终必须能够被 AI 代理访问。如果访问方式是 API 调用，那么代理就需要拥有一个可用于调用该 API 的身份，并且知道如何使用它。这很可能意味着他们要做一个自定义 MCP 服务器——这是他们的第一个 MCP 服务器。

而当前自动化做得不够好的地方，是没有很好地用所有相关数据来补充事故工单。金融系统数据受到高度监管，因此做数据关联可能相当有挑战性。不过，如果我们从事件指标的数据模型来考虑，很可能存在一种单向哈希，可以用来把某个指标与某个账户关联起来。因此，AI 代理可以围绕这个哈希，找到相关指标和日志，并进一步识别出其他可能有用的数据点，例如用户平时活跃的时间段。它可以把原始数据和对这些数据的分析结合起来，写入工单系统中。

而这些写操作也必须被加入到 AI 代理的技能集中，这就会需要第二个 MCP 服务器。

现在，让我们看看这一新事故响应方式在 crawl 阶段的工作流：

工作流 1：

1. 自动化创建一个工单。
2. 一名欺诈团队成员请求 AI 进行调查。
3. AI 调查结果被加入到工单中。
4. 欺诈团队成员执行适当的 SOP。

工作流 2：

1. 一位客户打电话进来投诉存在欺诈问题。
2. 欺诈团队创建一个工单。
3. 团队成员发起 AI 调查。
4. 调查详情被加入到工单中。
5. 团队执行正确的 SOP。

在工作流 2 中，人这一环节很可能始终都会存在。客户会主动发起事故。但未来，无论是工作流 1 还是工作流 2，当工单被创建时，这个事件本身就可以自动触发 AI 调查，而无需团队成员再手动调用。哪怕只是减少了一个人工步骤，也是一项小而可衡量的成功。

到了 walk 阶段，大多数动作就会由 AI 来处理，但仍保留人工监督。walk 阶段的工作流如下：

工作流 1：

1. 自动化创建一个工单。
2. AI 代理为其补充调查细节，并推荐应执行的 SOP。
3. 欺诈团队成员批准该 SOP，或者建议换用另一个 SOP。

工作流 2：

1. 一位客户打电话进来投诉欺诈问题。
2. 欺诈团队创建一个工单。
3. AI 代理为其补充调查细节，并推荐一个 SOP。
4. 团队成员批准该 SOP，或者建议换用另一个 SOP。

最后一个阶段是 run。run 阶段的工作流如下：

工作流 1：

1. 工单由 AI 代理创建。
2. AI 代理用调查结果填充工单详情。
3. AI 执行 SOP。
4. AI 解决该工单，并将其送交人工复核。

工作流 2：

1. 自动化创建一个工单。
2. AI 代理用调查结果填充工单详情。
3. AI 执行 SOP。
4. AI 解决该工单，并将其送交人工复核。

工作流 3：

1. 由人工创建一个工单。
2. AI 代理用调查结果填充工单详情。
3. AI 执行 SOP。
4. AI 解决该工单，并将其送交人工复核。

最终，系统的可信度会增长到一种程度，使得“人工复核”可能不再频繁出现。不过，一般来说，无论事故是由人处理还是由机器处理，定期进行复盘审查始终都是一种良好实践，因此我们绝不会建议彻底去掉人工复核。让 AI 按固定节奏发布一份关于工单、处理结果，以及其中是否有任何工单被重新打开的摘要，也将有助于向相关业务干系人展示成功指标和总体成本节约。

不过等等，这套同样的事故工作流能否也应用于内部事故？答案是：可以！ 虽然数据的使用方式会有所不同，事故管理工具也可能不同，但很多数据和工作流实际上几乎是一模一样的。

下面是把 AI 融入过程后的基础事故响应工作流：

图 4.2 —— 简化版事故工作流

在这个工作流的核心，你会有：一套关于事故的事实来源（source of truth）、用于调查事故的可观测性数据，以及一个解决结果。只要能以安全的方式接入，你几乎可以把 AI 代理连接到这些环节中的任何一个。同样适用 crawl、walk、run 这种渐进式方法。假设我们现在正在处理一个处于 run 阶段的应用类事故：

1. 首先，工单基于一个告警被创建，告警表明我们的应用没有按照正常参数进行响应。

2. AI 代理判断这是一起关键事故，并将工单标记为关键级别。它还可能向 Slack 等渠道发送额外告警，通知人工团队。

3. 接下来，AI 代理补充事故上下文。它会调查若干可能原因：

   • 网络与负载均衡器问题
   • 应用健康状况
   • 数据库健康状况

4. 调查结果被写入事故工单。这些内容稍后会对根因分析非常有帮助。

5. 原因最终被定位为应用本身。由于某种原因，它超出了自己的内存配额。

6. AI 代理发起一个 Pull Request，用于提高内存配置，并把该 PR 链接到事故工单上。

7. 一名人工审核者查看该 PR 及其关联事故，然后批准或拒绝这个改动。

8. 随后，对日志进行分析，以确定为什么应用会表现出类似内存泄漏的症状。

9. 根因被找出，并且可以直接实施修复，或者至少提出修复建议。

10. AI 代理生成一份根因分析文档，供相关方审阅。

为了确保 AI 没有出现幻觉或发生错误，人类检查点依然是必要的。但它能够快速缩小原因范围、解析日志并发起 Pull Request，这让 AIOps 在这一领域成为真正的乘数器。一个人类借助 AI 的帮助，现在可以以高得多的效率处理一次事故。记住，一个准确的 AI，前提是它拿到的是正确的数据，并且这些数据被正确地增强过；它手中可用数据的质量，将直接决定它能把工作做得多好。

终于完成了。我们得到了什么？

在云迁移之后，ACME Financial Services 花了很长时间来修补自身在可观测性方面的缺陷。这是一段漫长的旅程，需要数年时间、大量规划、优先级谈判，甚至还要做出一些牺牲，但他们最终还是完成了所有计划中的改进。所有应用现在都会发送 OTel trace 和指标，并且会用 OTel 元数据增强应用日志。所有新功能都被放在 OpenFeature 之后受控发布，而收集到的指标信息也被应用开发团队用来帮助做优先级规划。所有面向客户的应用都已经淘汰了基于日志的告警。ACME Observability 已经成为公司可观测性实践的新核心支柱，并在从静态告警转向带有可执行上下文的动态告警中发挥核心作用。虽然对这些新实践的评估还处于早期，但已经能观察到一些改善：

之前	之后
排查事故需要拉很多人参与	相关团队识别过程被简化
解决时间长	解决时间下降
告警疲劳	告警更具可执行性
欺诈检测能力有限	欺诈检测与响应范围扩大
功能发布风险高	功能开关能力已启用

表 4.4 —— ACME Financial Services 的前后对比

如今，事故响应团队的效率已经高得多。过去，一旦告警到来，事故响应团队往往要召集一大批干系人，一起参与诊断与缓解问题；而现在，响应团队能够准确知道哪些团队需要参与某起事故，并且只会把这些团队拉进来。得益于归属元数据与可追踪性信息，事故响应团队现在不仅知道哪一个应用卷入了事故，还知道还有哪些其他应用参与了导致该告警的一连串事件。这也减轻了应用开发团队的压力，因为每个团队被拉进事故的次数都大幅减少了。事故响应团队也更能专注于记录行动、推动事故解决，而不是把时间浪费在确保“所有重要干系人都在场”这件事上。

事故解决时间也出现了明显下降。合适的应用开发团队能够更早参与事故，而告警本身也带有帮助他们调查问题的上下文。过去，应用团队必须在日志里大海捞针，试图理解发生了什么、时间顺序如何，以及哪些变更可能与事故有关；而现在，他们可以在 ACME Observability 中直接获得日志、指标、部署历史和代码变更历史，这些都能帮助他们诊断事故根因。

无意义告警的数量也大幅下降。虽然要让每个人都对每一条事件作出响应仍然是一场文化战，但随着告警逐渐证明自己更相关、更有价值，公司文化正在慢慢发生改变。那些没有得到处理的告警数量，也在开始缓慢下降。

这些变化甚至也在帮助打击欺诈。ACME Observability 工具中的 AI / ML 功能可以检测并对偏离正常活动的使用模式发出告警。它已经在缓解和应对新型欺诈模式方面，产生了明显效果。

由于事故处理得更快、参与的人更少，公司的整体氛围也改善了。事故成本更低了，因为持续时间更短，也不需要那么多人来解决。运维团队和应用团队的压力都小了很多，因此他们在处理事故时也更加高效。过去那种普遍存在的倦怠现象已经得到了缓解，甚至开始下降。

这些结果，都是这个项目可衡量的成功。它们的重要性不仅体现在工程层面，也体现在高管层面。回到 DORA 指标来看，它们不仅映射工程健康度，也直接映射业务健康度。

变更失败率（change failure rate） 、变更前置时间（lead time to change） 和 MTTR 的下降，会直接对客户产生正面影响。这些指标直接对应着客户在使用系统时的成功感与愉悦感。

而 部署频率（deployment frequency） 的提升，则意味着客户可能会更快看到新功能。当系统中的变更整体变得更小、更频繁时，这些变更通常也会被测试得更充分，并且更加稳定。那些已经在收集的可观测性数据，本身就可以被用来计算这些指标，并生成业务报表，从而为理解整个组织增加一个关键维度。

最重要的是，更频繁地发现并阻止欺诈，可以降低成功安全事件所带来的财务损失风险。那个原本用来决定“投入多少才算合理”的模型，也同样可以用来证明这笔投资已经回本。如果我们能把系统成本和人工工时成本一起跟踪，并与我们原本允许的预算上限相比，结果仍然维持在那条线之下或等于它，那么无论从哪个角度看，这个项目都应被视为成功。

也许，所有这些工作带来的最好结果，是 ACME Financial Services 声誉的提升。随着客户遭遇的问题更少、持续时间更短，他们对 ACME Financial Services 的感受会更加正面，也更值得信赖。更多信任意味着更多客户；但在金融服务行业中，一个值得信赖的声誉，是无价的。

小结

在本章中，我们一路跟随着我们的虚构公司 ACME Financial Services，看到它在完成云迁移后，如何陷入了一个困难而且难以管理的局面。运营成本骤增，而他们原有的可观测性实践也不再奏效。他们必须想办法解决这些问题，否则这些问题最终会对公司造成严重伤害。为此，他们不得不组建一个团队，去调查并学习新的可观测性实践和工具，评估新工具，规划公司级改进，部署新基础设施，协调优先级，并争取高层管理对整个计划的支持。这是一项影响全公司的艰巨工程，历时多年才最终完成，但结果是：事故响应流程更高效了，而且最重要的是，公司声誉得到了改善。

而这其实也只是他们旅程的开始。和许多复杂问题一样，解决了一批问题之后，往往又会暴露出那些起初并未被看到、或者并未被理解的新问题。推动这些改变的最大动力之一是成本控制，但可观测性工作组也发现：降低成本并不像他们原本想象的那么容易。

成本只是一个更大挑战中的一个维度。在本章中，我们讨论了让可观测性“真正有意义”的重要性，也就是如何从令人不堪重负的数据，走向可执行的信息。在下一章中，我们将进一步讨论：内部开发者平台（IDP）如何帮助组织把可观测性数据转化为可执行信息——而这，也是 ACME Financial Services 在后续章节中将继续学到的一课。