業界の成果：SREチームはインシデント対応に優れています。インシデントの頻度を減らすデータは、誰も積極的に調査する時間がないログやメトリクスの中にあります。
によって マデリン・マレン による投稿
ユースケース
プラットフォーム信頼性インテリジェンスとエンジニアリングメトリクス
エンジニアリングチームは、シグナルを継続的に監視し、そのデータを積極的に調査することで、ユーザーに影響する障害が発生する前にリスクの蓄積を特定し、インシデントを防止するためにオブザーバビリティデータを使用します。シグナルには、エラーレートの傾向、レイテンシのパーセンタイル、デプロイ頻度、SLOのバーンレート、およびサービスに関連するその他の指標が含まれる場合があります。インシデント対応のリアクティブなアプローチからプロアクティブな信頼性インテリジェンスへの移行には、2つの要素が必要です。それは、サービス全体でのテレメトリデータへの統一されたアクセス、およびエンジニアリングの意思決定のペースでそのデータをクエリできる方法です。エンジニアリングリーダーが「現在のバーンレートでエラーバジェットのしきい値に近づいているサービスはどれか？」と尋ねて、数日ではなく数秒で回答を得られるようになれば、インシデントが発生する前に軽減策を決定できます。プロアクティブなアプローチは、アップタイムと、緊急対応に費やされる可能性のあるR&D能力の両方を保護します。
あなたのエンジニアリング組織がリアクティブなのは、選択によるものではありません。それはアーキテクチャによるものです。オブザーバビリティデータ（メトリクス、ログ、トレース、エラーバジェット、SLOバーンレート）はあります。インストルメンテーションもあります。あなたが持っていないのは、エンジニアリングの意思決定が実際に必要とするペースで、そのデータに質問できる方法です。質問に回答できる頃には、インシデントはすでに進行中です。
それはオンコール担当者の問題ではありません。それはデータアクセスの問題であり、ほとんどのエンジニアリング組織がまだ名前を付けていないギャップです。
計画外のインシデントにはすべてビジネス上のコストがかかります。ロードワークから引き抜かれるエンジニアリング時間、失われる顧客の信頼、SLAの露出、および下流で急増するサポートボリュームです。信頼性はエンジニアリングの衛生問題ではありません。それは収益保護とR&D効率の問題であり、他のビジネス機能と同じ分析的厳密さが必要です。
The Trade DeskのリードプリンシパルソフトウェアエンジニアであるChase Holland氏は次のように述べています。「製品を構築する上で最も費用のかかる部分は、もはやコードを書くことではありません…それは何をするかを決定することです。何をすべきかについてのデータがより良いほど、より迅速に意思決定を行うことができます。」信頼性の文脈では、それは月曜日 に軽減すべきリスクを決定するためにデータを使用することを意味し、土曜日に緊急パッチを書くことを避けることができます。
最新のオブザーバビリティプラットフォームはインシデント対応に最適化されています。つまり、違反時にアラートを発し、診断し、修復します。それらは、エンジニアリング担当副社長が実際に知りたい上位の質問、つまり「今後30〜60日でインシデントとして現れる信頼性のリスクを蓄積しているシステムのどの部分か？」に答えるようには設計されていません。それに答えるには、データリクエストキューを待たずに、数十のサービスにわたるエラーレートの傾向、レイテンシパーセンタイル傾向、および容量使用率の傾向を調査する必要があります。シグナルは存在します。それらをプロアクティブに読み取るエンジニアリングリーダーの能力は存在しません。
信頼性インテリジェンスとは、ユーザーに影響するインシデントとして現れる前に、信頼性のリスクをプロアクティブに特定するためにテレメトリデータを使用する実践です。メトリクス、ログ、トレース、エラーバジェット、デプロイメントレコードのようなものは、従来のオブザーバビリティとは1つの重要な点で異なります。オブザーバビリティは現在何が起こっているかを教えてくれますが、信頼性インテリジェンスは、サービスポートフォリオ全体のトレンド分析に基づいて、今後7〜30日で何が起こりそうかを教えてくれます。信頼性インテリジェンスを実践する組織は、SLO違反アラートを待ちません。火曜日の午前中に、サ ービスの1つでエラーバジェットが通常の2倍の速度で消費されていることを特定し、週末のオンコールローテーションがそれを感じる前に対応方法を決定します。
大規模システムのエンジニアリングリーダーは、MTTR（平均解決時間）、インシデント頻度、サービスごとのSLO遵守状況など、適切なメトリクスを追跡しています。これらのメトリクスは、チームがどのように対応しているかを示します。それらは、何が来るかを示しません。構造的に欠けているのは上位の質問です。つまり、「インシデントになる前に信頼性のリスクはどこに蓄積しているのか、そしてそのリスクはビジネスにどのくらいの開発時間、ロードキャパシティ、顧客の信頼を犠牲にしているのか？」ということです。
その質問に答えるためのデータは、あなたのテレメトリに存在します。しかし、エンジニアリングリーダーが特別なツールやアナリストのサポートなしにクエリできる形式ではありません。あなたのSREチームは対応に優れています。彼らは、毎週数百のサービスのトレンドデータをプロアクティブに調査するリソースを持っていません。そのため、シグナルが蓄積し、インシデントが発生します。あなたのチームは慣れているため、MTTRは改善します。しかし、それを減らすための分析が実行されなかったため、インシデント頻度は減りません。そして、発生しなかったはずのすべてのインシデントは、出荷ではなく火消しに費やされたR&Dキャパシティです。
今週の問題は、当社の製品ラインの1つで成長が鈍化しており、その理由を特定しようとしていることです。インサイトを取得し、取得したインサイトを信頼できるかどうかを知ることは非常に困難です。 — AIネイティブプラットフォームのプロダクト担当VP
データアクセスの問題は、データ信頼性の問題にまで及びます。この状況は、あらゆる規模のエンジニアリング組織に当てはまります。プロアクティブな信頼性データの調査は構造的に困難であるため、リアクティブな診断がデフォルトとなっています。なぜなら、それを減らす上位の分析には、エンジニアリングリーダーがオンデマンドで持っていないデータアクセスが必要だからです。そして、回答を得られたとしても、それが正しいとは限りません。MTTRは改善しますが、インシデント頻度は改善しません。
この即時アクセスなしでは、信頼性に関する会議は、Holland氏が「意見に基づいた交渉」と呼ぶものにしばしば陥ります。チームが運用データに関する単一の信頼できる情報源を持たない場合、それを修正するのではなく、トレンドの原因について数週間議論することになります。セルフサービスモデルに移行することで、The Trade Deskのようなグローバルな広告テクノロジーリーダーは、数週間の議論を迅速で検証された解決策に変え、チームがより高い意図を持って動けるようにしました。
Databricks Genieは、エンジニアリングリーダーが自然言語で運用テレメトリデータを調査できるようにします。エンジニアリング担当副社長は、「過去14日間でp99レイテンシが20％以上増加したサービスはどれか、そしてQ2にインシデントが発生したサービスとの依存関係の重複はどれか？」と尋ねることができます。その質問は、数日ではなく数秒で実際のエンジニアリングデータから表示されます。
フォローアップの質問も自然になります。「現在のバーンレートでエラーバジェットのしきい値に近づいているサービスはどれか、そしていつブレークすると予想されるか？」または「Q3におけるトラフィックの多いサービスでのデプロイ頻度とインシデント率の相関関係は？」この機能は単純なデータセットに限定されません。10,000を超えるテーブルの巨大な環境全体で可視性を維持するために、The Trade Deskは「Genie Router」を構築しました。これは、質問を適切なデータ環境に自動的にルーティングします。これにより、標準的なダッシュボードを圧倒するであろう技術的な複雑さを処理しながら、チームに単一のインターフェースを維持できます。各回答は、実際のテレメトリ、デプロイメントレコード、およびインシデント履歴から引き出され、アナリストのために質問を翻訳する前に、任意のエンジニアリングリーダーが直接クエリできるようになります。
信頼性に関するコミットメントがビジネス上のコミットメントでもあるエンジニアリングリーダーにとって（SLAの露出、顧客の信頼、インシデントによって消費されるR&Dキャパシティなど）、その調査速度は、プロアクティブなリスク管理とリアクティブな火消しの違いです。エラーバジ ェットは単なる技術的なメトリクスではなく、ビジネスリソースです。Genieはそれをそのように管理することを可能にします。軽減策のスプリントを正当化したであろう信頼性シグナルは、インシデント中ではなく、その前に現れます。
ステップ1 — テレメトリを集中化する。メトリクス、ログ、トレース、デプロイメントレコード、およびインシデント履歴を統一されたデータ環境に集約します。断片化されたツールは、プロアクティブな分析が行われない主な理由です。各サービスのデータが異なるシステムに存在する場合、エンジニアはクロスサービスの質問に答えることができません。
ステップ2 — 遅行指標だけでなく、先行指標を定義する。MTTRとインシデント頻度は、すでに発生したことを測定します。先行指標は、これから発生することを測定します。SLOバーンレートの軌跡、p99レイテンシの傾向、現在の消費率でのエラーバジェット残量を遅行指標とともに追跡するチームは、ページが発火する前に介入できます。
ステップ3 — エンジニアリングリーダー向けのセルフサービスクエリを有効にする。インシデント頻度を減らす分析は、アナリストのサポートと48時間の待ち時間が必要なため、めったに実行されません。エンジニアリングリーダーが自然言語で自身の信頼性データをクエリできるようになると（「今四半期、デプロイ頻度とインシデント率の相関が最も高いサービスはどれか？」と尋ねる）、プロアクティブなリスク管理は四半期ごとの演習ではなく、 毎週の習慣になります。
複雑で大規模なシステムで高い信頼性を維持するエンジニアリング組織は、運用データをプロアクティブに調査し、ユーザーに影響するインシデントとして現れる前に蓄積されるリスクのシグナルを見つけることができる組織です。そのためには、アナリストのクエリキューのペースではなく、エンジニアリングの意思決定のペースに合わせて設計されたデータアクセスが必要です。
プラットフォーム信頼性におけるインサイト・トゥ・アクションのサイクルは、スプリントサイクルではなく、時間と日で測定されます。エンジニアリングチームが月曜の朝にp99レイテンシのトレンドを特定し、スタンドアップの前に緩和策を決定できる場合、インシデント対応ではなく、信頼性インテリジェンスで運用しています。同じ質問にデータリクエストと48時間の待ち時間が必要な場合、インシデントが先に発生します。
顧客 facing SLA を持つエンジニアリングチームにとって、そのスピードは直接的なビジネス上の結果をもたらします。Genie を使用すると、アドホック分析が 5 倍高速になり、アナリストが 2 日待つ必要があった信頼性に関する質問がスタンドアップの前に実行されます。
DATABRICKS GENIE · KEY DIFFERENTIATORS
あなたのデータのために構築され、あなたのルールによって管理され、あらゆるエンジニアリングリーダーに回答されます。
Q: インシデント防止のための観測可能性と監視の違いは何ですか？
Answer: 反応的な監視（何かが壊れたときにアラートを出す）と観測可能性（障害を予測するのに十分なシステム状態を理解すること）を、2〜3文で区別する必要があります。
Q: 今後のインシデントを最も予測できる観測可能性シグナルは何ですか？
Answer: SLO のバーンレート、p99 レイテンシのトレンド、デプロイメントに関連するエラー率を、最も実行可能な 3 つの先行指標として名前を挙げてください — 2〜3 文に収めてください。
Q: Databricks Genie は SRE チームがインシデントを防止するのをどのように支援しますか？
Answer: Genie の自然言語クエリ機能を、プロアクティブなトレンド調査という特定のユースケースに接続する必要があります — 既存のドラフトコピーから引用してください。
Q: 反応的なインシデント対応からプロアクティブな信頼性インテリジェンスに移行するにはどのくらい時間がかかりますか？
Answer: 正直かつ実践的に答える必要があります：中央集権化とツール導入は通常数週間かかります。プロアクティブなクエリへの文化的なシフトは、適切なセルフサービスアクセスがあれば 1〜3 か月かかります。
Q: エンジニアリングチームは信頼性を向上させるためにどの DORA メトリクスを追跡すべきですか？
Answer: 4 つの DORA メトリクス（デプロイメント頻度、リードタイム、MTTR、変更失敗率）を挙げ、変更失敗率と MTTR を組み合わせると最も強力な信頼性予測因子であることを指摘してください。
Genie があなたのチームにできることを見る
MTTR が改善し続けているのにインシデント頻度が改善しない場合、ギャップは実行ではなく、プロアクティブなデータアクセスにあります。信頼性は R&D の効率性の問題です。エンジニアリングリーダーがそれを管理するために AI/BI Genie をどのように使用しているかをご覧ください。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。