稼働時間と可用性

稼働時間と可用性

実店舗や決められた時間帯に営業する組織とは異なり、ITの世界は決して眠りません。 

今日の高度に接続されたデジタル環境では、テクノロジーに投資する場合、常にアクセス可能である必要があると多くの人が信じています。これを保証することは事実上不可能です。 以来 混乱が発生します、組織は、運用を円滑に実行するために必要なサービスを評価する必要があります。 たとえば、中断を最小限に抑えるために、ITサービスの停止中にどのようなサービスが必要ですか?

このタイプの評価では、組織はシステムの稼働時間(または信頼性)や可用性など、いくつかのメトリックを確認する必要があります。 これらのXNUMXつのメトリックはしばしば同じ意味で使用されますが、同じではありません。 

これらのXNUMXつのメトリックは、稼働時間の神話につながります。 稼働時間は可用性を意味するものではありません

これらのXNUMXつのメトリックの意味とそうでないものを理解することは、マネージドサービスプロバイダー(MSP)が正確で透過的な契約を作成するのに役立ちます。 

Contents [show]

稼働時間とは何ですか?

稼働時間とは、システムが通常の状況で動作する準備ができている時間の割合を指します。 このメトリックは、システム、ソリューション、またはインフラストラクチャの信頼性を測定し、最も一般的にはコンピューターを指します。

そう、 稼働時間は、マシンが稼働していて利用可能である時間であり、時間のパーセンテージとして表されます。 ただし、稼働時間は、必ずしもすべてのサービスとアプリケーションが利用可能であり、すぐに使用できることを意味するわけではありません。 

サービスレベルアグリーメント(SLA)を見ると、保証された稼働時間は過去のパフォーマンスによって決まります。 ただし、これは将来何が起こるかを示すものではありません。 

そうです、稼働時間は可用性の指標になる可能性がありますが、それは決して保証ではありません。 

2014年のGoogleの大停止 これは、100%の稼働時間が不可能であるという優れた例です。 この停止中、Google +やGmailなどのGoogleアプリケーションへのサービスは、25〜55分間停止し、ユーザーの約10%に影響を及ぼしました。 この例は、ITの現実と消費者の期待の間に存在する対立を示しています。 もっと 停止 今後数年間で、Google、Facebook、Instagram、Azure、Salesforceなどで発生しました。 とにかく、消費者の期待は依然として高いままです。 

ITプロフェッショナルは、100%の稼働率が神話であることを知っています。そのため、ポジティブな顧客体験を保証するレベルのサービス可用性を提供することを目指す場合、テクノロジーは非常に重要です。 

可用性とは何ですか?

対照的に、可用性とは、システムが必要なときに必要に応じて機能する確率です。 このメトリックは、チームがリモートで作業している場合に重要です。 データショー 現在、世界中の企業の16%が100%遠隔地にあり、99%の人が残りの人生でこのオプションを選択するため、たとえパートタイムであったとしても、この割合は今後数年間で上昇する可能性があります。 

関連しました: リモートワークの時代にIT部門がどのように進化しているか

これらXNUMXつのメトリックを比較するときは、稼働時間と可用性の違いをOEE(設備総合効率)およびTEEP(設備総合効率)として考慮してください。 

誤った仮定はコストがかかる可能性があるため、これらのメトリックの両方を理解することが重要です。 これらの指標を間違って表示すると、多くの場合、エクスペリエンスが低下します。 サービスプロバイダーは契約のしきい値を満たしますが、サービスのレベルは顧客の期待よりも低くなります。

この現象は、スイカ効果と呼ばれるものです。

アウトプットは定義された目標を達成できますが、結果は達成されず、不幸な顧客につながります。 

スイカの効果を深く掘り下げる

スイカの効果は、ITメトリックがすべての要件を満たしていると考えることの副産物です。 ただし、顧客のエクスペリエンスは不十分です。 指標は外側が緑色に見えますが、内側は赤色です。 

SLAレポートは見栄えがよく、MSPを満足させることができます。 対照的に、顧客は満足しておらず、ビジネスを他の場所に移しています。 カスタマーエクスペリエンスは不可欠であるため、MSPはサポート指標の重要性を過小評価してはなりません。 

実際のエンドユーザーエクスペリエンスに関する透明性のレベルが高いほど、ITチームはエンドユーザーの支援に集中しやすくなります。 「赤」の指標を深く掘り下げることで、ITチームは最も重要なことに注意を向けることができます。 最善の方法は、プロジェクトまたは四半期が終了する前に問題のあるメトリックを修正するために利用できる時間を最大化して、迅速かつ困難に傾倒することです。 

