チーム別アラート振り分けを設定する
アラートが増えるにつれて、「全員がすべてのアラートを受け取る」構造はすぐに破綻します。結局は皆がアラートを無視するようになり、本当に急を要する異常まで埋もれてしまいます。WhaTapの イベント受信タグ を使えば、「このアラートはこのチームだけに」のような振り分けを5分で構築できます。
このガイドは、メンバーの招待が完了したプロジェクトの管理者とアラート運用担当者を対象とします。
- チーム/役割別に異なるアラートを受信する仕組み
- 障害対応担当者ローテーションの技術的基盤(担当者だけにタグ付与)
- 全員一斉配信に比べ大幅に低いノイズ
事前準備
- メンバーの招待が完了している → チームとダッシュボードを共有する
- 基本のイベントルールが最低1つある → 最初のアラートを設定する
- メンバー管理 権限(他のメンバーにタグを付与するために必要)
ステップ1. イベント受信タグを作成する
経路: ホーム > プロジェクト > アラート通知 > 通知設定
- ユーザー別アラート受信設定 セクションのユーザー一覧で + タグ追加(または +)ボタンをクリックしてください。
- イベント受信タグ 画面で + 新規タグ作成 ボタンをクリックしてください。
- チーム/役割単位でタグを作成してください。
Backend担当者DBチームFrontend担当者管理者
- 色を指定して タグ作成 ボタンをクリックしてください。
- 「このアラートを誰が見るべきか」 で名前を付けてください(職務ベース)。個人名を入れると異動や退職のたびにタグ名を変更する必要が生じます。
- 最初は3〜4個が適切です。細分化はシグナルが溜まった後で遅くありません。
ステップ2. メンバーにタグを付与する
ユーザー一覧で、各メンバーに該当するタグを割り当てます。
- メンバー名の横のタグ領域をクリックし、作成したタグを割り当ててください。
- 複数の重複付与が可能です(例: DBチームであり管理者でもある)。
- イベントルールに受信タグが指定されている場合、該当タグを持たないメンバーはアラートを受信しません。全メンバーに引き続き基本アラートを届けたい場合は、タグを指定しないでください。
タグを付けただけでは、そのメンバーがアラートを受信できるわけではありません。アラート通知受信 権限(または本人の受信手段)も併せて有効化されている必要があります。
ステップ3. イベントに受信タグを紐付ける
作成したタグを実際のイベントルールに紐付けて、振り分けを動作させます。
- アラート通知 > イベント設定 メニューを選択してください。
- 既存のイベントルール、または新規ルールで イベント受信タグ フィールドを確認してください。
- そのイベント発生時に通知を送るタグを指定してください。
- 例: 「DBコネクションプール閾値超過」→
DBチーム - 例: 「決済API エラー率急増」→
Backend担当者
- 例: 「DBコネクションプール閾値超過」→
- 保存 ボタンをクリックしてください。
イベント受信タグが空の場合、プロジェクト全員 に通知が送信されます(既存動作)。
ステップ4. 担当者ローテーションへ拡張する
同じタグを誰が持っているかだけを切り替えれば、週次・月次の担当者ローテーションがすぐに実現します。
- 今週: Aに
Backend担当者タグを付与 - 来週: Aからタグを外し → Bに付与
イベントルールはそのままで、タグの割り当てだけを移すため 運用コストが低くなります。チームカレンダーやWikiに「今週の担当: B」という簡単な表があれば十分に管理できます。
結果確認
- ユーザー別アラート受信設定 セクションにタグ一覧が表示され、メンバー別の割り当てが見える
- テストイベント発生時、指定タグのメンバーにだけ通知が届く
- タグのないメンバーには該当イベントの通知が行かない(従来の全員配信に比べノイズ減)
チーム別アラート振り分けの基盤が完成しました。この次にエスカレーションや外部ツール連携を重ねれば、本格的な担当者体制になります。
参考。WhaTapのStatefulアラート方式
タグで受信対象を減らすこと以外にも、WhaTapは アラート自体をStateful方式で管理 し、ノイズを大幅に削減します。
| 方式 | 動作 |
|---|---|
| Stateless(他ツールの一般形) | 閾値を超えるたびに通知を繰り返し送信 |
| Stateful(WhaTap) | イベント状態がOnになった 最初の通知のみ 発生し、状態が続く間は重複通知を抑制。状態がOffに戻ると解除 |
同じ閾値超過が長く続いても、最初の1回と状態変化の時点 のみ通知が届くため、同じイベントを繰り返し受け取る疲労を構造的に軽減します。追加設定は不要で、デフォルト動作です。
重要度別にアラートチャンネルを分離する
Stateful方式と併せて、アラート 受信手段を重要度別に変える パターンも効果的です。
- Critical → SMS / モバイルプッシュ / PagerDuty・Opsgenie連携(緊急対応)
- Warning → Slack / Teamsチャンネル(チーム共有)
- Info / 参考 → Webhook・Email(ログ記録用)
このマッピングを個人別受信設定(メール・SMS・WhatsApp・モバイル)と組み合わせれば、当番者の携帯にだけ緊急通知が届き、チーム全体にはチャンネル共有のみが流れる構造になります。
次のステップ
- 未解決アラートの繰り返し送信 → 繰り返し通知(エスカレーション)を設定(例:
0, 1H, 1DをCriticalのみ適用) - Slack / PagerDuty / Webhook連携 → サードパーティ連携で外部ツールと結合
- 大量アラートの抑制 → イベント設定で同一イベントの持続時間やスロットリングを適用
- 自身の受信手段を選択 → メール/SMS/WhatsApp/モバイルの個人受信設定(メンバー権限 参照)