※この記事は翻訳されたものです。本記事の原文はこちら
– カスタマーエクスペリエンス担当バイスプレジデント Cassius Rhue
高可用性はITインフラをダウンタイムから保護するために不可欠ですが、購入すべき最適なHAソリューションはどのようにして見つければよいのでしょうか。この記事では、何を購入すべきかを見極めるのが難しい理由と、高可用性への投資について経営陣の同意を得るためのステップについて概説します。
Contents
優れたHAソリューションを購入するのなぜ難しいのか
バーバラ・ジョーン（仮名）は、会社のITインフラの大部分を担当するチームを率いており、高可用性への投資を行うよう経営陣を説得するために絶えず奮闘しています。彼女が高可用性（HA）保護の導入を勧めるたびに、さまざまな同僚が保留、反対、代替案の提案を表明し、さらには自社のエンタープライズアプリケーションが過去に何度か停止したことの重大性を軽視することさえありました。
彼女はいつも同じ疑問を抱いています。「組織、業界、影響を受けるアプリケーションにもよるけれども、ダウンタイムのコストが、45,000ドルから500,000ドルと推定される場合に、なぜ優れた（費用対効果の高い）HAソリューションの購入に同意することが難しいのだろう？」と。
HAが素晴らしい投資であることを経営陣に納得させる7つの方法
1. コスト回避のROIを考える
HAのROIを、コスト回避としてより正確に計算します。つまり、現在の想定コストを維持するために取るべき行動（高可用性の追加）と、何も取らない場合のコスト（ダウンタイム）を比較するのです。
HAによる保護がなければ、ダウンタイムは避けられません。なぜなら、ITシステムは、機械的なサーバーの故障から人為的なミス、ソフトウェアの非互換性など、さまざまなダウンタイム要因の影響を受けるからです。また、業種や企業規模によってもコストは異なります。SLAが厳しく、1日あたり数百万件のトランザクションを処理するような大手メーカーであれば、計画外のダウンタイムに対する違約金は、地方や地域に拠点を置く中小企業よりも大きくなります。さらに、ビジネスが高度に規制されている場合や、重要なサービスプロバイダーの場合、ダウンタイムに対する追加的な違約金は、製品や商品の販売以外でも発生する可能性があります。IT評価担当者がダウンタイムを間違って評価すると、その方程式によって堅牢な商用ソリューションの購入が難しくなってしまいます。
2. トータルソリューションのコストを考える
会社の評判の低下、顧客の不満、ITスタッフのフラストレーションなど、ダウンタイムそのものが会社に与えるダメージは計り知れません。バーバラ・ジョーンは、ストレスの多い、時には大きな混乱を伴うダウンタイムのインシデントに対応するために生産的な仕事を中断しなければならないことにうんざりしています。皆さんの組織では、ダウンタイムが非常に高額なスタッフの離職に与える影響を、どのように計算していますか？
3. 適切なHAは元が取れる
HAソリューションのコストは、単に必要なソフトウェアとサーバーのコストだけだと考えている企業もあります。社内のリソースやクラウドを使って自社で構築できると思い込んでいるのです。しかしこのような企業は、ソリューションのさまざまな側面と、それぞれの隠れたコストを考慮することを忘れています。たとえば、自家製ソリューションは短期的には導入コストが安いかもしれませんが、多くの場合、メンテナンス、継続的なサポート、チームのトレーニング、ドキュメント作成、技術的負債、ブレイクフィックス開発などの隠れたコストが存在します。さらに、自家製ソリューションの多くは、「社内でより安くできる」という見積もりを証明する際に、チームが取り組まない他の作業について、必ずしも見積もりや考慮をしていません。どのようなDIYプロジェクトでもそうですが、専門家に任せた方がいいこともあるのです。
4. ダウンタイムの定義を明確にする
ダウンタイムには、計画的なものと計画外のものがあります。ダウンタイムには、プラットフォームが利用できないことによる問題、アプリケーションのクラッシュ、ハードウェアの障害、ネットワークの停止、物理的なデータセンターの問題、侵害、人為的なミスによるものなどが含まれます。一部の評価では、顧客とIT評価者はプラットフォームの可用性に集中し、他のダウンタイムの原因を見失ってしまいます。たとえば、ある大手製造業のプロジェクトマネージャーは、クラウドプラットフォームは回復力、信頼性、冗長性を向上させるが、可用性に影響を与えるすべての問題をカバーできるわけではないと述べています。彼はさらに、多くの評価者がダウンタイムの根本原因として忘れている領域についても説明しました。
5. 関連用語を明確にする
最近私は、アプリケーションの可用性に関する典型的な顧客のニーズについて議論する業界のパネルに参加しました。最初の5分足らずのうちに、パネルの参加者数人が、さまざまな用語の頭字語や略語を10個以上使いました。簡単に理解できるものもあれば、ITプロフェッショナルのバックグラウンドがないとわからないような非常にニッチなもの、経験に応じて意味が変わってくるものもありました。たとえば、HA+DRはHigh Availability + Disaster Recovery（高可用性とディザスターリカバリー対応）なのか、それともHigh Availability with Data Replication（データレプリケーションによる高可用性）を意味するのか、などです。頭字語の使用は、業界の知識や経験のレベルが異なる人々の間での用語の多様な用途と相まって、購入プロセスにおける混乱や摩擦を引き起こす可能性もあります。
カスタマーエクスペリエンス担当として、私が担当するある顧客評価で購買チームとの間に深刻な摩擦が発生したことがありました。というのも、1人の承認者は会社が必要とするのはHAのソリューションだけだと考え、もう1人はHA+DRが必要だと考えていたからです。最終的に2人は、前者のHAは2つのノードのもの、後者のHAは2つのノード＋DRだということを理解しました。
6. HAソリューションの役割を明確に定義する
「期待」は、HAソリューションの購入をしばしば妨げるもう一つの理由です。カスタマーエクスペリエンス担当として、私たちは、度々ダウンタイムを引き起こしているプラットフォームとアプリケーションの不安定性に対応しているお客様と仕事をしてきました。評価プロセスの間、お客様はHAソリューションがプラットフォームの不安定性に対処できなかったと嘆いていました。負荷がかかると、ハードウェアのCPUとメモリが停止し、ネットワークは不安定になり、ほとんど使用不可能になりました。適切なサイズのシステムや信頼性の高いインフラを通じて基盤となるプラットフォームを改善する代わりに、このお客様は障害の原因がHAソリューションにあると考え、私たちとは袂を分かちました。IT管理者はしばしば、HAに何ができ、何ができないかについて、経営陣と期待値をすり合わせるのに苦労しています。HAソリューションは、ITインフラの問題をすべて解決する魔法の薬ではなく、むしろ健全なアーキテクチャーの不可欠で重要な要素です。ソリューションへの期待や要件に関して誤解が生じると、購入の障害となったり、阻止されることになります。
7. クラウドのSLAがアプリケーションのHAを提供しない理由を説明する
クラウドプラットフォームのSLAを見直し、何がSLAでカバーされ、何がカバーされないのかをしっかりと理解してください。多くのプラットフォームは、以前は評判の悪かったデータセンターに、必要とされるインフラの安定性、信頼性、柔軟性を提供しています。しかし、ほとんどのアプリケーションでは、可用性とアップタイムに関する責任は、クラウドベンダーではなく、依然としてIT管理者にあるのです。オンプレミスであろうとクラウドであろうと、システムがどこにあろうと、HAに「全く関与しなくて済む」ようなアプローチは存在しないのです。
もちろん、優れたHAソリューションの購入を困難にする誤解は、以上に述べたことがすべてではありません。他にも、スケジューリングプロセス、ユースケースの優先順位付け、要件の定義と明確化、成功基準、予算、予算権限、企業向け商用HAソリューションを採用しない場合のリスクに対する理解（またはその欠如）などで、しばしば大きな誤解が生じます。HAソリューションの詳細については、サイオステクノロジーまでお問い合わせください。
組織の階層間の誤解をなくす
優れたHAソリューションを評価・購入し、導入する際の大きな課題は、組織の異なる階層間の誤解に起因します。最初のコストに関する誤解を思い返し、コスト正当化の責任者が上司の承認を得るために何を説明しなければならないかを考えてみてください。次に、各人の上司の背景を考えてみましょう。彼らは技術者なのか非技術者なのか、同じチームにいるのか、それとも組織の別の場所にいるのか。次に、社内の様々なITレイヤー間の関係と、そのニーズやコミュニケーションがどのように議論や決定に影響するかを考えてみましょう。SIOSのカスタマーエクスペリエンスチームが関わる多くの企業では、データベース、アプリケーション、プラットフォーム、ネットワーク、セキュリティなど、IT部門の各部分に複数のテクノロジーチームを擁しています。これらの各テクノロジーチームは、要件、期待、成功基準を定義するために十分なコミュニケーションを取る必要があります。このレベルのコミュニケーションは簡単には実現しませんが、すべてのチームが遠隔地にあり、タイムゾーンも異なる場合はさらに難しくなります。
