如果您是大型 Kubernetes 支持的应用程序的站点可靠性工程师 (SRE)，优化资源和性能是一项艰巨的工作。有些高峰（例如繁忙的购物日）是您可以大致安排的事情，但是，如果做得正确，则需要煞费苦心地了解数百个微服务的行为及其相互依赖性，并且必须在每个新版本中重新评估它们 – 这不是一个非常好的事情。可扩展的方法，更不用说单调以及由此给 SRE 带来的压力了。而且，总会有意想不到的高峰需要响应。持续关注性能并将最佳数量的资源放在正确的位置基本上是不可能的。
现在解决这个问题的方法是通过严重的过度配置，或者猜测和无休止的警报相结合——需要支持团队进行审查和干预。它根本不可持续或不实用，而且当然不可扩展。但这正是机器学习和人工智能蓬勃发展的问题所在。在过去的十年里，我们一直在处理此类问题，而生成式 AI 等最新一代人工智能工具的到来，开启了将机器学习应用于 SRE 实际问题以实现 AIOps 承诺的可能性。
打开计算旋钮……以确保安全
无论您的可观察性仪表板有多么出色，数据量和对敏捷性的需求都太多了。您必须提供足够的资源才能实现所需的响应时间和错误率。对于担任此角色的人员来说，“为了安全”，将计算利用率固定在 30% 并准备监控数百个微服务以确保实现所需的服务级别协议 (SLA) 并不罕见。最终结果代价高昂——不仅需要计算资源，还需要专门用于维护 SLA 的 DevOps 资源。
看起来，尽管 Kubernetes 给我们带来了一切，但它已经超出了那些负责操作它的人的理解范围。水平 Pod 自动扩展 (HPA) 和反应式扩展解决方案仍然让 SRE 猜测在什么水平上设置适用于各种流量负载和服务图依赖性的 CPU 利用率阈值。流量与微服务加载以及性能之间不存在线性关系，这并不是更改应用程序部署状态的唯一原因。 SRE 还监控温度、故障和延迟等问题。
对于典型的 Kubernetes 应用程序，平均有数百个微服务。此外，每个微服务都依赖于与其他微服务互连关系网络中的其他微服务。对于一个人来说，查看并理解这一切，然后进行详细的更改，并每周对每个微服务的每个版本重复执行此操作并不容易。 SRE 象征性地“转动计算旋钮”，并希望它能够改善低于服务级别目标 (SLO) 的任何情况。但现实情况是，在一个依赖于另一个微服务的微服务上增加资源是没有用的，这实际上是瓶颈。
人工智能的理想用例
2024 年，当有人提到 AI 时，下一个想到的几乎必然是 ChatGPT。 ChatGPT 是生成式人工智能，可以选择最佳的下一个单词。虽然强大的 AIOps 平台所需的架构与 ChatGPT 有很大不同（稍后会详细介绍），但目标是相似的 – 为应用程序选择最佳的下一个状态。
现代微服务应用程序错综复杂的互连生态系统太大、太复杂，SRE 团队无法详细理解并做出这些决策。大多数自动扩展这些应用程序的努力都未能考虑到各个服务的细微差别要求和性能需求。 20 多年来，我不断听到这个问题（从我们在 Arrowpoint Communications 发明的 L5 网络负载均衡器开始）。
数字孪生逐步发展
训练数据是人工智能的燃料。为了教应用程序操作关键任务 Kubernetes 实例，我们需要开发有关如何优化性能的良好信息。数十年来，数字孪生已在多个领域得到应用，包括制造业 和 竞赛帮助人们重新创建真实对象的数字版本以研究其行为。在我们的案例中，我们使用性能指标来构建每个微服务的数字孪生。
在强化学习 (RL) 中，数字孪生用于创建模拟环境来生成观察空间，在其中可以训练模型来发现和学习最佳路径（也称为“轨迹”） ）来引导系统达到在成本、性能等方面具有所需目标属性的状态。在我们的例子中，我们使用近端策略优化（PPO）作为 RL 训练算法。我们的方法是服务图感知的，以考虑影响扩展的微服务的依赖性。最终，我们将拥有一个基于运营经验不断学习的无模型网络。
更好的响应能力和持续改进
Kubernetes 已经取得了长足的进步。有广泛的工具级自动化，但没有很多有效的系统级自动化。也许这与 Kubernetes 实例中的大量活动有很大关系。我们将问题归结为决定应用程序的最佳下一个状态。
人们一直在玩弄生成式人工智能，它可以为普通观众生成文字和图像。我们正在看到同样的技术如何改变我们的数字体验。
对于现在的 SRE 和未来的开发人员
今天的 SRE 可以从转型中受益。通过与 SRE 团队交谈，我们了解到他们被要求为自己的 SLO 做出贡献，但他们根本不知道从哪里开始。看来 Kubernetes 的复杂性已经超出了人类单独操作它的能力。
展望未来，应用 AIOps 模型并转向自主基础设施可以使微服务应用程序的复杂性和规模达到新的水平。