ほとんどの可観測性スタックは、「何が起こったのか?」という 1 つの質問に答えるのに優れています。
彼らは、どこを修正すればよいのかという次の質問には弱いのです。
このギャップがインシデント対応の速度を低下させる原因となります。チームはエラー率を確認し、トレースを開き、ログを読み取り、デプロイ タイムラインをチェックしますが、その後も手動でコードベースを検索する必要があります。
身近な出来事
デプロイ後に API が断続的に 500 を返し始めると想像してください。ダッシュボードにはスパイクが表示されます。トレースはチェックアウト サービスを指します。ログには検証エラーが含まれていますが、メッセージは一般的なものです。
現時点では、チームには別のチャートは必要ありません。方向性が必要です:
- チェックアウトを所有するリポジトリ
- 失敗したルートに接続されているハンドラー
- 検証動作を変更した最近のコミット
- 修正をレビューする必要がある人またはチーム
それがコードコンテキストです。
コードのコンテキストが重要な理由
コードのコンテキストを必要としない可観測性により、認識が生まれます。コードコンテキストによる可観測性により、修復への道が生まれます。
違いは小さいですが、運用上重要です。トレースにより、リクエストが失敗したことがわかります POST /チェックアウト。コード コンテキストは、検証ブランチ、昨日変更されたファイル、および通常その領域をレビューする所有者を指すことができます。
このマッピングにより、多くのインシデントの最初の 1 時間が節約されます。
最小限の有用なコンテキスト
調査全体をプル リクエストに添付する必要はありません。通常、レビュー担当者はコンパクトな事実セットを必要とします。
- 生産症状
- 影響を受けるサービス
- おそらくファイルまたは関数
- 最近のデプロイまたはコード変更
- 所有者または査読者
- 次のアクションを提案しました
それ以上のものは、それらの事実を葬り去るのではなく、裏付けるものでなければなりません。
ダッシュボードが止まる場所
ダッシュボードはシステムの動作を確認するためのものです。プル リクエストはシステムの動作を変更するためのものです。健全な修復ワークフローは、エンジニアに毎回手動でブリッジを依頼するのではなく、これらの世界を接続します。
シグナルがコードを見つけられない場合、アラートは別のキュー項目になります。シグナルがコードを見つけることができれば、チームはパッチを適用するか、ロールバックするか、バックログ項目を開くか、より深く調査するかを決定できます。
何を目指して構築するか
実際の目標は、より大きな可観測面ではありません。それはより短いパスです:
プロダクションシグナル -> コードコンテキスト -> レビュー可能なアクション
そのアクションはプル リクエストである可能性があります。 Jira の問題である可能性があります。問題が上流のプロバイダーに属しているというメモである可能性があります。重要なのは、制作側が話すたびにチームが白紙の調査から始める必要がないということです。
可観測性は失敗を示します。コードのコンテキストによって、失敗の行き先が決まります。
