生产就绪不是一次评审:文档、证据与持续治理如何落地

上一篇讨论了安全架构：身份、权限、密钥、数据和审计必须从系统边界开始设计，而不是上线前再补几项配置。

到这里，一个生产系统需要考虑的主要架构问题已经逐步展开。但还有最后一个问题：这些设计怎样在系统上线以后继续有效？

架构图可能已经过期，压测报告对应的是旧版本，Runbook 只有原作者能执行，曾经接受的剩余风险长期没有整改。即使上线前通过了一次生产就绪评审，也不能证明半年后的系统仍然具备相同条件。

生产就绪不是一个永久状态，而是一组架构主张在当前版本、当前流量、当前依赖和当前团队责任下，仍然有证据成立。

生产就绪评审不是上线盖章

生产就绪评审通常称为 PRR，即 Production Readiness Review。它要判断的不是功能能否演示，而是系统在真实环境中是否具备发布、观测、恢复、安全运行和被团队长期负责的条件。

Google SRE 对 PRR 的介绍把它用于验证服务是否满足生产设置和运行准备要求，并降低上线后的事故数量与影响。但 PRR 不是一张可以复制到所有系统的固定表格。服务的重要程度、依赖关系、数据风险和运行方式不同，评审重点也应该不同。

一次有效评审至少要形成四类结论：

• 哪些生产条件已经由证据证明；
• 哪些条件尚未满足，因此必须阻止发布；
• 哪些风险可以在限定条件下暂时接受；
• 谁负责后续整改，什么变化会使当前结论失效。

如果评审只留下“通过”两个字，几个月后就无法判断当时依据什么版本、什么环境和什么证据作出决定，也无法知道哪些风险被有条件地保留下来。

文档首先要支持理解、运行和恢复

文档的价值不在于数量，而在于非原作者能否依靠它理解系统、评估变更并完成故障处置。

一个生产服务通常需要几类相互关联的文档：

ADR 是 Architecture Decision Record，即架构决策记录。它不需要写成长篇设计文档，而是保留决策背景、候选方案、最终取舍、约束和后果。以后条件变化时，团队才能判断原来的选择是否仍然成立，而不是把历史实现误认为不可改变的规则。

Runbook 是运行处置手册。它不能只写“重启服务”“检查日志”，还要说明触发条件、所需权限、操作风险、中止条件、预期结果和恢复后的业务验证。涉及资金、数据修正和灾备切换时，还要明确什么情况必须转人工审批。

文档也需要有适用对象和版本。架构图对应哪个服务版本，接口契约从哪个版本生效，Runbook 最近一次演练是什么时候，责任人是否仍然在岗，都应能够被查到。否则文档越完整，误导性可能越强。

证据必须和架构主张、版本与环境关联

这个专题反复强调：测试通过、部署成功、生产就绪和生产长期稳定是不同层次的结论。

所以，证据不能只放在一个共享目录里。它至少要关联服务、版本、制品摘要、配置基线、环境、验证时间、执行者和结论。压测报告没有数据规模和流量模型，故障演练没有中止与恢复记录，安全扫描没有规则版本和覆盖范围，都不足以支撑明确结论。

例如，退款服务增加“大额人工复核”状态以后，原来的接口测试、压测和 Runbook 不能自动证明新版本仍然生产就绪。授权规则、任务积压指标、人工处置入口和恢复路径都发生了变化，原有证据需要重新确认适用范围。

证据还要允许结论被推翻。流量模型改变、外部依赖升级、数据量增长、重试策略调整、权限边界变化或团队责任转移后，原来的证明范围可能已经失效，需要重新验证，而不是继续引用旧报告。

PRR 应该按风险分级，而不是所有服务共用一套门槛

生产治理常见两种做法：

更实际的做法通常是组合使用。所有服务先满足最小基线，例如责任人、关键依赖、备份、观测、安全身份和故障入口；再根据业务影响、数据敏感度、外部副作用、流量规模和恢复目标提高评审强度。

