operational-excellence

卓越运营评估

第 1 步：收集背景信息

询问用户：

您希望我评估哪项工作负载或环境的卓越运营情况？请提供：

• 工作负载名称和简要说明
• 要分析的代码包/目录（CI/CD 配置、IaC、应用程序代码）
• 已知的运营痛点（可选 — 告警疲劳、部署缓慢等）

如果用户已提供详细信息，或您正在代码库中工作，请跳过此提示并开始探索。

第 2 步：CI/CD 和部署探索

分析代码库中的所有 CI/CD 和部署配置。

您必须检查：

• 流水线定义（CodePipeline、GitHub Actions、Jenkins、GitLab CI、CDK Pipelines）
• 部署配置（CodeDeploy、ECS 部署、Lambda 别名、Apollo）
• 构建配置（buildspec.yml、Makefile、package.json 脚本）
• 测试配置（单元、集成、端到端测试设置）
• 部署前关卡（审批阶段、质量关卡、安全扫描）

针对每条流水线/每项部署，记录：

• 文件路径和行号
• 阶段及其用途
• 部署策略（金丝雀、蓝绿、滚动、一次性全量）
• 回滚机制（告警触发时自动回滚、手动回滚、无）
• 测试覆盖率关卡
• 构件晋级流程

您必须标记：

• 生产环境采用一次性全量部署，且没有健康检查关卡
• 未配置回滚机制
• 流水线中没有自动化测试
• 原本自动化的流水线中存在手动步骤

第 3 步：可观测性探索

分析所有监控和可观测性配置。

您必须检查：

• CloudWatch 告警定义（位于 IaC 或配置文件中）
• 控制面板定义（CloudWatch 控制面板 JSON、Grafana 配置）
• 日志配置（日志组、保留期限、结构化日志库）
• 跟踪配置（X-Ray、OpenTelemetry、Jaeger）
• 自定义指标发布（CloudWatch PutMetricData、StatsD、嵌入式指标）
• 合成监控金丝雀（CloudWatch Synthetics）
• 应用程序级日志记录（结构化日志、关联 ID、日志级别）

针对每个可观测性组件，记录：

• 监控的内容及原因
• 文件路径和行号
• 覆盖范围的缺口（没有告警的服务、没有跟踪的流程）

您必须标记：

• 没有 CloudWatch 告警的服务或 Lambda 函数
• 服务边界之间缺少分布式跟踪
• 非结构化日志（没有 JSON、没有关联 ID）
• 关键业务操作没有自定义指标
• 日志保留期限设为“永不过期”，但没有说明理由
• 关键用户旅程没有合成监控金丝雀

第 4 步：事件和事件管理探索

分析事件响应和事件管理配置。

您必须检查：

• 告警路由（SNS 主题、PagerDuty/OpsGenie 集成、EventBridge 规则）
• 自动化修复（由告警触发的 Lambda 函数、SSM Automation）
• 运行手册和操作手册（SSM 文档、Markdown 运行手册、Step Functions）
• 升级配置
• 健康检查实现（ALB 健康检查、Route 53、自定义端点）

---STOP--- 检查点：探索完成 — 可以开始依据 WA Framework 进行评估

已在 {packages analyzed} 中发现 CI/CD 流水线（{X} 个流水线定义）、可观测性配置（{Y} 项告警/控制面板/跟踪设置）和事件管理模式。已记录部署策略、回滚机制和监控缺口。

是否要我继续依据 WA Operational Excellence 支柱问题评估这些发现并评估风险等级？

在用户明确确认之前，不得继续。

---

第 5 步：依据 WA Framework 问题进行评估

针对每个问题，提供：状态、证据（文件:行号）、缺口、风险。

OPS 1 — 您如何确定优先事项？

• 查找：SLO/SLI 定义、业务指标控制面板、健康检查端点
• 证据：告警阈值、显示业务指标的控制面板面板、包含 SLO 目标的 README/文档

OPS 2 — 如何构建组织架构以支持业务成果？

• 查找：CODEOWNERS 文件、清晰的软件包边界、所有权文档
• 证据：CODEOWNERS、package.json 团队字段、README 所有权章节

OPS 3 — 组织文化如何支持业务成果？

• 查找：测试覆盖率、PR 模板、贡献指南、代码审查配置
• 证据：测试目录、.github/PULL_REQUEST_TEMPLATE、CONTRIBUTING.md

