衡量自动化影响

自动化是一项投资。构建和维护响应手册需要投入工程时间。为了证明这项投入合理，并明确需要改进的地方，您必须衡量每个自动化工作流的影响。

没有指标，您无法区分每周节省数小时的响应手册和只是更快地悄悄做出错误决策的响应手册。度量会将自动化从凭感觉的尝试转变为一种工程实践。

最直观的指标是分析师节省的时间。对于每项自动化任务，估算手动处理的基准耗时，再乘以运行次数。

如果一次网络钓鱼分诊手动需要 30 分钟，每月运行 200 次：

两个生命周期指标可以体现安全运营中心的表现：

• MTTD（平均检测时间）——从失陷到检测。SOAR 对此影响较小；这主要是检测工程指标。
• MTTR（平均响应时间）——从检测到遏制。这正是 SOAR 发挥优势的地方。

请跟踪部署响应手册前后的 MTTR。从数小时降至数分钟，是自动化发挥作用的最有力证据。

自动化率是由响应手册完全或部分处理的事件，在所有事件中所占的比例，相对于需要人工处理的事件而言。

请进一步细分：

• 完全自动化——无需人工介入即可关闭。
• 人工辅助——响应手册完成信息补充，由人工做出判断。
• 完全人工处理——没有应用响应手册。

完全自动化率和人工辅助率不断上升，说明覆盖范围正在扩大；比率停滞不前则表明响应手册需要扩展。

如果决策错误，速度就毫无意义。请将效率指标与质量指标结合起来：

• 自动关闭的误报率（响应手册关闭的是否是真实威胁？）。
• 重新打开率——响应手册关闭后，分析师不得不重新打开的案例所占的比例。
• 否决率——分析师拒绝响应手册建议操作的频率。

否决率很高的快速响应手册并没有节省时间，只是在造成不信任。

有些数字看起来很亮眼，却会误导人。若响应手册处理的是琐碎或重复事件，那么响应手册执行次数就是一种虚荣指标。

一份响应手册每月触发 10,000 次，听起来很有成效；但如果其中 9,000 次是它本应抑制的重复警报，那么真正的问题是上游噪声，而不是自动化价值。请始终将活动计数与结果和节省的时间联系起来。

只有记录下来的内容才能被度量。请在每份响应手册中加入遥测数据：在开始和结束时发出一条结构化记录，其中包含决策、持续时间和来源事件。

影响需要通过比较来判断，因此您需要一个之前的数值。在推出自动化之前，记录当前的 MTTR、人工处理时间，以及每种警报类型所需的分析师工时。

跳过基线的团队永远无法证明自动化的价值；他们只有一个自动化后的数字，却没有任何可供比较的对象。即使只是非正式记录，也请先记录基线，然后在每份响应手册上线后重新度量。

高管关心的是风险和成本，而不是操作手册的内部细节。请将指标转换为他们熟悉的语言：

• 将节省的小时数表示为重新获得的全职当量（FTE）产能。
• 将 MTTR 的缩短表述为攻击者驻留时间和入侵风险的降低。
• 将一致性和审计覆盖范围表述为合规准备度。

通过一个将自动化与时间、风险和成本联系起来的仪表板，可以持续获得项目所需的资金支持。

指标会进入反馈闭环。请按固定周期审查这些指标，以决定要构建、修复或下线哪些内容。

• 覆盖率很高 -> 决策逻辑有误；请对其进行改进。
• 噪声较大的警报自动化率较低 -> 这可能是新增操作手册的候选对象。
• 很少触发的操作手册 -> 请考虑将其下线，以减少维护工作。

自动化永远不会真正完成；度量会告诉您下一步应该在哪里投入资源。

节省时间的数据只说明了一半情况。每本操作手册都承担持续的维护成本：集成会中断，应用程序接口会发生变化，决策逻辑也需要调整。

衡量价值的诚实方式是看净值：

度量自动化的影响：

• 通过度量来证明投资合理并找出改进方向；在部署操作手册前先记录基线。
• 跟踪每次运行节省的时间、MTTR 的缩短，以及自动化率（全自动、人工辅助和手动）。
• 将速度与质量结合起来：误报关闭数、重新打开率和人工覆盖率。
• 避免使用原始执行次数等虚荣指标；始终将活动与结果联系起来。
• 为操作手册添加遥测数据，用领导层关注的语言报告影响（节省的 FTE、驻留时间风险），并运行持续改进闭环。