IncidentRelay v2.3.1 的工作示例，于 检查。下面的名称、标识符和时间是说明性的；在使用生产凭据之前在测试部署中验证它们。
业务示例 · 设置 · 工作示例 · 验收检查 · 限制和失败模式
业务示例：每晚一次备份永远不会完成
说明性场景，而非客户案例研究。以下指标是针对您的试点的建议，不是衡量节省的结果，也不是 IR 包含每个报告仪表板的声明。
情况和风险。一家公司在工作日开始之前在两台服务器上备份其订单数据库。一项工作悄然停止；另一个成功了。单一的共同成功信号将掩盖差距。业务风险是仅在需要还原时才发现旧的或丢失的恢复点。
使用 IR 的工作流程。定义完成期限并分别跟踪每个预期服务器。主机仅在作业和成功检查完成后发送其心跳。未完成的操作会创建一个逾期警报，并路由至平台响应者，并提供备用升级路径。工程师调查或重新运行作业并记录结果。
需要验证的运营效益。在下一个业务转变之前将静默的计划作业失败转变为自有任务。相同的模式可以涵盖计划的导出或批处理作业，前提是其完成信号真正代表成功。
测量内容。跟踪每台服务器错过的最后期限、从最后期限到确认的时间以及最新验证备份的期限。将备份验证和恢复钻取结果保留在备份系统或操作报告中；不要从绿色心跳中推断出它们。
边界。心跳证明信号到达，而不是可以恢复数据。它不保证恢复点或恢复时间。测试独立恢复并从同一故障域外部监控 IR 本身。
将寻呼系统视为您运营的服务
考虑一个拥有生产集群和夜间数据库备份的平台团队。它希望 IR 靠近其监控堆栈，但这也使得团队负责唤醒它的系统。指定 Web 服务、调度程序、数据库、机密和恢复过程的所有者。
发布Docker设置分别运行网络和调度程序服务。在测试环境中遵循该部署指南后，从版本检查中检查它们：
docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-schedulerWeb 流程接受传入警报； 调度程序处理提醒、升级和定期作业。不要在每个 Web Worker 内部启动调度程序。正常运行的登录页面并不能证明定时升级正在运行。
检测一台主机上丢失的备份
创建一个计划完成检测信号，该检测信号在每日 UTC 时间 03:00 到期，附加到源为 heartbeat 的路由。启用实例跟踪；对于固定队列，请使用静态预期实例，例如 db-1 和 db-2。附上平台轮换或政策和测试渠道。
主机备份及其成功检查完成后，将此正文发送到内容类型为 JSON 的 POST /api/heartbeats/ping/HEARTBEAT_TOKEN。使用该检测信号的秘密 URL，而不是路由令牌或管理 API 令牌。
{
"status": "completed",
"instance": "db-1",
"payload": {
"job": "nightly-database-backup"
}
}从每个主机发送不同的实例值。如果没有实例跟踪，来自一台服务器的成功 ping 操作可能会隐藏另一台服务器丢失的备份。作业失败后，请勿从 shell 清理处理程序无条件发送成功 ping。从代理和作业日志中编辑秘密 ping URL。
测试失败，不仅仅是启动
- 对两个预期实例执行 Ping 操作，然后在简短的测试计划中故意忽略一个实例。当健康实例保持正常状态时，预计该实例会出现逾期警报。
- 恢复丢失的实例。如果启用自动解决，请验证其逾期警报是否已解决，而无需解决另一个实例的故障。
- 仅在测试部署中停止调度程序。观察对定时工作的影响并证明独立监督员注意到了这一点；然后恢复并验证处理。
- 将数据库、配置和所需机密还原到隔离环境中，并阻止出站通知。在允许交付之前检查旧的触发组，因此恢复演习无法寻呼生产响应人员。
成功 ping 并不是恢复测试
心跳检测丢失的信号；它们不是活动的 HTTP/TCP 探测器，无法证明备份可用。 IR 也无法可靠地通知您其自身的全面中断。在同一故障域之外保留外部可用性检查和单独的联系路径。
自托管不会消除聊天、电子邮件、语音或网络依赖性。决定哪种数据库和部署模型适合工作负载，固定测试版本，并演练升级和回滚。这些示例并未建立高可用性或吞吐量保证。
有意设置保留：默认情况下，已解决的警报历史记录会无限期保留。清理还可以删除链接的评论和发送记录，并且不一定会缩小数据库文件。保留不能替代备份。