上线门禁

概述 凌晨一点四十七分，手机震了。告警群炸了。 某出行项目新上线的推荐服务，上线不到 2 小时，3 个 Pod 全部 OOMKilled。内存从 800MB 飙到 2GB 限制值，然后被内核杀掉，Kubernetes 拉起新 Pod，又被杀掉。循环往复，用户请求全部打到降级链路上，P99 延迟从 80ms 飙到 2000ms。 事后复盘，问题出在哪？开发团队写了完整的单元测试，通过了代码审查，跑了压测——但没有人问过一个最基本的问题：这个服务在生产环境到底"准备好了"没有？ “准备好了"这三个字，在 SRE 圈子里有个正式名字：生产就绪审查（Production Readiness Review，PRR）。Google 在 SRE Book 第 32 章把它定义为 SRE 接手服务运维的第一步——只有通过 PRR 评审，SRE 团队才会同意承担该服务的运维责任。 但问题来了。传统 PRR 是一份文档，由 SRE 工程师逐条检查，填表签字。这种做法在服务数量少的时候还行，当一个企业有 50+ 微服务同时迭代时，人工 PRR 就成了发布瓶颈。开发团队抱怨"审批太慢”，SRE 团队抱怨"服务太多审不过来"，最后 PRR 变成走形式——签字盖章，该炸还是炸。 这篇文章讲的是：怎么把 PRR 从人工文档变成自动化门禁，用 7 个维度的可机器检查项替代人工判断，让"准备好"这件事变成 CI/CD 流水线上的一道闸门，而不是会议室里的一场审批会。 生产就绪审查到底是什么 先说人话。 生产就绪审查就是：一个服务在正式承接真实用户流量之前，必须通过的一组检查。检查的核心问题是——“如果这个服务在生产环境出事了，我们能不能发现、能不能定位、能不能恢复”。 这不是代码审查。代码审查关心的是"代码写得对不对"，PRR 关心的是"这个服务放到生产环境能不能活下来、出了事能不能救回来"。一个代码写得很漂亮但没有任何监控告警的服务，代码审查能通过，PRR 不能通过。 Google 的 PRR 模型覆盖几个核心维度：架构韧性、容量规划、监控告警、故障恢复、部署流程、安全合规。我在实际落地时把它扩展到 7 个维度，因为多出来的两个——运维归属和成本可见性——是我踩了坑之后发现不能省的。 维度 核心问题 传统人工检查 自动化门禁 架构韧性 挂一个副本会不会全挂 看部署 YAML 确认副本数 检查 PDB + 拓扑分布约束 资源配额 会不会 OOM 或 CPU 限流 看资源配置 检查 requests/limits + 历史利用率 部署安全 发坏了能不能回滚 问开发"能不能回滚" 检查滚动策略 + 回滚超时 可观测性 出了事能不能发现和定位 看有没有 Prometheus 指标 检查四金信号指标 + 告警规则 故障恢复 数据丢了能不能恢复 看有没有备份 检查备份频率 + 恢复测试记录 安全合规 权限管没管住 看 RBAC 配置 检查 NetworkPolicy + 镜像扫描 运维归属 出了事找谁 看 Wiki 文档 检查服务目录 + Runbook 链接 为什么人工 PRR 会失效 我在某出行项目推进 PRR 的时候，最初用的就是人工审查。SRE 团队写了一份 40 页的检查清单，每次新服务上线前，开发团队填表，SRE 逐条审核。结果三个星期后发现：...