SLAとサポートの違い：稼働率だけでサーバーを選ばない

保証対象の単位を読む

サービス全体、特定構成、単体インスタンスでは保証条件が異なることがあります。実際に契約する構成が保証の対象かを確認します。AWS Computeの公式SLAでも構成により区分が設けられており、数字だけを他社と並べる比較では前提を落とします。

稼働率と復旧目標を分ける

稼働率は一定期間の利用可能性を示す指標で、RTOは障害後の復旧目標です。高い稼働率表示があっても、任意の障害が必ず短時間で直るという意味にはなりません。業務側が許容できる停止時間から、代替手段や冗長化の要否を検討します。

受付・初動・解決を区別する

24時間受け付ける窓口でも、調査の開始、技術者の対応、アプリの修正範囲は別です。自社で情報を集める担当がいなければ、問い合わせ自体が遅れます。重要度の定義、連絡方法、必要な契約、一次切り分けの責任を見積もり時に確認します。

申請できる証跡を残す

障害の開始と終了、対象環境、問い合わせ番号、事業者の通知を保存します。返金やサービスクレジットの方式、申請期限、対象外の条件は個別契約で確認します。本稿は契約条項の解釈や補償を保証するものではなく、技術選定時の確認観点です。

契約書では計測対象のサービス、除外される停止、申請期限、必要な証跡を確認します。例えばWebサーバーの稼働率が対象でも、DNSやアプリの不具合は別扱いの場合があります。自社が困る停止がどの条項に該当するかを、具体例で事業者へ質問します。

導入・見直しのチェックリスト

• 契約予定の構成が保証対象ですか。
• 受付時間と技術対応時間を確認しましたか。
• 停止時の社内判断者と代替手段を決めましたか。