这些指南以 IR v2.3.1 为目标，并于 进行了检查。它们是工作示例，而不是生产默认值或交货时间承诺。
选择问题，然后配置
小型团队的事件响应在线商店：为结帐失败提供所有者和备份，而无需询问整个工程聊天室中谁还醒着。
开源待命DevOps夜间备份：注意到一台服务器上未完成的任务，并在下一个工作日之前分配后续工作。
自托管警报路由服务提供商：独立的客户端警报流并减少支持团队之间的手动转发。
针对 SREB2B SaaS 的随叫随到管理：跨时区、交接和节假日规划所有权，而不是依赖最先应答的人。
在估计回报之前衡量变化
这些是模型场景，而不是客户成功案例。将试点与涵盖类似警报源和工作时间的基线进行比较。跟踪确认、无主警报和手动重新路由的时间；报告样本大小以及百分比。检查相关商务、支持或备份系统中的业务成果。仅更快的确认并不能证明收入或可用性已恢复。
每个飞行员必须证明什么
成功的 HTTP 请求仅仅是一个开始。在真实设备上查看所选路线、服务、受托人和交付情况。然后测试响应程序丢失、重复事件、恢复和提供商中断。在移动生产发送器之前保留回滚路径。
IR接收来自监控系统的信号；它不会取代他们的检测逻辑。自托管还可以将可用性、备份、升级和提供商凭证留给您的团队。首先选择一个狭窄的工作流程，只有在验收检查通过后才进行扩展。