1 ダウンタイムの基本
1.1 定義と関連用語
ダウンタイムは、システムやサービスが利用不能となる、あるいは性能が著しく低下して業務遂行や利用が実質的に困難になる状態が継続する時間を指す。情報通信の文脈では、サーバやネットワーク、アプリケーション、クラウド基盤の停止だけでなく、機能制限や応答遅延が継続する場合も範囲に含まれることが多い。
関連用語として、可用性（availability）は「要求したときに利用できること」の度合い、稼働率（uptime）は停止がどれだけ少なかったかを表す指標である。障害（incident/defect）は原因の所在を問わずサービス品質に悪影響を与える事象を意味し、障害対応（incident management）はその回復と再発抑制を目的とする一連の運用活動を指す。計測・契約の観点では、停止時間に加えて性能劣化をどこまで「ダウン」とみなすかを合意する必要がある。
1.2 稼働率・可用性との関係
稼働率は、一定期間における停止の少なさを割合で示す考え方であり、可用性は「利用要求に対して応答できる状態であるか」をより広く捉える概念として用いられる。実務では両者は相互に関連し、特にSLAや運用目標では可用性を定義し、それを稼働率や停止判定、さらに性能条件と組み合わせて運用する。
ダウンタイムは「時間」という性質を持つため、可用性設計の際には、完全停止だけでなく「応答が遅すぎる」「一部機能しか使えない」といった劣化も、利用者の体感に照らしてどの条件で計上するかを定めることが重要となる。
1.2.1 稼働率の代表的な指標
代表的には、全期間に対する稼働時間の比率、または特定区間における停止時間の合計から算出する指標が用いられる。加えて、ユーザー影響の観点で「重大停止（major outage）」として区分し、軽微な不具合や短時間の再試行可能な劣化を分ける運用もある。
また、運用では保守停止を除外するか含めるか、メンテナンスウィンドウをどの扱いにするかが論点になりやすい。指標の定義が曖昧だと、同じ事象でも「達成」「未達成」の解釈が分かれるため、定量の前提条件を明示することが求められる。
1.2.2 可用性設計の考え方
可用性設計では、まず「利用者の要求」の粒度を決める。例えば、応答が一定秒以内で返ること、重要操作が成功すること、データ整合性が破綻しないことなど、利用シナリオに直結する条件を基準として設計する。次に、その条件を満たせなくなる状態をダウンタイムとして扱う範囲を定める。
設計上は、単純な冗長構成の導入にとどまらず、切替の時間、失敗時の挙動、部分障害の扱い、復旧後の整合性確認などを含む「運用可能性」を見込む。可用性は技術要素だけで決まらず、手順、監視、権限、意思決定の速さも含めた総合性能として整理される。
1.3 対象範囲（システム／サービス／ユーザー体験）
ダウンタイムの対象範囲は、構成要素の階層で分けて考えると整理しやすい。最下層ではホストや仮想マシン、ネットワーク機器などの停止、ミドル層ではアプリケーションやデータベースの停止・応答劣化、上位層ではサービスの機能が利用できない状態が該当する。
さらに、ユーザー体験（UX）の観点では、同じ基盤の不調でもユーザーが感じる影響は一様ではない。例えば、全体の平均レイテンシが小さく見えても、一部地域や特定操作だけが遅い場合、実利用においては実質的な停止に近いと判断されることがある。したがって、計測点と判定条件は、体験に近い形で定義されることが望ましい。
2 種類と分類
2.1 障害によるダウンタイム
障害によるダウンタイムは、意図しない停止や致命的な不具合によってサービスが利用できなくなるケースである。原因の性質や発生タイミングに応じて、計画停止と突発停止に分けて整理されることが多い。
2.1.1 計画停止
計画停止は、事前に手順と影響範囲を告知し、合意された時刻に実施される停止である。例として、ソフトウェアのアップデート、構成変更、容量拡張、保守点検などが該当する。計画停止はダウンタイムを含む場合があるが、運用目標や契約指標では除外・控除の扱いを定めることで、評価の公平性を確保する。
計画停止の鍵は、復旧目標時間（RTO）や復旧手順、切替計画、ロールバック方針、必要な連絡経路を事前に確立する点にある。さらに、影響を最小化するために、段階投入や対象の限定、利用時間帯の調整などの工夫が行われる。
2.1.2 突発停止
突発停止は、予告なしに発生する停止であり、設備障害、ソフトウェア不具合、設定ミス、人的操作の誤りなど多様な要因が考えられる。短時間で収束することもあれば、復旧に時間を要する場合もある。特にクラウドや分散システムでは、単一要素の障害が波及して広範な影響を生むことがある。
管理では、検知から影響把握、切り分け、暫定復旧、恒久対策の順に進めるのが一般的である。突発停止の評価では、停止時間だけでなく、復旧までの探索・判断に要した時間も含めて改善対象として扱うことが多い。
2.2 性能低下によるダウンタイム
性能低下によるダウンタイムは、システムが「動いている」ように見えても、応答性や処理能力が不足して利用が成立しない状態を含む。遅延や詰まりが蓄積すると、タイムアウトや失敗率の上昇を通じて、実質的な停止に近い体験が生まれる。
2.2.1 レイテンシ増大
レイテンシ増大は、要求から応答までにかかる時間が増えることで発生する。原因として、リソース枯渇（CPU、メモリ、I/O）、データベースの待ち行列、ネットワーク混雑、外部依存サービスの遅延などが挙げられる。増大の程度によっては、ユーザーは「遅い」だけに見えるが、実務上は予約や決済のような操作でタイムアウトが増え、結果として成功率が下がる。
管理上は、平均値では隠れるばらつきを考慮し、分位点（例えば中央値や高分位）や特定操作の遅延を監視対象にすることが有効となる。
2.2.2 スループット低下
スループット低下は、単位時間あたりに処理できる要求数が減る状態である。負荷増大、同時接続の増加、バックエンドのボトルネック、キュー滞留などが原因となり得る。スループットが下がると、処理待ちが増えてレイテンシも連鎖的に悪化し、結果としてタイムアウトやリトライの増加がさらに負荷を押し上げる。
対策では、ボトルネック特定のための観測点（アプリ内指標、データベース指標、周辺サービス指標）を用意し、ボリュームに対してどこが限界に達するかを分析することが重要になる。
2.3 外部要因による影響
外部要因による影響は、システム内部の変更や障害に限らず、周辺環境の不調によってサービス品質が悪化するケースを指す。原因が外部にある場合、責任分界や復旧時期の見通しが難しくなりやすい。
2.3.1 ネットワーク障害
ネットワーク障害は、経路の切断、遅延の異常、パケット損失、DNSの不調、帯域不足などとして現れることがある。通信が不安定だと、接続確立に失敗したり、再送の増加によりアプリの応答が遅れたりする。
対策としては、冗長経路、タイムアウトと再試行の設計、クライアント側の挙動制御、障害時の切替方針の整備がある。さらに、監視はネットワーク層とアプリ層の両方で行い、問題の所在を推定しやすくする。
2.3.2 電力・設備・通信事業者要因
電力設備の不具合、冷却機能の問題、収容施設の環境変動、通信事業者の回線障害なども、サービスに直接あるいは間接的に影響する。データセンター運用では冗長電源や非常用電源が整備されることが多いが、切替が間に合わない場合や、局所的に復旧が遅れる場合がある。
外部要因では、内部の復旧手順だけでは完結しないため、契約に基づく対応窓口、復旧見込みの共有、影響範囲の暫定評価を運用計画に組み込むことが求められる。
3 計測と管理
3.1 ダウンタイムの計測方法
計測では、まず「ダウンの判定条件」を定める。完全停止か、性能劣化か、一部機能の利用不能か、あるいはユーザー操作の成功率低下まで含めるかを決め、ログや監視データから再現可能な形で判定できるようにする。
次に、計測の粒度を揃える。時間の丸め方、対象サービスの範囲、影響が発生した時刻と復旧した時刻の定義を統一しないと、集計結果がぶれる。実務では、検知時刻と復旧時刻を同一の根拠データに基づけ、後から調整が入りにくい仕組みにすることが望ましい。
3.2 影響の見積もり（範囲と優先度）
影響見積もりでは、技術的な停止範囲だけでなく、業務・利用者への影響を階層化する。例えば、主要な決済やログインの可用性が落ちたのか、参照系の遅延に留まるのかで優先度は変わる。重要度が高い経路ほど復旧の順序も早くする必要がある。
見積もりには、利用統計（アクティブユーザー、操作頻度）、依存関係（外部API、データ更新系）、影響の広がり（地域、テナント、顧客契約）を組み合わせる。暫定的にでも優先度を出すことで、復旧作業の判断が速くなる。
3.3 監視・アラート設計
監視・アラート設計では、検知の早さと正確さ、運用負荷を同時に満たす必要がある。監視対象はインフラ、アプリ、外部依存、そして利用体験に近い指標まで含め、単一の数値に依存しない構成にする。
アラートは、誤検知が多いと無視され、逆に見逃しが多いと復旧が遅れる。したがって、閾値、継続時間、抑制条件、通知先、対応手順へのリンクといった設計要素を整理して運用に組み込む。
3.3.1 SLIとSLOの位置づけ
SLI（Service Level Indicator）は、サービス品質を表す観測可能な指標である。例えば、成功率、応答時間の分位、処理完了までの時間などが該当する。SLO（Service Level Objective）は、SLIがどの水準にあるべきかを期間とともに定める目標で、ダウンタイム管理の基準として機能する。
運用では、SLOを満たさない兆候をアラートとして扱う「エラーバジェット」の考え方が用いられることがある。これにより、単発の逸脱ではなく、継続的な劣化を早期に捉えて改善へつなげられる。
3.3.2 アラートの誤検知・見逃し対策
誤検知対策としては、閾値の妥当化、指標の分布に基づく設計、季節性や計画停止の影響を考慮した抑制がある。短時間の揺らぎに反応しすぎると通知頻度が増えるため、継続条件や相関確認を導入するのが一般的である。
見逃し対策では、重要経路に対する観測の補完が重要になる。ログのみ、監視のみといった偏りを避け、ユーザー影響に近いデータと、原因候補に直結する内部指標を併用することで、問題の所在を見失いにくくする。
4 対策と復旧
4.1 予防策（止まらない仕組み）
予防策は、ダウンタイムの発生確率を下げるだけでなく、発生しても拡大しにくい設計を含む。止まらない仕組みは、技術的な冗長化と、運用の整合性、変更管理の質によって成立する。
4.1.1 冗長化とフェイルオーバー
冗長化は、単一障害点を減らす目的で、複数の計算資源、複数経路、別系統のバックエンドなどを用意する考え方である。フェイルオーバーは、障害が検知された際に別系統へ切り替える手順を指す。ここで重要なのは、切替そのものが確実に成立することに加え、切替時間が許容範囲に収まること、データ整合性が維持されることだ。
設計では、切替条件の定義、スプリットブレインの回避、再切替の抑止なども検討対象となる。自動化する場合は、人の判断が不要になるのか、最小限の承認が必要なのかを明確にする。
4.1.2 キャパシティ設計と負荷対策
キャパシティ設計は、需要予測に基づいて必要な計算資源や帯域を見積もり、ピーク時でも品質目標を満たすように余裕を持たせる取り組みである。負荷対策には、自動スケール、キューイング、バッチ化、レート制限、キャッシュの活用などが含まれる。
負荷の急増は、単にCPUやメモリの不足だけでなく、外部依存の遅延によって内部待ちが増える形で現れる。したがって、ボトルネックの種類を事前に分類し、どの経路を優先的に保護するかを決めることが有効となる。
4.2 発生時の対応（止める・戻す）
発生時の対応は、状況を悪化させない「止める」判断と、サービスを回復させる「戻す」作業を同時に成立させることが目的である。作業の順序は事象により変わるが、まずは影響の範囲を抑える暫定対応を優先することが多い。
4.2.1 インシデント対応手順
インシデント対応手順は、初動から復旧までを定型化し、判断のぶれを減らすための枠組みである。通常は、検知、一次調査、影響評価、優先順位付け、暫定復旧、恒久復旧、事後確認の段階で進める。
初動では、誤った変更を連打しないことが重要になる。通信が断続的に切れる場合や、負荷が急騰している場合には、ログの読み取りと観測データの確認を並行させ、原因候補を絞る。そのうえで、サービスへの需要を調整したり、限定的に機能を停止して安定化を図るなどの戦術が検討される。
4.2.2 ロールバックと段階的復旧
ロールバックは、不具合が特定の変更に関連している場合に、以前の安定状態へ戻す手段である。段階的復旧は、全体を一気に再開せず、機能や地域、テナント単位などで段階的に戻して品質を確認する方法である。
段階的復旧では、戻した後に観測指標が目標水準に回復するか、障害の再発兆候が出ていないかを確認しながら進める。これにより、復旧直後の再障害やデータ破損のリスクを抑えられる。ロールバックと復旧確認の手順は、事前に実施可能な形で整備し、責任分担と必要な権限を明確にしておくことが望ましい。
4.3 再発防止と改善
再発防止と改善は、同種のダウンタイムを減らすための学習活動であり、技術だけでなく運用プロセスにも踏み込む。復旧が完了した後に、原因の理解と次の行動を具体化することで、単なる検討で終わらない仕組みを作る。
4.3.1 原因分析（再現性と根本原因）
原因分析では、再現性の評価と根本原因の特定を行う。単に「どこが壊れたか」を示すだけでなく、なぜその状態が起きたのか、どの統制（設計、テスト、変更管理、監視）が機能しなかったのかまで掘り下げることが重要となる。
根本原因分析には、時系列の整理、変更履歴の照合、ログとメトリクスの突合、関係者ヒアリングなどの手法が用いられる。可能であれば、類似条件での再現実験を行い、再発の条件を明確化することで、対策の優先度が合理的に決まる。
4.3.2 運用改善（手順・教育・監視強化）
運用改善は、手順の更新、教育の実施、監視と計測の拡充などを通じて、将来の事故を減らす。手順は、インシデント対応の判断基準、コミュニケーションの流れ、チェックリストの具体化を含めて改訂される。
教育は、担当者の経験差を埋めるために、過去事例の学習や演習により判断と操作を標準化する。監視強化では、今回見えなかった指標を追加し、アラートの質を改善する。結果として、次の障害時により早い切り分けと、より確実な復旧が可能になる。