第二章 审核与评估概述
各位工程师朋友，大家好。这一章我们聊聊审核与评估。很多刚入行的同事会问：审核和评估到底是不是一回事？我直接告诉你——不是。虽然它们经常被放在一起说，但本质上有区别。我在项目里见过不少团队把两者混为一谈，结果审核报告写得像评估报告，评估报告又像审核报告，最后评审会上被专家一顿批。
一、审核与评估的区别
先讲个我自己的经历。有一次我去一家供应商做功能安全审核，对方项目经理拿出一份厚厚的文档说：“这是我们做的评估报告，您看看。”我翻了几页，发现里面全是技术分析，什么FMEA、FTA、FMEDA全做了，但流程证据几乎没有。这就是典型的把评估当审核。
说白了，审核是查流程，评估是查技术。我习惯这样区分：
- 审核（Audit）：检查你有没有按照标准流程做事。比如开发流程是否合规、文档是否齐全、变更管理是否到位。
- 评估（Assessment）：检查你的技术方案是否安全。比如安全机制是否有效、故障覆盖率是否达标、残余风险是否可接受。
你想想看，一个项目如果流程乱成一锅粥，技术再牛也没用。反过来，流程再规范，技术方案漏洞百出，照样出事故。所以两者缺一不可。
核心区别速览：
| 维度 | 审核 | 评估 |
|---|---|---|
| 关注点 | 流程合规性 | 技术安全性 |
| 输出物 | 审核报告（含不符合项） | 评估报告（含安全论证） |
| 执行者 | 独立审核员 | 安全工程师/评估员 |
| 时机 | 项目关键节点 | 技术方案完成后 |
二、审核员资质要求
说到审核员，很多人觉得只要懂标准就能干。嗯，这里要注意——没那么简单。我见过一些审核员，标准背得滚瓜烂熟，但一到现场就抓不住重点。为什么？因为缺乏实战经验。
我个人认为，一个合格的审核员至少需要满足以下条件：
- 技术背景：至少5年以上相关领域开发经验。你连代码都没写过，怎么判断别人的代码是否安全？
- 标准理解：精通ISO 26262、IEC 61508等核心标准。不是背条款，是理解背后的安全哲学。
- 审核技巧：会提问、会观察、会取证。我曾经遇到一个审核员，全程只问“你们有没有做这个”，结果被对方用一份假文档糊弄过去了。
- 独立性：不能审核自己参与的项目。这是底线，也是红线。
我的建议：如果你打算走审核这条路，先去做几年开发，再去做几年安全评估，最后再转审核。这样你才能知道对方说的“我们做了”到底是真做了还是糊弄你。
三、审核计划制定
审核计划这东西，很多人觉得就是排个时间表。其实不然。一个好的审核计划，能让你在有限时间内抓住核心问题。我习惯这样制定：
- 第一步：明确审核范围——审哪个项目？哪个阶段？哪个功能模块？
- 第二步：确定审核准则——依据哪个标准？哪个版本？哪些条款？
- 第三步：分配审核资源——需要几个人？几天？谁带队？
- 第四步：制定时间表——什么时候入场？什么时候出报告？
- 第五步：准备检查表——这是关键。我每次都会根据项目特点定制检查表，而不是用通用模板。
避坑指南：我曾经见过一个审核计划，把整个项目所有流程都列进去了，结果审核员累死，被审核方也烦死。记住，审核不是面面俱到，而是抓关键风险点。你想想看，一个项目几十个流程，你全审一遍，时间够吗？
四、审核流程概览
审核流程其实不复杂，我把它总结成四个阶段：
- 启动阶段：开首次会议，明确目标、范围、日程。这个会很重要，我一般会花半小时讲清楚“我们为什么来审”“审什么”“怎么审”。
- 执行阶段：现场检查、文档审查、人员访谈。这个阶段最考验功力。我记得有一次，我通过一个工程师的随口抱怨，发现了一个隐藏很深的安全漏洞。
- 报告阶段：整理发现项，写审核报告。注意，不符合项要分等级：严重、一般、建议。别把所有问题都写成严重，那样反而没人重视。
- 跟踪阶段：确认整改措施是否落实。我见过太多项目，审核报告写得漂亮，但整改措施根本没执行。所以跟踪验证必不可少。
下面这张图是我自己画的审核流程框架，你可以参考一下：
最后说一句，审核不是找茬，是帮助团队提升安全水平。我每次审核结束都会跟对方说：“我不是来挑你毛病的，我是来帮你发现你没看到的风险。”心态摆正了，审核才能做好。
本章要点：
- 审核查流程，评估查技术，两者不能混
- 审核员需要技术背景+标准理解+实战经验
- 审核计划要抓关键风险，不是面面俱到
- 审核流程四阶段：启动→执行→报告→跟踪
公众号:蓝海资料掘金营，微信deep3321