捕捉症状和业务影响
记录用户观察到的情况、开始时间、受影响的服务或地点、影响范围、可用证据以及可靠联系方式。不要强迫报告者诊断根本原因或分配技术优先级。
用一条运维记录串联影响、责任人、诊断、进展更新、临时解决方案、恢复、验证和后续任务。
实时事件视图聚焦正在发生的服务中断和时间风险,帮助处置人员与服务负责人判断当前行动,并保留验证恢复及分析复发所需的信息。
最多 5 名用户可免费使用,无需信用卡。
无需编程即可调整字段、工作流和仪表板。 探索 1,000 多个应用模板和业务场景
第一个视图显示处理中事件工作。使用移动选项卡可以通过手机报告症状、影响、证据和联系方式。
记录应帮助人们快速恢复服务,同时防止重要背景和决策在聊天中丢失。
记录用户观察到的情况、开始时间、受影响的服务或地点、影响范围、可用证据以及可靠联系方式。不要强迫报告者诊断根本原因或分配技术优先级。
让一个人对事件负责,另一个角色在需要时对利益相关者的更新负责。展示下一步行动、下一次更新时间、升级状态和目标风险,而不是依赖私人提醒。
记录解决方法或恢复操作、技术验证、受影响用户确认以及重新打开的条件。已解决的状态不应抹去失败的恢复检查。
处置人员、服务负责人、领导者和受影响用户需要同一事件的不同视图。
保持可观察到的症状、最近的变化、受影响的配置项、日志或附件、调查记录、假设、行动和结果的时间顺序上下文,同时不要在用户更新中暴露私人技术讨论。
发布已确认的影响、可用解决方法、当前恢复活动以及下一次更新的时间。将事实与假设区分开,并保持受众和传达状态可见。
展示业务影响、已用时长、服务关键性、未履行的承诺、升级、复发情况,以及在恢复后是否需要问题评审或变更。
不是每个事件都需要完整的事后分析,但每次结束都应留下可辩护的运营结果。
将重复的症状和相关事件链接到问题记录,以便在响应渠道平静后,根本原因分析、已知错误和解决方法仍能继续进行。
当永久修复需要生产环境更改时,将事件连接到具有自身风险、验证、授权、实施和回滚决策的变更。
为重新开启的服务、重复的警报、用户投诉或未解决的纠正措施安排短期有效性检查。可重新审查时,关闭的信心更强。
严重性标签应解释响应模型,而不是替代判断。
| 观察到的状况 | 响应模型 | 关闭前的证据 |
|---|---|---|
| 关键服务对许多用户不可用 | 重大事件协调和频繁更新 | 满足恢复标准;已通知利益相关者 |
| 材料损坏但有解决方法 | 拥有事件并进行目标意识响应 | 解决方法或恢复已验证 |
| 有限的用户影响 | 标准事件队列 | 报告者或服务负责人确认使用 |
| 相同症状反复出现 | 事件加上关联问题 | 立即恢复与预防工作分开 |
根据处置人员所需的信号配置事件记录:受影响的服务、用户影响、已用时长、拥有者、当前操作、更新频率、解决方法、恢复和确认。
其结果是一个支持在中断期间采取行动并在恢复后仍然有用的事件记录。在不要求报告者诊断原因的情况下改变影响和紧急性问题,然后将记录发送给负责团队。
记录调查、决策、权宜措施、受众更新以及针对相同事件的下一步承诺行动。
要求技术恢复、业务验证、用户确认或其他定义的检查,并在事件重新打开时保留先前的历史记录。
Jodoo 可以协调事件记录及其人工交接,而不替代可观察性或呼叫工具。
影响捕获、优先级、责任归属、调查历史、通信、恢复检查、重新打开以及相关问题或变更工作。
参考警报、日志、跟踪、值班事件、部署记录、状态通信以及其权威系统中的技术证据。
本地事件关联、自动呼叫、事件聊天编排或可观察性引导的响应是核心购买需求。
事件用于恢复意外中断或降级的服务。服务请求满足定义的、预期的需求,如访问、设备或标准服务。保持生命周期相关但分开。
通常他们应描述可观察的影响和紧迫性。服务团队可以使用受影响的服务、用户范围、关键时间窗口、安全或合规影响以及可行的应对措施来应用优先级模型。
可以。保留原始的恢复操作和验证结果,记录服务再次失败的原因,并继续生命周期,而不是删除或掩盖早先的决定。
可以,通过适当的集成或自动化。监控仍然是技术信号的来源;Jodoo 协调影响、责任、更新、恢复检查及相关工作。
获得授权的配置人员可以在事件实践成熟的过程中,无需编写代码即可调整接收字段、优先级规则、响应步骤、通知、恢复证据和仪表板。