为 AWS 构建配置漂移检测器（使用 Snapshots、Lambdas 和 Next.js Dashboard）

Source: Dev.to

高层架构

以下是本文使用的架构图：

一览

• AWS 服务（例如 EC2、Security Groups）会按计划进行抽样。
• Snapshot Lambda 将原始 JSON 快照写入 S3 和 Supabase/PostgreSQL。
• Detect Lambda 将最新快照与之前的基线进行比较，以检测漂移。
• Alert Lambda 写入漂移事件、更新基线，并可选地发送 Slack 警报。
• Next.js 仪表盘 轮询由 Supabase/PostgreSQL 支持的轻量级 API，以展示漂移和基线。

文章的其余部分将从 SRE/DevOps 工程师的视角展开，关注快速反馈、清晰的审计轨迹以及不显得像副项目的 UI。

设计目标与约束

当我为此项目设定范围时，我设定了几个明确的目标：

• 检测有意义的漂移，而不是每一个变化的字段。
• 保持架构平淡且可观测：使用托管服务而非定制基础设施。
• 让 UI 对运维人员友好：想象成 SRE 控制台，而不是玩具仪表盘。
• 足够小巧以单独构建，但又足够可信，能够向资深工程师或招聘经理展示。

于是，架构自然地分为四个部分：

1. 快照管道。
2. 漂移检测引擎。
3. 警报与审计日志。
4. Web 仪表盘。

1. 快照管道

什么会被快照？

为了解决问题，我聚焦于 AWS 资源中一个范围狭窄但影响巨大的子集：

• EC2 实例 – 生命周期、实例类型、标签。
• 安全组 – 入站/出站规则以及关联的资源。

这些是常见的“快速修复”和“仅用于调试”更改的来源，随后可能演变为安全性和可靠性问题。

快照在系统中的流转

快照管道围绕一个计划的 Lambda 运行：

• 触发器：EventBridge 规则每 30 分钟运行一次。
• 快照 Lambda：
  1. 调用 AWS API 列出 EC2 实例和安全组。
  2. 将数据规范化为稳定的 JSON 结构。
  3. 将每个快照写入：
     • S3 – 原始、带时间戳的 JSON（例如 YYYY-MM-DD/HH-MM-SS.json）。
     • Supabase/PostgreSQL – 汇总的快照元数据，以便后续更快查询。

这为你提供了：

• 一个 低成本、追加式日志，记录每个时间点的世界状态（S3）。
• 一个 可查询的状态，用于仪表盘和漂移检测（Postgres）。

2. 漂移检测引擎

基线 vs. 快照

系统使用一个简单的思维模型：

• 快照 是“当前世界的样子”。
• 基线 是“我们期望世界的样子”。

每当有新的快照到达时，Detect Lambda 会将其与当前基线进行比较：

1. 按稳定标识符（例如实例 ID）映射每个资源。
2. 仅比较对可靠性/安全性重要的字段。
3. 忽略噪声大、变化快的字段（例如时间戳）。

输出是一组 漂移事件：

每个漂移事件包含：

• 资源元数据（ID、类型、环境）。
• 哪些字段发生了变化（前后对比）。
• 严重性分类（见下文）。

检测完成后，基线会 向前更新，使系统以增量方式跟踪漂移，而不是每次都从头重放。

3. 警报与严重性

并非所有漂移都等同。更改标签并不等同于向全世界开放 SSH。

严重性级别

Alert Lambda 的职责

• 将漂移事件写入 Supabase/PostgreSQL，以便后续查询。
• 根据需要更新基线。
• 可选地为 CRITICAL 和 HIGH 严重性事件发送 Slack 警报。

HIGH 和 CRITICAL 漂移的 Slack 通知

• 频道：例如，#infra-alerts
• 消息包含：资源、环境、严重性以及简短描述。

这可在控制 Slack 噪音的同时，为真正重要的更改提供紧密的反馈回路。

4. Next.js 仪表盘

仪表盘故意保持简洁，但针对 SRE/DevOps 工作流进行优化，而非演示。

关键视图

应用提供三个主要页面：

仪表盘

• 高层次统计：活跃漂移数量、基线数量以及受监控的环境数量。
• 最近的漂移，按时间和严重程度排序。
• 基线概览（哪些环境已覆盖，哪些基线已陈旧）。

漂移

• 漂移事件表，包含：
  • 严重性标签。
  • 资源和环境。
  • 漂移类型（ADDED, REMOVED, MODIFIED）。
  • 检测时间。
• 严重性、状态和环境的过滤器。

基线

• 基线列表，包含：
  • 名称、环境。
  • 状态（Active / Stale / Archived）。
  • 最近更新时间。
  • 链接到按基线过滤的漂移视图。

数据流

仪表盘通过轻量 API 层查询 Supabase/PostgreSQL：

• 获取漂移和基线的列表。
• 支持仪表盘指标的简单聚合（例如活跃漂移的计数）。
• 轮询频率足够高，使 UI 感觉“实时”，但又不至于对后端造成过大压力。

重点在于 运营清晰度。应当能够轻松回答：

• “最近有什么变化？”
• “这个环境的漂移是否比其他环境更频繁？”
• “哪些基线已经过期？”

为什么采用这种架构？

该设计有意避免过早的复杂性：

• 面向周期性工作的无服务器 – Lambda 加上 EventBridge 调度器非常适合“每 N 分钟运行一次并比较快照”。
• S3 + Postgres 提供了持久性和可查询性：
  • S3 用于原始历史数据。
  • Postgres 用于快速读取和简单聚合。
• Next.js 仪表盘：
  • 易于部署。
  • 易于在用户体验上迭代。
  • 与 Supabase 作为后端配合良好。

同时，它也为后续扩展留有余地：

• 添加除 EC2 和安全组之外的更多资源类型。
• 引入按环境的基线以及多账户支持。
• 通过时间线、差异视图和更丰富的过滤器扩展仪表盘功能。

未来改进

• 更好的差异视图 – 在 UI 中展示结构化差异（字段级别的前后对比），而不仅仅是“已修改”。
• 告警策略 – 可配置规则，决定哪些漂移在何处触发告警（Slack、邮件等）。
• 多云支持 – 抽象快照/检测逻辑，以处理其他云提供商。
• 漂移修复钩子 – 对特定类别的漂移，触发运行手册或自动修复。

当前版本聚焦于基础功能：检测、分类、告警和可视化。这已经足以捕获最痛苦的“有人更改了生产环境”问题，并在作品集或博客文章中讲述一个连贯的故事。

总结

Config Drift Detector 最初是为了让配置更改更加可见而创建的，但它也成为了一个很好的 小而专注的架构 练习：

• 一个清晰的数据流：AWS → snapshots → drift detection → alerts → dashboard。
• 最少的移动部件，每个部件都专注做好一件事。
• 一个 UI，反映了运维人员实际调查和响应漂移的方式。

如果你对配置管理、SRE 工具感兴趣，或只是想要一个超越 CRUD 的作品集项目，构建类似的系统是探索 云架构、可观测性 与 开发者体验 交叉点的绝佳方式。