このガイドは、顧客に影響を与える問題を診断するスキルを向上させるための入門書です。このガイドの手順に従うことで、アプリケーションのパフォーマンスの問題からより迅速に回復できるようになります。
このガイドは、オブザーバビリティの成熟度に関するシリーズの一部です。
前提条件
このガイドを使用するための要件と推奨事項を次に示します。
New Relic 可観測性の範囲:
- 必須:分散トレースを使用するAPM、コンテキスト内の APM ログ、およびインフラストラクチャ エージェント
- 推奨:ログとネットワーク監視(NPM)
必須: サービスレベル管理
Recommended [推奨]: New Relic APM、分散トレース、NRQL クエリ、および
UI
推奨: これらのガイドを読みました:
概要
このガイドの使用を開始する前に、学習内容を理解するのに役立ちます。このガイドは、次のことを理解するのに役立ちます。
診断スキルの向上がビジネスに与える影響。
成功を測定するために使用される運用上の主要業績評価指標。
エンド ユーザーがさまざまな種類の信頼性の問題をどのように認識しているか。
問題の直接的な原因と根本的な原因の違い。
問題を見つけて解決するための基本的な診断手順には、次のものが含まれます。
- 問題の定義 - 問題ステートメントの作成
- 問題の原因を見つける
- その問題の直接の原因を見つける
一部のパフォーマンス問題カテゴリ (出力パフォーマンス、入力パフォーマンス、クライアント パフォーマンス) と、それらの問題の診断に使用される New Relic 機能 (APM、合成、
およびモバイルモニタリング）。
一般的な問題とその原因を理解するためのチート シートである問題マトリックスの使用方法。
最後に、これらの概念をよりよく理解するのに役立ついくつかのパフォーマンスの問題の例を確認します。
期待される成果
概要
ビジネスにとっての価値は次のとおりです。
- 業務に支障をきたすインシデントの発生を抑制する
- 問題解決に要する時間 (MTTR) の短縮
- インシデントの運用コストを削減
IT 運用と SRE の価値は次のとおりです。
- 理解と解決にかかる時間を短縮
事業成果
2014 年、 Gartner は IT ダウンタイムの平均コストを 1 分あたり 5,600 ドルと見積もっています。ビジネスに影響を与えるインシデントの累積コストは、知るまでの時間、頻度、修復にかかる時間、収益への影響、およびインシデントをトリアージして解決するエンジニアの数などの要因によって決まります。簡単に言えば、パフォーマンスへの影響を解決するために必要な人員を減らして、ビジネスに影響を与えるインシデントを減らし、インシデントの期間を短縮し、診断を高速化する必要があります。
最終的に、ビジネスの目標は、稼働時間を最大化し、ダウンタイムを最小化することです。ダウンタイムのコストは次のとおりです。
Downtime minutes x Cost per minute = Downtime cost
ダウンタイムは、ビジネスを混乱させるインシデントの数とその期間によって決まります。ダウンタイムのコストには多くの要因が含まれますが、最も直接的に測定できるのは運用コストと収益の損失です。
ビジネスは、以下の削減を推進する必要があります。
- ビジネスを混乱させるインシデントの数
- インシデントの運用コスト
運用成果
必要な運用上の結果は、製品層のサービス レベル目標への準拠を維持することです。これを行うには、低下したサービス レベルを診断し、診断を伝え、迅速な解決策を実行します。しかし、予期しない劣化やインシデントは常に発生するため、迅速かつ効果的に対応する必要があります。
このシリーズの他のガイドでは、知るまでの時間を短縮することに重点を置いています。アラートの品質管理ガイドでは、知るまでの時間を改善する事後対応的な方法に焦点を当て、 サービス レベル管理ガイドでは事前対応的な方法に焦点を当てています。
あなたが今読んでいるガイドでは、理解するまでの時間と解決するまでの時間の短縮に焦点を当てています。
主要業績評価指標 - 運用
「インシデント管理」と SRE 理論の世界では、多くの指標が議論され、議論されています。ただし、主要業績評価指標の小さなセットに注目することが重要であることにほとんどの人が同意しています。
以下の KPI は、成功した SRE およびインシデント管理プラクティスで使用される最も一般的な指標です。
信頼性に対するエンドユーザーの認識
顧客が製品のパフォーマンスをどのように認識しているかは、緊急性と優先度を測定する方法を理解する上で重要です。また、顧客の視点を理解することは、ビジネスが問題をどのように見ているかを理解するのに役立ち、影響を受ける機能をサポートするために必要なワークフローを理解するのにも役立ちます。顧客とビジネスの認識を理解すると、その機能の信頼性に影響を与えている可能性があるものをよりよく理解できます。
最終的に、顧客の視点から見たオブザーバビリティは、信頼性エンジニアリングに積極的かつ熟練するための最初のステップです。
デジタル製品のパフォーマンスとその機能に対するエンド ユーザーの認識に影響を与える 2 つの主要なエクスペリエンスがあります。以下の条件は、一般的な顧客用語を使用した顧客の観点からのものです。
根本原因と直接原因
問題の根本原因は、その問題の直接の原因と同じではありません。同様に、直接的な原因 (短期的) を修正しても、通常、問題の根本原因 (長期的) が修正されたことにはなりません。この区別をすることは非常に重要です。
パフォーマンスの問題を探すときは、まず「何が変わったの?」という質問をして、問題の直接の原因を見つけようとする必要があります。通常、変更されたコンポーネントまたは動作は根本的な原因ではありませんが、実際には最初に解決する必要がある直接的な原因です。根本原因を解決することは重要ですが、通常、インシデント後の遡及的な議論と長期的な問題管理が必要です。
たとえば、ログイン機能のサービス レベルが突然低下します。トラフィック パターンが通常よりもはるかに多いことがすぐにわかります。パフォーマンスの問題を追跡して、TCP 接続キューがはるかに大きくなるオープン TCP 接続制限の構成にたどり着きます。TCP 制限の引き上げといくつかの追加のサーバー インスタンスを展開することで、問題をすぐに解決します。短期的には問題の直接的な原因を解決しましたが、根本的な原因は、不適切なキャパシティ プランニング、マーケティングからの連絡の欠落、上流の負荷に意図しない結果をもたらす関連展開などである可能性があります。
この区別は、ITIL/ITSMインシデント管理と問題管理でも行われます。インシデント後の話し合いで根本原因が議論され、その後、長期的な問題管理プロセスで解決されます。
診断手順 (概要)
ステップ 1: 問題を定義する
最初のルールは、問題のステートメントをすばやく確立することです。問題文を作成するためのガイドはたくさんありますが、シンプルで効果的なものが一番です。適切に構成された問題ステートメントは、次のことを行います。
- エンドユーザーが経験していることを説明してください。エンドユーザーが経験している問題は何ですか?
- 製品機能の予想される動作を説明します。エンドユーザーが経験すべきことは何ですか?
- 製品機能の現在の動作を説明します。ユーザーが経験していることの技術的評価は何ですか?
問題文では、仮定を避けてください。事実に固執する。
ステップ 2: ソースを見つける
「ソース」は、問題の直接の原因に最も近いコンポーネントまたはコードです。
多くのジャンクション、スプリッター、バルブを介して接続された多くの水道管を考えてみてください。給水サービス レベルが低下しているというアラートが表示されます。どの合流点、分岐点、バルブ、またはパイプが問題を引き起こしているかを特定するまで、パイプを通る水の出力から問題を追跡します。電気バルブの 1 つがショートしていることに気付きました。そのバルブが問題の原因です。ショートはあなたの問題の直接の原因です。値を置き換えることで、直接的な原因を簡単に解決できます。根本的な原因は、気象条件、水中の化学物質、または製造など、より複雑なものである可能性があることに注意してください.
これは、複雑なテクノロジー スタックを診断する場合と同じ概念です。ログイン機能が制限されている場合 (出力)、問題をその制限の原因となっているコンポーネント (ソース) までさかのぼって修正する必要があります。それは、API ソフトウェア (サービス境界)、ミドルウェア サービス、データベース、リソースの制約、サード パーティ サービスなどです。
IT では、応答時間を改善するための主要なブレークポイント カテゴリが 3 つあります。
- 出力
- 入力
- クライアント
これらのカテゴリ (別名サービス レベル) 内でパフォーマンス メトリックを定義すると、問題の原因を特定する際の応答時間が大幅に短縮されます。これらのカテゴリの測定については、サービス レベル管理ガイドで説明しています。診断でそれらを使用する方法を理解するには、読み続けてください。
ステップ 3: 直接の原因を見つける
問題の原因に近づいたら、何が変わったのかを特定します。これにより、短期間で問題を即座に解決する方法をすばやく判断できます。ステップ 2の例では、ハードウェアの劣化によりショートが発生したため、バルブが機能しなくなったという変化がありました。
IT における一般的な変更の例は次のとおりです。
- スループット (トラフィック)
- コード (デプロイ)
- リソース (ハードウェアの割り当て)
- アップストリームまたはダウンストリームの依存関係の変更
- データ量
パフォーマンスに影響を与える問題のその他の一般的な例については、以下の問題マトリックスを参照してください。
ヘルス データ ポイントを使用する
前述のように、診断の旅をすぐに開始できる 3 つの主要なパフォーマンス カテゴリがあります。これらの正常性データ ポイントを理解すると、問題の原因がどこにあるかを理解するための時間が大幅に短縮されます。
問題マトリックス
問題マトリックスは、3 つの健康データ ポイントによって分類された一般的な問題のチート シートです。
問題の原因は、頻度の高い順に並べられており、最も一般的なものが一番上の行の左側に表示されます。より詳細な内訳を以下に示します。サービス レベル管理が適切に行われていれば、これらのデータ ポイントの 3 つのうち 2 つを迅速に除外することができます。
この表は、健康データ ポイントごとに並べ替えられた問題マトリックスです。
| データポイント | New Relic の機能 | 一般的な問題の原因 |
|---|---|---|
| 出力 | APM、インフラ、ログ、NPM | アプリケーション、データ ソース、ハードウェア構成の変更、インフラストラクチャ、内部ネットワーク、サード パーティ プロバイダー (AWS、GCP) |
| 入力 | 合成、ログ | 外部ルーティング (CDN、ゲートウェイなど)、内部ルーティング、インターネット上のもの (ISP など) |
| クライアント | ブラウザ、モバイル | ブラウザまたはモバイル コード |
問題は複雑化する傾向がありますが、サービス レベルを迅速に回復するために、「原因を突き止め」、「何が変化したか」を特定することが目標です。
問題例
問題の例を見てみましょう。あなたの会社が新製品を展開し、要求の大幅な増加により許容できない応答時間が発生したとします。ソースは、ログイン ミドルウェア サービスで検出されます。問題は、TCP キュー時間の急増です。
この状況の内訳は次のとおりです。
- カテゴリー: 出力性能
- 出典：ログインミドルウェア
- 直接的な原因: 追加のリクエスト負荷による TCP キュー時間
- 解決策: TCP 接続制限の増加とリソースのスケーリング
- 根本原因: ログイン ミドルウェアに影響を与えるダウンストリーム サービスのキャパシティ プランニングと品質保証テストが不十分
別の問題例
別の問題の例を次に示します。
- ログイン時に 500 のゲートウェイ エラーが突然増加しました...
- ログイン API の応答時間は、タイムアウトが始まるポイントまで増加しました...
- タイムアウトは、ミドルウェア層のデータベース接続まで追跡されました...
- トランザクション追跡により、ログイン要求ごとのデータベース クエリ数が大幅に増加していることが明らかになりました...
- 問題の直前に発生した展開の展開マーカーが見つかりました。
この状況の内訳は次のとおりです。
- カテゴリ: 入力性能の障害につながる出力性能の低下
- 出典：ミドルウェアサービス呼び出しデータベース
- 直接的な原因: コードのデプロイ後にデータベース クエリが 10 倍に増加
- 解決策: 展開のロールバック
- 根本原因: 不十分な品質保証テスト
ソース別の問題マトリックス
これは、ソース別にソートされた問題マトリックスを含む表です。
ソース | 一般的な直接原因 |
|---|---|
アプリケーション |
|
情報源 |
|
内部ネットワーキングとルーティング |
|
パフォーマンス パターンの異常の特定
ヒント
主要なトランザクション (機能) に関連するサービス境界で整形式のサービス レベルを設定すると、問題が存在するエンド ツー エンドのワークフローをより迅速に特定するのに役立ちます。
パターンの異常を特定することで、問題の直接の原因がどこにあるのかを特定する能力が向上します。
パターンの識別に関する優れた情報や無料のオンライン クラスはたくさんありますが、一般的な概念はかなり単純で、強力な診断能力を解き放つことができます。
パフォーマンス データのパターンと異常を特定するための鍵は、サービスがどのように実行されているかを知る必要がないことです。最近の動作が変化したかどうかを判断するだけで済みます。
このセクションで提供されている例では、メトリックとして応答時間またはレイテンシーを使用していますが、エラー、スループット、ハードウェア リソース メトリック、キューの深さなど、ほぼすべてのデータセットに同じ分析を適用できます。
ノーマル
以下は、APM での一見不安定な応答時間チャート (7 日間) の例です。よく見ると、応答時間の動作が反復的であることがわかります。つまり、7 日間にわたって行動に劇的な変化はありません。スパイクは反復的であり、タイムラインの残りの部分と比較して異常ではありません。
実際、データの表示を経時的な平均から経時的な**パーセンタイル**に変更すると、応答時間の変化がいかに「規則的」であるかがさらに明確になります。
異常な
このグラフは、最近の動作と比較して異常に増加したと思われるアプリケーションの応答時間を示しています。
これは、週ごとの比較を使用して確認できます。
パターンが変化し、先週の比較から悪化しているように見えます。
ソースを見つける
次に、New Relic でソースを見つける方法について説明します。このワークフローは分散トレースに依存していることに注意してください。
まず、エンド ユーザーが経験する遅延またはエラーに関連するアプリケーションを見つけます。これは、アプリケーションやコードが問題であることを意味するわけではありませんが、フロー (最初) 内のアプリケーションを見つけることで、より迅速にソースに近づくことができます。このアプリケーションが見つかったら、コード、ホスト、データベース、構成、ネットワークなどのコンポーネントをすばやく除外できます。
アプリケーションが特定されると、問題は、そのアプリケーション内のどのトランザクションが問題の一部であるかです。パフォーマンスの問題が発生していると特定したアプリケーションを使用し、影響を受けるトランザクションを特定します。ここで、前述のIdentif パフォーマンス パターンの異常で説明したパフォーマンス パターンの異常スキルを繰り返すことができますが、今回はトランザクション自体についてです。
次のドキュメントは、New Relic を使用して問題のあるトランザクションを特定するのに役立ちます。
問題のあるトランザクションが特定されたら、分散トレースを使用して、そのトランザクションをサポートするエンド ツー エンドのコンポーネントを確認できます。分散トレースを使用すると、スタック全体でレイテンシが発生している場所やエラーが発生している場所をすべて 1 つのビュー内ですばやく特定できます。
次のリソースは、分散トレーシングを使用して問題のソース コンポーネントを特定する方法を学習するのに役立ちます。
ソースの検索手順の簡単な要約を次に示します。
- 影響を受けるパフォーマンスに関連するアプリケーションを調べます。
- 問題の原因となっているトランザクションを特定します。
- 分散トレースを使用して、エンド ツー エンド フロー内で問題のあるコンポーネントを特定します。
これで、直接的な原因を特定する最終ステップに進むことができます。
直接の原因を見つける
ソース コンポーネントが見つかったら、直接的な原因の特定を開始できます。
前の手順の知識を使用すると、問題が遅延、成功、またはその両方であるかがわかります。
遅延の問題は、分散トレース内のトランザクション トレースや「インプロセス スパン」を使用して見つけることができます。
成功の問題のエラー メッセージもトレースで確認できますが、成功の問題の詳細は通常、アプリケーション ログで確認できます。
いずれにせよ、あなたが第 1 層のインシデント レスポンダーまたは SRE である場合、直接的な原因を見つけることは、通常、発見されたソース コンポーネントを担当する開発者およびエンジニアである対象分野の専門家 (SME) に委ねられます。
ソース コンポーネントを発見した後の最も効果的な次のステップは、そのコンポーネントの対象分野の専門家に連絡することです。トリアージで発見されたデータと、トラブルシューティングを有利に開始するために完了した診断を示します。
ヒント
コンテキスト内ログインと分散トレースの両方がデフォルトで有効になっていることに注意してください エージェント。 (エージェントをしばらく更新していない場合は、 エージェントを定期的に更新することをお勧めします。)
ログインコンテキストと分散トレースは、トリアージ、診断、および長期的な問題解決にかかる時間を短縮するために必要な重要な機能です。
さあ、New Relic で優れたサイト信頼性エンジニアになりましょう!
次のステップ
まだ読んでいない場合は、次のような関連する可観測性成熟度ガイドを読むことをお勧めします。