OPS 4 — 如何实现可观测性？

• 查找：包含关联 ID 的结构化日志、分布式追踪、自定义指标、仪表板
• 证据：日志记录器配置、X-Ray/OTEL SDK 用法、PutMetricData 调用、仪表板 JSON

OPS 5 — 如何减少缺陷、简化修复并改善上线流程？

• 查找：自动化测试（单元、集成、端到端）、代码检查、安全扫描、分阶段部署
• 证据：测试文件、ESLint/prettier 配置、SAST 工具配置、流水线阶段定义

OPS 6 — 如何降低部署风险？

• 查找：金丝雀/蓝绿部署、功能标志、自动回滚、部署告警
• 证据：CodeDeploy 部署配置、功能标志 SDK 导入、回滚告警 ARN

OPS 7 — 如何确认已准备好支持工作负载？

• 查找：针对已知故障模式的运行手册、部署前检查清单、负载测试、运营就绪评审
• 证据：SSM 文档、运行手册 Markdown 文件、负载测试脚本、就绪配置

OPS 8 — 如何了解工作负载的健康状况？

• 查找：复合告警、健康仪表板、依赖项健康跟踪、SLI 监控
• 证据：CompositeAlarm 构造、仪表板定义、健康检查端点

OPS 9 — 如何了解运营的健康状况？

• 查找：DORA 指标跟踪、部署成功监控、流水线健康仪表板
• 证据：流水线指标、部署监控告警、运营仪表板

OPS 10 — 如何管理工作负载和运营事件？

• 查找：针对运营事件的 EventBridge 规则、自动修复 Lambda、升级配置
• 证据：EventBridge 规则定义、修复 Lambda 代码、SNS 主题订阅

第 6 步：风险评估

针对每项发现，使用“影响 × 可能性”进行评估：

影响：轻微（造成不便，但有手动解决方法）| 中等（检测延迟、恢复时间延长）| 严重（未检测到的中断、无法回滚、数据丢失）

可能性：低（需要特殊情况）| 中（在正常运营中可能发生）| 高（很可能在下一次事故或部署期间发生）

影响	可能性	风险级别
严重	高	严重
严重	中	高
严重	低	高
中等	高	高
中等	中	中等
中等	低	中等
轻微	高	中等
轻微	中	低
轻微	低	低

第 7 步：生成评估结果

# Operational Excellence Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Maturity**: {1-5} — {one-line justification}

## Maturity Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| CI/CD & Deployment | {score} | {strength} | {gap} |
| Observability | {score} | {strength} | {gap} |
| Incident Management | {score} | {strength} | {gap} |
| Change Management | {score} | {strength} | {gap} |
| Continuous Improvement | {score} | {strength} | {gap} |

## Critical and High Risk Findings
{For each: ID, domain, title, description, evidence (file:line), impact, recommendation, effort, AWS services}

## Medium Risk Findings
{Same format, condensed}

## Low Risk Findings
{Summary table: ID | Domain | Title | Recommendation}

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Impact | Effort |
|---------|--------|--------|--------|
{Add alarms, fix log retention, enable rollback}

### Foundation (1-4 weeks)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Add tracing, implement canary deployments, create runbooks}

### Strategic (1-3 months)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Chaos engineering, self-healing automation, DORA metrics tracking}

## Next Steps
{Top 5 concrete actions the team should take this week}

第 8 步：提供后续选项

交付评估结果后，提供以下选项：

您希望我：

• 深入分析 CI/CD、可观测性或事件响应？
• 为已发现的缺口生成 CloudWatch 告警和仪表板 IaC？
• 针对特定故障模式创建运行手册？
• 为反复出现的问题设计自愈架构？
• 实现包含关联 ID 的结构化日志？

校准指南

• 如果工作负载具备 CI/CD 流水线、自动回滚、CloudWatch 警报和结构化日志，则属于成熟状态——应重点关注高级改进（混沌工程、基于 SLO 的告警、运营审查）
• 每项发现都必须有代码证据——检查现有内容后，不要泛泛地建议“应该添加监控”
• 如果无法从代码中确定某项信息（例如值班轮换质量、事件审查流程），请标记为“无法确定”，并说明需要哪些信息
• 列出差距之前，明确肯定现有的运营优势
• 对于正在进行架构转型的工作负载，应重点关注新架构带来的运营要求