devops

AWS DevOps Agent：10个最佳实践，充分利用它

发布: (2025年12月30日 GMT+8 01:27)
14 min read
原文: Dev.to

Source: Dev.to

在 AWS re:Invent 2025 的关键发布之一是全新前沿自主代理的推出：

  • AWS DevOps Agent
  • AWS Security Agent
  • Kiro Autonomous Agent

其中，AWS DevOps Agent 将彻底改变 DevOps 和 SRE 团队的工作方式。以下是充分利用 AWS DevOps Agent 的关键最佳实践。

1. AWS DevOps Agent 是一种 能力，而不是工具

“你没看错。DevOps Agent 并不是在你喝茶时就能解决所有问题的灵丹妙药。”

它是一种 能力——其结果取决于你的使用方式。

示例

你不能仅仅安装一个 AIOps 代理就指望 MTTR（平均修复时间）自动下降。

  • 警报仍会以相同的方式触发。
  • Runbook 无法执行。
  • 将没有服务所有权或已定义的 SLO（服务水平目标）。

你需要做的事

  1. 为每个服务定义 SLO。
  2. 将 Runbook 转换为 可执行的流程。
  3. 提供可观测性。
  4. 确保变更可见性。
  5. 启用其他能力，使代理能够：
    • 关联部署。
    • 提出解决方案。
    • 在有人参与的情况下执行。

记住：能力涉及 人员、流程和工具，而不仅仅是软件。

2. 可观测性是关键 – 代理需要 上下文

可观测性仍然至关重要。如果你以为可以把可观测性的话题搁置一旁，你会大吃一惊。代理需要上下文来行动，而上下文来源于你的遥测数据（指标、日志和追踪）。

如何提供上下文

  • 聚合所有遥测来源。
  • 如果 CloudWatch 不是你的首选，可以使用与主流可观测性工具的集成，例如 Datadog、Dynatrace、New Relic 和 Splunk。

目标是让代理通过遥测看到事件的 影响范围，从而了解系统的内部状态并以正确的意图采取行动。

示例

场景缺乏完整可观测性拥有完整可观测性
负载均衡器出现 5xx 错误代理仅看到 5xx 次数 → 建议扩容负载均衡器或服务。遥测显示 SQL 查询慢且 RDS 连接池耗尽（CPU 高）。代理判断根本原因是 RDS 问题，而非 ALB。

让代理了解 影响范围，而不仅仅是症状。可观测性是提供这些上下文的基础。

3. 定义 golden signals（latency、error rate、saturation、traffic）

Agents reason better on symptoms (effects) rather than raw alerts, which often generate noise. The more symptom data the agent has, the better it can act.

推荐做法

  • 而不是 使用 CPU > 80% 或 Memory > 75% 之类的警报，而是定义阈值，例如：

    • checkout latency P95 > 2 s
    • error rate > 1 %

  • 警报随后由 延迟增加 或 错误率上升 触发。

结果
即使基础设施指标看起来正常，代理也能对 用户体验 进行推理，从而更好地检测影响终端用户的问题，并实现更有效的根因分析。

4. 提供 可操作的指导 – 而非仅仅是维基

仅提供调查指引的 Runbook 本质上是文档。要让代理真正有用，需要赋予它 可执行的能力。

实现方式

  1. Lambda 函数，能够：

    • 拉取遥测数据。
    • 执行修复操作。

  2. Step Functions（或其他工作流引擎）来编排这些 Lambda 函数。

  3. 明确定义 前置条件、安全操作和回滚步骤。

示例工作流

步骤描述
Lambda 1确定根本原因（例如，SQS 堆积过高）。
Lambda 2确定正确的恢复操作（例如，重启消费者 Pod）。
Lambda 3执行修复（重启 Pod）。
Step Functions编排上述三个 Lambda，包含批准关卡和回滚逻辑。

在事故处理中，代理可以：

  • 调用 Lambda 拉取队列深度和消费者延迟。
  • 分析故障模式。
  • 推荐（或在获得批准后）执行 Step Functions 工作流。

这样，代理就成为 主动的运维人员，而不仅是被动的观察者。

5. 把代理当作人来对待——关注 护栏，而不是一刀切的权限

为代理授予完整的管理员权限和完全不给予它所需权限一样糟糕。代理需要 合理的访问级别 才能完成工作。

推荐的权限策略

  • 最小权限 IAM 角色 仍然很重要。
  • 护栏：明确界定 代理可以做什么、不能做什么。
    • 对 诊断 提供宽泛的访问（只读）。
    • 对 修复操作 实施严格控制（写入/执行）。

对于代理，你需要习惯在明确定义的轨道内运行的自主性，而不是试图阻止每一种可能的操作。

TL;DR 检查清单

  • ☐ 将 DevOps 代理视为一种 能力（人员 + 流程 + 工具）。
  • ☐ 提供 完整的可观测性（指标、日志、追踪），覆盖所有来源。
  • ☐ 定义 黄金信号 并使用基于症状的告警。
  • ☐ 用 可执行的 Lambda/Step Functions 工作流 替代静态运行手册。
  • ☐ 应用 护栏：诊断使用最小权限，修复采用受控方式。

遵循这些实践，你就能释放 AWS DevOps 代理 的全部潜能——将它从推荐引擎转变为云环境中具备上下文感知的自主运营者。

