云迁移后AIOps实施中的挑战与应对策略

这确实如此。

但另一方面，如果可观察性实践没有同步更新，系统可能变得难以排查问题、难以追踪根源、容易产生告警泛滥，甚至导致事故响应成本持续上升。

本文通过一个虚拟金融公司“时序折叠”的案例，解析一次企业级 AIOps 落地过程：它不是购买某个 AI 工具，也不是简单地将告警接入大模型，而是一套从问题识别、工具评估、数据治理、事故响应到业务结果度量的完整工程体系。

时序折叠是一家大型金融服务机构，业务涵盖个人投资、储蓄、企业退休计划管理、商业投资和保险。

它有几个显著特点：

首先，业务结构复杂。 不同业务线有大量应用，这些应用既相互独立，又会互相调用，共同支撑客户服务。

其次，监管要求严格。 金融服务行业不仅要保护客户隐私和金融信息，还要满足反欺诈、可疑活动检测、交易合规等监管要求。

再次，声誉极其重要。 对金融公司而言，客户信任几乎就是生命线。一次公开事故，不只是技术故障，还可能带来监管处罚、诉讼和客户流失。

因此，对时序折叠来说，可观察性不是“技术平台好不好看”的问题，而是直接关系到运营成本、客户体验、合规风险和企业声誉。

时序折叠刚刚完成一次大规模云迁移。

前端应用按照云原生设计原则重新架构，迁移到云厂商上的 Kubernetes 集群中运行。但并不是所有后端系统和数据都能上云。

原因很现实：

最终，形成了一个典型的混合环境：一部分应用在云上，一部分后端系统和数据仍然留在本地。

新的云原生应用被拆成大量微服务，部署在多个区域、多个 Kubernetes 集群上。它们获得了更好的弹性和横向扩展能力。

但问题也随之出现。

过去一个业务服务可能是：

迁移之后，同一个服务领域可能变成：

也就是说，一个服务领域从 10 个单体应用，变成了 3 个云区域中的 600 多个 Pod。

类似的增长发生在所有迁移到云上的服务中。整体来看，时序折叠需要管理和监控的组件数量，比过去增加了大约 80 倍。

更麻烦的是，应用还要跨云和本地通信。过去网络和安全都在本地处理，现在还要关心云上与本地之间的网络配置、安全、吞吐量和延迟。

而且网络里跑的不只是业务流量，还有大量可观察性数据：日志、指标、追踪、事件，都要不断发送到可观察性平台。

系统变复杂了，但可观察性实践还停留在旧时代。

时序折叠的事故管理高度依赖人工。

它有一个运维团队，负责接收公司各业务线应用产生的事件。这个团队还会监控社交媒体，看看有没有用户在抱怨系统问题。

听起来很负责，但问题在于：这个运维团队不是应用开发团队，它只大致了解公司有哪些功能，对应用之间的依赖关系理解有限。

于是，一旦事故发生，流程通常是这样的：

这就是典型的“撒网式事故响应”。

结果是，很多团队被不必要地拉进事故处理群。有人是来解决问题的，有人只是来证明与自己无关的。

事故本身还没解决，组织成本已经被拉满。

更糟糕的是，即便有专门的运维团队，仍有一些事故是用户先发现的。客户直接投诉，或者在社交媒体上抱怨，时序折叠才知道出了问题。

工作组开始分析问题，发现时序折叠的可观察性失控，主要来自五个方面。

云迁移后，系统产生了更多指标数据，告警数量随之显著上升。

第一个原因是服务变多了。

过去一个单体应用负责一组功能，只需要一套告警。迁移到微服务之后，原来的应用被拆成几十甚至上百个服务。很多团队只是把原来的告警配置复制到每个微服务上。

比如过去有一条告警，用来检测疑似 DDoS 攻击导致的流量突增。以前它只由一个应用触发，现在同样功能可能由 100 个微服务提供，于是每个微服务都可能触发类似告警。

第二个原因是静态告警仍然大量存在。

过去系统扩容依赖人工判断：CPU 高了、内存高了，就发告警，运维团队评估是否扩容。

但在 Kubernetes 环境里，很多资源指标已经被用于自动扩缩容。如果同一个指标既触发自动扩缩容，又继续触发人工告警，那告警就很可能变成噪声。

比如某个 Pod CPU 偏高，平台已经自动扩容了，但告警仍然把人叫醒。这不是可靠性，而是重复劳动。

过去应用运行在本地，通常是单体应用，一个应用负责一个相对清晰的任务。

现在，一个应用可能由多个微服务组成，其中一些微服务还会运行多个实例来提供冗余和扩展能力。

更复杂的是，一些服务被多个应用共享。

这意味着，一个共享服务出问题，可能影响多个业务线；但事故响应团队很难立刻知道影响范围，也很难知道一个请求到底经过了哪些服务。

