跳到主要内容

v1.9.0 — 事件预扩容 + Aurora 数据层基础（ADR-030）

· 阅读需 6 分钟
AWSops Team

v1.9.0 新增了事件预扩容功能，用于在可预测运维负载的事件（促销、直播、季度结算等）之前预热资源。同时，为了解构单台 EC2 主机上构建、运维、本地 JSON 状态全部耦合在一起的架构，本次还引入了 ADR-030 Aurora 数据层基础（CDK 栈、Schema、db.ts）。本次发布中的 Aurora 以默认 off / opt-in 的方式引入，对现有单主机部署没有影响。

核心变化

事件预扩容（ADR-010 Phase 1+2） · Aurora Serverless v2 基础（ADR-030 Phase 1） · ADR-029 变更操作门禁 · AI 代码审查工作流 · 僵尸连接清理强化

事件预扩容（ADR-010 Phase 1+2）​

为了能在大型流量事件开始之前预热资源，新增了 /event-scaling 管理员页面。从注册到脚本下载分为 4 个步骤：

  1. 注册事件 — 事件名称、开始/结束时间、受影响资源标签
  2. 采集历史指标 — 如果过去发生过同类事件，则通过 GetMetricData 批量采集该时段的 CloudWatch 指标（ASG·RDS·MSK·EBS·ALB）
  3. AI 生成预热计划 — Bedrock Sonnet 4.6 为每种资源生成多阶段预扩容计划，并通过 PLAN_JSON 标记返回结构化结果
  4. 下载 bash 脚本 — 按资源类型生成安全脚本（KEDA·HPA、Aurora 添加 Reader、MSK 分区扩展、ASG warm pool、EBS IOPS 提升）

先审后执行（mutation-by-review）​

仪表盘**不会直接执行变更操作。**脚本仅供下载，由运维人员审阅后在合适的环境（kubectl、aws cli）中自行应用。这与 ADR-029（Proposed）的变更操作门禁模型 —「AI 生成的 mutating action 只有在获得明确的人工批准后才可执行」— 保持一致。

相关文件​

文件职责
src/app/event-scaling/page.tsx事件注册·指标图表·计划显示·脚本下载 UI（仅限 admin）
src/app/api/event-scaling/route.tsCRUD + 指标 + Bedrock 计划 + 脚本（GET/POST/PUT/DELETE）
src/lib/event-scaling.ts数据模型 + JSON 持久化（data/event-scaling/）
src/lib/event-scaling-prompts.tsBedrock Sonnet 4.6 提示词 + PLAN_JSON 解析
src/lib/event-scaling-scripts.ts按资源类型的 bash 脚本生成器
src/lib/queries/event-scaling.tsCloudWatch GetMetricData + ASG/RDS/MSK/EBS/ALB 资源状态查询

Aurora 数据层基础（ADR-030 Phase 1）​

由于构建服务器和运维服务器绑定在同一台 EC2 上，AgentCore Docker 构建时 Next.js 延迟会飙升、Steampipe FDW 查询会超时。为解决此问题，ADR-030 决定转向 ECS Fargate 工作负载 + Aurora 应用状态 + 双 ECR（Dev=Private、Prod=Public）。v1.9.0 仅包含其中的 Phase 1 基础部分。

本次引入的内容​

组件说明
infra-cdk/lib/awsops-data-stack.tsAurora Serverless v2 PostgreSQL 15.5（0.5–4 ACU、Writer + Reader、KMS 加密、IAM 认证、Private Subnet、rds.logical_replication=1）
infra-cdk/data/schema.sql幂等的 7 表 Schema（inventory_snapshots、cost_snapshots、agentcore_memory、agentcore_stats、alert_diagnosis、event_scaling_plans、report_schedules）+ schema_migrations 版本追踪 + touch_updated_at 触发器
src/lib/db.ts应用侧 pg Pool（与 Steampipe 池分离）。支持 AURORA_DATABASE_URL DSN 或 AURORA_HOST/USER/PASSWORD/DB 独立环境变量，提供 isAuroraEnabled() / checkDbHealth() 辅助函数
scripts/13-deploy-aurora.shCDK 部署 + 从 Secrets Manager 获取凭证并通过 psql 应用 Schema。支持 deploy / schema / status / dsn 子命令

opt-in 部署​

默认为 off。要启用，需明确指定上下文标志：

cd infra-cdk
npx cdk deploy AwsopsDataStack -c enableAurora=true
# 或使用脚本
../scripts/13-deploy-aurora.sh deploy

如此设置门禁的原因是：(1) Aurora Serverless v2 最低 0.5 ACU 计费（约 $43/月）并不适合所有环境；(2) Phase 1 dual-write 尚未引入，实际数据仍写入 data/*.json。

Steampipe 保持不变​

ADR-030 的微妙之处在于：Steampipe 是 stateless 的。FDW 实时查询 AWS API 并将结果短暂存放在内存中，因此即使容器重启也没有会丢失的「数据」。Aurora 所替代的不是 Steampipe，而是仪表盘自身在 EC2 磁盘上积累的 data/*.json（库存·Cost·内存·alert 记录·event-scaling 计划等）。

下个版本计划（Phase 1 dual-write）​

7 个源文件将获得双写路径。写入同时进入 JSON 和 Aurora 两侧，读取在7 天奇偶校验门禁通过之前继续从 JSON 侧进行：

  • resource-inventory.ts、cost-snapshot.ts、agentcore-memory.ts、agentcore-stats.ts、alert-knowledge.ts、event-scaling.ts、report-scheduler.ts

ADR-029：变更操作框架（Proposed）​

事件预扩容以先审后执行的方式引入，是因为 ADR-010 Phase 3（自动执行）的门禁模型尚未确定。ADR-029 将该门禁 —「在什么条件下、以什么权限模型允许执行 AI 生成的变更操作」— 以 Proposed 状态登记，明确其为未来 Phase 3 工作的先决条件。

AI 代码审查工作流​

新增了在 PR 打开或更新时由 Claude 自动执行代码审查的 GitHub Actions 工作流（.github/workflows/claude-review.yml）。审查提示词针对 AWSops 约定（Steampipe pg Pool、basePath、SCP 阻断列等）进行了定制。

僵尸连接清理强化​

src/lib/steampipe.ts 的僵尸清理任务改为使用专用的短生命周期 Client，而不再从池中借用 connection。即使 Cost Explorer/IAM 摘要 FDW 处于 hung 状态导致整个池耗尽，清理也能继续运行。阈值也缩短到了 90 秒。

统计对比​

项目v1.8.1v1.9.0变更
页面4143+2（/event-scaling、/login 修正后计入）
API 路由1819+1（/api/event-scaling）
SQL 查询文件2526+1（event-scaling.ts）
ADR28 篇（001-028）30 篇（001-030）+2（029 Proposed、030 Accepted）
CDK 栈3（Awsops·Cognito·AgentCore）4+1（AwsopsDataStack，opt-in）
部署脚本12 步13 步+1（13-deploy-aurora.sh）
lib 文件2731+4（event-scaling* 3 个、db.ts）

参考​