6. 为 Agent 制定知识转移计划 – 你的团队成员需要一点“看护”

将 DevOps Agent 当作新加入的团队成员来对待。它在 AWS 方面可能是超级英雄，但在 你们特定的云实现 上仍然是新手。

  • 用详细信息对 Agent 进行培训，让它能够全面了解你的架构、实现方式和业务背景。
  • 把它想象成刚加入团队的资深解决方案架构师——不要假设它已有先前知识。
  • 把你拥有的所有资料都分享并做好入职引导，而不是让它直接投入火灾扑救（紧急故障处理）。

需要提供的内容：

  • 架构图
  • 文档
  • 服务映射
  • 业务背景
  • 已知的故障模式

这些信息可以让 Agent 在处理警报时，将支付 API 的优先级置于报告任务之上，并避免重复已知的错误修复措施。

关键要点： 上下文信息可以减少错误的自动化操作。

7. 让代理了解开发人员在做什么

是的，它是一个 DevOps 代理，但仍然需要了解开发人员正在处理的工作。将你的 CI/CD 流水线连接进来，并向代理提供此可视性。

  • 代理可以 将运营问题与最近的代码更改和部署关联。
  • 它能够识别具体的提交或流水线执行，并将其隔离，以更好地理解根本原因。

Reality check: 目前大多数事件都是代码相关或部署相关的。老话仍然成立——如果你不动它，它就不会自行崩溃。

How this helps

  • 加速代理定位根本原因的能力。
  • 降低平均修复时间（MTTR）。

Example

  1. 在某个时间点出现延迟峰值。
  2. DevOps 代理检查 CI/CD 流水线，发现紧随峰值之前有一次部署。
  3. 该提交包含对支付相关文件的更改。
  4. 代理拉取额外指标，高置信度地将它们关联，并得出警报是由最近的部署引起的，建议回滚。

如果没有 CI/CD 上下文，代理会在调查基础设施问题上浪费时间，从而增加 MTTR。

8. 在代理成熟之前握住它的手——从人机交互开始

最初你需要高度参与——从第一天起就指望完全自主的代理是不现实的。

  • 观察其行为，解释上下文，并提供代理可以执行的详细建议。
  • 所有纠正措施在初期都应经过审批流程。

建立信任

  • 通过设置适当的防护措施，逐步提升自主性。
  • 使用聊天功能提供细节、讨论失败场景，并实时制定响应计划。
  • 如果发现误报或错误的根因分析，纠正代理并说明你不同意的原因，以便其有效学习。

目标： 主动采取行动确保代理成功，而不是等它失败。

示例：

  • 代理建议重启 RDS 实例。
  • 人类拒绝该操作，并解释在高峰时段重启 RDS 可能导致数据丢失或影响客户。
  • 代理学习到时间窗口、业务约束以及更安全的替代方案。

在后期阶段，代理可以自动重启 无状态服务，但对任何 数据层更改 仍需审批。通过引导式自主性建立信任。

9. 使用业务指标衡量代理性能

代理并不是一个部署后就可以忘记的闪亮对象。如果它不能积极改善结果，那它就是毫无用处的。

关键指标

  • Mean Time to Resolve (MTTR)
  • 噪声降低（例如，每次事件的警报数量）
  • 自动识别的根本原因比例
  • 代理执行的补救措施比例

这些指标帮助你了解代理是否在提供真实价值。

没有测量，就没有有意义的改进。

示例

指标部署前部署后
MTTR45 分钟18 分钟
每次事件的警报数12035
自动诊断的事件0 %40 %
自动补救的事件0 %20 %

这些才是你应该努力实现的真实业务收益。如果无法展示可衡量的影响，代理就只是一个闪亮的演示。

10. 主动审视代理调查缺口并努力解决

DevOps 代理在首次尝试时往往不够完善，尤其是在早期阶段。

  • 持续审查调查缺口（例如，遗漏的根本原因、误报）。
  • 迭代改进 代理的知识库、护栏和自动化脚本。

通过系统性地解决这些缺口，您可以确保代理随着时间的推移变得更可靠、更有价值。

调查缺口

由于以下原因，代理将无法继续许多调查：

  • 实现缺口
  • 缺失的上下文
  • 缺乏遥测数据
  • 缺失的功能
  • 权限问题

您需要定期审查这些调查缺口并向代理提供必要的输入。随着时间的推移，这将使代理变得更高效、更智能。

示例

场景：
代理停止调查并报告无法确定根本原因，因为 数据库查询指标缺失。

你的回复：

  1. 启用 RDS Performance Insights。
  2. 添加 慢查询日志。
  3. 创建一个 Lambda 函数来获取查询统计信息。
# Example Lambda function to fetch RDS query stats
import boto3

def handler(event, context):
    client = boto3.client('rds')
    response = client.describe_db_instances()
    # Add logic to retrieve and process Performance Insights data
    return response

结果：
有了这些额外的上下文，代理可以识别长时间运行的查询并建议以下操作：

  • 创建索引
  • 查询限流

关键要点

  • 每一次失败都是代理的训练数据点——而不是放弃它或指责的理由。
  • 持续 与 AWS DevOps 代理一起演进，并将其带入更高水平的自动化和洞察之旅。
Back to Blog

相关文章

阅读更多 »