SLAに関する7つの誤解とは、Uptime.comが解説：ダウンタイムはゼロにはならない

Uptime.comは、SLAに関する誤解がDevOps業務に悪影響を与える場合があると公式ブログで指摘した。SLAについて、7つの一般的な誤解を取り上げ、どこが間違っているのかを解説した。

[＠IT]

　Webサイトのアップタイムやパフォーマンスを向上させるソリューションを提供するUptime.comは、2021年2月19日（米国時間）に公式ブログで、SLA（サービスレベル契約）に関する誤解について解説した。SLAについて誤った考えを抱いていると、DevOps業務に悪影響を与える場合があるという。DevOps担当者向けに7つの一般的な誤解を取り上げ、どこが間違っているのかを解説した。

誤解1　1つの開発言語を使うべきだ

　DevOpsを適切に進めるには、複数のツールが必要だ。作業に応じて適切なツールを使う必要があり、使用する言語を1つに絞るべきではない。

　PythonやJavaScriptは多種多様な目的に使えるが、決して唯一の選択肢ではない。

誤解2　100％のアップタイムは達成可能で、持続可能でもある

　この誤解は、今回取り上げた中で最も有害な誤解だろう。この誤解のせいで、非現実的なSLAを達成できずに仕事を失ったり、企業として訴えられたり、ユーザーが不満を抱いたりするからだ。

　100％のアップタイムは達成不能、持続不能だ。SLAで規定すべき目標基準については、2つのシンプルな原則がある。この原則に基づいて自社に適した内容を検討しなければならない。

1. SLAの義務としてアップタイムを決定するには、サービスレベル指標が必要になる
2. SLAでは義務を定義する。同時にエラー予算（許容可能なダウンタイム時間）も定めなければならない

誤解3　システムのアップタイムは、サービスの可用性と同じである

　管理画面のステータスページでは、全てが問題なく稼働していると表示されていても、ユーザーからはそうではないと否定される場合がある。これは、サービスの可用性に注意を払っていないのが原因だ。

　顧客と接点があるシステムが最も重要だ。SLA通りに99.99999999％のアップタイムを実現したとしても、Webサイトにアクセスできなければ、顧客はアップタイムのレベルなど気に掛けない。

　まずはインフラやネットワーク、サービスについて知識を深める必要がある。何が分からないのかが分かっていない状態だからだ。モニタリングだけではこの問題の解決にはならない。障害が発生して初めて、そもそも何が問題なのか気付く場合もある。エラー予算を確保しておけば、障害や見落としを学習につなげることができる。

　顧客と接点があるシステムの接続が切れたら、早急に接続を回復するよう努めることが、評価の決定的な悪化を避けるために有効だ。

誤解4　クラウドなら任せきりにできる

　クラウドコンピューティングは営業担当者の宣伝文句の通り、安全性が高く、柔軟に運用できるかもしれない。だが、大規模なクラウドプロバイダーは攻撃の対象となる領域も大きく、問題が発生した場合の影響も少なくない。

　大手CDN（Contents Delivery Network）がダウンしたときのことを覚えている方も多いだろう。そのせいでインターネットの半分がダウンしたからだ。こうした障害が再び起これば、多くの企業があおりを受ける。例外はモニタリングを常に実行し、バックアップを取っていた企業だけだ。

　ここに教訓がある。CDNやクラウドのサービスは優れているが、だからといってモニタリングやバックアップソリューションの必要性が薄れることはない。

誤解5　Webサイトモニタリングツールは無料で構築できる

　無料で構築できることは確かだが、それは自宅を自分で建てるようなものだ。Webサイトモニタリングツールの開発とメンテナンスには、多大なリソースを投入する必要がある。つまり、無料ではない。

　無料のWebサイトモニタリングサービスは、出発点としては良い。だが、利用可能な機能が限られる。いつまでも無料サービスで事足りることはまずない。

　「サブスクリプションベースのアップタイムモニタリングサービスに何を求めるか」、検討が必要になる。

誤解6　インスタントアラートは必須である

　インスタントアラートについては、まず次の質問について考えておく必要がある。

• 夜中にシステムがダウンした瞬間に、DevOpsチームが目を覚ますことは重要か
• 大規模な停止の発生から例えば2分後に、アラートを受けられればよいのではないか
• 接続状態の一時的な変動や、急な変化の継続を把握するため、そのたびに本当にたたき起こされたいか
• パフォーマンス問題を全体として追跡し、それらを関連付けて、必要な変更措置を見いだす方が効果的ではないか

　インスタントアラートは確かに便利だが、より重要なのはアラートが適切に届くようにすることだ。最も早くアラートを受けるのは行動を取る態勢が最も整っている人々になるようにすれば、問題解決にかかる時間が減る。アラートの階層化は、SLAを守るためにアップタイム時間の比率を高める上で最も確実だ。

　そもそもエラー予算を確保していれば、インスタントアラートの必要性は少なくなる。障害の許容範囲が定められているからだ。

誤解7　ネットワークは最適化に関係しない

　この誤解は見落としやすい。だが、ネットワークは、ユーザーのシステムへの接続やシステムのパフォーマンス、全体的なコンテンツ提供を大きく左右する。

　ネットワークプロバイダーを選ぶ際には、エンドユーザーのために処理すべき負荷に対応できる複数のプロバイダーを十分調査し、比較検討しなければならない。ホスティングやコンテンツ提供のためにどのプロバイダーを選ぶのかは、非常に重要な意味を持つ。

　調査しなければならない要素の一つは、プロバイダーが配置したサーバの数だ。サーバが多ければ、コンテンツ提供がよりユーザーに近い場所から行われる可能性が高い。

　通信速度については、現行のプロバイダーと同等の水準が求められる他、規模の大小にかかわらず、負荷が同じように効率的に処理される必要がある。

おまけ　年間数時間のダウンタイムが発生しても、何も失われない

　この考え方が間違っている証拠は多くあるのだが、誤解として根強い。ダウンタイムが長引くほど損失も拡大してしまう。問題はその金額がいくらになるかだが、定量化は難しい。それでも、売上高が公表されている企業について、その数字を基に計算できる。例えば、ダウンタイム10時間当たりのコストを試算しよう。業界別に単位時間当たりのコストを割り出し、自社の数字をこれと比較するといったことも可能だ。

　いずれにしても、こうした損失を軽減し、ダウンタイムを必要最小限にとどめ、顧客接点インフラの可用性を継続することが重要だ。