AIOps 自动化 DevOps 监控，实现更快速的安全修复
当代码变更速度快于人工审查速度时，AIOps 在 DevOps 中解决了什么问题？
这是一个正确的切入点，因为现代交付流水线可能会以微小、隐蔽的方式失败。一个新库的版本、一个错误的配置文件或一个脆弱的依赖项可能会绕过常规检查，稍后表现为构建缓慢、发布损坏或安全漏洞。
AIOps 将机器学习引入该流程。它观察流水线已经产生的迹象，将其与过去的模式进行比较，并在问题扩散之前标记出看起来异常的地方。
为什么 DevOps 需要更智能的监控
DevOps 团队已经使用测试、日志、警报和部署脚本。问题在于数据量。服务越来越多，代码路径越来越多，变更越来越多，信号也越来越多，超出了人工仔细检查的能力。
这正是 AIOps 发挥作用的地方。它并不替换流水线。它以大规模读取流水线，并寻找在充满噪音的控制台中难以看到的模式。
AIOps 可以发现基本自动化可能遗漏的缺失代码、奇怪代码、脆弱依赖、错误配置以及其他缺陷。它还可以指出不必要或以增加风险的方式编写的代码。
其价值在于检测速度。问题发现得越早，它接触生产系统、日志、客户或安全控制的时间就越少。
这种模式如何运作
尽管工具复杂，但这种模式的形状很简单。
代码存在于源代码仓库中。构建和测试通过 CI/CD 流水线运行。日志和事件在此过程中收集。AIOps 工具研究这些数据流，并学习什么是正常状态。
然后，它们将新的变更与旧的行为进行比较。如果提交以可疑方式更改了代码结构、运行时行为或部署模式，系统可以发出警告或触发操作。
这就是数据如此重要的原因。AIOps 依赖于有用的历史记录。它从源代码、流水线事件、测试输出、部署日志和先前的事件中学习。没有这些数据，它就几乎没有可比较的内容。
企业版的这种模式还需要控制。团队需要访问仓库、用于模型训练的数据层，以及能够在适当阶段调用 AI 检查的流水线。目标不是创建一个巧妙的辅助工具。目标是创建一个将 AI 作为正常流程一部分的流水线。
一个小例子
考虑一个添加新支付服务并更新容器镜像的发布。代码在审查中看起来没问题，单元测试也通过了。但是，新服务使用了未预期的依赖项，并且一个配置值改变了容器的启动方式。
AIOps 可以通过多种方式发现这种不匹配。它可能会注意到依赖项的缺失。它可能会看到启动行为不再符合已知模式。由于过去类似的代码导致测试或预发环境失败，它可能会标记此变更。
该警告为团队提供了一个在发布到达生产环境之前进行查看的位置。修复可能很小，例如恢复丢失的软件包或更正配置文件。重要的是，问题出现得很早，而此时修正变更的成本仍然很低。
安全修复需要相同的流水线纪律
AIOps 通常被讨论为一种运维工具，但安全是同一故事的一部分。一个弱的库、一个有风险的代码模式或一个错误的部署设置可能会迅速转化为安全问题。
一些工具专注于代码审查。另一些关注运行时行为。有些旨在通过日志和指标监控基础设施健康。在一起，它们帮助团队同时捕获缺陷和暴露面。
在实践中，这意味着流水线成为风险的过滤器。审查步骤可以标记不安全的代码模式。运行时步骤可以捕获低效率或异常行为。基础设施步骤可以检测到表面上看起来健康但正朝错误方向漂移的系统中的异常。
这对于经常变动的团队来说是一个实际的收益。快速的发布周期没有留下太多事后进行缓慢人工审查的空间。
AIOps 对企业交付的改变
当堆栈的其他部分为此做好准备时，AIOps 效果最佳。云原生系统有所帮助，因为容器和 Kubernetes 使得更容易将模型与应用程序流的其余部分一起进行测试、打包和部署。
这也改变了团队对数据的思考方式。日志、测试和部署记录不再是遗留物。它们成为训练材料和运营证据。如果数据分散在孤岛中，或者分类不当，模型的可学习内容和可信度就会减少。
这就是企业就绪性重要的原因。数据团队、DevOps 工程师和应用所有者都有各自的角色。一组人知道信号在哪里。另一组人知道流水线的行为方式。还有一组人知道真正的故障是什么样子的。
业务的服务端也发生了变化。事件管理和变更管理团队需要了解为何发出警报以及允许何种类型的自动响应。这里产生虚假的确信感是危险的。重点在于更好的可见性和更快的审查，而不是对模型的盲目信任。
实用的教训
当 AIOps 被视为 DevOps 系统的一部分，而不是一个单独的层时，它能发挥最佳作用。它从仓库数据、流水线事件、日志和旧事件中学习。它检查缺失代码、错误配置、脆弱依赖和异常行为。然后，它可以帮助团队更早地从检测转向纠正。
EuroOp LLC 将此视为一个具有明确商业形态的应用研发模式：让流水线在工作发生的地方变得更智能。这是 EuroOp Insights 旨在反映的工程纪律类型，源自 EuroOp 产品背后流水线的单一实用启示。