「3時間ダウン」なのに可用性98%？ 可用性パーセントの読み方
まとめ
- 可用性パーセントは「不安定だった時間の幅」ではなく「その間に実際に失敗した割合」を表す。断続障害だとこの2つは大きくずれる
- 障害の実効ダウン ≒ 障害が続いた窓の幅 × その窓での失敗率。3時間36分の窓でも失敗率が1割なら実効ダウンは20分台になる
- 可用性の測り方は時間ベースと成功率ベースの2系統。等間隔で叩く外形監視(Synthetic)の成功率は、実質「時間ベースの可用性の近似」になる
- 「1日◯%」を月次の指標に直すときは、手計算で希釈するより集計クエリの期間を月に広げて直接測るほうが正確。他の障害日も自然に織り込まれる
「3時間不安定」なのに可用性98%になる理由
障害対応のあと、ポストモーテムには「顧客影響 約3時間36分」と書いた。ところが監視ツールの可用性を見ると 98.26% と出ている。24時間の 98.26% はダウン換算で約25分だ。3時間36分と25分、どちらが正しいのか。
答えは「どちらも正しい。指しているものが違う」。
- 3時間36分 は、エラー（502 など）が出たり出なかったりしていた時間帯の幅
- 約25分 は、その間に実際に失敗したぶんを「完全ダウン相当」に換算した量
障害中ずっと全断していたわけではなかった。オートスケールが次々にインスタンスを入れ替えて容量を維持しようとしていたので、生きているサーバに当たったリクエストは成功していた。だから窓は長くても、失敗したのは一部にとどまる。
この関係は式にできる。
実効ダウン ≒ 障害が続いた窓の幅 × その窓での失敗率窓が3時間36分（216分）、その間の失敗率が11.4%なら、実効ダウンは 216 × 0.114 ≒ 24.6分。24時間に対して約1.7%、つまり可用性98.3%あたりに着地する。別々に出した「窓の幅×失敗率」と「24時間の成功率」が近い値に落ちるのは、両方とも同じ実効ダウンを別角度から見ているからだ。
もし本当に3時間36分ずっと全断していたなら、可用性は (24 - 3.6) / 24 ≒ 85% まで落ちる。98%で収まったこと自体が「断続的だった」ことの裏付けになる。
可用性の測り方は2系統ある
可用性の数字を受け取ったら、まず「どっちの流派で測ったものか」を確認する。ここを揃えないと議論が噛み合わない。
| 時間ベース (uptime) | 成功率ベース (success rate) | |
|---|---|---|
| 定義 | アップしていた時間 ÷ 総時間 | 成功リクエスト ÷ 全リクエスト |
| 得意な文脈 | 単一サーバ、ホスティングSLA、契約上の稼働率 | 分散システム、SLO、部分障害が普通な環境 |
| 断続障害の扱い | 「落ちていた時間」を数える（定義が曖昧になりがち） | 失敗した割合をそのまま数える |
ホスティングやクラウドの契約でよく見る「稼働率 99.9%」は時間ベースが主流。一方でSREの世界でSLOを組むときは、成功率ベース（成功したリクエストの割合）を使うのが標準的だ。分散システムでは「一部のノードだけ落ちる」が日常なので、時間ベースだと表現しづらい。
「稼働率」という言葉は語感としては時間ベース寄りだが、実際に数字を出しているツールが成功率ベースということはよくある。名前と中身がずれていないか、必ず定義に当たる。
外形監視の成功率は「時間ベースの近似」になる
ここが引っかかりやすいところだった。手元の可用性は、こういうクエリで出していた（監視名は伏せた）。
SELECT percentage(count(*), WHERE result = 'SUCCESS')
FROM SyntheticCheck
WHERE monitorName = '<your-monitor>'これは合成監視(Synthetic monitoring)のチェック成功率だ。一見すると成功率ベースに分類したくなる。でも外形監視は一定間隔でサービスを叩く。実ユーザーのトラフィック量では重み付けしていない。時間を均等にサンプリングしているだけだ。
だから、この成功率は実質「時間ベースの可用性の近似」になる。1分間隔で叩いていれば1日1440回、そのうち1.74%が失敗＝約25回失敗＝時間換算で約25分ダウン、ときれいに対応する。トラフィックが多い時間帯の失敗を重く数えたりはしない。
- 実ユーザーのリクエストログから成功率を出す → トラフィック加重の成功率ベース
- 等間隔の外形監視から成功率を出す → 時間ベースの近似
同じ「成功率」でも母数が違うと意味が変わる。「サーバー稼働率」のような時間ベース寄りの指標名なら、外形監視の成功率はむしろ相性がいい。
「1日◯%」を月次で語るなら期間を広げて直接測る
障害があった日の可用性が 98.26% だとして、これを月次の指標として1つ報告したいとき。つい「1日ぶんのダウンを月全体に薄める」手計算をしたくなる。
月次(30日) = (43,200分 - 25分) / 43,200分 ≒ 99.94%この計算は「障害日以外は全部100%だった」という仮定が入っている。しかし同種の障害が別の日にも起きていたら、その失敗ぶんが月次には含まれるべきで、手計算では抜け落ちる。
素直なのは、可用性を出したのと同じクエリの集計期間を月に広げることだ。
SELECT percentage(count(*), WHERE result = 'SUCCESS')
FROM SyntheticCheck
WHERE monitorName = '<your-monitor>'
SINCE '2026-06-01 00:00:00' UNTIL '2026-07-01 00:00:00'こうすれば月内の全チェックを集計エンジンが数えてくれる。他の障害日も自然に織り込まれた「本当の月次値」が一発で出るし、仮定を挟まないぶん報告用の一次データとしても筋がいい。手で希釈するのは、集計期間を変えられないときの最後の手段くらいに考えておく。
持ち帰り
可用性パーセントを見たら、報告する前に3つ確認する。
- 分母は何か 。時間か、実リクエストか、外形監視か。母数が違えば同じ「98%」でも意味が変わる
- どの期間の集計か 。1日か1ヶ月か。期間は数字と必ずセットで語る
- 窓の幅と実効ダウンを混同しない 。「N時間不安定」と「可用性X%」は別物で、
窓の幅 × 失敗率で橋渡しできる
数字そのものより、「何を分母に、どの期間で測ったか」を一緒に出すほうが、受け手は判断しやすい。可用性%は、単体だと意外と何も言っていない。SLI/SLOの設計まわりはNew Relic ハンズオン: SLI/SLO の設計の基本でも触れている。