为什么自己主办一个待命平台?
待命系统载有敏感的操作数据:雇员时间表、联系方式、警报有效载荷、服务名称、事件时间表和与内部系统的链接。 一些小组倾向于将这些信息保存在自己的网络和数据库中。
自我托管也使各小组能够控制部署的时间,整合,保留,备份和准入边界. 权衡是直截了当的:您操作平台并拥有其可用性. 没有魔法云, 只有一台接收发票的电脑。
IncidentRelay 包含什么
- 待命时间表、旋转层和临时控制层
- 警告 Alertmanager,Zabbix,Sentry 和通用网络呼号的路由 。
- 升级政策、提醒和答复者请求。
- 服务、依赖性、维护窗口和事件优先事项。
- Mattermost,Telegram,电子邮件,浏览器推,webhook和语音通知.
- 个人API令牌和OpenAPI文档。
部署选择
IncidentRelay 支持几种部署模式,使团队能够使用熟悉的操作工具.
| 方法 | 典型用途 |
|---|---|
| Docker Compose | 评价、较小的环境和直接部署集装箱。 |
| RPM 软件包 | 红帽般的Linux系统通过软件包和系统的工作流程进行管理. |
| 手工系统d | 基于源的部署和自定义的Python环境. |
| Helm 图表 | Kubernetes 部署有单独的网络, 调度器和可选的Telegram 工人 。 |
数据库和规模选择
SQLite可用于小型单节点设施. PostgreSQL是更大或更长运行环境,更高警戒量和部署多个网络工人的实际选择. 调度器是一个单独的程序,因此提醒和升级不会在网络工人中重复。
与您已运行的堆栈融合
IncidentRelay 充当监测系统、服务所有权、时间表和通知目的地之间的路由层。 路由有他们自己的接收符,并确定接收警报到哪里去. 通道描述被选中的响应者是如何被通知的.
通用的webhoks和OpenAPI端点使得无需等待特定供应商的集成即可连接内部工具. 自定义的语音提供者可以安装给运行自己电话工作流程的团队.
业务责任
自办事故平台应像生产基础设施一样对待. 计划数据库备份,监控网络和调度服务,测试通知渠道,并为影响IncidentRelay的事件保留紧急路径. 它本身。
API,配置和计划可能在发布之间演化,因此在生产推出前审查发布说明和测试升级.