したがって、稼働時間の指標が満たされている場合でも、 カスタマーエクスペリエンスを考慮する クライアントがサービスの価値がまだ不足していると感じた場合。 エンゲージメントが低下すると、変化を促す原動力が低下し、企業は今日の顧客にとって最も重要な問題を正確に改善できなくなります。 

重要なのは、問題が発生する前に問題を特定することです。 これは、LogicMonitorなどの可観測性プラットフォームを介して実現できます。 

ファイブナインのコンセプト

「ファイブナイン」は、稼働時間または可用性に関して99.999パーセントを意味する一般的な用語です。 

たとえば、可用性レベル「1 Nine」は、90%の稼働時間を示します。これは、年間36.5。5日のダウンタイムに相当します。 可用性レベルが上がると、関連する稼働時間も増えます。 企業が「99.999ナイン」の可用性を宣伝する場合、これはXNUMXパーセントまたは約の稼働時間の測定値を指します 5.26分 年間のダウンタイムの。 

稼働時間と可用性のファイブナインは重要なセールスポイントです。そのため、サプライヤは99.999パーセントの稼働時間SLAを販売しています。 問題は、場合によっては、稼働時間または可用性スコアにXNUMXが追加されるたびに、必ずしも信頼性が向上するとは限らないことです。 顧客が自分の能力に基づいてサプライヤーまたはサービスプロバイダーに焦点を合わせることがより重要です。

マネージドサービスプロバイダーとして、これはあなたが輝くことができる場所です。 

たとえば、顧客と協力して 事業継続性 計画は、混乱が発生したときに違いを生む可能性があります。 ファイブナインを達成するには、機器と人員の両方を考慮する必要があります。 稼働時間と可用性は、機器がダウンしていないことによって決まります。これらのメトリックは、コンポーネントに障害が発生したときの応答の速さにも影響されます。 事業継続計画は不可欠です。

これには、予期しないイベントにより適切に対応できる自動ツールを使用するなど、プロアクティブなアプローチが必要です。 

詳しくはこちら: ITビジネス継続性計画を強化するためのソリューション

SLAの詳細

重要なメトリックと会社の統計を認識することは重要ですが、顧客が正確な測定ツールを求めている場合、SLAは合理的に無意味になる可能性があります。 契約の価値を真に評価するには、企業は全体像を見なければなりません。 SLAには、ある程度のコミットメントが必要です。 99.99パーセントのSLAを誇ることは優れていますが、問題が発生したときに支援するのに十分なスタッフがいない場合、このコミットメントを満たすのは困難です。 したがって、XNUMXの数が多いほど、より多くのリソースが必要になります。 

このタイプの合意はしばしば灰色の領域につながり、問題が発生した場合、補償は通常最小限であるか存在しません。 たとえば、クラウドプロバイダーは、停止が発生した場合に顧客にサービスクレジットを提供することがよくあります。 ただし、これらのクレジットは通常、費用をカバーしていません。 たとえば、停止は企業の取引または販売能力に悪影響を及ぼし、収益の損失や評判の低下につながる可能性があります。 

「XNUMX時間のSLA応答ウィンドウ」は、災害復旧計画を作成する際に企業が常に認識しておく必要のあるもうXNUMXつの変数です。 サプライヤーは多くの場合、このXNUMX時間の期間を契約条件に含めます。これは理想的に聞こえますが、問題がその期間内に修正されることを意味するわけではありません。 代わりに、サプライヤがその時間にトラブルシューティングを開始することを意味します。 その結果、システムはより長くオフラインになる可能性があり、多くの場合オフラインになります。 

SLAとSLO

卓越したカスタマーサービスを保証するために、一部のMSPは、提供するSLAの保証を提供しなくなりました。 代わりに、サービスレベル目標(SLO)を設定します。 コンプライアンスを測定するには、サービスレベルインジケーター(SLI)を検討して、稼働時間を回復する必要があります。 MSPがホストされたサーバーで99.96%の稼働時間を提供する場合、この値は、順守しようとしている目標を表します。 ここでの目標は、コンプライアンスを測定し、紛争を回避することです。 

さらに、さまざまなワークロードに関してさまざまなSLA契約を作成することは有益です。 たとえば、クラウドインフラストラクチャサービスでは、より優れた機能を確保するために5以上のナインが必要になる場合がありますが、優先度の低いワークロードは、サービスの可用性に関して低いパフォーマンスで動作できます。 

稼働時間と可用性はどのように追跡されますか?

稼働時間と可用性を測定するための計算があります。 ただし、これらのメトリックを測定するのは難しい場合があります。 

