PagerDuty 대안을 비교하는 것
유용한 질문은 두 개의 제품이 동일한 메뉴가 있는지 여부. 대안이 운영 워크플로우를 지원하는지 여부는 다음과 같습니다. 일정, 알림, 라우팅, 알림, 인정, 에스컬레이션 및 신뢰할 수 있는 사고 기록.
IncidentRelay는 드롭 인 클론이 아니며 모든 상업 플랫폼과 기능 패리티를 주장하지 않습니다. 그것은 SRE, DevOps 및 운영 팀을위한 실용적인 자체 호스팅 워크플로에 중점을 둡니다.
핵심 작업 흐름 적용
| 자주 묻는 질문 | IncidentRelay 접근 |
|---|---|
| On-call 일정 | 회전, 층, 회원 기간, overrides 및 달력 피드. |
| 경고 접수 | Alertmanager, Zabbix, Sentry 및 일반적인 webhook 엔드 포인트. |
| 로그아웃 | 노선 토큰, 라벨 매치, 서비스, 팀 및 severity 필터. |
| 관련 기사 | Reminders 및 주문된 에스컬레이션 정책 단계 타겟팅 사용자 또는 교체. |
| 응답자 행동 | Acknowledge, 해결, 침묵, 의견 및 추가 응답자 요청. |
| 공지사항 | 채팅, 이메일, 브라우저 푸시, webhooks 및 플러그인 음성 통화. |
Self-hosting는 거래 오프를 변경
호스팅 플랫폼은 운영 작업을 감소시킵니다. 자체 호스팅 플랫폼은 데이터, 배포, 통합 및 액세스에 더 많은 제어를 제공합니다. IncidentRelay는 두 번째 접근 방식을 취합니다. 데이터베이스, 배포 모델, 네트워크 경계 및 업그레이드 타이밍을 선택하십시오.
그 제어는 백업, 모니터링 및 가용성에 대한 책임이 있습니다. 팀은 정직하게 "오픈 소스"를 "운영 자체"에 대한 동의로 대우하는 것보다 비용을 평가해야한다.
PagerDuty 마이그레이션
사용자, 팀, 일정, 에스컬레이션 정책, 서비스, 웹후크 경로 및 유지 관리 기간을 마이그레이션합니다.
마이그레이션 도구는 공개 API를 사용하며 제품 데이터베이스에 연결하지 않고 기본적으로 드라이런 모드에서 실행됩니다. 변경 사항을 적용하기 전에 생성된 보고서를 검토하세요.
노선 및 채널은 별도의
IncidentRelay는 아웃고딩 알림 채널에서 들어오는 알림 경로를 분리합니다. 경로는 입구 토큰을 소유하고 팀, 서비스, 일정 및 일치 행동을 결정합니다. 채널은 선택한 응답자가 접촉하는 방법을 결정합니다.
이 모델은 두 가지 다른 질문에 대한 답을 쉽게 할 수 있습니다 : 누가이 경고를 제출 할 수 있으며, 결과 알림이 전달되어야합니까?
서비스 및 사건 상황
서비스는 영향을받는 시스템, 소유권, runbooks, 의존성 및 기본 이해 관계자에게 경고를 연결합니다. 사건 중, 응답자는 우선 순위를 관리 할 수 있으며, 추가 도움을 요청하고 모든 통계를 작성하지 않고 이해 관계자에게 알려줍니다.
IncidentRelay이 적합 할 수 있습니다.
- 귀하의 팀은 자체 호스팅 배포를 요구합니다.
- 오픈 소스 스케줄링 및 경고를 하나의 플랫폼에서 필요로 합니다.
- Alertmanager, Zabbix, Sentry 또는 webhook 기반 모니터링을 사용합니다.
- 알림 또는 음성 워크플로우를 확장하고 싶습니다.
- 플랫폼 실행의 운영 책임을 수락합니다.
실제 사건 흐름으로 평가
팀, 회전, 서비스 및 경로 만들기. 테스트 경고를 전송, 선택한 on-call 사용자를 확인, 알림에서 인정 및 에스컬레이션 경로 테스트. 그것은 당신에게 더 많은 기능을 체크리스트가 될 것입니다.
IncidentRelay는 적극적으로 개발되었습니다. 현재 기능에 대한 changelog을 따르십시오.
PagerDuty는 PagerDuty, Inc. IncidentRelay의 상표는 PagerDuty와 제휴하지 않습니다.