PagerDuty の代替と比較するもの
2つの商品が同じメニューを持っているかどうかは、有用な質問ではありません。 チームの運用ワークフローをサポートする代替手段は、スケジュール、アラートインテーク、ルーティング、通知、承認、エスカレーション、信頼性の高いインシデント履歴に依存するかです。
IncidentRelayは、ドロップインクローンではなく、すべての商用プラットフォームで機能のパリティを主張しません。 SRE、DevOps、およびオペレーションチームに対して、実用的なセルフホストワークフローに焦点を当てています。
コアワークフローのカバレッジ
| 必須条件 | IncidentRelay アプローチ |
|---|---|
| オンコールスケジュール | 回転、レイヤー、会員期間、オーバーライド、カレンダーフィード。 |
| アラートの摂取 | Alertmanager、Zabbix、Sentry、および一般的なWebhookエンドポイント。 |
| ログイン | ルートトークン、ラベルの一致器、サービス、チームおよび重度のフィルター。 |
| エスカレーション | ユーザや回転をターゲットとするエスカレーションポリシーのステップをリマインダーし、注文。 |
| 回答者行動 | Ack確認、解決、沈黙、コメント、および追加の応答者のリクエスト。 |
| お知らせ | チャット、メール、ブラウザのプッシュ、Webhook、プラグイン可能な音声通話。 |
自己ホスティングはトレードオフを変更します
ホストされているプラットフォームは、運用作業を削減します。 セルフホスト型プラットフォームは、データ、デプロイメント、統合、アクセスをさらに制御できます。 IncidentRelay は 2 番目のアプローチを取ります。データベース、デプロイメントモデル、ネットワーク境界、アップグレードのタイミングを選択します。
その制御は、バックアップ、監視、可用性の責任が付属しています。 チームは「オープンソース」を「運用する」の代名詞として扱うのではなく、正直にコストを評価するべきです。
PagerDuty の移行
ユーザー、チーム、スケジュール、エスカレーションポリシー、サービス、Webhook ルート、メンテナンスウィンドウを移行します。
移行ツールは公開 API を使用し、製品データベースには接続せず、デフォルトでドライランモードで動作します。変更を適用する前に生成されたレポートを確認してください。
経路とチャネルは別々にとどまります
IncidentRelay は、発信通知チャネルから受信するアラート ルートを分離します。 ルートは、インテークトークンを所有し、チーム、サービス、スケジュール、マッチング行動を決定します。 チャネルは、選択した応答者がどのように連絡するかを決定します。
このモデルは、2つの異なる質問に答えるのが簡単です:このアラートを提出することができ、結果通知が配信されるべき場所?
サービスおよびインシデントのコンテキスト
サービスは、影響を受けるシステム、所有権、ランブック、依存関係、およびデフォルトの利害関係者にアラートを接続します。 インシデント中に、応答者は優先順位を管理し、追加のヘルプを要求し、すべてのオブザーバーにアクティブなアサインをすることなく、ステークホルダーに通知を維持することができます。
IncidentRelayが合う場合
- チームには、自発的な展開が必要です。
- 1つのプラットフォームでオープンソースのスケジューリングとアラートルーティングが必要です。
- Alertmanager、Zabbix、Sentry、または webhook ベースの監視を使用します。
- 通知や音声ワークフローを拡張したい。
- プラットフォームの運営上の責任を承諾します。
実際のインシデントフローで評価
チーム、回転、サービス、ルートを作成します。 テストアラートを送信し、選択したオンコールユーザーを検証し、通知から確認し、エスカレーションパスをテストします。 機能チェックリストよりも多くのことを伝えます。
IncidentRelay は積極的に開発されています。 現在の機能の changelog に従って下さい。
PagerDuty は PagerDuty, Inc. IncidentRelay の商標です。 PagerDuty と提携していません。