根据证据创建问题
使用重复的症状、服务历史、趋势分析、重大事件复盘、供应商信息或高影响的近乎发生的事故来开启一个带有明确调查问题的问题。
归集相关事件,分析影响因素,发布可执行的临时解决方案,管控永久修复,并验证复发率是否真正下降。
工作区从重复模式和已知错误状态开始。它将即时恢复与根本原因工作分开,同时连接验证更改所需的证据,并测试预防措施是否有效。
最多 5 名用户可免费使用,无需信用卡。
无需编程即可调整字段、工作流和仪表板。 探索 1,000 多个应用模板和业务场景
第一个视图显示活动问题、已知错误、解决方法以及纠正措施状态。其他标签页关联事件、变更和有效性检查。
事件管理现在恢复服务。问题管理询问导致中断可能再次发生的原因。
使用重复的症状、服务历史、趋势分析、重大事件复盘、供应商信息或高影响的近乎发生的事故来开启一个带有明确调查问题的问题。
记录疑似原因、支持和矛盾证据、实验、观察、依赖关系以及影响因素。不应仅为了填写字段就将早期理论转化为正式根本原因。
发布一个安全、范围明确的权宜之计,处置人员现在可以应用,然后用自己的风险、验证、授权、实施和回滚证据来管理永久更改。
只有当处置人员能够识别该情况并安全行动时,已知错误记录才有用。
说明受影响的服务或配置、可观察的指标、触发条件、用户影响、诊断检查和排除条件,以便处置人员知道何时适用该记录。
记录前提条件、步骤、风险、权限、预期结果、验证和回滚。指定负责人和审查日期,以防解决方法成为永久性的口口相传的做法。
记录何时、由谁、在何环境中以及取得什么结果应用了解决方法。这种使用历史能够改善响应以及永久修复的决策。
完成某个动作并不等同于降低其旨在解决的操作风险。
选择一个可衡量的指标,例如复发率、故障量、恢复时间、警报模式、客户影响或人工干预,并设定适当的观察期。
确认已批准的修正措施已到达预期的服务、配置、地区或用户组,并且监控或业务检查仍按预期运行。
如果事件再次发生或措施未改善,保留早期的假设和行动证据,然后继续调查,而不是通过关闭来制造成功。
这可以防止问题工作重复事件或变更控制。
| Question | 主记录 | 有用的结果 |
|---|---|---|
| 我们现在如何恢复服务? | 事件 | 已验证的恢复或安全变通方法 |
| 为什么这会一直发生? | 问题 | 支持的原因和预防计划 |
| 回应者在此期间如何安全处理? | 已知错误 | 可识别的症状和受控变通方法 |
| 我们如何安全地改变生产环境? | 变更 | 授权的实施和验证 |
连接症状、受影响的服务、假设、证据、已知错误、变通方法、纠正变更和有效性检查,而无需将它们强制纳入事件单。
结果是一个预防系统,其中每一个理论、临时解决方法、变更和有效性决策都与运营证据保持关联。将多个事件关联到一个问题,同时保留每个事件的影响、时间、恢复路径和服务背景。
显示谁可以使用临时解决方法,其风险和限制,以及哪些条件需要升级而不是非正式重复使用。
跟踪变更或操作直至完成,定义观察期,并在关闭风险之前记录复发情况或其他有效性信号。
在技术分析保留在最适合的工具中进行的同时,保持问题记录与运营证据的联系。
重复事件分组、假设、证据引用、已知错误、受控解决方法、纠正性变更、行动及有效性评估。
引用拓扑、日志、指标、跟踪、代码、部署、供应商分析和知识源,而不是将它们重复为无结构化笔记。
自动化拓扑、遥测关联、机器辅助根因分析或成熟的嵌入式知识生态系统在上线时至关重要。
事件管理在服务中断后恢复正常服务。问题管理调查一个或多个事件背后的原因和条件,并控制旨在减少重复或影响的工作。
包括可识别的症状、受影响的服务或配置、已确认或可疑原因、诊断检查、带有风险和验证的受控解决方法、责任人、审核日期,以及相关事件和变更的链接。
不需要。仅在事件重复发生、影响较大、不确定性高、存在风险或具有学习价值时,才创建问题记录,以便进行超出恢复的调查。避免将问题记录作为每个事件的强制性重复。
可以。在保持监控系统作为技术来源的同时,将相关警报、趋势和诊断证据链接或导入,同时使用Jodoo作为调查和后续处理的记录。
是的。获得授权的配置人员可以在无需编写代码的情况下完善假设、证据、解决方法、纠正措施、审核和有效性检查的字段和工作流程。