配置审核是对配置项及其受控组合进行独立检查的活动，用来确认配置项被正确标识、版本与变更被如实记录、基线内容完整一致。它分为功能配置审核与物理配置审核两类：前者看配置项是否满足已确认的需求与功能特性，后者看实际交付物、文档与版本标识是否和配置记录吻合。基线与配置状态记录是审核的输入和比对依据，审核负责核对三者是否一致。
要点总览（TL;DR）
- 配置审核是对配置项及其受控组合做独立一致性检查的活动，确认标识、版本、变更记录与实际内容相符，产出审核记录与不符合项。
- 功能配置审核关注配置项是否满足已确认的需求与功能特性，以需求文档、设计说明、测试记录为比对依据，重点看验证证据是否完整。
- 物理配置审核关注交付物、文档与版本标识是否与配置记录一致，核对数量、版本号、存放位置和实物形态，输出差异清单与处置建议。
- 基线与配置状态记录是审核的输入：基线给出应有状态，状态记录给出实际状态，审核比对三者是否吻合，结论回写记录并触发整改或基线更新。
- 配置审核区别于设计评审与测试验证，它判断受控信息与实物是否一致，签字只是结论确认形式，不能替代逐项比对。
配置审核的准确定义与不包括的范围
配置审核可以概括为：在配置管理流程中，由相对独立的人员对配置项及其受控组合进行检查，确认配置项的标识、版本、变更记录和实际内容与既定要求一致，并形成可追溯的审核结论。它的目的不是重新做一遍设计或测试，而是回答一个核对性问题——我们声称受控的东西，和实际存在的东西，是不是同一件、同一版、同一状态。
理解这个定义，需要抓住三个要素。审核对象是配置项及其受控组合，例如一个软件版本所包含的源码、安装包、接口文档、测试记录的组合，而不是单个文件本身。审核依据是已经确认的需求、基线、配置状态记录等受控信息。审核产出是审核记录与不符合项，供后续整改或基线更新使用。
配置审核有明确的边界，以下工作属于相邻流程，不纳入配置审核的范围：
- 仅需求版本变更的处理流程：需求如何提出变更、如何评估影响、如何走变更审批，属于变更管理；配置审核只核对变更是否被如实记录并反映到受控状态中。
- 交付制品的打包与发布管理：制品如何构建、如何入库、如何分发到环境，属于制品与发布管理；配置审核核对的是打包结果与配置记录是否一致。
- 设计评审与测试验证：这两类活动判断方案好不好、功能对不对，配置审核判断受控信息与实物是否吻合。
换句话说，配置审核站在流程的后段做一致性核对，它依赖前面各环节留下的记录，也反过来检验这些记录是否可信。
功能配置审核关注什么
功能配置审核（Functional Configuration Audit，FCA）检查的是配置项是否满足已确认的需求与功能特性。它要回答的问题是：这个配置项在功能上是否达到了基线所承诺的水平，相关验证是否已经完成并有记录。
功能配置审核的比对依据通常包括需求文档、设计说明、接口约定和测试记录。审核人员会逐项核对需求条目是否有对应的实现说明和验证证据，关注接口、性能等约定特性是否被验证过，验证结论是否与需求一致。审核结束后输出审核记录与不符合项清单，未通过项进入整改。
| 检查维度 | 检查内容 | 典型证据 |
|---|---|---|
| 需求覆盖 | 已确认需求是否都有对应实现与验证 | 需求文档、需求跟踪记录 |
| 功能特性 | 功能行为是否符合需求描述 | 设计说明、测试用例与结果 |
| 接口约定 | 内外接口是否按约定实现并验证 | 接口文档、联调记录 |
| 性能等约定特性 | 性能、容量等指标是否被验证 | 性能测试报告 |
| 验证完整性 | 测试是否覆盖需求且结论明确 | 测试记录、缺陷关闭情况 |
功能配置审核的难点在于证据的完整性。需求条目多、验证记录分散时，逐条比对容易遗漏。实际执行中通常先建立需求与验证证据的对应关系，再按对应关系抽查或全查，审核记录中写明每条需求的核对结论。
物理配置审核关注什么
物理配置审核（Physical Configuration Audit，PCA）检查的是实际交付物与文档、版本标识是否与配置记录一致。它要回答的问题是：我们交付或归档的东西，在数量、版本、标识和存放位置上，是否和配置管理记录描述的一样。
物理配置审核的比对依据是配置状态记录、版本标识规则和交付物清单。审核人员会核对配置项的数量、版本号、存放位置是否与记录相符，关注安装包、说明书、源码标签等实物形态是否齐全且标识正确。审核结束后输出差异清单与处置建议，差异项需要修正记录或修正实物。
| 检查维度 | 检查内容 | 典型证据 |
|---|---|---|
| 数量与完整性 | 交付物清单中的配置项是否齐全 | 交付物清单、入库记录 |
| 版本标识 | 版本号、标签是否与记录一致 | 版本记录、源码标签 |
| 存放位置 | 配置项是否存放在记录指定的位置 | 配置状态记录、库目录 |
| 实物形态 | 安装包、说明书等是否与描述相符 | 制品包、随附文档 |
| 文档配套 | 文档版本是否与对应配置项匹配 | 文档版本记录 |
物理配置审核常被误解为“数一数文件够不够”。实际上版本标识和存放位置同样关键：一个版本号标错，后续追溯就会指向错误的内容；配置项放错库目录，交付时就可能取到旧版本。差异清单要写清差异类型、影响范围和处置建议，便于责任方修正。
配置审核与基线、配置状态记录如何配合
三者在同一受控流程中分工明确：基线提供应达到的受控状态，配置状态记录提供实际发生的变化与当前状态，审核比对基线、记录与实物三者是否一致，审核结论再回写状态记录，并触发基线更新或整改。
具体配合可以按以下顺序理解：
- 建立基线：在需求或版本确认后形成基线，明确这一时点应包含哪些配置项、各自是什么版本，这是审核的“应有状态”。
- 维护配置状态记录：变更发生后，记录变更内容、影响配置项和当前版本，形成“实际状态”的流水。
- 执行审核：以基线为参照，以状态记录为线索，核对实物与文档是否与两者吻合，功能配置审核侧重需求与验证，物理配置审核侧重实物与标识。
- 形成结论并回写：审核通过则确认受控状态有效；发现不符合项则记录整改，整改完成后更新状态记录，必要时调整或重建基线。
| 要素 | 在审核中的角色 | 提供的信息 | 审核后的动作 |
|---|---|---|---|
| 基线 | 应有状态的参照 | 应包含的配置项及版本 | 确认有效，或按结论更新基线 |
| 配置状态记录 | 实际状态的线索 | 变更历史与当前版本 | 回写审核结论与整改结果 |
| 配置审核 | 一致性核对活动 | 审核记录与不符合项 | 触发整改或基线更新 |
这条链路说明，审核不是孤立的一次检查，而是让基线和状态记录保持可信的校验环节。基线若长期不核对，可能停留在纸面；状态记录若只记不核，可能积累偏差。审核把两者与实物对齐，受控状态才真正成立。
在工具承载上，ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，并围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯。对于配置审核而言，这意味着基线内容和变更记录可以在同一套对象体系中查阅，审核人员比对“应有状态”与“实际状态”时不必在多个系统间拼接信息。审核记录与不符合项也可以作为过程数据留存，供后续追溯使用。具体审核模板与操作方式需结合实际开通模块确认。
相邻概念区别：配置审核、评审与测试
配置审核容易与设计评审、测试验证混为一谈，三者的对象和结论并不相同。设计评审针对方案与设计本身，判断设计是否合理、是否满足要求；测试验证针对产品行为，判断功能是否正确；配置审核针对受控信息与实物的一致性，判断记录是否可信。
| 活动 | 主要对象 | 回答的问题 | 典型结论 |
|---|---|---|---|
| 设计评审 | 设计方案、技术文档 | 设计是否合理、是否满足需求 | 评审意见与修改建议 |
| 测试验证 | 产品功能与行为 | 功能是否正确、指标是否达标 | 测试通过或缺陷记录 |
| 功能配置审核 | 需求与验证证据的对应关系 | 需求是否都有实现与验证记录 | 审核记录与不符合项 |
| 物理配置审核 | 交付物、文档与版本标识 | 实物是否与配置记录一致 | 差异清单与处置建议 |
关于术语，配置审核在不少资料中也被称为配置审计（Configuration Audit），功能配置审核与物理配置审核是它的两个基本类别。不同组织在叫法上可能有所差异，但检查对象和判断依据基本对应。需要区分的是，配置审核与财务审计、合规审计不是同一概念，后者关注资金或制度执行，配置审核关注配置项受控状态的一致性。
具体例子与常见误解
以一个版本发布前的审核场景为例。某团队准备发布 V2.3 版本，基线中登记了 12 个配置项，包括源码标签、安装包、接口文档和测试报告。配置状态记录显示，发布前有两项需求变更已合入，涉及接口文档更新。审核时，功能配置审核逐条核对变更需求是否有对应的测试记录，发现其中一项性能指标只有开发自测记录、缺少正式测试报告，记为不符合项；物理配置审核核对安装包版本号与基线登记一致、接口文档版本已更新、源码标签指向正确提交，发现说明书仍是上一版本，记为差异项。两项问题整改后，状态记录回写审核结论，基线确认有效，版本才进入发布。
这个例子说明，两类审核各有侧重，又共同支撑发布决策。围绕它，有几个常见误解值得纠正：
- 误解一：审核等于走签字流程。签字只是审核结论的确认形式，审核的实质是逐项比对证据。没有比对过程的签字，无法发现需求缺验证、文档版本错配这类问题。
- 误解二：有基线就不需要审核。基线定义的是应有状态，实物是否真的达到这个状态，需要独立核对。基线越重要，越需要审核来确认它没有被悄悄偏离。
- 误解三：状态记录只是台账。状态记录是审核的线索来源，记录是否准确直接影响审核效率。把状态记录当作被动登记，审核时就只能靠翻找原始材料，追溯成本会明显上升。
把这三条纠正过来，配置审核才能从形式动作变成受控状态的实际保障：基线给出承诺，状态记录留下轨迹，审核负责验证承诺与轨迹是否和实物对得上。
常见问题
功能配置审核和物理配置审核必须都做吗，还是可以只做其中一类？
两类审核回答的问题不同，是否都做取决于受控对象和发布要求。功能配置审核核对需求与验证证据的对应关系，物理配置审核核对交付物、文档与版本标识的一致性。若版本包含需求变更且对外交付，两类问题都可能出现，通常都需要覆盖；若只是内部归档某批文档，物理一致性检查的权重会更高。具体取舍建议在配置管理计划中写明审核范围、触发时点和责任人，避免临时决定导致遗漏。
审核发现的不符合项，应该改实物还是改记录？
先判断哪一方偏离了已确认的受控状态。若基线或需求是明确的，实物与记录不符，通常修正实物或补齐缺失证据；若实际变更已经发生且合理，只是记录未及时更新，则应更新配置状态记录，必要时按变更流程调整基线。差异清单中写清差异类型、影响范围和处置建议，整改完成后回写状态记录，使记录与实物重新对齐。
基线已经冻结了，为什么还要再做配置审核？
基线定义的是应有状态，冻结只表示这一时点的内容被确认，实物是否真的保持在这个状态需要独立核对。发布前合入变更、文档版本替换、制品重新打包等动作都可能让实物偏离基线。审核以基线为参照、以状态记录为线索，核对三者是否吻合，基线越关键，越需要审核确认它没有被悄悄偏离。
配置状态记录平时怎么维护，才能让审核更省力？
把状态记录当作变更发生时的同步动作，而不是事后补台账。每次变更合入时记录变更内容、影响的配置项和当前版本，版本标识与存放位置随实物同步更新。记录准确时，审核人员可以按记录直接定位待核对项，减少翻找原始材料的时间；记录长期滞后，审核就只能靠全量排查，追溯成本明显上升。
配置审核和设计评审、测试验证的结论能互相替代吗？
不能互相替代，三者对象和结论不同。设计评审判断方案是否合理，测试验证判断功能是否正确，配置审核判断受控信息与实物是否一致。测试通过说明功能达标，但需求条目是否都有对应验证记录、交付文档版本是否匹配，仍需审核核对。实际流程中三者可以共享证据，但结论各自独立。
