オブザーバビリティは『システムに質問できる状態』
オブザーバビリティ（可観測性）は、本番システムに対して「何が起きているか」を後追いで質問できる状態を作る考え方です。監視（事前定義された指標を見る）より一歩進んだ概念で、未知の問題にも対応できます。本記事では、オブザーバビリティの3本柱と実装パターンを編集部の視点で整理します。SREへの転身ガイド もご参考に。
3本柱の役割
(1) ログ：個別イベントの記録。(2) メトリクス：時系列の集計値。(3) トレース：1リクエストの流れ。(4) 相互補完：問題発見→詳細調査→再現の流れ。(5) イベント：高次の業務イベント。Sentry活用、Webパフォーマンス改善 もご参考に。
ログの設計
(1) 構造化ログ：JSON 等で検索可能に。(2) レベル分け：DEBUG/INFO/WARN/ERROR。(3) トレース ID の埋込：横断検索の基盤。(4) 個人情報マスキング：プライバシー保護。(5) 保存期間と検索性：コストとのバランス。セキュリティエンジニアへの転身ガイド もご参考に。
メトリクスの設計
(1) RED メソッド：Rate・Errors・Duration。(2) USE メソッド：Utilization・Saturation・Errors。(3) SLI/SLO/SLA：目標値の階層。(4) ヒストグラム：分布を見る。(5) カスタムメトリクス：業務指標も追跡。「平均値だけ見る」は危険で、パーセンタイルを見る習慣が重要です。
分散トレーシング
(1) OpenTelemetry：事実上の標準。(2) サンプリング：全件は高コスト。(3) span 属性：絞り込みの軸。(4) 非同期処理の追跡：context 伝播。(5) UI での可視化：Jaeger・Tempo・Datadog。マイクロサービス設計 もご参考に。
OpenTelemetry の導入
(1) SDK のインストール：言語別 SDK。(2) 自動計装の活用：HTTP・DB・gRPC を自動。(3) エクスポータ設定：Jaeger・OTLP・各種 SaaS。(4) 環境分離：開発・本番でサンプリング率を変える。(5) コスト管理：トレース・ログ量の制御。Python学習、TypeScript学習 もご参考に。
アラート設計
(1) SLO 違反でアラート：症状ベース。(2) 原因系メトリクスは情報として：通知しない。(3) 誤検知を減らす：通知疲れを避ける。(4) 担当者の自動割当：オーナーシップ。(5) 定期的な見直し：古いアラートを削除。エンジニアの燃え尽き予防 もご参考に（通知疲れ）。
運用上のコツ
(1) 『未知の未知』に備える：事前定義に頼らない。(2) ダッシュボードの整備：見る人が一目で。(3) ポストモーテム文化：障害から学ぶ。(4) ランブック整備：対応手順を残す。(5) 定期的な障害訓練：本番想定の演習。エンジニアのドキュメント技術 もご参考に。
失敗しがちなパターン
(1) ログだけ・メトリクスだけ：横断調査ができない。(2) 過剰収集：コスト爆発・ノイズ。(3) 個人情報の混入：規制違反リスク。(4) アラート過多：通知疲れで重要なものを見落とす。(5) 調査文化なし：データが活用されない。対策は、(1)3本柱統合、(2)サンプリング、(3)マスキング、(4)SLO ベース通知、(5)障害訓練、です。IT・Web業界の職種完全マップ もご活用ください。