--- title: IT停止の構造 description: ITチームは、ITの停止パターンを分析して、主要なインシデントに効率的に対応する必要があります。 image: https://blog.opsramp.com/hubfs/social-suggested-images/Anatomy_of_an_IT_outage-2.jpg --- [![OpsRamp](https://blog.opsramp.com/hubfs/HPE_OpsRamp_Logo_Gray_Blue_RGB-0423.svg "OpsRamp")](https://www.opsramp.com/) [ Schedule a Demo ](https://info.opsramp.com/request-demo?hsLang=ja) [![English](https://blog.opsramp.com/hs-fs/hubfs/en-us.png?width=32&height=32&name=en-us.png)](http://www.opsramp.com) [![English](https://blog.opsramp.com/hs-fs/hubfs/ja.png?width=32&height=32&name=ja.png)](https://blog.opsramp.com/ja//ja/anatomy-of-an-it-outage?hsLang=ja)   # [IT停止の構造](https://blog.opsramp.com/ja/anatomy-of-an-it-outage) [**](http://twitter.com/share?url=https://blog.opsramp.com/ja/anatomy-of-an-it-outage) ** [**](https://www.linkedin.com/shareArticle?mini=true&url=https://blog.opsramp.com/ja/anatomy-of-an-it-outage&summary=blog.opsramp.com&source=OpsRamp) [**](mailto:?Subject=Check%20Out%20This%20OpsRamp%20Blog%20Post&Body=I%20came%20across%20this%20post%20on%20the%20OpsRamp%20Blog%20and%20thought%20you'd%20like%20it.%20Check%20it%20out:%20https://blog.opsramp.com/ja/anatomy-of-an-it-outage) 4 Min Read | 9月 27, 2021 [![IT停止の構造](https://blog.opsramp.com/hubfs/social-suggested-images/Anatomy_of_an_IT_outage-2.jpg) ](https://blog.opsramp.com/ja/anatomy-of-an-it-outage) ![](https://blog.opsramp.com/hs-fs/hubfs/Mahesh-Ramachandran.png?width=120&name=Mahesh-Ramachandran.png) By [Mahesh Ramachandran](https://blog.opsramp.com/ja/author/mahesh-ramachandran#author) ![SUBSCRIBE](https://no-cache.hubspot.com/cta/default/308166/89850b51-b95b-4330-9c88-2bdac48746b6.png) **In our [最初のブログ ](http://blog.osramp.com/anatomy-of-an-it-outage)、ITの停止の背後にある3つの主要な構造、つまり容量の制約、コンポーネントの障害、および人的エラーによる停止について調べました。この投稿では、さまざまなタイプの停止を予測および検出するためのアプローチを確認します。 ITが停止する可能性がある場合の目標は、早期に予測してすぐに検出することです（を参照）。 **Figure 1**).** **![Outage Analysis](https://blog.opsramp.com/hubfs/Blog_images/Anatomy_02_Goals_FIg-1.png "Outage Analysis")** ****図2 ** 停止を予測および検出するためのフレームワークをレイアウトします。フレームワークを見てみましょう... ** **![Outage Prediction and Detection Framework](https://blog.opsramp.com/hubfs/Blog_images/Anatomy_02_Approach_Fig-2.png "Outage Prediction and Detection Framework")** ## **ステップ1-メトリックとイベントを特定する ** 最初のステップは、障害の信頼できる指標であるメトリックとイベントを特定することです。メトリックとイベントは、監視するIT要素からのデータです。メトリックは、IT要素の可用性、パフォーマンス、および容量に関する情報を伝達します。停止を検出するための鍵は、監視するメトリックとイベント値を選択することです。 **指標 ** IT要素で直接測定できる数値データです。例えば： - データベースアプリケーションでのSQLクエリ要求の数。 - サーバーのCPUとメモリの使用率。 **イベント **IT要素がステータスを示すために発行する情報の断片です。例えば： - An event from your [マイクロソフトウィンドウズ ](https://en.wikipedia.org/wiki/Microsoft_Windows) そのアプリケーションについてのサーバー  機能を停止しました。 - A [trap](https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol) ネットワークデバイスからは、重要なコンポーネントに障害が発生したことを示している可能性があります。 イベントは、メトリックよりも多くの情報を伝達します。これらを総合すると、イベントとメトリックは、IT環境の現在および将来の可能性のある状態に関する洞察を提供します。 3種類の停止では、さまざまな種類のメトリックとイベントを選択する必要があります。これらのタイプを見てみましょう... **容量メトリック **IT要素の一部のリソース（ディスク、メモリ、CPU、トランザクション処理能力など）の容量が不足していることを示します。一般的な容量メトリックは次のとおりです。 - サーバーまたはストレージアレイの残りのディスク容量が少ないことは、ディスク容量の状態を反映しています。 - サーバーの高いメモリ使用率またはページング率は、メモリ不足の状態を反映しています。 - アプリケーションのリクエストキューのキューの長さの値が高い場合は、アプリケーションの処理能力が使い果たされていることを示しています。   容量メトリックは、IT要素から入手できます。たとえば、Microsoft Windowsには、メモリ使用率とページング率が含まれています。カスタムアプリケーションの場合、他の基礎となるメトリックから適切な容量メトリックを導出する必要がある場合があります。 監視する容量メトリックを選択または導出するときは、これら2つの基本的な容量関連の質問の1つに答えるメトリックを探してください（を参照）。 **図3 **): - **使用率メトリックの場合 **、メトリックは、残りのリソース（ディスク容量、メモリなど）の「量」を示していますか？ - **待機時間メトリックの場合 **、メトリックは、リソース（ディスクI / Oなど）にアクセスするのを待つ「時間」を示していますか？ ![Capacity Related Outages](https://blog.opsramp.com/hubfs/Blog_images/Anatomy_02_Capacity_Outages_Fig-3.png "Capacity Related Outages") **障害メトリックとイベント **障害が発生したか、発生しようとしていることを示します。例えば： - ネットワークデバイスにpingを実行すると、100％のパケット損失が発生します。 - ストアアレイからのディスク障害イベント。 既知の「バイタルサイン」をテストすることで、ほとんどの種類の障害を特定できます（を参照）。 **図4 **）。これらは、バイタルサインの一般的なタイプです。 - **応答メトリック **：要素をプローブして、リクエストへの応答を測定できます-例：ネットワークまたはアプリケーションの要求に対する応答時間。 - **進捗チェック **：要素をプローブして、特定のプロセスが実行され、前進しているかどうかを確認できます-例： SQLサービスが機能しているかどうかを確認します。 - **自己申告イベント **：ほとんどの要素は、ログまたはイベントを介してヘルスに関する診断イベントを発行します。 ![Component Failure Related Outages](https://blog.opsramp.com/hubfs/Blog_images/Anatomy_02_Component_Outages_Fig-4.png "Component Failure Related Outages") **メトリックの変更 **ヒューマンエラーによってトリガーされます。これらのエラーは環境に変化を引き起こし、その結果、コンポーネントの障害や容量の問題が発生します。このような変更には、アプリケーションまたはインフラストラクチャ構成の更新が含まれます。 最新のIT環境では、停止の大部分は変更によるものです。典型的なIT環境は1日に多くの変化を経験します。従来の環境では数十回の変更から、「DevOps」スタイルの環境では数千回の変更になる可能性があります。通常、変更を展開する前にすべての変更の影響を評価することは実用的ではありません。したがって、変更に関連する停止を予測する問題は、実際には議論の余地があります。ただし、停止の原因となった可能性のある変更に遡及的に停止を関連付けることができます。これを行うには、次のことを考慮してください。 - >**変更量を測定するための指標。 ** サーバー上のアプリケーションの更新数など、ロールアウトされた変更の量を追跡できます。 - **失敗を変更に関連付ける **: 停止を診断するときは、停止時刻より前の変更量を確認してください。変更による停止は、変更後すぐに現れます。 **図5 ** は、このアプローチの概念的な例を示しています。 ![Human Error Related Outages](https://blog.opsramp.com/hubfs/Blog_images/Anatomy_02_human_errors_Fig-5.png "Human Error Related Outages") ## **ステップ2-しきい値を設定する ** 指標を特定したら、検出と予測は指標に適切なしきい値を選択することです。しきい値は、障害が進行中であることを示したり（検出）、緊急の問題を規定したり（予測）することができます。 **図3 ** は、検出と予測のしきい値の概念的な例を示しています。 **検出。 **検出のしきい値は通常、簡単に識別できます。通常、主要なメトリックの通常の範囲は既知であり、主要な障害イベントも既知です。例えば： - 95％を超える持続的なCPU使用率は、サーバーの容量の問題を示しています。 - ディスク障害には、特定のイベントが関連付けられています。 **予測。 **予測のしきい値にはトレードオフが含まれます。誤った予測を取得することと、問題について十分な早期警告を取得しないことの間にはトレードオフがあります。ディスク容量については、70％（積極的）から90％（保守的）の間の任意の場所で空き領域のしきい値を設定できます。履歴データを使用して、最適なトレードオフポイントを見つけることができます。 ## **ステップ3-要素を監視する ** 監視するには、IT要素を単一障害点と冗長障害点の2つのタイプに分類します。これらの2つのタイプの要素の監視には少し異なる方法でアプローチする必要があります。 **単一障害点。** These  要素は、ITチェーンの「最も弱いリンク」です。単一障害点には、それらが利用できない場合にその機能を引き継ぐことができる冗長な対応物がありません。例えば、 **図6 **は、ロードバランサー、アプリケーションサーバー、およびデータベースサーバーを使用した一般的なアプリケーションの展開を示しています。ロードバランサーとデータベースサーバーが単一障害点です。単一障害点は停止につながります。したがって、単一障害点を追跡することを忘れないでください。 **冗長な障害点。 ** これらの要素は一緒に「クラスター化」されるため、いずれかの要素に障害が発生した場合、クラスター内の別のピアが引き継ぐことができます。たとえば、図6では 、アプリケーションサーバーは冗長な障害点です。 1台のサーバーが実行されている限り、アプリケーションは引き続き機能します。 冗長ポイントで障害が発生しても、すぐに停止することはありません。個々の要素の状態とクラスターの集約状態を追跡する必要があります。検出と予測のしきい値を個々の要素とクラスターの両方に適用します。図6  例を示します。各アプリケーションサーバーと、クラスター内で使用可能な要素の数を追跡する必要があります。アプリケーションが実行中の1つのアプリケーションサーバーで動作する場合、クラスターの検出しきい値は0になり、予測しきい値は1になります。 ![Points of Failure](https://blog.opsramp.com/hubfs/Blog_images/Anatomy_02_Point_of_FailureFig-6.png "Points of Failure") ## **ステップ4-履歴データを分析して微調整する  ** **毎日 障害インスタンスは、メトリック、イベント、およびしきい値を学習して微調整するための貴重なデータポイントです。各要素の障害からの履歴データを分析して、根本原因を特定します。監視システムによって障害が検出または予測されなかった場合は、障害を分析します。あなたの目標は、より良い障害指標となる特定のメトリック、イベント、およびしきい値を特定することです。これらの結果を継続的な改善サイクルに組み込みます。 ** [Tweet](https://twitter.com/share) [ Share](http://www.linkedin.com/shareArticle?mini=true&url=https://blog.opsramp.com/ja/anatomy-of-an-it-outage?latest1) [**](mailto:?Subject=Check%20Out%20This%20OpsRamp%20Blog%20Post&Body=I%20came%20across%20this%20post%20on%20the%20OpsRamp%20Blog%20and%20thought%20you'd%20like%20it.%20Check%20it%20out:%20https://blog.opsramp.com/ja/anatomy-of-an-it-outage) Share [Tweet](https://twitter.com/share) [ Share](http://www.linkedin.com/shareArticle?mini=true&url=https://blog.opsramp.com/ja/anatomy-of-an-it-outage?latest1) [** ](mailto:?Subject=Check%20Out%20This%20OpsRamp%20Blog%20Post&Body=I%20came%20across%20this%20post%20on%20the%20OpsRamp%20Blog%20and%20thought%20you'd%20like%20it.%20Check%20it%20out:%20https://blog.opsramp.com/ja/anatomy-of-an-it-outage) X --- ## Recommended posts [![可観測性はまだ初期段階ですか?](https://blog.opsramp.com/hubfs/Blog_Hero_Observability_Report_2024@2x-100.jpg)](https://blog.opsramp.com/ja/observability-early-days?hsLang=ja) [可観測性はまだ初期段階ですか?](https://blog.opsramp.com/ja/observability-early-days?hsLang=ja) [![ユニファイドサービスインテリジェンス：デジタルトランスフォーメーションのための秘密兵器](https://blog.opsramp.com/hubfs/Unified-Service-Intelligence-dashboard-preview.jpg)](https://blog.opsramp.com/ja/unified-service-intelligence?hsLang=ja) [ユニファイドサービスインテリジェンス：デジタルトランスフォーメーションのための秘密兵器](https://blog.opsramp.com/ja/unified-service-intelligence?hsLang=ja) [![「ガラスの単一ペイン」がIT運用の苦痛となっている5つの理由](https://blog.opsramp.com/hubfs/Blog_images/SPOG/SPOG-hero.jpg)](https://blog.opsramp.com/ja/single-pane-of-glass?hsLang=ja) [「ガラスの単一ペイン」がIT運用の苦痛となっている5つの理由](https://blog.opsramp.com/ja/single-pane-of-glass?hsLang=ja) ### Get our regular updates and news © 2026 OpsRamp, LLC. All rights reserved.  [Privacy](https://www.opsramp.com/privacy/) | [Accessibility](https://www.opsramp.com/accessibility) | [Terms of Use](https://www.opsramp.com/terms-of-use/) ![](https://dc.ads.linkedin.com/collect/?pid=342636&fmt=gif) ![](https://px.ads.linkedin.com/collect/?pid=342636&fmt=gif) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Mahesh Ramachandran", "url" : "https://blog.opsramp.com/ja/author/mahesh-ramachandran" }, "dateModified" : "2021-09-27T19:12:46.716Z", "datePublished" : "2021-09-27T19:09:25.000Z", "headline" : "IT停止の構造", "image" : [ "https://blog.opsramp.com/hubfs/social-suggested-images/Anatomy_of_an_IT_outage-2.jpg" ], "mainEntityOfPage" : { "@id" : "https://blog.opsramp.com/ja/anatomy-of-an-it-outage", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.opsramp.com/hubfs/logo.png" }, "name" : "OpsRamp,Inc." } } ```