AI 基础
什么是事故自动化？工作流、护栏与使用案例
将 Unite.AI 添加到您在 Google 上的首选来源
事故自动化使用软件来检测、丰富、路由、协调，有时还会修复运营或安全事故。它将监控信号与运行手册、工单、沟通、访问控制和恢复操作相连接，使响应者花更少的时间复制数据，更多的时间做决策。
自动化并不等同于取消人为责任。安全的程序会将低风险的确定性步骤与可能影响客户或生产的操作区分开来，然后根据影响程度应用审批、受限凭证、审计日志、超时和回滚。
关键要点
- 在尝试自主修复之前，自动化可重复的证据收集。
- 使用严重性、置信度、影响范围和可逆性来选择审批级别。
- 将每个运行手册视为带有测试和负责人、具备版本管理的生产代码。
- 衡量检测、确认、恢复、复发以及用户影响，而不仅仅是警报数量。
从信号到协同响应
工作流可以对警报进行去重、附加最近的部署和日志、识别服务所有者、打开事故记录、呼叫值班团队、创建沟通渠道并启动时间线。这些步骤在不进行风险诊断的情况下减轻认知负担。
关联必须保留证据。如果平台过于激进地对症状进行分组，可能会隐藏并发事故。将自动化链接到 IT 运维所有权，并保留响应者可能需要的原始信号。
根据风险选择操作
只读查询、快照和可逆的流量切换通常比删除数据、轮换广泛凭证或更改生产模式更容易实现自动化。为每个操作定义前置条件、执行超时、后置条件以及回滚。
使用最小权限的服务身份，并将授权与工作流引擎分离。高影响步骤应要求指定审批人。如果 AIOps 提出原因或修复方案，响应者仍需有支持证据并具备安全的拒绝方式。
构建可靠的运行手册
运行手册应声明输入、依赖、所有者、范围、失败行为以及产生的证据。在预演和演练日进行测试。幂等步骤很有价值，因为重试不会产生额外危害。
像其他软件一样对自动化进行版本管理和审查。监控凭证过期、API 变更、速率限制、部分执行以及服务之间的隐藏耦合。当自动化平台本身不可用时，仍需手动流程。
恢复后学习
自动化应保留带时间戳的信号、决策、操作、审批和结果记录。随后进行无责审查，可将导致事故的系统条件与最终触发因素区分开来，并将经验教训转化为经过测试的改进。
有用的度量包括平均确认时间和恢复时间、安全步骤自动化比例、失败操作率、重复事故以及客户影响。将发现与 DevOps 规划关联，而不是仅仅优化已关闭工单的数量。
事故自动化的类型
事件自动化对传入信号进行标准化和丰富。协调自动化创建事故记录、呼叫所有者、打开沟通渠道并发布状态更新。诊断自动化执行只读查询或捕获快照。修复自动化改变系统状态，而恢复自动化验证服务健康并关闭临时缓解措施。
这些类别不应共用同一默认信任级别。丰富通常可以自动运行；生产故障切换可能需要置信检查和审批人；数据恢复通常需要事故指挥官和应用所有者。控制应依据潜在影响，而非步骤是由规则还是机器学习模型实现。
安全事故增加了证据保存的要求。自动化必须避免在捕获易失数据之前修改受损主机，避免在公共渠道泄露敏感指示器，或在未了解影响范围的情况下隔离共享基础设施。运营和取证运行手册可能会重叠，但其执行顺序可能不同。
工作流设计与控制平面
将运行手册建模为具有前置条件和终结结果的显式状态。每个操作应报告已启动、成功、失败、超时或跳过，并附带不可变的执行标识符。中心编排器可以协调步骤，但下游服务应自行强制授权并独立验证输入。
使用受限的短期凭证并限制自动化引擎的网络路径。区分开发、测试和生产运行环境。机密信息不得出现在聊天记录或日志中。对于高影响操作，需要两人审批或紧急破窗角色，其使用会立即生成审查记录。
设计时考虑部分失败。工单可能在呼叫失败时已创建；流量切换可能在某一区域成功而在另一区域超时。补偿操作、对账任务和明确的所有权可防止工作流仅因编排过程结束而报告成功。
示例、测试与成熟度
成熟的首个用例是数据库连接耗尽：收集连接池指标、最近部署、慢查询和所有者信息；打开事故；提出可逆的扩容或流量操作；要求审批；随后验证错误率和延迟。相同模式可用于证书过期、磁盘压力、作业失败或可疑账户活动。
通过单元测试、模拟 API、预演事故、演练日和受控生产演练来测试运行手册。注入陈旧数据、权限拒绝、慢依赖、重复事件和冲突事故。确认重试是安全的，且响应者能够在不与自动化冲突的情况下手动接管。
成熟度从通知、到丰富、再到引导操作、最后到受限的自动修复逐步提升。进阶应基于证据：稳定的诊断、低失败操作率、已验证的回滚以及明确的用户收益。自主关闭应保持稀少，直至系统能够证明恢复并保留足够的证据供后续学习。
案例演示：自动化生产服务事故
考虑一个支付 API 在部署后错误率上升的情况。监控发出包含服务、环境、地区、版本、错误预算和运行手册链接的结构化警报。自动化将其与变更记录、依赖健康、最近日志和所有权信息进行丰富，然后将重复警报合并为一个事故。确定性策略可以立即暂停进一步的发布；回滚应要求提供新版本导致问题的证据以及回滚的安全性。
工作流指派事故指挥官，打开沟通渠道，记录时间线，并建议诊断步骤。自动化修复从低风险的可逆操作开始，例如将流量切换到健康实例。每个操作都需要授权、并发限制、超时、已验证的后置条件以及回滚。生成式摘要可以帮助响应者，但源遥测和命令保持可见，以便团队能够质疑不正确的叙述。
衡量检测、确认、缓解和恢复的时间；警报数量；重复抑制；修复成功率；复发率以及自动化导致的危害。针对凭证过期、区域部分失效、误导性警报和回滚失败进行演练。恢复后，保留事实时间线，识别导致问题的技术和组织因素，更新运行手册和测试，并跟踪纠正工作直至完成，而不是将快速缓解视为可靠性工作的结束。
实用实施清单
将概念转化为受限且可测试的工作流：检测 → 丰富 → 分类 → 审批 → 修复 → 学习。指定负责的所有者，记录数据和依赖，建立简易基准，设定接受和停止标准，测试代表性故障，并在扩大范围前定义监控、回滚和审查。记录版本和假设，以便其他团队能够复现结果并了解变更情况。
上线前，进行有文档记录的就绪评审，邀请构建、运营、安全以及受系统影响的人员。测试正常情况、边界条件、依赖故障和误用；保留证据和未解决的风险。明确谁可以批准发布、修改阈值、覆盖输出或停止操作。实际数据到来后重新审视决策，因为技术上成功的试点并不保证在更大规模下的可靠表现。
- 证据：保留原始信号和上下文。
- 护栏：范围、审批和回滚。
- 学习：审查改进系统和运行手册。
常见问题
事故自动化与 AIOps 是同一回事吗？
否。AIOps 将分析或机器学习应用于运维数据。事故自动化是更广泛的执行与协调层，可使用简单规则、AIOps 输出或两者结合。
首先应自动化哪些内容？
从高频、低风险、易于理解的步骤开始，例如丰富、所有权查询、证据采集、状态更新以及可逆的诊断。
主要参考文献
