サーバーの稼働率とは、サービスを利用できた割合
サーバー分野の稼働率（availability / uptime）は、定義した測定期間または有効なリクエスト全体に対して、サービスが利用可能だった割合です。
日本語の「稼働率」は、製造設備やCPUがどれだけ使われているかという利用率の意味でも使われます。この記事では、レンタルサーバーやWebサービスの可用性を示す稼働率に限定します。重要なのは、サーバー機器の電源が入っていることではなく、利用者が必要な機能を正常に使えることです。監視用のpingだけ成功していても、Webページが500エラーになり、ログインや決済が失敗するなら、利用者視点では利用可能とは言えません。
時間基準の稼働率
1か月などの期間のうち、定義したサービスが利用可能だった時間の割合です。連続停止を分単位で集計しやすい一方、利用者が少ない時間と多い時間を同じ重みで数えます。
リクエスト基準の稼働率
正しく形成された有効なリクエストのうち、成功したリクエストの割合です。部分障害や負荷変動を反映しやすい一方、成功と数えるステータス、遅すぎる応答、対象エンドポイントを定義する必要があります。
「サーバーは動いている」と「サービスを使える」は同じではない
DNS、ネットワーク、TLS証明書、データベース、アプリケーション、外部APIのどこかが失敗すると、機器自体は起動中でも利用者の操作は失敗します。測定対象をホストの死活だけにせず、公開ページ、ログイン、検索、購入など重要な利用経路に合わせてください。
時間基準とリクエスト基準の計算式
Google SREは、時間を基準にする方法と、成功したリクエストを基準にする方法を示しています。どちらを使う場合も、分子と分母に含める条件を先に固定します。結果の小数点以下を丸めると、許容停止時間の差が隠れるため、SLA判定では契約に定めた精度を使います。
時間基準
（測定期間 − 定義した利用不能時間）÷ 測定期間 × 100
30日間で43.2分利用不能なら、（43,200分−43.2分）÷43,200分×100＝99.9%です。
リクエスト基準
成功した有効リクエスト数 ÷ 有効リクエスト総数 × 100
100万件の有効リクエストのうち99万9,000件が成功なら、999,000÷1,000,000×100＝99.9%です。
30日間で99.9%を計算する
- 1測定期間を30日と決めます。30日×24時間×60分＝43,200分です。
- 2監視記録から、定義に合う利用不能時間を合計します。例では43.2分とします。
- 3利用可能時間は43,200分−43.2分＝43,156.8分です。
- 443,156.8分÷43,200分×100＝99.9%です。
逆算では、43,200分×（1−0.999）＝43.2分です。この値は目標から算出した許容不能時間相当であり、停止予定や実績を示すものではありません。
99%から99.999%までの停止時間換算
月は30日、年は365日と固定して算出します。月の日数やうるう年を混ぜると比較できないため、前提を表題や注記に残してください。次の値は、期間×（1−稼働率）で求めた算術上の利用不能時間です。
表は横にスクロールして、30日と365日の差を比較できます。
| 稼働率 | 30日（43,200分） | 365日（525,600分） | 読み方 |
|---|---|---|---|
| 99% | 7時間12分 | 3日15時間36分 | 100分の1が利用不能時間相当 |
| 99.9% | 43分12秒 | 8時間45分36秒 | 1,000分の1が利用不能時間相当 |
| 99.95% | 21分36秒 | 4時間22分48秒 | 2,000分の1が利用不能時間相当 |
| 99.99% | 4分19.2秒 | 52分33.6秒 | 10,000分の1が利用不能時間相当 |
| 99.999% | 25.92秒 | 5分15.36秒 | 100,000分の1が利用不能時間相当 |
「9」が一つ増える差は、単純な見た目以上に大きい
99.9%と99.99%では、30日換算の利用不能時間が43分12秒から4分19.2秒へ約10分の1になります。ただし、高い目標値だけで実績が決まるわけではありません。測定対象、監視方法、冗長構成、復旧手順、障害履歴も併せて評価します。
稼働率を測る前に固定する6つの条件
稼働率は測定仕様から作られる数値です。事業者比較でも社内運用でも、次の条件が違う値を同じ表へ並べないでください。公開SLAだけで不明な項目は、利用規約、サービス仕様、サポートへ確認します。
測定期間
暦月、連続30日、四半期、365日などを明示します。月ごとのSLAを年間値へ単純平均すると、各月のリクエスト数や日数の差を反映できない場合があります。
対象範囲
サービス全体、特定リージョン、契約アカウント、仮想サーバー、エンドポイントのどれを測るか決めます。DNSや管理画面が対象外なら、その影響も別に見ます。
成功条件
HTTPステータスだけでなく、応答時間、内容の正しさ、ログインや保存の完了を定義します。遅すぎて実用にならない応答を成功に含めるかも決めます。
除外条件
計画メンテナンス、不可抗力、利用者設定、上流事業者などの扱いを確認します。計画停止を分母から除くのは、指標または契約がそう定める場合だけです。
部分障害の集計
利用者の10%だけが失敗した時間を、全停止とするか、失敗リクエスト割合で重み付けするか決めます。時間基準だけでは影響人数を表しにくい点に注意します。
観測地点と証拠
事業者内部監視、外形監視、利用者ログのどれを正とするか決め、時刻、リージョン、エラー、継続時間を保存します。単一地点の通信障害をサービス全体の停止と誤認しない構成にします。
部分的な利用不能にはリクエスト基準が役立つ
全利用者が同時に止まるとは限りません。一部リージョン、一部API、一定割合のリクエストだけが失敗する場合、成功リクエスト数を基準にすると影響を連続的に表せます。ただし、重要度の異なる操作を一括集計すると、件数の多い軽い操作が決済など重要機能の障害を隠すため、利用経路ごとのSLIも併用します。
稼働率とSLI・SLO・SLA・関連概念の違い
似た言葉は、測るもの、目標、契約、設計特性という役割が異なります。Google SREの整理では、SLIが定量指標、SLOがその目標、SLAが不達時の扱いを含む合意です。稼働率はSLIとして使われますが、目標値や契約そのものではありません。
| 用語 | 何を表すか | 稼働率との違い |
|---|---|---|
| SLI | サービス水準を測る定量指標。成功リクエスト率、遅延、正しさなど。 | 稼働率はSLIの一種になり得ます。SLIには必ず測定方法と対象イベントの定義が必要です。 |
| SLO | SLIに対して設定する目標値または目標範囲。例：30日で99.9%以上。 | 実測値ではなく目標です。実測99.92%とSLO 99.9%を同じ「稼働率」と呼ぶと達成状況が分かりません。 |
| SLA | サービス水準と、不達時のサービスクレジットなどの扱いを定める契約上の合意。 | 実績の保証値そのものではありません。算定式、除外、請求期限、救済内容まで含めて読みます。 |
| エラーバジェット | SLOから許容される失敗量。基本形は1−SLO。 | SLO 99.9%なら0.1%が予算です。残量を変更速度と信頼性改善の判断に使います。 |
| 信頼性 | 一定条件と期間で、期待する機能を故障なく果たす性質。 | 稼働率は利用可能だった割合です。故障回数と復旧の速さが違っても、合計停止時間が同じなら同じ稼働率になり得ます。 |
| 冗長性 | 障害時に引き継げるよう、構成要素や経路を重複させる設計特性。 | 冗長性は可用性を高める手段です。切替失敗や共通原因障害があれば、冗長でも高い実績値になるとは限りません。 |
| 利用率・使用率 | CPU、回線、設備などの能力がどの程度使われているか。 | 高いほど良い指標ではなく、逼迫の兆候にもなります。サービスが利用可能だった割合とは別です。 |
| 耐久性 | 保存したデータが失われず保持される性質。 | サービスへ一時的に接続できなくてもデータは保持され得ます。逆にアクセス可能でもデータ破損があれば耐久性の問題です。 |
データセンターTierを固定の稼働率へ変換しない
Uptime Instituteは2009年にTier基準から「年間の予想停止時間」への言及を削除し、現行のTier Standard: TopologyはTierレベルへ可用性予測を割り当てないと説明しています。Tierは設備トポロジーの保守性・耐障害性などを扱う枠組みであり、特定サービスのSLAや実測稼働率と同一ではありません。「Tier IIIだから99.982%」のような固定換算で事業者を比較しないでください。
SLAの99.9%を比較する5つの手順
SLAは数字の大きさだけで選びません。AWS S3の公開SLAのように、月間稼働率の計算、サービスクレジット、適用条件、除外事項、請求手続きが別々に定められる例があります。契約するサービス自身の最新版を確認してください。
- 1
対象サービスと単位を確認する
Webサイト全体ではなく、ストレージ、仮想サーバー、リージョン、アカウントなど限定された単位かを確認します。DNS、CDN、データベース、利用中アプリが別契約なら、全体の可用性は一つのSLAだけでは決まりません。
- 2
計算式と測定期間を確認する
暦月か連続期間か、事業者側ログか外形監視か、エラー応答や遅延をどう数えるかを読みます。「99.9%」でも式が違えば結果は比較できません。
- 3
除外と計画メンテナンスを確認する
事前通知した保守、利用者の設定、外部ネットワーク、不可抗力、ベータ機能などが除外されるか確認します。除外が広いほど、利用者が経験した停止とSLA上の停止に差が出ます。
- 4
救済内容と申請条件を確認する
多くの公開SLAでは、不達時の救済は利用料金に対するサービスクレジットで、申請期限や証拠が必要です。自動付与か申請制か、次回請求へ充当するのか、上限はいくらかを確認します。
- 5
実測履歴と運用体制を別に確認する
SLAは過去実績ではありません。公式ステータス履歴、第三者または自社の外形監視、障害報告、復旧手順、バックアップと切替試験を確認し、事業継続に必要な対策を自社側でも持ちます。
サービスクレジットは、通常、事業損失の全額補償ではない
SLA不達による救済は契約条件に従います。利用料金の一部を将来の請求へ充当する形式でも、売上損失、従業員の待機、信用低下が自動で補償されるとは限りません。許容できない業務影響は、冗長化、バックアップ、代替手段、復旧目標、保険や個別契約を含めて別途設計してください。
確認した一次資料・公式資料
定義、計算、SLO、エラーバジェット、SLA、Tierの扱いは次の公式資料で確認しました。SLAはサービスごとに異なるため、契約前と障害申請時に対象サービスの最新版を確認してください。
サーバー稼働率のよくある質問
稼働率99.9%なら、1年間に停止するのは約52分ですか？
いいえ。365日換算の99.9%は8時間45分36秒です。約52分33.6秒になるのは99.99%です。さらに、これは除外なしで期間から逆算した算術上の利用不能時間相当で、実際の停止予定やSLA判定を示すものではありません。
99.9%と99.99%は、数字上ほとんど同じではありませんか？
許容される利用不能時間は約10分の1です。30日換算では99.9%が43分12秒、99.99%が4分19.2秒です。ただし、測定条件が異なるSLA同士は、この数字だけで比較できません。
計画メンテナンスは稼働率の計算から除外しますか？
一律には除外しません。社内SLIや契約SLAが計画停止をどう定義しているかに従います。利用者視点の実測値では計画停止も利用不能として把握し、契約判定用の値とは分けて持つ方法があります。
SLA 99.9%は、実際の稼働率が99.9%以上という保証ですか？
SLAはサービス水準と不達時の扱いを定める合意で、過去の実測値そのものではありません。算定範囲や除外条件のもとで基準を下回った場合に、サービスクレジットなどが適用される契約があります。実績は別に確認します。
データセンターがTier IIIなら、稼働率も決まりますか？
固定の割合には変換できません。Uptime Instituteは現行Tier Standard: TopologyがTierレベルへ可用性予測を割り当てないと説明しています。Tier分類、サービス設計、運用、アプリケーション、SLA、実績を分けて評価してください。
監視でサーバーへpingが通れば、稼働中と数えてよいですか？
重要なサービスの稼働確認としては不十分です。pingが成功しても、Webが500エラー、ログイン不可、データ保存失敗という状態は起こります。利用者が行う重要操作を外形監視し、成功条件と応答時間を定義してください。
可用性と運用を続けて確認する
稼働率は「何を、いつ、どこから、どう成功と数えたか」で読む
サーバー分野の稼働率は、サービスが利用可能だった割合です。まず時間基準かリクエスト基準かを決め、期間、範囲、成功条件、除外、部分障害、観測地点を固定してください。99.9%は30日で43分12秒、365日で8時間45分36秒の利用不能時間相当ですが、SLOやSLAは実測値とは役割が違います。SLA比較では数字だけでなく、算定式、除外、サービスクレジット、申請条件、実測履歴まで確認することが、誤解のない判断につながります。
この記事の確認体制
Finite Field 編集部
Google SREの可用性・SLI・SLO資料、AWSの公開SLA、Uptime InstituteのTier公式説明を照合し、期間換算を再計算して編集しています。契約条件は変更されるため、個別サービスのSLAは必ず公式最新版を確認してください。
Finite Fieldへ相談
監視指標・SLO・障害対応の設計を相談する
サーバー監視が死活確認だけになっている、重要操作のSLIを定義したい、SLOとエラーバジェットを運用判断へつなげたい場合は、対象サービス、利用者影響、現行監視、障害履歴を準備してください。
可用性と監視設計を相談する現在の構成と要件を確認したうえで対応可否をご案内します。無停止、特定の稼働率、復旧時間、損失回避を事前に保証するものではありません。