调用链变复杂，可追踪性却没有跟上。

告警太多之后，响应团队开始分不清哪些要处理，哪些只是噪声。

这会带来两个后果：

告警疲劳最危险的地方在于，它不是简单的“通知太多”，而是会让团队失去对告警的信任。

一旦大家默认告警没用，真正重要的告警也会被忽略。

工作组发现，越来越多的事故不是内部系统先发现，而是在用户投诉后才被发现。

这个问题没有单一根因。它更像是前面几个问题叠加后的结果：告警太多、可追踪性不足、责任不清、响应变慢，最终导致事故漏到用户那里。

这对金融公司来说非常严重。

因为用户感知到的问题越多，信任损失越大。

并不是说应用没有团队负责。

问题在于，事故发生后，响应团队即使定位到了某个应用，甚至某个 Pod，也不知道该找哪个团队。

过去这个问题也存在，但云迁移后被放大了。

因为一个应用现在被拆成更多组件，不清楚谁拥有哪个服务、哪个 Pod、哪个部署对象，事故响应就会变成“到处找人”。

可观察性失控带来的不仅是事故响应问题，还有运营成本问题。

时序折叠过去的运营预算和竞争对手差不多。云迁移后，运营成本显著上升，已经高于竞争对手。

更糟糕的是，运营成本挤占了其他预算，比如新功能开发和关键业务创新。

高层开始明确要求：必须扭转运营成本持续上升的趋势，把成本降回合理水平。

这时，可观察性不再只是工程团队自己的问题，而变成了公司级经营问题。

时序折叠身处金融行业，必须满足大量监管要求。

它不仅要保护客户隐私和金融信息，还必须检测和阻止欺诈交易，识别并报告可疑活动。

问题是，欺诈模式永远在变化。

公司可以开发工具检测某一种欺诈模式，但一旦工具上线并阻止这种模式，攻击者就会调整方法。

新的欺诈模式出现后，时序折叠通常要经历三步：

第一，检测新的欺诈模式。 根据模式、金额、现有检测系统能力不同，这可能几乎实时完成，也可能需要几天。

第二，分析欺诈模式。 发现异常只是开始，还要诊断哪些系统被利用、攻击者如何利用。

第三，阻止欺诈。 公司必须寻找对策，阻止当前欺诈和未来尝试。如果问题跨多个应用或业务领域，开发和测试可能很慢。

在诊断和响应期间，公司会持续损失资金。

损失可能是几百万，甚至上亿元。

除了金融欺诈，还有其他风险，比如攻击者入侵云资源，用公司基础设施挖矿。

所以，对时序折叠来说，AIOps 如果能帮助更快发现异常模式、更快增强工单、更快触发标准操作流程，就不只是提升运维效率，而是直接减少业务损失。

云迁移之外，时序折叠还在推动研发提速。

过去它的部署流程非常重。

应用团队通常把多个功能一起开发，然后按季度发布一个新版本。部署过程大致是：

这种流程很重，但以前一年只做几次，还能忍。

后来，公司开始推动迭代式开发和更快交付，于是部署次数大幅增加。旧部署流程开始成为阻碍。

时序折叠做了一些改进：引入标准 CI/CD，把新构建部署到非生产 Kubernetes 集群；还开发了自研工具，根据测试覆盖率和自动化测试程度，自动化部分部署审批。

一些应用甚至能做到：非生产环境准备好后，自动部署到生产环境。

但部署变多后，事故也自然变多。

这并不一定是质量下降，而是复杂度增长太快。新功能可能跨多个应用，事故响应团队开始迷失在大量变更中。

时序折叠还遇到一个产品侧问题。

新功能越来越多，但团队越来越不清楚这些功能到底有没有被使用，用户是否喜欢，是否值得继续投入。

过去重大功能会放在配置门控后发布，也就是通过配置控制功能是否启用。

现在配置门控控制的功能越来越多，事故团队和应用团队都很难知道：

功能越多，系统越复杂。

如果没有功能使用数据，团队只能靠投诉数量、backlog 时间、主观判断来排优先级。

这会进一步推高研发和运维成本。

作为云迁移的一部分，时序折叠也调整了可观察性技术栈。

它选择了云厂商提供的托管 Prometheus 和 Grafana，因为比自己运行类似系统更省成本。

Prometheus 负责指标和告警。 Grafana 负责可视化和 Dashboard。

日志方面，他们从本地日志方案迁移到了云端日志采集器。即便本地应用，也会把日志发送到云端日志采集器。

这个日志采集器不只是存日志，还支持从日志创建 Dashboard 和告警。

一开始听起来不错，但很快暴露两个问题。

第一，告警有延迟。

日志采集器需要时间消费和处理日志，所以告警往往在问题发生 15 分钟甚至更久之后才出现。

对于一些后台任务，这可能还能接受。

