根据明确标准宣布
使用服务关键性、用户范围、收入或运营影响、监管暴露和预期持续时间来决定何时将正常事件处理转为重大事件协调。
在一条共享时间线上管理指挥分工、技术工作流、相关方沟通、关键决策、恢复标准和事后行动。
重大事件室根据指挥和业务影响而开启——而不是普通的工单表单。团队可以看到谁在领导、受影响的内容、下一次更新的时间、已做出的决策,以及在事件结束前必须满足的条件。
最多 5 名用户可免费使用,无需信用卡。
无需编程即可调整字段、工作流和仪表板。 探索 1,000 多个应用模板和业务场景
第一个视图是重大事件指挥室。使用标签页检查通讯、服务影响、恢复检查和后续行动。
关键事件需要明确的权威和节奏,同时技术团队仍可自由调查。
使用服务关键性、用户范围、收入或运营影响、监管暴露和预期持续时间来决定何时将正常事件处理转为重大事件协调。
指定一名事件指挥官、技术负责人、通讯负责人、服务负责人和工作流负责人。避免让最技术的处置人员同时协调每个决策和受众。
按顺序记录已确认的事件、假设、决策、行动、结果、更新时间和状态变化。时间轴应区分当时已知的信息与事后复盘得知的内容。
可预测的更新模型可减少重复问题,并防止未经验证的解释成为承诺。
选择运营、管理、客户和监管受众;记录其更新间隔、负责人、批准的渠道及下次更新时间。
说明已确认的影响、当前行动、应急措施及下一次更新。将怀疑原因保留在技术工作流中,直到有证据支持更广泛的说明。
捕获诸如回滚、故障切换、功能禁用、流量减少或受控降级等选择,并记录决策负责人、时间、理由、预期结果和观察到的结果。
技术恢复、用户恢复和纠正措施是相互关联但不同的里程碑。
在解除指挥之前,确认服务可用性、交易成功、监控信心、积压处理、相关的数据完整性、用户验证以及利益相关者的沟通。
保留时间线和证据,然后检查条件、信号、保障措施、协调及决策,而不要将审查变成寻找个人责任的猎捕。
为每个措施指定应对的风险、负责人、截止日期、完成证据和有效性检查。仅有一个文档并不能减少复发。
升级是为了协调需要和业务后果,而不仅仅是为了一个响亮的标签。
| 信号 | 指挥决策 | 操作响应 |
|---|---|---|
| 关键的多服务或广泛用户影响 | 宣布重大事件 | 分配指挥角色并更新节奏 |
| 由稳定的权宜措施控制的严重影响 | 在风险被理解之前保持指挥 | 监控权宜措施并计划受控恢复 |
| 技术严重性高但业务影响有限 | 保持标准事件,除非协调需要更多 | 使用自有的专家响应 |
| 恢复已实现但信心不完全 | 暂勿撤离 | 验证监控、交易、用户和积压事项 |
在重大事件期间使用 Jodoo 保持声明、角色、工作流、决策、利益相关者更新、恢复标准和后续记录可见
结果是一个在响应期间仍清晰可读、在复盘期间可辩护的指挥记录。记录事件指挥官、技术负责人、通讯负责人、服务负责人以及每个工作流,不要将责任埋在聊天中
更改受众、消息字段、下次更新的时间和升级规则,以匹配影响和组织的响应实践
将解除待命的证据与事后复盘、问题、变更以及服务恢复后仍未完成的纠正措施关联起来。
在专用工具处理检测、呼叫和技术协作的同时,保持关键响应协调的可见性。
声明、指挥角色、工作流、决策、利益相关者更新、恢复标准、解除待命、复盘和纠正措施。
将呼叫事件、会议或聊天室、可观测性证据、部署记录和状态页面通信联系起来,而无需复制每个技术事件。
呼叫排班、自动呼叫、警报关联、事件室自动化和可观测性集成必须开箱即用。
当业务影响、服务重要性、协调复杂性、监管风险或预期持续时间需要专门的指挥、沟通和决策节奏,超出正常事件处理时,应宣布为重大事件。
使用能够协调优先级、角色、节奏和决策的事件指挥官。最深入的技术专家通常应领导技术工作流,而不是承担所有指挥责任。
定义诸如稳定服务、成功交易、可接受的监控、可管理的积压、验证数据、用户确认和已完成的利益相关者更新等标准。恢复信心应是可观察的。
不会。保持在专业工具中进行告警、通知和技术诊断。使用 Jodoo 来处理指挥角色、决策、利益相关者更新、恢复标准以及事件后的跟进。
可以。获得获得授权的配置人员可以在不需代码的情况下更改指挥字段、工作流、更新时间、决策记录、恢复检查和仪表板。