specsfy-specialist-observability

可観測性

使用する場面

• 依頼に計装（ログ、メトリクス、トレース）、インシデント調査、SLI／SLO の定義、またはダッシュボード／アラートの構築が含まれる場合に呼び出します。
• ロールアウトの継続、一時停止、またはロールバックを許可する客観的なシグナルを定義する場合にも呼び出します。
• すでに検出された特定のレイテンシーの根本原因を診断する場合は呼び出しません。プロファイリングと最適化には $specsfy-specialist-performance-engineering を使用します。ここでの可観測性はシグナルシステムの設計に関するものであり、すでに計装されている個別の事象の調査に関するものではありません。
• ここで定義したシグナルによってロールアウトの failure_action を決定する場合は、$specsfy-specialist-delivery-engineering と組み合わせます。

フロー

1. ツールを選ぶ前に、実際の運用上の問い（「ユーザーにとってチェックアウトは機能しているか？」など）と重要なジャーニーを定義します。
2. サービスの重要度に応じて、明示的なエラーバジェットとともに SLI（測定可能な指標）と SLO（許容目標）を設定します。
3. 信頼境界／システム境界（HTTP、キュー、ジョブ、データベース）と、それらを越えて引き継ぐ必要がある相関コンテキスト（トレース ID、リクエスト ID）をマッピングします。
4. 設計段階からカーディナリティを制御しながら、イベント、メトリクス、スパンを計装します。後から修正する方法は避けます。
5. テレメトリ内の機密データを保護（リダクション、マスキング）し、シグナルの種類ごとに保持ポリシーを定義します。
6. 意思決定を基準にダッシュボード（この画面は何の判断に役立つか？）を、アクションを基準にアラート（このアラートが発生したら何をするか？）を構築します。
7. 実際のインシデントで信頼する前に、成功、失敗、部分的な劣化という3つの状態でテレメトリを検証します。

パターン

• イベント名、重大度、相関 ID、必要最小限のコンテキストを含む構造化ログ（キーと値、または JSON）を使用します。データ抽出に正規表現が必要な、自由形式の連結文字列は使用しません。
• メトリクスのラベルには、カーディナリティが限定され、把握されている値（正規化されたエンドポイント、ステータスコード、テナント数が少ない場合のテナントなど）のみを使用します。ユーザー ID、クエリ文字列を含む未加工の URL、未加工のエラーメッセージはラベルに使用しません。ラベルの値が一意であるたびに、保存される時系列が増加します。
• トレースでは、HTTP、キュー、非同期ジョブをまたいで同じ相関コンテキストを維持します。キューの境界で「途切れる」トレースでは、最もよくある問題（サービス間の分散レイテンシー）をデバッグできません。
• アラートはユーザーへの実際の影響、または SLO 違反の差し迫ったリスクを示すものにします。すべてのアラートに担当者と参照可能なランブックを用意します。関連するアクションのないアラートはノイズであり、チームにアラートを無視する習慣をつけさせます。
• ダッシュボードは、集約されたヘルスビュー（RED／USE）から始め、そこから詳細なシグナルへ掘り下げられるようにします。その逆にはしません。
• トレースのサンプリングでは、ボリュームの大きい正常系のサンプリング率を下げる場合でも、エラーと重要なビジネストランザクションは100％保持します。
• テレメトリ自体は安全に障害を処理します（製品を停止させず、劣化にとどめます）。メトリクスエクスポーターが停止しても、計装対象のアプリケーションを停止させてはなりません。

アンチパターン

• 構造や一貫した重大度レベルなしに「すべてをログに記録する」こと。ストレージコストが増加し、インシデント中に関連イベントを見つける能力が低下します。ログの量は可観測性ではありません。
• カーディナリティの高いラベルを持つメトリクス（例：user_id や order_id をラベルにすること）。保存される時系列の数が急増し、メトリクスバックエンドが停止したり、コストが大幅に増加したりする可能性があります。
• 症状のメトリクスではなく、原因のメトリクスに設定するアラート（例：「SLO を超えるエラー率／レイテンシー」ではなく「CPU 高負荷」でアラートすること）。無害なピークでノイズを発生させ、ユーザーへの実際の影響を必ずしも検出できません。
• 「そのとき役立ちそうに見えた」という理由だけで作られ、定期的に見直されないダッシュボード。古くなったパネルが蓄積し、インシデント時に本当に重要なパネルと注意を奪い合います。

検証

• 制御されたシナリオでエンドツーエンドのテレメトリーを生成し、相関関係（trace id）がマッピングされたすべての境界をまたいで伝播することを確認します。
• 想定されるカーディナリティ、推定コスト、設定された保持期間を確認し、機密フィールドがサービスの外に出る前にレダクションされることを確認します。
• 設定したアラートが、本来作動すべきシナリオ（テストまたはシミュレーション）で実際に作動することと、リンクされたランブックをコードを書いていない人でも実行できることを確認します。
• 既知の障害シナリオに対して、実際のインシデント時にチームが使うクエリを実行し、実用的な時間内に期待するシグナルが返されることを確認します。
• ダッシュボードが存在するだけでシステムを「可観測」と宣言してはいけません。証明となるのは、コードやデータベースにアクセスせず、テレメトリーだけでチームが元の運用上の問いに答えられることです。

関連する Skills

• $specsfy-specialist-server-report は、Ansible による読み取り専用の収集を通じて、ホストごとのレポートにログ、サービス、ディスク使用量をまとめます。

• $specsfy-specialist-debugging はシグナルを利用して原因を特定し、証拠が不十分な場合は追加の計装を求めます。

• $specsfy-specialist-docker と $specsfy-specialist-docker-swarm はランタイム、サービス、ノードのシグナルを公開します。このスキルでは相関関係と判断を定義します。

• $specsfy-specialist-postgres と $specsfy-specialist-redis は、ここでカーディナリティと保持期間を管理したデータ／キャッシュのシグナルを生成します。

• $specsfy-specialist-web-api-design は契約における相関関係とエラーを定義します。このスキルでは運用中のエンドポイントの振る舞いを測定します。

• $specsfy-specialist-performance-engineering は、ここで定義したシグナルによってすでに検出されたレイテンシーやボトルネックの根本原因を診断します。

• $specsfy-specialist-delivery-engineering は、ここで定義したヘルスシグナルがロールアウトの続行またはロールバックの判断に使われる場合に利用します。

• $specsfy-specialist-application-security は、テレメトリーにセキュリティイベントを記録する（または意図的に記録しない）必要がある場合に利用します。

references/standards.md を読んで、可観測性の柱、ダッシュボードのフレームワーク（RED／USE）、SLI／SLO、OpenTelemetry の公式情報源を確認してください。