- サーバーやシステムが停止してサービスを利用できなくなる時間のこと。計画的なメンテナンス停止と突発的な障害による停止の2種類がある
- ITIC 2021年の調査によると大企業の18%でダウンタイム1時間のコストが500万ドルを超えると報告されており、可用性の維持はビジネスの死活問題になりつつある
- SLA（サービスレベル契約）では年間稼働率99.9%（いわゆるスリーナイン）が一般的な水準で、これは年間8.76時間のダウンタイム許容を意味する
【深掘り】これだけ知ってればOK！
ダウンタイムには明確に2種類がある。計画ダウンタイムはOSパッチ適用・ハードウェア交換・データベースのバージョンアップなど、事前にスケジュールして実施する停止だ。ユーザーへの事前告知が可能なため、影響を限定しやすい。一方の計画外ダウンタイムはハードウェア障害・ソフトウェアのバグ・サイバー攻撃・自然災害・オペレーションミスなどによる予期しない停止で、対応が後手に回りやすく損害が拡大しがちだ。
コスト面の影響を具体的に見てみると、ECサイトではダウン中に購入できなかった分の売上が直接的な損失になる。さらに間接的には顧客の信頼失墜・ブランドイメージの棄損・SLA違反による賠償・インシデント対応の人件費という複数の損失が積み重なる。特に月末・年末・キャンペーン期間中のダウンは通常の何倍もの損害につながるという点は押さえておきたい。
SLAの稼働率数字は一見わかりにくいが、年間ダウンタイムに換算すると実態が見えてくる。99%なら年間87.6時間、99.9%なら8.76時間、99.99%なら52.6分、99.999%なら5.26分だ。クラウドサービスを選定する際は稼働率の数字だけでなく、「ダウンタイムが発生したときのサポート体制と補償内容」もSLAで確認することが重要だ。
よくある誤解
稼働率99%なら十分安定していると思いがち
99%と聞くと安心しがちだが、年間にすると87.6時間もダウンできることを意味する。本番サービスで「99%」を提案されたら、実際の停止時間に換算して判断することが重要だ。
SLAの稼働率がサービス全体の可用性を保証すると思っている
SLAで定義される稼働率の計測対象は多くの場合、主要機能の一部に限られる。計画メンテナンス時間・一部ユーザーのみに影響した障害・クライアント側の問題はSLAのダウンタイムに含まれないケースが多い。SLAの細則を読まずに「99.99%だから安全」と判断するのはリスクがある。
会話での使われ方
今月のダウンタイム、合計で3時間超えてます。SLAの99.9%を割り込むペースなので、インシデント報告書を月内に出してください。
インフラチームのリーダーが担当者に月次振り返りミーティングで指示している場面。SLA違反の可能性を数値で示して対応を求めている。
クラウド移行の選定基準、ダウンタイムのコストを試算してから決めた方がよくないですか？今のオンプレの年間障害時間を見ると、移行コストより損失の方が大きい気がします。
情報システム部の担当者が役員会議でクラウド移行の費用対効果を議論している場面。ダウンタイムコストの試算を意思決定の根拠に使っている。
今夜の定期メンテ、計画ダウンタイムで2時間見てますがユーザーへの告知はもう出ましたか？
運用担当者がメンテナンス前日にSlackでコミュニケーション担当に確認している場面。計画ダウンタイムはユーザーへの事前告知がセットで必要になる。
【まとめ】3つのポイント
- 計画か計画外かで対応コストが大きく変わる：計画ダウンタイムは告知と準備で影響を最小化できるが、計画外ダウンタイムは発見の遅れが損害を加速させるため監視体制が鍵になる
- 稼働率は年間ダウンタイム時間に換算して判断する：99%は年間87.6時間、99.9%は8.76時間、99.99%は52.6分と覚えておくと、SLAの数字が体感で理解できるようになる
- 冗長構成とフェイルオーバーがダウンタイム対策の中核：アクティブ・スタンバイ構成とDR訓練の組み合わせが可用性を高める基本設計で、クラウドのマルチAZはその自動化実装にあたる
よくある質問
- QSLAのダウンタイムに含まれないケースはどんなものですか？
- A
多くのSLAでは計画メンテナンス時間・不可抗力（自然災害など）による停止・クライアント側の設定ミスや環境に起因する問題・一部ユーザーのみに影響した局所的な障害がダウンタイムの計測から除外されます。SLAを結ぶ前に計測方法と除外条件を必ず確認することをお勧めします。
- Qダウンタイムを自動検知するにはどうすればいいですか？
- A
外部から定期的にHTTPリクエストを送って応答を確認する死活監視ツールが一般的です。Datadog・New Relic・Pingdom・UptimeRobotなどが代表的なサービスで、応答が返ってこない場合にSlackやメールへ即時通知する設定ができます。クラウド環境ならAWS CloudWatchアラームやGCPのUptime Checkを使う方法もあります。
- Q定期メンテナンスを深夜に行う理由は何ですか？
- A
アクセスが最も少ない時間帯に実施することで、影響を受けるユーザー数を最小限に抑えるためです。ただし深夜メンテナンスはエンジニアの体力的負担が大きく、疲弊からミスが増えるリスクもあります。CI/CDとゼロダウンタイムデプロイが整備されれば昼間でも安全に作業できるため、長期的には仕組みで解決することが理想です。
- Qダウンタイムとレスポンスタイムの違いは何ですか？
- A
ダウンタイムはシステムが完全に停止して応答できない時間を指します。レスポンスタイムはシステムが動いてはいるものの、リクエストへの応答が遅くなっている状態を測る指標です。SLAでは両方を別々に定義することもあります。
【出典】参考URL
https://www.docusign.com/ja-jp/blog/what-is-SLA-Service-Level-Agreement ：SLAとダウンタイムの関係の解説
https://www.sat-corp.jp/glossary/downtime ：ダウンタイムの基本定義
https://bcblog.sios.jp/minimizing-downtime-with-high-availability/ ：ダウンタイムコストと高可用性構成の解説
コメント