ネットワーク稼働時間たとえば、ネットワークが稼働している時間を指します。 これは、365日間の稼働時間とダウンタイムの比率を計算することによって追跡および測定され、パーセンテージで表されます。 

ネットワーク稼働時間を計算する方法の例を次に示します。

  • 24時間/日x365日/年= 8,760時間/年 
  • ネットワークが稼働している8,760年あたりの時間数÷100時間xXNUMX =年間の稼働時間の割合。

したがって、ネットワークが7年の間にXNUMX時間ダウンした場合、ネットワークの稼働時間は次のようになります。

  • 8,753÷8,760 = 0.9992
  • 0.9992 x 100 = 99.9.2パーセント

繰り返しますが、稼働時間は過去のパフォーマンスに直接関係しています。 そのため、課題が発生します。 たとえば、99.999のSLAコミットメントでクラウドソリューションを利用できる場合があります。 ただし、脆弱性、さらには サイバー攻撃 ベンダーの制御が及ばない停止を引き起こす可能性があります。 サービスが数日間影響を受けると、サービスの可用性が低下します。 

  • 可用性を測定する場合、測定は時間損失によって決まります。
  • 信頼性(稼働時間)を測定する場合、測定は頻度と障害の影響によって決まります。

企業がサーバーの稼働時間を一貫して追跡するために、監視サービスもあります。

稼働時間と可用性を取り巻くその他の主要な指標は何ですか

顧客がMSPを評価するときは、メトリックを使用して評価します。 関連するメトリックは、MSP組織の管理者の役割を持つ人々によっても監視されます。 ここでの目標は、適切なパフォーマンスレベルを維持し、主要業績評価指標(KPI)を積極的に改善することです。 

稼働時間は通常、サービス改善指標でカバーされます。 ただし、他のいくつかのメトリックは、MSPとして注意を払う価値があります。 これらのメトリックは、データを活用して、ITプロバイダー間の決定要因を強調します。 

  • 更新率 —このメトリックは、稼働時間と可用性に直接関連していませんが、顧客が期待するサービスを受けているかどうかを示しています。 更新率が低い場合は、質問する時が来ました、なぜですか? どのような期待が満たされていませんか? お客様はいくつかの理由で更新しないことを選択する場合がありますが、フィードバックを求めることが重要です。 
  • 顧客満足度スコア カスタマーサービスの品質の強力な指標です。 繰り返しになりますが、稼働時間や可用性などの指標に焦点を当てて深く掘り下げることで、高レベルの指標についてより深い洞察を得ることができます。
  • 通知する平均時間(MTTN) MSPがサービスの停止について顧客に通知するまでに経過する平均時間です。 
  • 平均修復時間(MTTR) MSPが問題を解決するための平均時間を指します。 競争力を維持するために、低いMTTRを目指してください。

その意味で、稼働時間と可用性を考慮することは不可欠ですが、MSPメトリックのすべてではありません。 マネージドサービスを監視する際に考慮すべき全体像があります。 

稼働時間と可用性のどちらがより重要ですか?

今日の現在のビジネス環境では、可用性はリモートワークへの移行に基づく重要な指標になりつつあります。 

特にSLAを作成する場合は、両方のメトリックが重要ですが、これらは全体像の一部にすぎません。 重要なのはメトリックだけではなく、それらを使用して行うことです。 

サービスの稼働時間と可用性を向上させるには、お客様が私たちが完璧な世界に住んでいないことを理解することが不可欠です。 特に顧客のニーズと要件に関しては、コミュニケーションが非常に重要です。 

テストの実行、フェイルセーフの実装、および障害点の排除に向けた取り組みに加えて、継続的な監視が不可欠です。 可用性を監視することで明確になります。 これが、可用性の高いシステムを構築する方法です。 

稼働時間は関係ありませんか?

100%の稼働時間を達成することは、達成不可能な目標です。 説明したように、稼働時間は過去のパフォーマンスを反映しています。 その意味で、これは将来の可用性の貴重な指標ですが、保証ではありません。100の稼働時間は事実上不可能です。 

そのため、企業はプロジェクトのメンテナンス要件と潜在的なロジスティクスの遅延に焦点を当てる必要があります。 そうすることで、ダウンタイムをより正確に予測して可用性を向上させることができます。 消費者の期待に応えるために、ITチームは問題を予測し、可視性を向上させてより早く回復する必要があります。 完全なカバレッジ、 柔軟な統合, 深い報告 これを達成するための重要な焦点領域であり続けます。

LogicBlogの他の記事

アンペアロボット 影

お店の話をしましょう。

STARTED GET