稼働時間と可用性

決まった時間に営業している実店舗や組織とは異なり、ITの世界は決して眠らない。多くの人は、テクノロジーに投資したらいつでもアクセスできるようにすべきだと考えているが、それを保証するのは事実上不可能だ。 混乱が発生します、組織は、運用を円滑に実行するために必要なサービスを評価する必要があります。 たとえば、中断を最小限に抑えるために、ITサービスの停止中にどのようなサービスが必要ですか？

このタイプの評価では、組織はシステムの稼働時間 (または信頼性) や可用性など、いくつかの指標を検討する必要があります。これら 2 つの指標はよく同じ意味で使用されますが、異なるものです。 

これら 2 つの指標は、稼働時間に関する神話につながります。稼働時間は可用性を意味するものではありません。 

稼働時間とは、システムが稼働している時間の割合です。たとえば、過去 100 か月間にアプリのダウンタイムがなかった場合、稼働時間は 99.72% です。XNUMX 時間の停止があると、稼働時間は XNUMX% 程度に低下します。可用性には、稼働時間とメンテナンスの要素が含まれます。アプリがほとんどの時間稼働している場合でも、計画されたメンテナンスによって可用性が低下する可能性があります。

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

稼働時間とは何ですか？

稼働時間とは、システムが通常の状況下で操作可能な状態にある時間の割合を指します。この指標は、システム、ソリューション、またはインフラストラクチャの信頼性を測定し、通常はコンピューターを指します。

つまり、稼働時間とは、マシンが稼働して利用可能であった時間の長さを、時間の割合で表したものです。ただし、稼働時間は必ずしもすべてのサービスとアプリケーションが利用可能で、使用できる状態であることを意味するわけではありません。 

