ストーリー

アラート設計の原則

アラート疲れを防ぐ設計

アラートレベルの定義

アラートルールの設計

LLMシステム向けアラートルール

from dataclasses import dataclass
from enum import Enum

class AlertLevel(Enum):
    INFO = "info"
    WARNING = "warning"
    ERROR = "error"
    CRITICAL = "critical"

@dataclass
class AlertRule:
    """アラートルール定義"""
    name: str
    metric: str
    condition: str  # ">", "<", "==", "change_rate>"
    threshold: float
    level: AlertLevel
    window_minutes: int = 5
    consecutive_count: int = 3  # N回連続で閾値超過
    notification_channels: list[str] = None
    runbook_url: str = ""  # 対応手順書のURL

# NetShop社のアラートルール例
alert_rules = [
    AlertRule(
        name="エラー率上昇",
        metric="error_rate",
        condition=">",
        threshold=0.05,
        level=AlertLevel.ERROR,
        window_minutes=5,
        consecutive_count=3,
        notification_channels=["slack-ai-alerts", "email-oncall"],
        runbook_url="https://wiki.netshop.co.jp/runbook/error-rate"
    ),
    AlertRule(
        name="レイテンシP95超過",
        metric="latency_p95_ms",
        condition=">",
        threshold=5000,
        level=AlertLevel.WARNING,
        window_minutes=10,
        consecutive_count=2,
        notification_channels=["slack-ai-alerts"]
    ),
    AlertRule(
        name="品質スコア低下",
        metric="quality_score",
        condition="<",
        threshold=0.7,
        level=AlertLevel.ERROR,
        window_minutes=60,
        consecutive_count=1,
        notification_channels=["slack-ai-alerts", "pagerduty"]
    ),
    AlertRule(
        name="コスト急増",
        metric="hourly_cost_usd",
        condition="change_rate>",
        threshold=2.0,  # 前時間比200%
        level=AlertLevel.WARNING,
        window_minutes=60,
        consecutive_count=1,
        notification_channels=["slack-ai-alerts", "email-finance"]
    ),
    AlertRule(
        name="ドリフト検出",
        metric="psi_score",
        condition=">",
        threshold=0.2,
        level=AlertLevel.ERROR,
        window_minutes=1440,  # 日次
        consecutive_count=1,
        notification_channels=["slack-ai-alerts"]
    ),
]

ダッシュボード設計

ダッシュボードの階層構造

Level 1: エグゼクティブダッシュボード（経営層向け）
├── 月次AIコスト推移
├── 主要KPIサマリー（品質、可用性、コスト）
└── インシデント件数推移

Level 2: オペレーションダッシュボード（運用チーム向け）
├── リアルタイムメトリクス（エラー率、レイテンシ、スループット）
├── モデル別パフォーマンス比較
├── アラート状況一覧
└── ドリフト検出状況

Level 3: デバッグダッシュボード（開発チーム向け）
├── リクエスト詳細ログ
├── プロンプト別成功率
├── トークン使用量の内訳
└── エラーの詳細分析

主要パネルの構成

運用ランブック

ランブックの構成

エラー率上昇時のランブック例

【ランブック: エラー率上昇】

1. 初期確認（5分以内）:
   □ エラーの種類を確認（APIエラー? タイムアウト? バリデーション?）
   □ 影響を受けているモデル/エンドポイントを特定
   □ 直近のデプロイ変更がないか確認

2. 原因切り分け（15分以内）:
   □ 外部API（OpenAI等）のステータスページを確認
   □ 入力データの異常がないか確認（サイズ、形式）
   □ インフラメトリクス確認（CPU、メモリ、ネットワーク）

3. 対処:
   □ 外部APIダウンの場合 → フォールバックモデルに切替
   □ 入力データ異常の場合 → 入力バリデーション強化
   □ インフラ問題の場合 → スケーリング or 再起動
   □ 原因不明の場合 → エスカレーション（AI推進チームリーダー）

4. 復旧確認:
   □ エラー率が閾値以下に回復したことを確認
   □ 影響を受けた処理の再実行が必要か判断
   □ インシデントレポートを作成

まとめ

チェックリスト

• アラート疲れを防ぐ設計原則を理解した
• 4段階のアラートレベルと対応SLAを設計できる
• LLMシステム向けのアラートルールを定義できる
• 階層的なダッシュボード設計ができる
• ランブックの構成と記述方法を把握した

次のステップへ

次は演習で、NetShop社のモニタリング基盤を実際に設計します。

推定読了時間: 30分