絶えず変化する顧客や関係者のニーズに対応し続ける中で、IT環境は複雑さを増しています。その結果、ITシステムを常に安定して稼動させることは、ますます困難になっています。
事実、回答した大企業の82%が、ITの複雑さがデジタルトランスフォーメーションで期待される成果の妨げになっていると考えています(ここで言う成果とは、生産性の向上、イノベーションの促進、コラボレーションの強化、セキュリティの改善、顧客満足度の向上などです)。
どのような状況下でも頼れる信頼性の高いシステムをITチームが確実に提供できるようにするためには、求められる可用性やパフォーマンスを効果的に追跡するための最適なメトリクスを理解しておくことが重要です。
そこでこの記事では、アップタイムとパフォーマンスに関する信頼性の要件に対応するために組織が注目すべき主要なメトリクスについて説明します。
NISTでは信頼性を以下のように定義しています。
システムまたはコンポーネントが、一定の期間、一定の条件下で障害を発生させることなく稼動し続ける能力。
信頼性は、設計段階からITシステムの内部に組み込まれている必要があります。これにより、高い稼動率を求め、中断をできるだけ避けたいユーザーの大きな期待に応えることができるのです。
ここで紹介するメトリクスは、組織が必要なアップタイムとパフォーマンスを確保するために役立ちます。また、信頼性メトリクスとは異なる観点として、ITシステムの一般的な障害メトリクスもご紹介します。
障害発生の頻度が低い場合、そのITサービスやインフラは信頼性が高いとみなされます。平均故障間隔(MTBF)は、何らかの障害が発生する頻度を追跡するための可用性メトリクスです。
配車サービスのモバイルアプリの例を考えてみましょう。1つの問題発生(配車をリクエストできないなど)から別の問題発生(請求書を作成できないなど)までの平均経過時間はどれくらいでしょうか?問題の根本原因の観点からすれば、それぞれの障害は類似している場合もあればまったく異なる場合もありますが、重要なのは、長期的にどれだけ安定性を維持できるかという点です。
MTBFを、MTRS (平均サービス回復時間)などのメトリクスと組み合わせることで、サービスの信頼性をさらに正確に把握できるようになります。MTBFを高く維持しながらMTRSを低く抑えることが、高可用性サービスを設計する上で不可欠です。
ITコンポーネントのライフサイクル全体を通じて、障害の発生は避けられません。完璧なシステムは存在しないからです。コンポーネントの老朽化に伴い、修理やバグの修正、部品の交換、その他の復旧作業が実施されますが、これらの対応が将来的な障害発生の頻度に予期せぬ影響を与える可能性があります。
障害発生率(ROCOF)は、修理が可能なシステムでの障害発生の頻度を測定するための信頼性メトリクスです。障害や修復による影響にはさまざまな要因が関わるため、ROCOFはシステムごとに異なる場合があります。
ROCOFは以下の方法で計算します。
このメトリクスによって、障害の発生しやすさの傾向を把握できます。特に保証期間の終了後、大規模な修理の実施後、あるいは多くのメンテナンス作業後のシステムにおける障害発生の頻度の傾向を知るのに役立ちます。ROCOFのデータは、具体的には以下のように活用できます。
コンポーネントのパフォーマンスと過去の障害に関する十分なデータを収集して分析することで、ITシステムに負荷がかかった際に障害が発生する可能性を予測できるようになります。
オンデマンド障害確率(PFD/PFOD/POFOD)というメトリクスは、システムが特定の機能をオンデマンドで(つまり要求に応じて)実行しようとした際に、その実行に失敗する確率として定義されています。
このメトリクスは、主に車のエアバッグやミサイルのような、1回限りの使用が想定されるシステムに利用されます。ただし、キャパシティが固定されているITシステムや、修理できないITシステムにとっても重要な指標となる場合があります。
ピーク時のパフォーマンスは、ITシステムの信頼性を測る重要な指標です。
PFDを測定することで、ITチームは、システムが要求を効果的に処理し、過負荷状態を回避できる可能性をより正確に予測できるようになります。
最後の信頼性メトリクスはエラー率です。これはリクエストが失敗する割合として定義されます。このサービスレベル指標は、サイトリライアビリティエンジニアリング(SRE)の4つのゴールデンシグナルのうちの1つです。これらのシグナルの役割は以下のとおりです。
エラーは、ソフトウェアのバグやハードウェアの障害などの問題を示している可能性があるため、ITの健全性を測る上で重要な指標となります。エラーには次のようなものがあります。
エラーの発生率を測定することで、ITチームは根本的な問題を把握し、それが重大な障害に発展する前に対処できます。
SREではエラーバジェットというメトリクスを使用します。これはエラー率を追跡するためのメトリクスであり、必要に応じて取り組みの焦点をイノベーションからシステムの安定化へと切り替えるための制御メカニズムとして機能します。これは、サービスのあらゆる側面に適用される「エラーに対するユーザーの許容度」と考えることができます。
エラーバジェットは、サービスのSLO (可用性など、サービスレベル目標)の値を1から差し引いて算出されます。例えば、SLOが99.9%のサービスであればエラーバジェットは0.1%であり、これは特定の期間内で100万件のリクエストに対して1,000件のエラーが許容されることを意味します。
(関連記事:SLOとSLIの違い)
複雑なITシステムの信頼性を測定するのは困難な作業です。IT組織は、そのために適切なツールを選び、投資する必要があります。そうすることで、膨大なデータを収集して分析し、ITシステムの安定性と障害発生の可能性に関するインサイトを獲得できるようになります。
しかし、無計画に資金を投じることには、大きなリスクが伴う可能性があります。企業は、自社にとって最も重要な指標の測定に注力し、ツールへの投資から得られる信頼性メトリクスを効果的に活用して行動できるよう、組織体制を整える必要があります。
このブログはこちらの英語ブログの翻訳です。
この記事について誤りがある場合やご提案がございましたら、splunkblogs@cisco.comまでメールでお知らせください。
この記事は必ずしもSplunkの姿勢、戦略、見解を代弁するものではなく、いただいたご連絡に必ず返信をさせていただくものではございません。
Splunkプラットフォームは、データを行動へとつなげる際に立ちはだかる障壁を取り除いて、オブザーバビリティチーム、IT運用チーム、セキュリティチームの能力を引き出し、組織のセキュリティ、レジリエンス(回復力)、イノベーションを強化します。
Splunkは、2003年に設立され、世界の21の地域で事業を展開し、7,500人以上の従業員が働くグローバル企業です。取得した特許数は1,020を超え、あらゆる環境間でデータを共有できるオープンで拡張性の高いプラットフォームを提供しています。Splunkプラットフォームを使用すれば、組織内のすべてのサービス間通信やビジネスプロセスをエンドツーエンドで可視化し、コンテキストに基づいて状況を把握できます。Splunkなら、強力なデータ基盤の構築が可能です。