为什么事件响应团队也应测试人工智能工具？

人工智能改变了安全与运维团队处理事件的方式。如今，它被用于告警分类、运行手册检索、行动建议，甚至用于编制事后分析。但被称为 Tabletop Exercises 的模拟演练仍然主要测试人员对流程的了解，以及他们在压力下做出决策的能力，却没有测试已经成为他们与信息之间中介的智能系统。

由 Webflow 以赞助内容形式发布的这篇文章认为，这造成了一个实际缺口：如果人工智能是实际响应流程的一部分，那么它也应成为测试的一部分。这适用于安全团队、使用人工智能进行故障分类的网站可靠性团队、依靠人工智能指导升级处理的支持团队，以及使用人工智能自动化访问请求的 IT 运营团队。

从测试人员到测试整个系统

传统模拟演练假定工具是固定不变的，主要变量是人员：谁收到告警？谁拥有决策权限？团队是否能足够迅速地遵循运行手册？但人工智能工具的故障未必会以明显故障的形式出现。它可能自信地提供错误摘要，可能因为关键词匹配而检索出过时的手册，也可能提出看似合理但并不安全的行动。

这些无声的故障可能会拖慢响应，或在没有错误信息提醒的情况下将团队推向错误决策。因此，不包含这些情况的演练，只测试了真实事件期间将运行的整个系统的一部分。

应纳入演练的情况

• 自信地给出错误答案：可以模拟根本原因识别或文档检索中的幻觉。目的不是假定系统不会出错，而是测试响应人员核实信息、避免将答案视为事实的能力。
• 人工智能系统发生故障：应测试用于调查的系统变得不可用，或受到事件本身影响时会发生什么，以及团队是否仍然知道如何手动执行分类。
• 在压力下越过防护措施：这些控制措施在平静的审查中可能看似合适，但当事件持续数小时、有人希望系统直接执行行动而不是将其提交人工批准时，可能会被忽视。
• 手动技能逐渐弱化：长期依赖自动检索可能会削弱团队搜索文档和在没有帮助的情况下执行步骤的能力。
• 交接点模糊：应测试工作人员是否清楚知道系统的职责在哪里结束、人的决策从哪里开始，尤其是在自动建议具有说服力但部分错误的情况下。

团队如何更新演练？

机构无需取消现有项目，而应增加一个针对人工智能工具本身的层面。还应让构建和管理这些工具的人员参与其中，因为他们最有能力确定工具的故障模式。复盘会议也不应只问“团队是否遵循了运行手册？”，还应提出另一个问题：“团队是否给予了系统恰当程度的信任？”信任程度过低会浪费工具的价值，而过度信任则可能把错误答案直接变成事件恶化的原因。

文章强调，一次测试并不足够，因为模型、检索来源和防护措施会随着时间推移而变化。因此，每当影响响应的系统组件发生变化，都应重新进行演练。

certi.news 的编辑解读

这里真正的变化并不是将人工智能加入工具清单，而是它进入了决策链中具有影响力的位置。这扩大了事件响应的范围：团队测试的不仅是人员准备程度，还包括这一压缩信息并提出下一步行动建议的中介的可靠性。该观点的局限也很明确：文章没有提供独立的测量结果或评估此类演练的统一标准，而且依据的是 Webflow 的经验，因此应将其建议视为可调整的实用框架，而非普遍性的证明依据。