但对于面向客户的服务，这意味着用户至少已经受影响 15 分钟。

第二，应用团队可以自由创建日志告警。

很多团队自己决定告警条件和阈值。非生产环境里大量告警没人处理，生产环境里的告警也逐渐被忽视。甚至很多人直接用邮件规则过滤告警。

这就是告警疲劳的典型表现。

问题很多，但不可能一次性解决。

时序折叠的项目负责人决定建立一个决策框架。

最重要的判断标准是：某项改进能不能降低成本，以及能降低多少成本。

他们先找当前工具和流程中的最大缺口，再判断每个缺口对运营成本上升贡献了多少。

之后再研究解决方案，比较潜在方案能带来多少成本下降。

这一步很关键。

AIOps 项目很容易变成“看起来很先进”的工程，但如果没有成本和收益判断，就很难获得高层支持，也很难在应用团队排期中争取优先级。

工作组认为，最容易也应该最优先做的是所有权问题。

公司内部所有部署机制都支持某种元数据，所以他们可以要求每个部署对象都带上所属团队信息。

做法包括：

这项工作不需要引入复杂工具，对应用交付影响相对较小，却能明显改善事故响应。

只要部署元数据里有 Owner，事故响应团队就知道应该找谁，而不是把一堆团队都拉进事故群。

这也能间接缓解告警疲劳，因为只有真正相关的团队会被拉进来。

下一组问题被归为中等工作量。

首先是可追踪性。

现在跨多个应用、多个业务领域追踪问题几乎不可能。多个团队必须一起查日志、对时间线、理解应用交互。

这需要研究行业方案和可能的新工具。

其次是欺诈检测。

虽然这不是传统可观察性问题，但工作组认为，如果新工具能帮助识别异常行为模式，就应该纳入评估标准。

最后是功能使用情况。

如果能知道哪些功能被使用、使用频率如何、哪些功能几乎没人用，就可以帮助团队决定继续投入、修复还是移除，从而降低复杂度。

最难解决的问题是告警疲劳。

工作组认为，告警疲劳的根源既来自静态告警，也来自组件数量增加、日志告警延迟、缺少上下文和缺少所有权。

他们明确了几个方向：

他们意识到，仅仅减少告警数量还不够。

告警还必须更有用。

工作组认为，现有工具已经不足以解决这些问题。

于是他们先做了一张能力矩阵：

这张表说明了一件事：Prometheus 和 Grafana 很重要，但它们不能覆盖企业级 AIOps 所需的全部能力。

尤其是可追踪性、欺诈检测、告警管理、上下文关联、动态告警和异常检测。

时序折叠对新工具有几个明确要求。

第一，不能造成严重厂商锁定。 这是公司政策，因为他们过去吃过厂商授权涨价的亏。

第二，购买前必须能完整评估。 不能只看演示，必须能试用付费产品的完整能力。

第三，优先使用开放标准。 开放标准能降低迁移风险，也保留未来自建工具的可能性。

第四，开源是加分项。 不是强制要求，但会让审批更容易。

第五，授权成本必须合理。 工具是否值得购买，要看预期收益能否覆盖成本。

时序折叠内部偏好自建工具，而不是购买第三方工具。

但工作组也知道，不能只看表面成本。

这里有两个经济学原则很重要。

第一个是机会成本。

如果自建一个工具需要 2 年、10 个开发人员、1 个技术负责人、部分项目经理和架构师时间，那这些资源就不能用于开发新产品、修复关键 bug 或提升客户体验。

第二个是专业化。

可观察性厂商长期专注这个领域，已经积累了专业能力。时序折叠的核心专长在金融服务，不在可观察性工具，也不在 AI/ML 工具研发。

所以，即使自建看起来便宜，购买仍然可能是更好的选择。

当然，工作组也会考虑是否有开源项目可以作为内部方案基础，以及第三方工具部署到受限环境中需要多长时间。

有些工具即使已经有 Kubernetes 部署文件，在大型金融机构受控环境里跑起来，也可能需要数周甚至数月。

时序折叠把调查工作拆成四个小组：

四个小组并行研究，并定期开会同步进展。

可追踪性小组希望解决一个问题：

如何理解一个请求穿过多个服务、多个容器、多个应用时，到底发生了什么？

他们很快发现了 OpenTelemetry，也就是 OTel。

OTel 是开源项目，支持多种编程语言，可以采集 trace、metrics 和 logs。

小组最先关注的是 trace。

Trace 可以理解为一次请求的完整路径记录，由多个 span 组成。通过 span ID 和上下文传播，团队可以追踪一个请求从入口到后端，经过哪些服务、每一步耗时多少、在哪里失败。

这正是他们需要的能力。

更重要的是，OTel 不只支持 trace，还支持指标和日志。

它不强制规定日志怎么写，但可以为日志补充上下文，让日0001