効果的な根本原因分析の実行

根本原因の分析とは何か

根本原因の分析とは、障害が発生した際に、現在実施されているプロセスやシステムで改善可能な障害を特定するための手法やプロセスです。

根本原因の分析を効果的に実践すると、次のことが可能になります。

• 障害やヒヤリハットの要因を特定し、その要因に対処するための対策を講じることができる
• 障害の再発を防ぐ
• 顧客体験を向上させる
• リスクに伴うコストを削減する

根本原因分析の実施には綿密なプロセスが必要です。これには、障害の解決に携わる適切なチームを見つけること、この間に取られた有効なメモを確認すること、平均検出時間（MTTD）と平均解決時間（MTTR）を特定するために使用されているモニタリングツールのデータを確認すること、再発のリスクを最小限に抑えたり排除したりするだけでなく、その効率を改善することなどが含まれます。

チームが関与することで、障害の詳細を共有し、効果的なコミュニケーションを行い、良い結果を生み出すことができます。

根本原因の分析：コツとポイント

根本原因の分析には、包括的な調査、判断、評価、修正を必要とします。これらはすべて、New Relic が提供するサービスの特徴でもあります。根本原因の分析を実施するために使用される調査手順には、以下に説明するような多くの種類があります。

• 問題の特定：問題を認識したら、まず最初に問題の内容と症状（例えば機器の故障、プロセスの不具合、ヒューマンエラーなど）を明確にする。それが完了したら、根本的な原因の解明を試みる一方で、問題を封じ込めるために、原因と思われる要因を切り分けることが重要です
• データ収集：問題が特定されたら、障害報告書、スクリーンショットやログなどの証拠、関係者へのインタビューなど、できるだけ多くのデータを収集します。これらのデータを使用することで、一連のイベント、特に問題につながった有害なイベント、関連システム、問題の発生期間、全体的な影響を判断することができます
• 根本原因の特定：根本原因の分析チームは、根本原因を確認するためにフィッシュボーン図、パレート図、その他のツールなどの手法を用いてしてブレインストーミングセッションを実施します。根本原因分析マネージャーが司会進行役を務めますが、会議は協力的で非難の余地のないものでなければなりません
• 解決策の実装：根本原因は1つ以上の解決策を示している可能性があり、根本原因分析チームは最適な修正と、提供するタイミングを判断する必要があります。解決策を実装したら、それが効果的であることを確認するためにモニタリングする必要があります。このプロセスは、より正式には根本原因の是正措置と呼ばれます
• アクションの文書化：根本原因分析の重要な部分は、問題となっている問題の再発を防ぐことです。問題とその解決策を文書化し、チームが将来参照できるようにすることが不可欠です。根本原因分析チームは、予防措置だけでなく、物理的またはプロセスの改善に関する推奨事項を文書に含めることもできます

根本原因分析を実施するための5つのステップ

恒久的な解決策が見つかるまでの間、一時的な解決策を提供することは、後日問題を解決するための計画がある限り、理想的です。根本原因分析が完了後は、しばらくしてから事後分析をすることが重要です。根本原因分析後に招集をかけることで、チームが集まって計画を立て、学んだ教訓と再発防止方法を共有できるため、再発防止に役立ちます。

根本原因分析のフレームワークと方法論

根本原因分析の落とし穴：学んだ教訓

根本原因分析のユーザー・ジャーニーはそれぞれユニークであり、解決に至るまでのアプローチやテクニックは様々ですが、その結果から共通のベストプラクティスや学びを得ることができます。途中で避けるべき落とし穴のいくつかを次に示します。

