オブザーバビリティ
見えないものは直せません。オブザーバビリティはインシデント後に後付けするものではなく、設計段階から組み込むものです。プロダクションに関する質問に答えるためにコード変更が必要なら、それは計装が間違っています。
ルール
- 三本柱：ログ、メトリクス、トレース。 それぞれ異なる質問に答えます — 何が起きたか（ログ）、どれくらい＆どの程度頻繁に（メトリクス）、なぜ遅かったか（トレース）。3つすべてが必要です。
- 構造化ログのみ。 JSON（またはそれに類する形式）。スケール環境では
grepは戦略になりません。 - すべてのログ行に相関/トレースID。 サービス間の境界を越えてヘッダーで伝搬します。1つのIDでリクエストの全体像をつなぎ合わせます。
- すべてのエンドポイントにREDメトリクス。 Rate（レート）、Errors（エラー）、Duration（持続時間、P50/P95/P99付き）。リグレッションを検出するための最低限の指標です。
- すべてのリソースにUSEメトリクス。 Utilization（使用率）、Saturation（飽和度）、Errors（エラー） — CPU、メモリ、プール、キュー、ディスク、ネットワークに対して。
- すべてのクロスサービスコールをトレース。 OpenTelemetry を使用します。DBクエリやキャッシュヒットもスパンとして取得します。
- 生のメトリクスではなく、SLOに基づいてアラートを発報。 「CPU > 80%」は午前3時に人間を無駄に起こします。「P99レイテンシがSLOを5分間超過」は実際のユーザー体験の問題を捉えます。
- ヘルスチェックとレディネスチェックは異なるエンドポイント。
/health= 「生きています、再起動しないでください。」/ready= 「今すぐトラフィックを受け入れられます。」 そのように扱ってください。 - 適切なレベルでログを出力し、イベントごとに1回だけ出力。
INFOはリクエストライフサイクル、WARNは復旧可能な問題、ERRORは人間の対応が必要なもの。重複ログはダッシュボードを誤ったものにします。 - PIIや機密情報をログに記録しない。 アペンダーでマスクしてください。呼び出し元が覚えているとは期待しないでください。
- すべてのアラートはランブック（対応手順書）を参照する。 文書化されたアクションがないアラートは、ページングを装ったSlack通知に過ぎません。
レッドフラグ
- プロダクションをデバッグするためにPodにSSH接続する。
- 日常的に発報されて無視されるアラート。（アラート疲れは信頼性の問題です。）
- コンテキスト、ID、スタックトレースなしで
"error occurred"とだけ言うログ。 - パーセンタイルなしで平均値のみを示すメトリクス。
- サービスごとのダッシュボードはあっても、ユーザージャーニーごとのダッシュボードがゼロ。