低风险内部查询服务可以采用轻量自检和团队确认；涉及资金、权限、敏感数据或不可逆动作的服务，需要独立验证、安全评审、恢复演练和明确的风险接受人。重大架构变更即使功能范围不大，也可能触发重新评审。

评审结论也不必只有“通过”和“不通过”。可以区分已经满足、带条件满足和阻塞发布，但每一种状态都必须有明确条件。所谓“带条件”不能成为长期绕过标准的入口，它必须关联补偿措施、责任人和到期时间。

剩余风险必须由有权的人接受

生产系统不可能消除全部风险。问题不是能否做到零风险，而是谁在什么证据下接受哪一项剩余风险。

一条可以管理的剩余风险至少要记录：

• 风险是什么，可能影响哪些用户、数据和业务结果；
• 为什么当前无法立即消除；
• 已有什么缓解或补偿措施；
• 哪些指标或事件表明风险正在扩大；
• 谁有权接受，接受到什么时间；
• 何时必须重新评审或停止运行。

架构师可以分析风险，平台和服务团队可以提出缓解方案，但不能代替业务或管理责任人接受超出其权限的业务后果。开发人员在工单中写一句“暂时接受”，也不能成为高风险系统继续上线的充分依据。

当补偿措施失效、风险超过期限、业务影响扩大或原责任人已经变化时，当前风险接受结论应视为失效，重新进入整改或发布阻塞；具备治理平台时，可以由系统自动标记并触发重新评审，而不是无限延期。

平台要把生产基线变成默认能力

如果每个服务团队都要从头接入日志、Trace、密钥、发布门禁、备份和漏洞扫描，生产就绪会退化成大量重复建设，检查表也会越来越长。

平台工程更适合提供一条受支持的默认路径。服务目录是统一登记服务、依赖、责任人和运行信息的入口，可以把分散的生产信息关联起来。例如：

• 服务模板默认包含健康检查、结构化日志、指标和请求关联；
• 制品构建默认记录版本、依赖、摘要和验证结果；
• 发布流水线默认执行契约、迁移、安全和回滚预检；
• 运行平台默认提供身份、密钥、资源边界和审计接入；
• 服务目录默认记录 SLO、Runbook 和当前风险；
• 自检接口能够持续报告关键生产条件是否满足。

默认能力可以减少团队反复实现相同机制，但不能替代业务责任。平台能够检查服务是否配置了超时，不能决定退款业务超时后应该重试、查询还是转人工；平台能够保存审计记录，不能定义谁有权批准大额退款。

例外也不能被完全禁止。有些服务确实需要不同的存储、网络或恢复方案，但例外应说明原因、责任、验证方式和退出条件。否则所谓技术自由最终会变成无人维护的运行分叉。

责任接管要通过演练，而不是通过会议宣布

系统由原开发者运行一段时间后，经常需要交给值班、运维或其他团队。文档已经移交、培训已经完成，不等于新责任人能够独立处置问题。

接管验证可以选择一个受控场景：让没有参与原始开发的人根据告警定位故障，查到服务依赖，找到 Runbook，获取必要权限，执行缓解和恢复，并确认业务状态已经正确。原作者只观察，不代替操作。

演练能够暴露文档中看不见的问题：告警没有指向责任人，权限申请需要原作者，Runbook 缺少前置条件，恢复步骤只能修复技术状态，或者依赖团队根本不知道自己被写进了处置流程。

只有非原作者能够在目标时间内完成理解、判断和处置，运行责任才真正发生转移。无法接管时，结论应是责任仍未转移，而不是要求新团队签字后自行承担未知风险。

持续治理由变化触发，而不是按年复查一次

系统的生产条件会随着变化不断失效。持续治理需要识别哪些事件应该触发重新验证：

