访谈用来解释痕迹
技术证据能回答「发生了什么事」，但往往回答不了「为什么会有这次操作」。人员访谈的作用就在这里：把业务背景、授权情况、操作习惯补进来，让技术痕迹有一个合理的解释。访谈结果不替代技术证据，两者的关系是印证与补充。
按时间线问，不按猜测问
准备阶段先把待解释的节点按时间线列出来，访谈时顺着时间顺序询问操作与授权情况，问题保持开放。避免引导式提问，因为引导出来的回答既没有证明力，也会污染后续核查方向。回答与日志矛盾的地方单独记下来，作为待核实线索。
基本信息
| 适用平台 | 与工具无关，属于调查方法 |
|---|---|
| 准备材料 | 时间线中待解释的节点清单、相关日志片段 |
| 记录要素 | 时间、问题、回答、记录人、被访谈人确认签名 |
| 提问方式 | 开放式、按时间顺序，避免引导 |
| 输出 | 访谈记录与待核实线索清单 |
典型使用场景
- 解释非工作时间的登录：确认是否有加班、远程支持或巡检安排
- 确认脚本来源：判断某计划任务是业务部署还是外部植入
- 验证授权范围：某次数据导出是否有业务需求与审批
- 核对账号共用情况：解释同一账号出现的异常操作来源
- 补充上下文：为时间线上难以解释的片段提供业务视角
访谈提纲示例
访谈提纲示例
问：03:20-04:00 期间是否有人远程协助处理 H1？
答：有，运维外包王工经 VPN 接入处理数据库问题。
对照片段：VPN 日志 03:18 建立会话，与回答一致。
问：是否知晓域名 updates.example.invalid？
答：不清楚，没配过这个地址。
待核实：该域名解析来源进程尚未确认。
记录人：李四 被访谈人确认：王工（签名/日期）访谈记录要素
| 要素 | 要求 | 作用 |
|---|---|---|
| 时间 | 访谈开始与结束时刻 | 确定回答所对应的情形 |
| 问题 | 原话记录，不改写 | 避免记录过程引入偏差 |
| 回答 | 尽量逐字记录 | 保持可核查性 |
| 对照片段 | 相关的日志或证据引用 | 当场印证或标注矛盾 |
| 确认签名 | 被访谈人确认记录无误 | 记录具备可核查性 |
访谈中得到的回答属于陈述，不能单独作为技术结论的依据；报告里要把「陈述」与「日志印证」分开表述，读者才能判断证据强度。
涉及个人信息与人事处理的内容按最小必要原则记录，只保留与事件解释直接相关的部分。