IncidentRelay v2.3.1 的工作示例，于 检查。下面的名称、标识符和时间是说明性的；在使用生产凭据之前在测试部署中验证它们。
业务示例 · 设置 · 工作示例 · 验收检查 · 限制和失败模式
业务示例：三个客户端系统，一个嘈杂的支持聊天系统
说明性场景，而非客户案例研究。以下指标是针对您的试点的建议，不是衡量节省的结果，也不是 IR 包含每个报告仪表板的声明。
情况和风险。服务提供商支持三个客户端，每个客户端都有应用程序和基础设施警报。一切都在一次聊天中完成。工程师将消息转发给其他团队，而重复的警报会掩盖原始报告。业务风险是延迟所有权和可避免的支持工作，即使监控及时检测到故障也是如此。
IR 工作流程。将每个客户服务映射到其负责的团队，并为每个发件人使用预期的路由令牌。匹配环境和服务标签，选择待命目标，并仅在预期所有权边界内进行组重复。在扩展模式之前，使用下面的匹配器试用一个客户的生产计费服务。
验证操作优势。用显式路由替换常规消息转发。保留可以采取行动的团队的第一响应，同时在多个主机报告相同问题时保留单独的子警报。
测量内容。对每个客户端的第一个路由决策后重新分配的警报、没有所有者的组以及每个客户端的每个潜在故障的通知进行计数。还要审查被拒绝或不匹配的测试事件：如果客户端的中断变得不可见，那么更少的页面并不成功。
边界。标签匹配不是客户数据隔离。单独审查访问权限、凭据和部署边界。不一致的标签或过于广泛的分组仍然可能会将工作发送给错误的团队或合并不相关的症状；在加入另一个客户之前验证这些案例。
单独的摄入、所有权和交付
生产计费服务和暂存副本不应意外唤醒同一个人。对于第一个试点，为生产计费团队创建 Webhook 路由，选择其默认服务和轮换或策略，然后附加渠道。它的接收令牌选择路线；仅匹配标签并不能验证发件人身份或选择任意路由。
窄路由匹配器和显式分组键
将其粘贴到路线的匹配器编辑器中。它是一个匹配器对象，而不是传入的 webhook 主体。所有条件都使用 AND 语义。要求生产和服务标签可将暂存和未标记的事件排除在这条路线之外。
{
"source": "webhook",
"labels": {
"environment": "production",
"service": "billing-api"
}
}对于本示例，将路线的 group_by 字段设置为：
["alertname", "severity", "labels.cluster"]然后，同一集群中报告相同警报的两个主机可以共享一个警报组，同时保留单独的子身份。对于通用 Webhook，请使用稳定的指纹，例如 billing:node-1:health 和 billing:node-2:health。包含有关失败和恢复的预期标签，并且切勿使用新的时间戳作为每次重试的标识。
重复数据删除和分组不同：相同的指纹更新子指纹；具有相同组密钥的不同指纹会在一组中创建单独的子项。路线、团队、来源和服务也是范围分组。仅当每个主机应该是一个单独的组时，才将 instance 添加到分组字段。
当一个发送者真正为多个团队服务时
当必须从事件内容中选择所有权时，请使用全局编排。在构建器中，从条件 labels.environment equals production 和 labels.service equals billing-api 开始，然后从同一组中选择有效的团队、路线和服务对象。不要在安装之间复制数字对象 ID。
验证并模拟匹配和不匹配，发布，然后使用具有 hybrid 兼容性的 shadow。在切换到 active 之前检查实际执行情况。影子记录决策而不改变生产行为；模拟器不能证明端到端交付。
使用小型路由测试矩阵
| 输入 | 本示例的预期结果 |
|---|---|
| 生产计费事件 | 匹配器通行证；选定的服务、受让人和渠道与计划的所有权相匹配。 |
| 暂存或丢失服务标签 | 匹配器未通过。确认发件人的预期替代路径；此示例不会创建包罗万象的路由。 |
| 重复指纹 | 同一个子项已更新。当分组标签匹配时，不同的主机指纹会在同一组中创建第二个子指纹。 |
| 两个孩子中只有一个康复 | 那孩子下定决心；该小组继续射击，直到所有射击儿童康复为止。孤立恢复不会创建新组。 |
避免悄然抹去证据的规则
空的匹配器可以匹配所有内容。名为 severity 的标签不会自动与标准化事件严重性相同的字段；使用记录的现场路径并检查真实的标准化事件。不需要在也需要接受恢复的接收路径上使用 status=firing。
active + legacy 不应用编排决策。在hybrid中，无效的实体组合可以回退到旧路径；相反，权威 orchestration 模式会阻止对评估或实体验证失败的处理。有意识地选择失败行为。
开始时不要使用广泛的 drop 或 suppress 规则。抑制和分组可以减少通知，但不会使不良的监控信号发挥作用。保留经过测试的先前版本，并在扩展部署之前检查意外的不匹配情况。