要点: 可観測性は、チームがより速く正しい判断を下せるときに価値を持ちます。
この記事の用語: SLI：実際のサービス品質を測る指標。SLO：その目標。エラーバジェット：許容できる失敗量。
現場の課題
CPUとメモリが正常でも、一部テナントの決済や公開処理だけが失敗することがあります。優先度のないダッシュボードやアラートを増やすほど、重要な信号は埋もれます。
単純な対策だけでは不十分な理由
資源メトリクスは利用者が仕事を完了できたかを示しません。重要な業務フローのSLIとSLOから始め、トレース、ログ、インフラ メトリクスへ下りて原因を探します。
処理フロー
利用者 業務フロー
SLI・SLO→Metrics
集約Signal→トレース
因果関係→ログ
選択検証結果
SLI・SLO→Metrics
集約Signal→トレース
因果関係→ログ
選択検証結果
アーキテクチャ上の判断
Boundaryで測定
契約上EligibleなBusiness Outcomeを数えます。
Cardinality制御
Route等はメトリクス、テナント等はトレース・ログへ置きます。
SymptomでPage
エラー-budget Burnを緊急アラートに使います。
さらに深く考える
Rare 失敗をSampling保持
エラー、Slow トレース、高価値業務フローをTail ルールで保持します。
SLOでChangeをGovern
Budgetに応じリリース速度とReliability投資を切替えます。
実装手順
- 利用者が体験する境界で、成功率と遅延のSLIを定義します。
- トレース IDとテナントコンテキストを伝播しつつ、メトリクスのラベルの種類数を制限します。
- 複数の時間枠でエラーバジェット消費率を測り、運用手順書と担当者を付けてアラートします。
コード例: Multi-window Burn Rate
budget = 1 - sloTarget
burnShort = errorRate(5m) / budget
burnLong = errorRate(1h) / budget
if burnShort > 14 and burnLong > 6:
page(owner, runbook, affectedJourney)二Windowで短い低影響Spikeを避け、実障害対応からThresholdを調整します。
想定しておく障害
- キュー境界でトレース コンテキストを失います。
- テナント Labelが時系列を爆発させます。
- ログへトークンが残ります。
監視すべきこと
| 指標 | 何が分かるか |
|---|---|
| 業務フロー別Budget Burn | Reliabilityをリリース判断へ接続します。 |
| Region別p50・p95・p99 | Tail問題を分離します。 |
| Telemetry Drop・Sampling率 | 検証結果欠落を示します。 |
設計の検証方法
- Host正常のまま業務フローを壊しアラートを確認します。
- 高Cardinality入力でもSeriesを制限します。
- HTTP、キュー、ワーカーを一トレースで追跡します。
本番導入の進め方
売上や運用に直結する業務フローを一つ選び、新SLIを旧アラートと並行運用します。実障害対応と数週間比較し、価値を証明した信号だけを置き換えます。
本番前チェックリスト
- SLOに担当者とBudget判断があります。
- テナントIDを無制限メトリクスのラベルにしません。
- シークレットをRedactしデータ 種別別Retentionを使います。
まとめ
良い可観測性は、顧客影響を素早く根拠ある運用判断へ変えます。