production-audit

Production Audit

当用户询问应用是否准备好上线（ready to ship）、生产环境可能会出什么故障，或者发布前必须修复哪些问题时使用此 Skill。这是对社区早期过时的 production-audit 方案的维护者安全重构版：既保留了核心的生产就绪评估视角，又去除了未指定版本的远程代码执行和第三方数据共享风险。

何时使用

• 用户询问“这能直接上线吗？”、“线上可能会爆什么坑？”、“我们遗漏了什么问题？”、“帮我审计一下这个 repo”或“可以发布了吗？”。
• 新功能已合并，需要在发布前或合并后进行一轮风险排查。
• 即将进行公开发布、Demo 演示、客户交付或投资者演示。
• CI 虽然全绿，但用户不仅想看测试结果，更想评估真正的生产环境风险。
• 已有可用于收集证据的已部署 URL、发布分支（release branch）、PR 或当前工作区代码。

何时不使用

• 处于日常开发编码阶段、焦点在于行级安全编码时；请优先使用 security-review。
• 面对纯库（libraries）、模板、纯文档仓库或脚手架项目时——除非用户明确要求评估打包/发布就绪度而非应用生产就绪度。
• 用户要求进行正式的合规审计时。本 Skill 属于工程维度的风险排查，不提供法律、财务、医疗或行业监管认证。
• 手头只有产品设想，尚无任何仓库代码、部署环境、CI 或运行界面证据时。

工作原理

所有审计结论均基于本地以及用户明确授权的证据构建。切勿擅自运行版本未固定的远程代码、将仓库内容上传至第三方服务，或调用外部扫描工具，除非用户明确批准了该特定工具与数据流向。

请按以下顺序操作：

1. 梳理并明确发布影响面（release surface）。
2. 读取近期变更与当前分支状态。
3. 检查仓库中实际存在的运行时、身份认证（auth）、数据、支付、后台任务、AI 以及部署边界。
4. 检查 CI、测试、数据库迁移（migrations）、环境变量文档和回滚路径。
5. 给出简明扼要的“允许上线/阻断上线”建议，并附上具体修复方案。

证据检查清单

优先从成本低、本地易获取的信号入手：

git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD

接着检查特定项目的相关层面：

• 依赖包脚本（package scripts）、CI 工作流、发布脚本、Docker 文件及部署配置清单（manifests）。
• API 路由、Webhooks、鉴权中间件、后台 Worker、定时任务（cron jobs）和数据库迁移脚本。
• 环境变量文档以及启动健康检查。
• 可观测性钩子（observability hooks）、错误上报、日志记录、健康检查接口和监控大盘。
• 回滚流程、基础数据 Seed、Migration 以及历史数据补全（backfill）说明。
• 核心用户流程的端到端（E2E）测试覆盖情况。

如果审计范围包含已部署的在线 URL，仅对该 URL 进行浏览器或 HTTP 基础检查；除非用户提供了安全的测试账号，否则避免执行需要鉴权的操作。

风险评估视角

安全与鉴权

• 公开路由、API 路由和管理员路由是否隔离清晰？
• 身份认证与权限校验（Auth & Authorization）是否在服务端强制执行？
• 密钥/敏感信息（Secrets）是否避免泄露到了客户端 Bundle、日志、示例输出和提交的文件中？
• 限流（Rate limiting）、CSRF 防护、CORS 策略和文件上传校验是否在必要处落实到位？
• AI 或 Agent 相关交互界面是否防御了 Prompt 注入、Tool 滥用以及不可信内容侵入特权操作的风险？

数据完整性

• 数据库 Migration 是否能平滑向前执行，并备有回滚或恢复预案？
• 破坏性 Migration、数据补全（backfills）和数据导入是否进行了安全的分阶段处理？
• 数据库 Policy、权限赋予（grants）和 service-role 边界是否符合应用的多租户模式？
• 写操作、后台任务和 Webhook 处理函数的重试机制是否具备幂等性（idempotent）？

支付与 Webhooks