• 业务范围、风险等级或关键用户群变化；
• 服务边界、数据所有权或主要依赖变化；
• 流量、数据量、消息大小或保留周期显著增长；
• 数据库、消息、身份、构建或运行平台发生重大升级；
• SLO、RTO、RPO、权限和合规要求变化；
• 发生严重事故、长期告警或重复人工处置；
• 服务负责人、值班团队或外部供应商发生变化。

Google SRE 的发布检查实践也强调检查表需要根据内部基础设施和服务特点调整，并定期清理过时内容。持续治理不是每年把旧表格重新勾选一遍，而是让真实变化和运行事件驱动相应的架构、证据和责任更新。

一个基本闭环可以是：变化进入服务目录或发布流程，系统识别受影响的生产条件，自动执行可以确定的检查，把无法自动判断的风险交给责任人，整改结果重新关联到当前版本，生产运行继续提供反馈。

服务评分可以发现趋势，但不能替代判断

团队可能把文档完整度、测试覆盖、SLO、漏洞、告警和演练情况汇总成服务评分。这有助于发现长期没有维护的服务和共性能力缺口，但评分不能成为生产就绪的唯一答案。

两个得分相同的服务，可能分别存在“文档少但风险低”和“资金操作缺少授权审计”两种完全不同的问题。平均分还可能掩盖单项阻断风险，例如备份从未恢复验证、生产环境使用共享管理员凭证。

评分适合用于排序、趋势和资源投入，不适合抵消硬性条件。涉及身份缺失、数据不可恢复、关键依赖无责任人或高风险动作不可审计时，不应允许其他指标的高分把问题平均掉。

Agent 和 AI 功能不能降低生产门槛

Agent Runtime、工具调用和语义服务进入生产以后，同样需要服务责任人、依赖拓扑、版本基线、权限边界、SLO、Runbook 和验证证据。

模型评测通过只能支持已覆盖输入上的行为判断，不能证明工具权限、外部副作用、数据传播和故障恢复已经满足生产要求。模型、Prompt、Skill、工具版本或语义模型发生变化，也可能让原有证据失效。

AI 可以帮助检查文档差异、整理证据、发现过期依赖和生成评审建议，但最终风险接受必须由明确责任人完成。Agent 自己生成一份“生产就绪报告”，不能同时成为报告的独立证据和批准者。

持续治理也要留下验证证据

治理是否有效，不能只看检查项完成率，还要看逾期风险、重复事故、接管失败、无责任依赖和人工绕过是否在减少。表格变得更完整而运行问题没有变化，说明治理可能只增加了文档负担。

小系统也需要最小治理基线

低风险、依赖简单、故障可以在工作时间人工处理的内部系统，不需要完整 PRR 委员会、复杂服务评分和持续合规平台。

最小治理基线仍然应该包含：系统用途和边界、当前责任人、关键依赖、部署与恢复方法、基本观测入口、已知剩余风险，以及能够证明当前版本可运行的测试和发布记录。

这些内容可以放在一个简短文档和现有流水线中。重点不是形式统一，而是换一个人以后仍然知道系统为什么这样设计、出问题找谁、怎样恢复，以及哪些结论有证据支撑。

小结

从总体架构、服务边界、内部依赖，到分布式状态、技术选型、容量、可观测性、容错和安全，这些设计最终都要进入可以持续维护的文档、平台能力、运行责任和验证证据。

生产就绪
不是一次评审的结论，
而是架构主张在持续变化中仍然有证据成立。

文档不是归档材料，PRR 不是上线盖章，评分也不能替代风险判断。真正的持续治理，是让每一次重要变化都能找到受影响的架构决策、重新生成必要证据，并由有权的人接受剩余风险。

架构设计也因此不是项目开始时的一次活动。它始于业务目标和风险，在实现、发布和运行中不断接受证据检验，再根据真实反馈修正边界、机制和责任。这才是一个系统从“功能完成”走向“可以长期负责”的完整过程。