简介：《等保测评服务方案》共1个doc文件，约1.07MB，面向信息安全合规负责人、等保测评实施人员及企业系统运维与安全建设团队，帮助梳理等级保护定级备案、测评实施与整改复测的完整工作脉络。文档围绕信息系统定级、专家评审、主管审批、公安备案等环节展开，并覆盖物理安全、网络安全、主机与应用安全、数据备份恢复、安全管理制度、人员与系统运维管理及渗透测试等检查维度。内容还给出测评依据、被测系统描述、现场测评四阶段与复测评三阶段的组织方式，可作为编写项目方案、准备测评材料和开展安全整改的参考底稿。目前已有989人学习，适合需要了解等保流程、搭建合规文档框架或查漏补缺的初、中级安全从业者按需查阅。
1. 一份 .doc 撑起一次等保测评：省掉的不是打字时间，是二次上门
做等保测评项目的人大多有过这种体验：定级报告写完被退回，理由是 S/A/G 三性赋值没有判据；现场测评跑了三天，回到工位整理证据才发现截图缺设备名和时间戳，只能再约一次上门。这份《等保测评服务方案.doc》的价值不在文字量，而在于它把定级与备案、测评指标裁剪、十类测评内容的实施步骤和每项对应的配合清单串成了一条能照着走完的链路。它不是标准原文的复述，而是一份作业底稿：现场谁访谈谁、上机看哪几个配置项、要甲方提前准备什么材料，都写在了对应小节里。适合刚接手等保测评交付的工程师、需要自建整改台账的甲方安全岗，以及要拿它改成投标技术方案的售前。下面按落地顺序拆：先定级备案，再裁指标，再排现场，最后讲复测评怎么收口。
2. 定级与备案：S/A/G 三性赋值怎么判、五步流程怎么走完
定级是整个项目的地基，地基歪了，后面指标裁剪、报告口径、复测评范围全部要跟着返工。这一章把定级对象怎么圈、三性怎么赋值、备案材料怎么凑齐讲透。
2.1 定级对象不是「一台服务器」，圈错了后面全错
定级对象指的是承载相对独立业务应用、由明确运营使用单位负责、具有确定业务边界的系统。三个条件缺一不可：业务相对独立、责任主体明确、边界可描述。常见翻车是把整个机房当成一个对象，或者反过来把一个系统的前台、后台、数据库拆成三个对象分别定级，结果测评指标重复计、报告里对象描述对不上拓扑图。
比较稳妥的切法是按业务应用切，基础设施单独处理。业务系统各自定级；虚拟化平台、云管平台这类承载多个业务系统的基础设施单独作为一个定级对象；纯网络设备、纯机房环境不单独定级，作为业务系统的组成部分被测。某集团的办公自动化、对外门户、核心业务三套系统，就是三个对象，等级可能各不相同，测评方案里要分开列表，不能合并成一张表蒙混过去。
圈完对象要落一张清单，字段至少包含：系统名称、业务描述、运营使用单位、上线时间、承载数据类别、是否联网、是否涉及个人信息。这张清单后面会直接变成备案表、测评方案、报告里的对象描述，字段口径统一了，后面改一处就行，不用满篇找。
2.2 S/A/G 三性赋值：从「受侵害客体 + 侵害程度」倒推，不要凭感觉
S 是业务信息安全性，指业务信息的保密性、完整性被破坏后造成的影响；A 是业务服务保证性，指业务服务中断或被降级造成的影响；G 是通用安全保护，不针对具体业务信息和服务，通常与系统等级保持一致。三个维度分别赋值，取最高者作为系统等级，这是标准给出的方法，不是拍脑袋。
赋值靠的是两步推导：先确定受侵害的客体，再确定客体受侵害的程度。矩阵如下：
| 受侵害客体 | 一般损害 | 严重损害 | 特别严重损害 |
|---|---|---|---|
| 公民、法人和其他组织的合法权益 | 第一级 | 第二级 | 第二级 |
| 社会秩序、公共利益 | 第二级 | 第三级 | 第四级 |
| 国家安全 | 第三级 | 第四级 | 第五级 |
实操里最容易含糊的是「程度」怎么定性。判据要写成可核查的句子，而不是形容词。比如 S 维度不要写「数据泄露影响较大」，要写「泄露 10 万条以上客户身份信息，可能触发监管处罚并造成直接经济损失」，把数据量、信息类型、后果链条写清楚。A 维度不要写「中断影响业务」，要写「服务中断 2 小时以上，业务受理窗口无法办理，日均影响 X 笔业务」。这些句子直接抄进定级报告的赋值说明栏，专家评审时没人会追问。
一个高频误判是「有备份就可以降 A」。备份解决的是恢复能力，不是中断影响，业务中断时间段内的损失照样发生。只有在双活、异地接管这类真正缩短中断时间的架构下，才谈得上把 A 往下调，而且要写明接管切换的实测时间。
2.3 定级报告与备案表：五步流程的输入、输出和卡点
定级流程是确定定级对象、确定安全保护等级、组织专家评审、主管部门审批、公安机关审核备案五步。每一步都有明确的输入输出，卡在哪一环，后面全停。
| 步骤 | 责任方 | 产出物 | 常见卡点 |
|---|---|---|---|
| 确定定级对象 | 运营使用单位 | 系统清单 | 对象边界重叠或拆分过细 |
| 确定等级 | 运营使用单位、测评方协助 | 定级报告初稿 | S/A/G 赋值无判据 |
| 专家评审 | 专家组（不少于规定人数） | 评审意见与签字页 | 专家名单、签字、日期缺失 |
| 主管部门审批 | 上级主管单位 | 批复文件 | 无主管单位的需说明归属 |
| 公安备案 | 属地公安机关 | 备案证明 | 系统名称与报告不一致 |
备案材料一般包括：备案表、定级报告、专家评审意见、主管部门批复、系统拓扑与说明、安全管理制度目录。材料准备阶段最耗时的不是写，是对齐。四处出现的系统名称必须字字一致：备案表、定级报告、测评合同、测评报告。标点、括号、全半角都算不一致，复测评时会被要求回去改备案，这个后悔药不好吃。
2.4 备案完成不等于结束：把备案信息接进资产台账
拿到备案证明之后，很多人就把它归档进项目文件夹了，后面现场测评要核对象、复测评要核范围，又得翻出来对一遍。更省事的做法是把备案信息接进资产台账，作为台账的一列：系统编号、备案号、定级等级、备案日期、下次复测评到期日。台账里有了这一列，年度测评计划直接从台账筛，不用每年重新问一遍甲方「你们有几个系统备过案」。
备案信息变更也有讲究。系统扩容、迁移、业务范围变化，只要不改变定级要素，一般不需要重新备案，但要在测评报告的对象描述里说明变更；如果业务范围变化导致 S 或 A 的赋值依据变了，就要重新走定级和备案。判断标准还是回到那两条：受侵害客体变没变，侵害程度变没变。
3. 测评指标怎么裁：二级 66 项、三级 73 项的对照与取舍
指标裁剪是测评方案里最容易照抄出错的地方。原始方案给了两张汇总表，看着规整，直接抄进新项目就会出问题，得先弄明白这些数字是怎么堆出来的。
3.1 二级 66 项、三级 73 项：数字是怎么堆出来的
原始方案把指标分成通用类 G、业务信息安全性类 S、业务服务保证类 A，再按技术和管理各五个安全分类展开。二级的分布是这样：
| 安全分类 | 安全子类 | S | A | G | 小计 |
|---|---|---|---|---|---|
| 安全技术 | 物理安全 | 1 | 1 | 8 | 10 |
| 安全技术 | 网络安全 | 1 | 0 | 5 | 6 |
| 安全技术 | 主机系统安全 | 2 | 1 | 3 | 6 |
| 安全技术 | 数据安全及备份恢复 | 2 | 1 | 0 | 3 |
| 安全技术 | 应用安全 | 4 | 2 | 1 | 7 |
| 安全管理 | 安全管理制度 | 0 | 0 | 3 | 3 |
| 安全管理 | 安全管理机构 | 0 | 0 | 5 | 5 |
| 安全管理 | 人员安全管理 | 0 | 0 | 5 | 5 |
| 安全管理 | 系统建设管理 | 0 | 0 | 9 | 9 |
| 安全管理 | 系统运维管理 | 0 | 0 | 12 | 12 |
| 合计 | 10 | 5 | 51 | 66 |
三级的分布：
| 安全分类 | 安全子类 | S | A | G | 小计 |
|---|---|---|---|---|---|
| 安全技术 | 物理安全 | 1 | 1 | 8 | 10 |
| 安全技术 | 网络安全 | 1 | 0 | 6 | 7 |
| 安全技术 | 主机系统安全 | 3 | 1 | 3 | 7 |
| 安全技术 | 数据安全及备份恢复 | 5 | 2 | 2 | 9 |
| 安全技术 | 应用安全 | 2 | 1 | 0 | 3 |
| 安全管理 | 安全管理制度 | 0 | 0 | 3 | 3 |
| 安全管理 | 安全管理机构 | 0 | 0 | 5 | 5 |
| 安全管理 | 人员安全管理 | 0 | 0 | 5 | 5 |
| 安全管理 | 系统建设管理 | 0 | 0 | 11 | 11 |
| 安全管理 | 系统运维管理 | 0 | 0 | 13 | 13 |
| 合计 | 12 | 5 | 56 | 73 |
3.2 这张汇总表照抄之前先核一遍：对不上的地方就是坑
把两张表横向摆开逐行对，会发现一个明显异常：应用安全三级只有 3 项，二级却有 7 项。高等级系统的控制项比低等级少，这在逻辑上不成立，大概率是原表某一行的分列数值写错了。同类问题还有数据安全及备份恢复，二级 3 项、三级 9 项，这个递进幅度也偏大，需要回标准原文逐条核。
核对方法不复杂，就三步：第一步横向核，每个子类的 S+A+G 必须等于小计；第二步纵向核，技术五类小计相加、管理五类小计相加，两者之和必须等于合计；第三步跨级核，同级子类的三级项数不应少于二级。三步下来，任何一处数字不闭合都会暴露。
这三步靠人眼看容易漏，用脚本对一遍更稳。做法是把指标台账维护成 CSV，一行一个控制项，然后统计：
import csv from collections import Counter, defaultdict # 指标台账：一行一个控制项 # 字段：level(2/3) category(十类子类名) cls(S/A/G) control_id 控制项编号 def load(path): with open(path, newline="", encoding="utf-8") as f: return list(csv.DictReader(f)) rows = load("controls.csv") # 1) 横向核：每个 (等级, 子类) 下 S/A/G 的条数 stat = defaultdict(Counter) for r in rows: stat[(r["level"], r["category"])][r["cls"]] += 1 # 2) 跨级核：三级项数不应少于二级 for cat in {r["category"] for r in rows}: n2 = sum(stat[("2", cat)].values()) n3 = sum(stat[("3", cat)].values()) flag = " <-- 三级少于二级，回查" if n3 < n2 else "" print(f"{cat}: 二级 {n2} 项 / 三级 {n3} 项{flag}") # 3) 合计核：与技术小计、管理小计、总合计对账 print("L2 合计:", sum(v for k, v in stat.items() if k[0] == "2")) print("L3 合计:", sum(v for k, v in stat.items() if k[0] == "3"))这段脚本没有任何第三方依赖，level决定按二级还是三级统计，category与方案里的十类安全子类名保持一致，cls只接受 S、A、G 三个值。脚本跑出来的合计要跟标准原文逐项对，跟方案里的表也要对，两边不一致时以标准原文为准，方案的表作为需要修订的对象。参数上唯一要注意的是category的命名必须和报告里的分类名完全一致，中间多一个空格都会统计成两组。
3.3 S/A/G 标记不只是分类，它决定报告里怎么写结论
通用类 G 的指标是所有同等级系统都要测的，S 类和 A 类指标则跟业务强绑定。判断某个 S 类指标测不测，依据是定级时 S 维度的赋值是否高于系统整体等级。举例说，一个定三级的系统，如果 S 赋值是二级、A 赋值是三级，那么 S 类的高等级指标可以不作为符合性判定的必测项，但仍要在报告里说明不适用的理由，而不是直接删掉。删掉是最危险的做法，复核时无法解释指标缺项。
实操里我会在指标台账里加两列：applicable（适用/不适用）和reason（不适用理由）。不适用的理由必须指向定级结论，比如「本系统 S 赋值为二级，故 S3 类指标不适用」。这样报告生成时可以直接从台账导出，不用再人工回忆当初为什么跳过某一项。
3.4 指标挂对象：一张对照表管到底
指标是抽象的，测评对象是具体的，中间必须有一张对照表把「哪个指标在哪个对象上用哪种方式取证」固定下来。这张表决定了现场测评的动线，也决定了证据文件的命名规则。
| 指标编号 | 指标名称 | 测评对象 | 取证方式 | 证据编号 |
|---|---|---|---|---|
| NET-03 | 访问控制策略 | 核心交换机 | 检查、访谈 | E-NET-03-01 |
| HOST-01 | 身份鉴别 | 应用服务器 A | 检查 | E-HOST-01-01 |
| APP-02 | 访问控制 | 业务系统 | 检查、测试 | E-APP-02-01 |
| DATA-01 | 数据完整性 | 数据库服务器 | 访谈、检查 | E-DATA-01-01 |
对照表的价值在现场：测评工程师拿着表按对象走，一个对象上的所有指标一次测完，不用为了找一个配置项反复换机器。证据编号提前编好，现场只负责按编号落文件，回来整理时不会出现同一项证据三份重名文件的情况。
4. 现场测评四阶段：访谈、检查、测试怎么排期和取证
方案里把整个实施拆成现场测评和复测评两大块，现场测评又分测评准备、方案编制、现场测评、分析和报告编制四个阶段，复测评分安全整改、复测评、报告编制三个阶段。这个划分不是形式，每一阶段的交付物都是下一阶段的输入，缺一环就要回头补。
4.1 四个阶段的时间盒与交付物
| 阶段 | 主要动作 | 交付物 | 常见延期原因 |
|---|---|---|---|
| 测评准备 | 组建项目组、收集系统资料、发放配合清单 | 资料回执、系统调查表 | 甲方资料缺失、接口人变更 |
| 方案编制 | 定对象、定指标、定方法、定进度 | 测评方案（甲方确认） | 指标范围争议、渗透测试授权未签 |
| 现场测评 | 访谈、检查、测试、取证 | 现场记录表、证据文件 | 设备无法登录、窗口期冲突 |
| 分析报告 | 单项判定、整体测评、风险分析 | 测评报告 | 证据不全需二次上门 |
方案编制阶段最容易被压缩，实际上它决定了后面所有工作量。我的习惯是把测评方案和配合清单一起发出去，配合清单按测评对象分组，每组写明要谁到场、要开哪个账号、要提供哪几份文档。甲方拿到清单能提前一周准备，现场就不会出现「这个设备的密码只有离职的人知道」这种局面。
4.2 访谈、检查、测试：三种取证方式各有各的证据形态
方案里对三种方法的定义很准：访谈是有目的地交流以理解、澄清或取得证据；检查是观察、查验、分析；测试是用工具或手工验证。落到取证上，三者的证据形态完全不同，混着用会导致报告里证据支撑不足。
| 方式 | 证据形态 | 适用控制点 | 注意事项 |
|---|---|---|---|
| 访谈 | 访谈记录（时间、地点、被访谈人岗位、问答摘要、签字） | 管理制度、机构设置、人员管理、运维流程 | 记录不能只写「已了解」，要写具体回答 |
| 检查 | 配置截图、文档复印件、现场照片 | 物理环境、设备配置、制度文档 | 截图需同屏体现主机名、配置项、时间 |
| 测试 | 扫描报告、验证步骤与结果 | 漏洞、访问控制有效性、边界完整性 | 需授权、需报备源 IP、需限速 |
访谈记录是最容易被做薄的一类证据。写「访谈安全主管，确认已建立安全管理制度」等于没写。合格的记录要落到具体问答：「问：制度最近一次评审是什么时候？答：本年 3 月，评审记录编号 XX，修订了备份恢复章节。」这种记录在复核时能自证，不用回头找甲方补材料。
检查类证据的关键是「一屏原则」。一张截图里要能同时看到设备主机名或 IP、具体配置项、系统时间。分三张截图各截一部分，看着很全，实际上无法证明这三张图来自同一台设备的同一时刻，复核时很容易被打回。
4.3 十类测评内容的实施要点和配合清单
方案按物理安全、网络安全、主机系统安全、应用安全、数据安全及备份恢复、安全管理制度、安全管理机构、人员安全管理、系统建设管理、系统运维管理十类展开，每一类下面都列了子类、测评内容和配合需求。这个结构本身就是现场动线，按类走、按子类取证。
| 安全分类 | 子类数（二级/三级） | 主要对象 | 主要取证方式 |
|---|---|---|---|
| 物理安全 | 10 / 10 | 机房 | 访谈、检查 |
| 网络安全 | 6 / 7 | 交换机、防火墙、拓扑 | 访谈、检查、测试 |
| 主机系统安全 | 6 / 7 | 服务器、管理终端 | 访谈、检查 |
| 应用安全 | 7 / 3（需核实） | 业务系统 | 访谈、检查、测试 |
| 数据安全及备份恢复 | 3 / 9 | 数据库、备份介质 | 访谈、检查 |
| 安全管理制度 | 3 / 3 | 制度文档 | 访谈、检查 |
| 安全管理机构 | 5 / 5 | 岗位职责文件 | 访谈、检查 |
| 人员安全管理 | 5 / 5 | 人员档案、协议 | 访谈、检查 |
| 系统建设管理 | 9 / 11 | 建设过程文档 | 访谈、检查 |
| 系统运维管理 | 12 / 13 | 运维记录 | 访谈、检查 |
物理安全十项里，最花时间的不是技术检查，是要材料。防雷要建筑物防雷检测报告，防火要消防系统检查和维护记录、机房验收文档，防水防潮要建筑施工图和验收文档，电力供应要 UPS 和备用电源的维护维修记录。这些材料通常在甲方基建或后勤部门手里，不在信息中心，现场临时要基本要不到。配合清单里必须写清楚「由哪个部门提供、什么格式、是否接受复印件」。
主机和应用两类是上机操作密集区，账号要提前开。我的做法是让甲方开一个只读的审计账号，能看安全策略、账户列表、日志配置、服务列表，不改配置。这样既满足检查需要，也避免测评过程中误改生产配置引起争议。需要在命令行里看配置的，由甲方运维人员操作、测评人员口述指令，方案里很多配合需求写的就是「系统管理员配合上机查看」，这种分工值得保持。
4.4 漏洞扫描与渗透测试的边界：别把测评做成攻击
方案把工具测试单列出来，包括漏扫设备和一批常见渗透测试工具。这一步的风险最高，做之前必须把边界划清楚：书面授权、时间窗口、源地址报备、速率限制、禁止写操作、禁止社会工程学和口令爆破（除非单独授权）。
授权书要写明测试源 IP 段、目标 IP 段、时间窗口、允许的测试类型、应急联系人。时间窗口避开业务高峰，一般放在夜间或周末，并且提前通知值班人员，避免告警触发后当成真实攻击处置。扫描速率要限，全端口全插件的默认配置在老旧设备上很容易打出业务抖动，这个锅最后算在测评方头上。
扫描器规则库版本要记录进报告，不然复测评时无法说明「上次扫出来的漏洞这次没有了，是因为修了还是因为规则库没更新」。工具清单里列的具体型号和版本，报告里要照录，这是可追溯性的一部分。
5. 避坑：定级备案和现场测评里最容易翻车的五个点
这一章的五条都是从返工记录里挑出来的，每条按现象、原因、解决三段说。看过一遍，至少能少跑两趟现场。
5.1 S/A/G 三栏全填「中」：专家评审第一个退回
现象：定级报告交上去，专家评审意见写「赋值依据不足，无法支撑定级结论」，整份退回重写。
原因：填表的人把三性当成打分项，觉得「中等」最保险。实际上 S/A/G 是从受侵害客体和侵害程度倒推出来的，必须有推导链条，没有链条的赋值在评审时无法质证。
解决：每个维度单独写一段判据，落到数据量、业务量、时间、后果。S 写清泄露的信息类型和条数、可能触发的处罚和损失；A 写清允许的最长中断时间、中断期间影响的业务笔数；G 一般不单独论证，跟随系统等级。三段判据写进报告赋值说明栏，评审时直接指给人看。
5.2 指标按三级裁，系统实际定二级
现象：测评方案发过去，甲方说我们备案是二级，你怎么按三级测；报告出来等级口径和备案证明对不上，复测评时被要求重出。
原因：直接套用了上一个项目的方案模板，指标范围没改。
解决：指标范围的唯一依据是备案证明上的等级。方案编制第一步就把备案号、备案等级、备案日期抄进方案首页。等级拿不准时按高的准备材料没关系，但报告口径必须按备案等级出。如果甲方确实要按高一级做建设整改，那是整改建议里的事，不改变测评结论的等级口径。
5.3 截图缺环境标识，报告复核时无法自证
现象：现场测了两天，回来整理证据发现一批配置截图只有中间一块，看不到主机名、看不到 IP、看不到时间，报告写到一半只能约二次上门。
原因：截图时图省事，只截了配置项本身，忽略了「这张图属于哪台设备的哪个时刻」这个基本问题。远程桌面全屏截图还容易把多台机器的窗口叠在一起。
解决：立一条硬规矩，每张截图必须同屏出现三类信息：设备标识（主机名或 IP）、配置项内容、系统时间。做不到就先打开系统信息页再截，或者截两张并在记录表里注明关联关系。截图文件名按「证据编号_对象名_序号」命名，当场命名，不要等回来再猜。
5.4 制度文档「有」，但版本是上一版
现象：访谈时安全主管说制度去年修订过，翻出来的文档签发日期还是三年前，访谈记录和文档证据互相矛盾。
原因：制度修订后没有走发布流程，或者发布了但没有收发文记录，纸面版本和实际执行版本脱节。
解决：查制度不能只看有没有，要看三样：签发页的批准人和日期、收发文登记记录、宣贯或培训记录。三样齐了才算「已发布并执行」。缺任何一样，就在报告里如实写不符合，并在整改建议里给出补做发布流程的具体动作。帮着甲方把这三样补齐，比在报告里含糊过去更有价值。
5.5 漏洞扫描扫出业务中断
现象：白天对生产系统做全量扫描，业务侧反馈页面卡顿、部分接口超时，运维直接把扫描 IP 封了。
原因：没有约定时间窗口和速率，扫描器默认并发拉满，老旧中间件在高压下响应变慢甚至连接池耗尽。
解决：扫描前走三步——报备源 IP 和时间窗口、把并发和每秒请求数压到业务可承受范围、先对非生产镜像或测试环境试扫一轮摸清敏感插件。生产扫描安排在业务低谷，全程有人值守，出问题立刻停。这条血泪经验值一次项目复盘。
6. 复测评与整改闭环：一张三列台账把不符合项追到底
整改阶段最常见的场景是：报告出了三十多条不符合项，甲方问「先改哪个」，测评方答「都重要」，然后一个月过去没人动。要破这个局，靠的不是催，是把不符合项变成可追踪的台账。
我一般用三列结构：控制项、现状证据编号、整改证据编号。第一列写指标编号和一句话描述，第二列指向初次测评时的证据文件，第三列留空等整改后填。复测评现场只做一件事——按第一列逐条核第三列，有编号的看证据，没编号的记未整改。这样复测评的工期基本取决于台账质量，而不是现场重新摸一遍。
| 控制项 | 现状证据 | 整改证据 | 优先级 |
|---|---|---|---|
| HOST-01 身份鉴别 | E-HOST-01-01 | E-HOST-01-02 | 高 |
| NET-03 访问控制策略 | E-NET-03-01 | E-NET-03-02 | 高 |
| OPS-07 备份恢复演练 | E-OPS-07-01 | 待补 | 中 |
| DOC-02 制度评审记录 | E-DOC-02-01 | E-DOC-02-02 | 低 |
优先级按「风险 × 整改成本」分四档，高风低成本的先做，这类通常是配置类问题，改一条策略、关一个端口、开一个审计项，一两天能闭环；高风险高成本的进建设规划，比如缺双活、缺堡垒机，当期改不完就写进整改计划并注明时间节点；低风险低成本顺手做；低风险高成本可以延后，但要在报告里说明理由。这个分档不是学术分类，是给甲方排工期用的。
复测评取证有个细节值得强调：整改后的证据要跟初次证据同角度、同字段重拍。上次截的是「账户策略」页面，这次还截这个页面，两张图放一起能直接看出改了哪一项。换个角度截，等于让人重新对照一遍，复核时容易起争议。
证据归档用脚本统一命名，比手工改名靠谱：
#!/usr/bin/env bash # 证据归档：<根目录>/<测评项编号>/<测评项编号>_<对象名>_<时间戳>.png # 用法：./collect.sh HOST-01 应用服务器A /tmp/shot.png set -euo pipefail item="$1" # 测评项编号，与台账第一列一致 host="$2" # 测评对象名，与方案对照表一致 src="$3" # 原始截图路径 root="${EVIDENCE_ROOT:-./evidence}" # 归档根目录，可用环境变量覆盖 dst="$root/$item/${item}_${host}_$(date +%Y%m%d%H%M%S).png" mkdir -p "$(dirname "$dst")" cp "$src" "$dst" printf '%s\t%s\n' "$dst" "$(date -Iseconds)" >> "$root/index.txt" # 追加索引，报告引用时直接查三个参数分别对应台账第一列、方案对照表的对象名、原始文件路径。EVIDENCE_ROOT用环境变量传，是为了让初次测评和复测评落到两个不同根目录，避免覆盖。index.txt那行是后悔药——报告写完发现某张图引用错了，按时间戳能在索引里倒查回原始文件。
从那以后我每次开复测评启动会，第一件事不是讲进度，是把这张三列台账投到屏幕上，逐条问「这条谁负责、什么时候能给证据」，答不上来的当场标红。台账不漂亮，但比任何整改承诺都管用。希望帮到你。
本文还有配套的精品资源，点击获取
