什么样的即时调度软件应该解决
值班时间表回答了一个简单的操作问题：现在谁负责？当团队有多个时区、交接、分层覆盖、假期、临时替换和不同的升级路径时，答案就变得不那么简单。
IncidentRelay 继续接近警报路由 时刻表不是一个孤立的日历:它决定了哪些响应者收到警报,何时发出提醒,如果当前人不承认事件,谁是下一个.
时间表、班次和旋转层
团队可以创建旋转并加入一个或多个层. 每层可以定义自己的参与者,时间和限制. IncidentRelay 计算这些层的最终调用结果, 给操作员一个当前所有者, 同时保留它背后的结构 。
- 创建团队专用值班轮换.
- 初级、二级或时间限制的覆盖率使用层。
- 设定会员期, 计划更改不会重写历史 。
- 应用临时覆盖而不重建基本计划。
- 将轮换与路线和升级政策联系起来。
现实生活中的临时重置
人们度假,换班,偶尔发现两个日历在交割前5分钟出现分歧. 旋转重置在固定时间内替换预定人员,同时使原旋转配置完好无损.
这使得业务时间表明确和可以审计。 responders可以看到最终的拥有者,而管理员则保留基础旋转并覆盖历史.
日历访问
IncidentRelay 包括一个内部日历, 并支持只读日历同步 。 团队可以通过CalDAV或私人ICS的feed和查看Outlook,Google日历,苹果日历,雷鸟和兼容客户端的待命换班.
日历订阅对能见度有用,但IncidentRelay仍然是提醒所有权和升级的真相来源. 在个人日历中移动一个事件不会默默地重写运行时间表.
连接到提醒响应的时间安排
时间表在推动行动时变得很有价值。 入境警报与路线、服务、队伍和轮换相匹配。 IncidentRelay 然后通过配置的频道通知当前待命用户, 当警报仍未被确认时可以升级 。
通知选项包括Mattermost,Telegram,电子邮件,浏览器推,webhoks和可插件语音提供者. 报复者可以承认或解决事件,同时保持所有权。
给谁用的?
IncidentRelay 是为 SRE,DevOps , 平台, 基础设施和操作团队设计 的, 这些团队想要在自己的环境中有一个待命调度系统. 当警报数据、用户数据和时间表仍由小组控制时,这一点尤为重要。
部署在生产中的小组应首先测试其调度规则、通知渠道、备份和部署模式。