20. 通知先を複数持つシステム設計：チャネルごとの通知戦略の確立
単一通知チャネルへの依存がもたらす運用上のリスク
システムが正常に動作しても、通知先がダウンしていたり、特定のチャネルが利用できなくなったりすると、オペレーターは「何も通知が来ない」という事象を「システム停止」と誤認しがちです。通知システム自体を信頼性の高いインフラとして設計することが求められます。
通知の階層化とチャネルの役割定義
通知を単なるメッセージ送信と捉えるのではなく、通知の「重要度」と「即時性」に基づいてチャネルを階層化することが重要です。
| 重要度/即時性 | 推奨チャネル | 通知の目的 |
|---|---|---|
| クリティカル (Critical) | PagerDuty, 電話, 専用アラートシステム | 即時対応が必要な障害や、ビジネス停止に直結する事象のみに限定する |
| 高 (High) | Slack (メンション必須), メール | 担当者への即時確認を促す。複数人への通知が必要な場合が多い |
| 低 (Low) | Slack (一般チャンネル), チケットシステム | 情報共有、記録、後から確認するべき情報（例：日次レポートの完了通知） |
通知の分岐ロジックの組み込み
通知ロジックは、単なる「送信」ではなく、「条件分岐」の塊として設計する必要があります。これは、ワークフローエンジンや中央の通知サービス層（Notification Service）に集約するのが理想的です。
具体的なフローは以下のようになります。
- 1. イベント発生の検知: ワークフローエンジンが「処理完了」イベントをトリガーとする。
2. 状態判定: 処理結果が「成功」か「失敗」か、「警告」かを判定する。
3. 優先度マッピング: 判定された状態に基づき、通知の優先度（Critical/High/Low）を決定する。
4. チャネル選択と送信: 優先度に基づき、対応するチャネル群（例：CriticalならPagerDutyとSlack）に対して、適切なメッセージを送信する。
運用上の注意点
通知が多すぎると、オペレーターは「通知疲れ（Alert Fatigue）」を起こし、本当に重要なアラートを見逃す原因になります。そのため、通知の送信は、必ず「通知の重複チェック（冪等性）」と「通知の抑制期間（Cooldown Period）」を設けることが極めて重要です。同じ事象が短時間に複数回通知されないよう、通知サービス層で制御する必要があります。
まとめ：通知は「情報」ではなく「アクション」を伝える手段
通知システムは、単に情報を届けるパイプラインではなく、受信者に「次に何をすべきか」という明確なアクションを指示するインターフェースとして設計すべきです。重要度に応じたチャネルの使い分けと、通知の重複防止策が、運用上の信頼性を支えます。