• 問題提起の定義が不完全または不十分
• 間違った物事やシグナルに焦点を当ててしまう。長期的な視点で考え、決して近視眼的なアプローチをとらないこと
• 症状や原因を一目見ただけで立ち止まり、他の手段や可能性を探ったり、深く掘り下げたりしない
• 焦点を絞ってください。すべてをすぐに調査できるわけではありません。影響が大きく、重大な影響を与える障害を絞り込みます
• 関連チームを巻き込み、できるだけ早く根本原因の分析を開始して、重要なデータの損失や競合する優先事項との重複を防ぎます
• 根本原因分析のためのデータ収集は難しく、時間がかかります。近道をしたり仮説を立てたりすると、このプロセスが非効率になったり、誤った結論につながったりします。New Relic のコラボレーション機能を活用することで、データのサイロ化を解消し、チームが他のプラットフォームの UIエクスペリエンス（インシデント、アラート、ダッシュボード）のコンテキストでデータを確認できるようになります
• 調査結果と修正点をまとめ、推奨事項を記載したエグゼクティブ・レポートを作成し、より広範な組織と共有します
• 推奨事項を完了まで追跡します。効果的な根本原因分析の最終目標は、障害が二度と繰り返されないようにすることです。ほとんどの推奨事項は長期的なものであり、大幅な変更または軌道修正が必要になります。この目標を達成するには、進捗状況を追跡し、頻繁なステータス更新とコミュニケーションによって経営陣に責任を持たせることが効果的な方法です

ベストプラクティス：障害発生後の改善

根本原因の分析プロセスを容易にするために、次の点に留意してください。

• 異なるチームによる複数のデプロイメントが同時に行われる場合は、根本原因を簡単に追跡できるように、タイミングに加えて、各チームが何をしているのか、詳細なログを必ず保管しておく必要があります。複数のデプロイメントを追跡するのが難しい場合は、異なる時間を指定することも良いでしょう。New Relic の Change Tracking (変更追跡)機能を利用すれば、システムのどの部分でもデプロイの変更を把握することができ、パフォーマンスデータのコンテキスト化やより迅速な問題解決に役立てることができます
• 障害が発生した後は、必ず事後分析の招集をかけて、障害について話し合うとともに、再発を防ぐための長期的な解決策として何ができるかを検討します。また、同じ問題が再び発生した場合に運用チームが対処できるように、標準化された運用手順を必ず更新しておいてください
• リアルタイムの通知とアクティブなアラートのレビューを継続的に評価します。重大な問題が発生したときに重要なアラートを見逃さないように、重要でないアラートはオフにします
• 問題を迅速に解決するために、障害の解決に使用しているモニタリングツールを理解し、トレーニングを継続してください
• Slack、Zoom、ブリッジコールなど、障害発生時のチームコミュニケーションのための一元的なチャネルを用意します
• カスタムダッシュボードを分析して、障害を経時的に追跡します
• 根本原因の分析に最善の努力を払ったにもかかわらず、上層部が是正措置プロセスの実施に熱心でなかったり、真剣に取り組まない場合、根本原因の分析は成功せず、効果もあがりません
• 根本原因分析の成功の鍵は、継続的な改善に焦点を当て、障害から学んだことをより広範な組織と共有し、過去の失敗から学び、障害が再発した場合の対応方法について他のチームと連携した演習を取り入れることです
• 誰が悪いわけでもありません。複数のチームが一緒になって問題解決を容易にするために、全員がコミュニケーションをとりながら、問題の再発を防ぐための明確なプロセスを作り上げます
• New Relic はオールインワンのオブザーバビリティプラットフォームであり、死角をなくし、チームやデータのサイロ化を解消し、技術スタックに対する完全な可視性を単一の統合されたエクスペリエンスで提供することで、最終的に顧客が興味深いビジネス上および技術上の課題をより効果的に解決できるようにします

まとめ

組織が高性能、高スループットのシステムを構築、デプロイ、実行する場合、コンピューティングワークロードに障害が発生する可能性があります。本当に重要なのは、このような障害が発生したときに対処し、迅速に業務を復旧するための戦略を事前に策定しておくということです。ベストプラクティスと学んだ教訓を New Relic のようなフルスタックオブザーバビリティツールと組み合わせて利用することで、より迅速な解決、運用効率の継続的な改善、将来の障害再発防止が可能になります。