3. 验收标准与合同解读

在 Azure 企业云项目里，验收争议往往不是“做没做”，而是“做到什么程度才算合格”。SOW（工作说明书）、主合同与 SLA（服务级别协议）三份文件共同定义了这条合格线，但它们的语言风格完全不同：SOW 描述交付范围与工作内容，合同约定责任边界、付款条件与违约条款，SLA 则给出可量化的服务承诺。验收工程师的核心任务，是把这三类文本翻译成一组可测量、可复现、可判定的验收指标。

一、三类文件的解读侧重点

SOW 是验收清单的“骨架”。阅读时要逐条抽取交付物名词与动词：部署了哪些资源、迁移了哪些系统、交付了哪些文档与脚本。例如“完成 3 套订阅的 Landing Zone 部署，含 Hub-Spoke 对等互联与 Azure Firewall 策略”，这里可验证的对象是订阅数量、拓扑结构与防火墙策略条目，而不是“完成了网络建设”这类模糊表述。

合同提供的是“判定权与后果”。需要重点关注验收期限、默认验收条款、里程碑付款比例、缺陷分级与整改时限。例如合同约定“甲方在收到验收申请后 10 个工作日内未提出书面异议视为通过”，这条直接决定验收流程的时间压力与证据留存方式。

SLA 提供的是“量化阈值”。典型指标包括可用性百分比、工单响应与恢复时长、RPO/RTO、性能基线。解读时必须同时抓取三要素：指标定义、测量方法、统计周期。例如“虚拟机可用性 99.9%”必须追问：按分钟还是按小时采样？是否排除计划内维护窗口？由谁的数据源统计？缺少任一项，指标就不可验证。

二、四类验收的指标特征与判定方式

功能验收回答“交付物是否齐全且行为正确”。指标通常是布尔型或计数型：订阅数量、VNet 地址空间、对等互联状态、防火墙规则条数、备份作业成功率。判定方式以现场核对与操作复现为主，例如从 Spoke 子网发起连通性测试，验证经 Hub 防火墙的放行与拒绝路径是否符合设计。

性能验收回答“在约定负载下是否达标”。指标是数值型并带阈值与统计口径，例如“Web 前端 P95 响应时间 ≤ 800ms，持续 30 分钟，并发 200”。这类指标必须写清测试工具、测试位置、预热时间与采样窗口，否则双方对同一份压测报告会得出不同结论。

安全验收回答“安全控制是否有效落地且无高危缺口”。可验证对象包括 NSG 与 Azure Firewall 规则、Microsoft Defender for Cloud 安全建议的修复状态、特权角色分配、MFA 强制、Key Vault 密钥轮换策略。判定依据应来自平台自身的评估结果与抽样渗透/配置核查，而不是口头承诺。

合规验收回答“是否满足法规、行业标准与内部制度”。典型指标有数据驻留区域、日志留存天数、资源标签完整率、Azure Policy 合规百分比、审计记录可导出性。合规验收常以报告与截图作为证据，并需要明确抽样范围与时间点。

三、把文本条款转成可验证指标的实操方法

推荐使用“条款 → 指标 → 证据 → 判定规则”四列映射法。以一条 SLA 为例：

原文：核心业务系统月度可用性不低于 99.9%
指标：Application Insights 可用性测试，5 分钟采样，月度统计
证据：Azure Monitor 可用性测试报告 + 事件时间线导出
判定：可用性 ≥ 99.9% 且计划外中断累计 ≤ 43 分钟/月
例外：提前 5 个工作日公告的计划维护窗口不计入

再以 SOW 中的网络条款为例，可拆成三条可执行检查：Hub 与 3 个 Spoke 的对等互联状态均为 Connected；Spoke 间流量经 Azure Firewall 检查，直连路径被拒绝；防火墙策略按应用组命名且与设计文档条目一致。每条检查都对应一个可在门户或 CLI 中直接观察的结果。

四、验收清单示例

下表是一份可直接改造使用的验收清单片段，覆盖四类验收，字段包含指标、目标值、证据与判定规则。示例中的数值均为教学假设，实际项目应以合同与 SLA 原文为准。

五、常见解读陷阱

• 把“尽力而为”当承诺：SLA 中“目标”“建议”类措辞不构成硬性验收条件，需在合同中确认其约束力。
• 忽略测量口径：同一可用性数字，按分钟采样与按小时采样结果差异明显，必须在验收前书面确认。
• 证据链缺失：指标达标但无导出报告、无时间戳、无执行人，验收时仍可能被质疑。
• 四类验收混用：用功能验收的“通过/不通过”去判定性能指标，会导致阈值争议无法收敛。

完成指标提取后，建议将清单固化为可追踪的验收台账：每条指标记录责任人、证据位置、当前状态与判定结论。这样在验收会上，讨论的焦点会从“感觉做得怎么样”转向“这条指标的证据是否满足判定规则”，验收效率与可信度都会显著提升。