4. Playbook 设计前的需求分析

很多团队在引入 SOAR 时，第一反应是“先把能自动化的都自动化”，结果往往做出大量低价值 Playbook：要么触发条件模糊、频繁误报，要么执行到一半需要人工补数据，要么上线后没人能说清它到底有没有用。问题不在编排工具，而在于跳过了需求分析这一步。Playbook 的需求分析，本质上是把一句模糊的运营抱怨，翻译成一份可设计、可实现、可验收的规格说明。

一、从痛点出发，而不是从工具能力出发

需求分析的起点应当是安全运营中真实存在的痛点，而不是“SOAR 支持哪些动作”。常见的痛点可以归为几类：告警量超出人力处理能力、重复性处置动作占用大量时间、跨系统切换导致响应延迟、处置标准因人而异、关键线索在多个平台之间丢失、夜间与节假日响应能力下降。这些痛点有一个共同特征——它们都能被描述为“某类事件在某个环节上，人工反复做了同样的判断和操作”。

把痛点转成可自动化场景，可以用一个简单的判断链：该场景是否高频发生？处理步骤是否相对固定？所需数据能否通过 API 或集成自动获取？判断逻辑是否可以用明确规则表达？如果四个问题的答案都是肯定的，它就是一个高优先级的自动化候选。反之，如果某类事件每次都需要资深分析师做开放式研判，那么更适合做“半自动化”——由 Playbook 完成信息聚合与初步富化，把结论留给人工。

二、定义目标：一句话说清“这个 Playbook 要解决什么”

目标定义要避免“提升安全能力”这类无法验收的表述。一个合格的目标应当包含对象、动作和可观测的结果。例如：“对来自 EDR 的‘可疑 PowerShell 执行’告警，在 2 分钟内完成主机信息、进程树、网络连接的自动富化，并对确认为恶意的样本自动隔离主机，将分析师从平均 15 分钟的手工排查中释放出来。”这句话里已经隐含了触发源、处理时限、处理动作和收益指标。

目标还要明确边界：这个 Playbook 不处理什么。例如上述场景中，若告警来自非受管主机，或进程属于已知的运维脚本白名单，则不应进入自动隔离分支。边界写清楚，后续设计分支和测试用例时才有依据。

三、输入与输出：把接口约定前置

输入决定了 Playbook 能否被正确触发，也决定了它能否拿到足够的数据。输入通常包括三类：触发事件本身（告警来源、告警类型、严重级别、时间戳）、事件携带的实体（IP、域名、文件哈希、主机名、账号）、以及外部上下文（资产库中的主机归属、业务重要性、历史告警记录）。设计时要逐项确认：这个字段由谁提供？格式是什么？缺失时如何处理？

输出同样需要提前定义。输出不只是“发一条通知”，而应包括：处置动作的结果（是否隔离、是否封禁、是否创建工单）、产生的证据（富化结果、判定依据、执行日志）、以及回写到哪些系统（工单系统、CMDB、告警平台）。输出定义清楚，才能让下游流程和审计有据可依。

四、成功标准：让 Playbook 上线后能被验收

成功标准是需求分析中最容易被忽略、却最影响长期价值的部分。它至少要覆盖四个维度：准确性、时效性、覆盖率和可观测性。准确性关注误判与漏判，例如“误隔离率不超过 1%”“白名单命中不触发隔离”；时效性关注每个关键环节的耗时上限；覆盖率关注自动化实际承接了多少比例的事件；可观测性则要求每一步执行都有日志、每个判定都有证据、关键指标能上报到运营看板。

这些标准不是拍脑袋定的，而应来自现状基线。例如，如果当前人工处理该类告警平均耗时 15 分钟、误判率约 3%，那么把目标设为“2 分钟内完成富化、误隔离率低于 1%”就是有依据的。上线后按同一口径统计，才能判断 Playbook 是否真正解决了痛点，而不是制造了新的告警噪音。

五、一份可直接使用的需求分析记录表

把上述内容落到纸面，可以用下面这份记录表。它不追求字段多，而是确保每个关键决策都有出处，方便评审和后续迭代。

完成需求分析后，团队应当得到一份经过评审的规格说明：场景清晰、目标可验收、输入输出明确、成功标准可量化、边界与例外有约定。这份说明既是后续流程设计、节点编排和测试用例编写的依据，也是上线后评估效果、决定是否迭代或下线的基准。需求分析做得越扎实，Playbook 的返工就越少，自动化收益也越容易说清楚。