• 在解析信任 Payload 字段之前，是否先校验了 Webhook 签名？
• 每个支付、订阅或履约相关 Webhook 是否都保证了幂等？
• 是否妥善处理了重放攻击（replay）、重复投递和乱序投递的情况？
• 测试环境（test-mode）与生产环境（live-mode）的凭证密钥是否相互隔离？

运维与保障

• 应用能否基于干净的代码副本（clean checkout），通过文档记录的命令成功启动？
• 必需的环境变量是否有清晰命名、校验以及 Fail-Fast 机制？
• 是否具备能够证明依赖服务连通性的健康检查（health check）？
• 部署、回滚以及故障负责人（incident-owner）的联系与处理路径是否有文档记录？
• 日志是否既能提供有效排查信息，又不会泄露密钥或个人隐私数据？

用户体验

• 上线关键路径是否兼顾并覆盖了桌面端和移动端？
• 表单在移动端使用时，是否避免了输入框被自动放大（input zoom）、布局重叠或无法提交的问题？
• 加载中（loading）、空状态（empty）、报错（error）和权限不足（permission-denied）状态是否明确告知了用户发生了什么？
• 当核心业务操作失败时，是否有客服支持或自我修复恢复路径？

评分机制

评分是为了明确修复优先级，而非追求数学上的绝对精准。

等级	分数	含义
存在阻断问题（Blocked）	0-49	严禁上线，必须先修复核心高危风险
风险较高（Risky）	50-69	仅允许灰度小范围发布或内部 Beta 测试
可附带条件发布（Launchable With Caveats）	70-84	需负责人明确接受已知风险方可上线
状态良好（Strong）	85-100	现有证据下未发现明显的上线阻断项

若出现以下任意情况，最高得分不得超过 69 分：

• 敏感数据缺乏身份认证或权限校验。
• 支付或订单履约的 Webhook 不具备幂等性。
• 必需的数据库 Migration 无法安全执行。
• 密钥泄露到了客户端 Bundle、日志或版本库文件中。
• 高影响度的重大发布缺少回滚预案。

若 CI 未全绿，或核心上线流程未经端到端（E2E）测试验证，最高得分不得超过 84 分。

输出格式

开门见山用一句话总结：

生产环境审计：76/100，可附带条件发布。在正式公开上线前，需优先修复 Webhook 幂等性和补充回滚文档这两项风险。

随后依次列出：

• Blockers（阻断项）：上线前必须修复的问题。
• High-value fixes（高价值修复项）：用户若想进一步提升得分建议优先修复的项目。
• Evidence checked（已核查证据）：审查过的文件、命令、CI 状态、在线 URL 或 PR。
• Evidence missing（缺失证据）：若补充提供可进一步提高评估置信度的信息。
• Next action（下一步行动）：一个具体的修复或验证步骤。

优点简短提及即可。用户关心的是能否上线，因此最有价值的回答是剩余风险和下一步行动。

示例

用户：

is this ready to ship?

回复：

生产环境审计：68/100，风险较高。原因是 Stripe Webhook 虽然做了签名校验但缺乏幂等处理，且待执行的 Migration 缺少回滚说明。

Blockers（阻断项）:
- 履约处理前需为 `checkout.session.completed` 补充幂等逻辑。
- 编写并测试 `20260511_add_billing_state.sql` 的回滚路径。

High-value fixes（高价值修复项）:
- 增加健康检查，验证数据库与支付服务商的连通性。
- 补充一条涵盖套餐升级、Webhook 履约及账单页刷新的 E2E 测试流程。

Evidence checked（已核查证据）:
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- 发布分支的 GitHub Actions 运行记录

Next action（下一步行动）: 要我现在先帮你补全 Webhook 的幂等逻辑吗？

反模式（应避免的做法）

• 默认把运行 npx <package>@latest 或远程扫描器作为审计手段。
• 未经明确授权，将源码、密钥、客户数据或内部架构拓扑上传至第三方审计服务。
• 给出分数却不列出具体核查过的证据。
• 将 CI 测试全绿直接等同于具备生产就绪度。
• 以句式套路化的“后续有需要随时告诉我”作为结尾。

参见

• Skill: security-review
• Skill: deployment-patterns
• Skill: e2e-testing
• Skill: tdd-workflow
• Skill: verification-loop