Google Cloud在2026年9月6日为Google SecOps推出Case Playbooks预览功能。过去的Playbook主要围绕单条Alert运行，一个安全案件中出现多条相关告警时，同一动作可能被重复执行；新功能把自动化范围提高到整个Case容器，让团队能够对案件中的告警、实体和上下文集中处理。
这项变化适合包含大量相似告警的调查场景。比如同一个IP地址出现在十条告警中，Case Playbook可以只做一次信誉查询，再把结果同步到相关实体，减少重复请求和第三方API费用。
自动化范围从单条Alert扩大到整个Case
Alert Playbook关注一条告警的上下文，Case Playbook则可以访问案件内的全部告警与实体。安全团队可以在案件创建时运行工作流，也能在调查过程中手动挂载Playbook，或者直接执行一次Case级Manual Action。
这种范围变化并不是把原有脚本简单循环多次。一个案件可能把多个来源、多个规则产生的告警聚合在一起，Case Playbook的目标是利用汇总后的上下文完成一次统一操作。
真正减少的是重复响应，而不是告警数量。例如创建一个统一的ITSM工单、发送一条完整通知或对案件内实体做一次批量富化，都比逐条告警触发更容易保持结果一致。
重复实体默认只处理一次
同一个IP、主机名或用户可能在多个告警中反复出现。Case Playbook会聚合案件内的实体，并在每个动作中提供Deduplicate entities开关，该选项默认启用。
启用后，平台按照实体标识和类型提取唯一对象，只把去重后的集合发送给第三方工具。外部结果返回后，系统再把信息同步到案件内所有匹配的重复实体，避免浪费API额度。
实体循环也有独立的去重开关。只有确实需要保留每个告警实例的属性时，才适合关闭去重；否则同一对象可能被重复封禁、查询或提交给外部系统。
Case Playbook支持三类运行方式
第一类是在新案件摄取时自动挂载，可以选择全部案件、自定义条件或指定Tag。第二类是在调查过程中手动把工作流应用到Case，适合临时重新富化全部实体或补充统一通知。
第三类是Reaction Trigger，根据案件负责人、优先级、阶段、标签、评论或自定义字段的变化自动执行。这让Playbook不只在案件刚创建时运行，也能跟随调查生命周期继续响应。
管理员还可以在案件界面直接运行Case级Manual Action。内置集成默认支持该范围，自定义Python脚本则要确认能够遍历整个告警数组，否则可能漏掉部分实体详情。
只会提取Open状态告警的数据
官方文档明确说明，Case Playbook执行时只处理和提取案件中状态为Open的告警数据。已经关闭的告警不会自动进入同一次处理范围，这一点会直接影响统计、富化和外部同步结果。
案件范围不等于无条件覆盖案件中的全部历史告警。上线前应使用包含Open与Closed告警的测试Case验证脚本输入，避免团队误以为Playbook会处理完整历史记录。
Case Playbook执行记录目前也不会进入Legacy Monitoring仪表盘，以及Managed BigQuery和BYOBQ形式的SOAR Data Exports。依赖这些旧监控或导出渠道审计自动化的团队，需要额外确认可观测方式。
预览阶段应先检查集成版本和脚本范围
Case Playbooks属于Pre-GA预览能力，环境中没有看到功能时，需要在Preview Features中检查开关或联系管理员。预览功能的支持范围和兼容性仍可能变化，不适合未经验证就直接接管关键处置流程。
Google同时列出了多项集成的最低版本要求，包括Jira 58、ServiceNow 67、GoogleChronicle 84和Siemplify 108等。旧版本集成可能无法完整支持Case级工作流，升级前要核对依赖与回滚方案。
更稳妥的做法是先选取通知、建单或只读富化这类可回退流程试用，再检查实体去重、告警状态、权限和执行记录。确认不会重复修改外部系统后，再逐步加入封禁、账号重置等高影响动作。
