在 PagerDuty 选项中进行什么比较
有用的问题不是两种产品是否有相同的菜单。 选择是否支持您团队的操作工作流程取决于:时间表、警报接收、路径、通知、确认、升级和可靠的事件历史。
IncidentRelay不是一个滴入式克隆,也不主张每个商业平台的特征均匀. 它侧重于为SRE,DevOps和业务团队提供实用的自办工作流程.
核心工作流程覆盖面
| 要求 | IncidentRelay办法 |
|---|---|
| 待命时间表 | 旋转、层层、会籍期、超载和日历信息。 |
| 警报摄入量 | Alertmanager, Zabbix,Sentry和通用的网络hook端点. |
| 运行 | 路标,标签匹配器,服务,团队和重度过滤器. |
| 升级 | 提醒和命令针对用户或轮换的升级政策步骤。 |
| 反击行动 | Ack知识、解决、沉默、评论和其他响应者请求。 |
| 通知 | 聊天,电子邮件,浏览器推,webhooks和可插入的语音呼叫. |
自负盈亏
托管平台减少业务工作。 自动托管的平台对数据、部署、集成和访问提供了更多的控制。 IncidentRelay采取第二种方法:你选择数据库,部署模型,网络边界和升级时间.
这种控制伴随着对备份、监测和可用性的责任。 团队应该诚实地评价这一成本,而不是将"开源"作为"操作自己"的同义词.
PagerDuty 迁移
迁移用户、团队、排班、升级策略、服务、Webhook 路由和维护窗口。
迁移工具使用公共 API，不会连接产品数据库，并且默认以试运行模式运行。应用更改前，请查看生成的报告。
路线和渠道分开
IncidentRelay将进入的警报路线与离开的通知渠道分开。 一条路由拥有接收符,决定团队,服务,调度和匹配行为. 通道决定如何联系选定的响应者.
这种模式使得回答两个不同的问题更加容易:谁被允许提交这一警报,以及由此产生的通知应在哪里送达?
服务和事件背景
服务将警报与受影响的系统、所有权、运行簿、依赖性和违约利益攸关方联系起来。 在发生事故时,应答者可以管理优先权,请求额外帮助,并随时向利益攸关方通报情况,而不使每个观察员都成为活跃的受让人。
当IncidentRelay可能适合时
- 你的团队需要自备部署
- 您需要开放源代码的排程和在一个平台的提示路径 。
- 您使用 Alertmanager,Zabbix,Sentry 或基于 Webhook 的监视 。
- 您想要扩展通知或语音工作流程 。
- 你接受运行平台的操作责任.
用真实的事件来评估
创建团队,轮换,服务和路线. 发送测试提示,验证选中的待命用户,从通知中确认并测试升级路径. 这说明你不止是一份特写清单
IncidentRelay正在积极开发。 遵循 changlog 当前的能力 。
PagerDuty是PagerDuty的商标, IncIncidentRelay不隶属于PagerDuty.