可観測性とSLO
概要
見えないものは運用、デバッグ、改善できません。可観測性は、最初の障害発生後に後付けするものではなく、設計段階から組み込むものです。すべてのインシデントで最初に問うのは「何が変わったのか、誰が影響を受けているのか」— これに答えられないシステムは、5分で直るはずの障害を発掘調査に変えてしまいます。
原則（普遍）
- 3つのシグナル。 構造化ログ（機械可読、自由形式テキストではない）、メトリクス（カウント、レート、所要時間）、トレース（サービス間をまたがるリクエストの経路）を出力します。リクエストはエンドツーエンドで相関ID/トレースIDを保持します。
- ゴールデンシグナルを計測する。すべてのサーフェスに対して：エンドポイント/オペレーションごとのレート、エラー、所要時間（RED）、およびリソース飽和度。新しいエンドポイントは、可観測性が確保されるまで「完了」とは見なされません。
- ヘルスはエンドポイントであり、推測ではない。 liveness（「動作中か？」）とreadiness（「トラフィックを処理できるか？」）を別々のチェックとして公開します。
- 重要なユーザージャーニーに対してSLOを定義し、それを測定するSLIと、信頼性と機能開発のトレードオフを明示的かつデータ駆動で行うエラーバジェットを設定します。
- 症状に対してアラートを発報し、原因には発報しない。 ユーザーが影響を受けているときにページングする（SLOバーン、readiness失敗）のであって、内部の些細な変動ごとにはページングしません。すべてのアラートはアクション可能である必要があります — 誰も対応しないアラートは、人々がアラートを無視する習慣を育てます。
メカニズム（このスタック）
- 構造化JSONログをstdoutに出力し、プラットフォーム（例：AKS → Azure Monitor / Log Analytics）が収集します。サービス内での自由形式テキストログは禁止です。
- アプリサーバーとPostGraphileにOpenTelemetryを組み込み、トレース/メトリクスをAzure Monitor / Application Insights（またはPrometheus/Grafana）にエクスポートします。
- データパス全体に相関IDを伝搬 — エッジで生成され、ブラウザ → アプリ → PostGraphile とコンテキストヘッダーとともに渡され、すべてのログ行とスパンに付与されます。
- HTTPルートとGraphQLオペレーションごとのREDメトリクス、PostgreSQLのスロークエリログ +
pg_stat_statements。 - liveness/readinessエンドポイントをKubernetesプローブに接続（
cloud-delivery-aks参照）。readinessは実際の依存関係の健全性（DBに到達できるか？）を反映し、単なるプロセス起動状態ではありません。 - フロントエンド： web-vitalsとクライアントエラーを同じバックエンドに報告します。
- ユーザージャーニーごとのSLOとダッシュボード、バーンレートアラート。
スケールのタイミング
ローンチ前のローカルプロジェクトでは、今すぐ構造化ログとヘルスエンドポイントを実装し、SLO/アラートは実際のユーザーを保護する必要が生じるまで延期します。最初の決定記録にモードを明記してください。
完全な根拠：憲法第IX条および第XVI条。engineering-constitution/references/engineering-constitution.mdにバンドルされています。