モジュール 12ターム4 · 本番運用11 ポスター項目

オブザーバビリティと SRE

ログインすると、進捗を複数のデバイスで保存できます。ログインするまでは、このブラウザに保存されます。

なぜ重要なのか

アラートより先に顧客から「壊れている」と知らされるなら、それはモニタリングではなく、顧客に QA をさせているだけです。オブザーバビリティは、AI が書いたコードをデバッグ可能にするものでもあります。自分で書いていないコードなら、システム自身に何をしているかを語ってもらう必要があります。

学習目標

  1. OpenTelemetry で構造化ログ、メトリクス、トレースを出力できる。
  2. ユーザーの満足度を反映した SLI と SLO を定義し、エラーバジェットを運用できる。
  3. 対応可能で、アラート疲れを起こさないアラートを書ける。
  4. 4 つのゴールデンシグナルのダッシュボードを構築できる。
  5. LLM とエージェントの振る舞い、コスト、品質を観測できる。

レッスン

12.1 3 つのシグナル（58〜61, 66）

  • ログ（59）: 構造化された JSON で、1 行に 1 イベント。request_id、user_id/tenant_id（PII ではないもの）、level、event、処理時間を含めます。シークレット、トークン、パスワード、カード番号の全桁、生の個人データは決してログに出しません。保持期間を設定します。
  • メトリクス（61）: 安価な数値の時系列データです。サービスには RED（Rate、Errors、Duration）、リソースには USE（Utilisation、Saturation、Errors）を使います。
  • トレース（60）: 1 つのリクエストを、サービス、キュー、LLM 呼び出しをまたいで、スパンとタイミング付きで追跡します。トレースコンテキストはキューと webhook を通して伝播させます。
  • モニタリング（58） は既知の障害モードを監視します。オブザーバビリティ（66） は、新しいコードをリリースせずに、稼働中のシステムに新しい問いを投げかけられるようにします。両方が必要です。
  • ベンダーロックインを避けるため OpenTelemetry を使います。

12.2 4 つのゴールデンシグナル

レイテンシ、トラフィック、エラー、飽和度（Google の SRE プラクティスより）。サービスごとにダッシュボードを 1 つ用意し、ページの最上部に置きます。

12.3 SLI、SLO、エラーバジェット（63, 64, 65）

  • SLI（64）: 良いイベントの割合を計測したものです:「500 ms 未満で正常に処理されたリクエスト / 全リクエスト」。
  • SLO（63）: 一定期間における SLI の目標値です:「28 日間で 99.9%」。
  • エラーバジェット（65）: 許容される失敗の量です。28 日間の 0.1% は約 40 分です。バジェットが残っていれば、どんどんリリースしてかまいません。使い切ったら、ペースを落として信頼性を改善します。
  • SLO はサーバー単位ではなく、ユーザージャーニー単位（ログイン、チェックアウト、AI の回答）で決めます。100% は誤った目標です。コストが見合わず、あらゆる変更を止めてしまいます。

12.4 アラート（62）

  • 人を呼び出すのは、CPU のスパイクのたびではなく、ユーザーが今まさに、あるいはまもなく困る とき（症状ベース）だけにします。
  • SLO に対する burn-rate アラート を優先します（速い消費はページング、遅い消費はチケット）。
  • すべてのアラートを runbook にリンクします: 何を意味するか、どう確認するか、どう緩和するか。
  • ビジネスアラートも設定します: 1 時間サインアップがゼロ、決済成功率の低下、LLM の利用額の急増、DLQ の増加、cron のハートビートの欠落。
  • アラートのノイズを毎月見直し、誰も対応しないアラートは削除します。

12.5 ヘルスチェックとプローブ（56, 57）

07 · レジリエンスパターン を参照してください。複数リージョンから実際のジャーニーを確認する外部の合成監視を追加します。

12.6 LLM とエージェントのオブザーバビリティ

すべてのモデル呼び出しをトレースします: モデル、バージョン、プロンプトのバージョン、入出力トークン数、コスト、レイテンシ（最初のトークンまでの時間と合計）、ツール呼び出し、検索したソース、ユーザーフィードバック、eval のスコア。ツール: Langfuse、Helicone、Braintrust、または OpenTelemetry GenAI の規約に沿って既存のバックエンドへ送る方法。モデルやプロンプトの変更後は、品質のドリフトに注意します。

12.7 エラートラッキングと RUM

ソースマップとリリースタグ付きの例外トラッキング（Sentry または同等のツール）。Core Web Vitals のリアルユーザーモニタリング。

Lab 12: ユーザーより先に気づく

  1. アプリに OpenTelemetry（ログ、メトリクス、トレース）をエンドツーエンドで組み込みます。キューの経由と LLM 呼び出しも含めます。
  2. 重要なジャーニーについて 3 つの SLO を定義し、ダッシュボードと burn-rate アラートを構築します。
  3. アラートごとに runbook を書きます。
  4. staging で何かを壊し、壊れてからアラートが出るまでの時間を計測します。
  5. LLM のコストと品質のパネルを作ります。

完了の定義

AI プロンプトパック

  • 「このサービスに OpenTelemetry の計装を追加してください。キューを通してコンテキストを伝播させてください。すべての LLM 呼び出しとツール呼び出しを、トークン数とコストの属性付きのスパンで囲んでください。」
  • 「ログ出力の呼び出しを監査し、シークレット、トークン、個人データを出力する可能性があるものにフラグを付けてください。」