サービス レベル契約 (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ナイン」は、稼働率が90パーセントであることを示し、これは年間36.5日のダウンタイムに相当します。可用性レベルが上がると、関連する稼働率も上がります。企業が「ファイブナイン」の可用性を宣伝する場合、これは稼働率の測定値が5パーセント、つまり約 5.26 minutes 年間のダウンタイム。 

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

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

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

これには、予期しないイベントに適切に対応するために自動化ツールを使用するなどの積極的なアプローチが必要です。 

続きを読む： ITビジネス継続性計画を強化するためのソリューション

SLAの詳細

重要な指標や会社の統計情報を把握することは重要ですが、顧客が正確な測定ツールを求めている場合、SLA は意味をなさない可能性があります。企業は、契約の価値を判断するために、全体像を把握する必要があります。SLA には、一定レベルのコミットメントが必要です。99.99 パーセントの SLA を誇るのは素晴らしいことですが、問題が発生したときに支援するスタッフが不足している場合、このコミットメントを満たすのは困難です。したがって、XNUMX の数が多いほど、必要なリソースが多くなります。 

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

「4 時間の SLA 応答時間枠」は、企業が災害復旧計画を作成する際に注意しなければならないもう 1 つの変数です。サプライヤーは多くの場合、この 4 時間の時間を契約条件に含めていますが、理想的に思えますが、その時間枠内に問題が解決されるわけではありません。むしろ、サプライヤーがその時間内にトラブルシューティングを開始することを意味します。その結果、システムがオフラインになる時間が長くなる可能性があり、実際にそうなることがよくあります。

SLA と SLO

優れた顧客サービスを保証するために、一部の MSP は SLA の保証を廃止し、代わりにサービス レベル目標 (SLO) を設定しています。SLO は、サービス レベル指標 (SLI) によって測定される内部目標であり、稼働時間などの目標に対するパフォーマンスを追跡します。たとえば、MSP はホストされたサーバーの稼働率を 99.96% にすることを目標とする場合があります。このアプローチは、コンプライアンスを測定し、紛争を回避するのに役立ちます。

さまざまなワークロードに対して異なる SLA を作成することも有益です。クラウド インフラストラクチャなどの優先度の高いサービスでは、機能性を高めるために 5 ナイン以上のパフォーマンスが必要になる場合がありますが、優先度の低いワークロードでは、より低いパフォーマンス レベルでも許容できます。基本的に、SLA は外部コミットメントであり、多くの場合、コンプライアンス違反に対する罰則が伴います。一方、SLO は、サービス品質を効果的に管理するのに役立つ内部目標です。

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

稼働時間と可用性のメトリックを計算することは可能ですが、正確に測定するのは難しい場合があります。 ネットワーク稼働時間たとえば、ネットワークが稼働している時間を指します。 これは、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 コミットメントを備えたクラウド ソリューションが利用できる場合があります。ただし、脆弱性やサイバー攻撃によって、ベンダーの制御を超えた停止が発生する可能性があります。サービスが数日間影響を受けると、可用性が低下します。 

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

企業は監視サービスを使用して、サーバーの稼働時間を一貫して追跡することもできます。

ケーススタディ: BFCM 週末の Stripe の 99.9999% 稼働率

概要： 大手オンライン決済サービスプロバイダーのStripeは、 驚異的な99.9999%の稼働率を達成 2022年のブラックフライデーとサイバーマンデー（BFCM）の週末に実施されました。これは年間でわずか約31.5秒のダウンタイムであり、同社の優れたインフラストラクチャと綿密な計画を実証しています。

主な成果:

• プラットフォームの稼働時間: BFCM 期間中は 99.9999% の稼働率を維持し、20,000 秒あたり 3 件を超えるリクエストを処理し、毎日 XNUMX 億ドルを超えるトランザクションを処理しました。
• CTO の見解: Stripe の CTO である David Singleton 氏は、5 分間のダウンタイムでも数千万ドルの大きな収益損失につながる可能性があると指摘しました。

成功のための戦略:

1. ワークロードとキャパシティ計画
   • シミュレーションと負荷テスト: Stripe は、BFCM トラフィックに備えて、広範囲にわたるシミュレーションと負荷テストを実施しました。トラフィックを増やし、システムの動作を分析することで、必要なインフラストラクチャ容量を決定しました。
   • ピーク負荷処理: 同社のインフラストラクチャは、ピーク時に 20,000 秒あたり XNUMX 件を超えるリクエストを処理し、堅牢な容量計画への投資を正当化しました。
2. 可用性と稼働時間に関するSLA
   • 野心的な目標: 4 または 5 ナインの稼働率は一般的ですが、Stripe は BFCM 期間中に 90 ナインを達成し、XNUMX 日間の平均稼働率を XNUMX ナインに維持して期待を上回りました。
   • ダウンタイムの計算: Stripe は、10 のパワー トリックを使用してダウンタイムを計算し、可用性の目標を達成できるようにしました。たとえば、3 つの 1.44 つの可用性では、XNUMX 日のダウンタイムは約 XNUMX 分になります。
3. APIパフォーマンス
   • 支払いインテントAPI: 厳格なストレス テストを通じて 99.9999% の成功率を達成し、トラフィックがピークになる状況でも高い応答性と最小限のエラーを保証します。

学んだ教訓：

• ワークロードと容量の計画: 大量のトラフィックを管理し、システムの信頼性を確保するために不可欠です。
• ストレステスト： 潜在的な問題を特定し、ピーク負荷下でもシステムが堅牢性を維持することを保証するために重要です。
• 野心的な目標を設定する: 高可用性と信頼性への取り組みを推進するのに役立ちます。

結論： BFCM 期間中の Stripe の並外れた稼働時間は、信頼性と拡張性に対する同社の献身の証です。ワークロード計画、容量テスト、野心的な可用性目標に対する同社のアプローチは、トラフィックのピーク時に同様の課題に直面している他の企業にとって高い基準となります。

稼働時間と可用性に関連するその他の重要な指標は何ですか?

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

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

• 更新率: この指標は稼働時間や可用性とは直接関係ありませんが、顧客が期待するサービスを受けているかどうかを示します。更新率が低い場合は、その理由を尋ねてみましょう。どのような期待が満たされていないのでしょうか。顧客が更新しないことを選択する理由はいくつかありますが、フィードバックを求めることは重要です。 
• 顧客満足： これらのスコアは、顧客サービスの品質を示す強力な指標です。ここでも、稼働時間や可用性などの指標を詳しく調べて焦点を当てることで、高レベルの指標についてより深い洞察を得ることができます。
• 平均通知時間 (MTTN): これは、MSP がサービス停止について顧客に通知するまでに経過する平均時間です。 
• 平均修復時間 (MTTR): これは、MSP が問題を解決するのにかかる平均時間です。競争力を維持するには、MTTR を低く抑えることを目指します。

その意味では、稼働時間と可用性は考慮すべき重要な要素ですが、MSP メトリックのすべてではありません。マネージド サービスを監視する際には、より広い視点を考慮する必要があります。 

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

リモート ワークへの移行に伴い、可用性は重要な指標になりつつあります。両方の指標は、特に SLA を作成するときに重要ですが、全体像の一部にすぎません。重要なのは指標だけではありません。指標をどう活用するかが重要です。 

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

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

稼働時間は関係ないのでしょうか?

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

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

リソース ミネソタ・バイキングスがLogicMonitorを活用した方法 優れた IT パフォーマンスを実現します。ケース スタディ全体を読んで、稼働時間と可用性を向上させる戦略とソリューションを見つけてください。