稼働率99.9%の中身を分解する
サーバー会社の案内に「稼働率 99.9%」と書かれている。契約前にその数字を見て、良さそうだと判断した。けれど実際には月に何度か、サイトが開かないという連絡が社内から来る。99.9% は嘘なのか、それとも自分の見方がずれているのか——という状況で読まれることを想定した記事です。
先に結論
- 99.9% は月あたり約 43 分の停止を許容する数字であり、「ほぼ止まらない」ではなく「月に 40 分台までは想定内」という意味です
- 稼働率は母数の定義でいくらでも変わります。何を分母に、何を「停止」と数えたのかを確認しない限り、数字どうしの比較は成立しません
- 停止の記録は、回数で見るか、止まっていた時間の合計で見るかで印象が変わります。短い停止が何十回あっても、数時間の停止 1 回のほうが稼働率を大きく下げることがあります
- サイト担当者にとって重要なのは年間の百分率ではなく、「1 回あたり何分止まり、その間に誰が気づき、誰が動いたか」です
99.9% が許している停止時間を、まず分に直す
数字を分に直すと印象が変わる
稼働率は百分率で書かれます。百分率のままだと、99.9% と 99.99% はどちらも「ほぼ 100%」に見えます。そこで、許容されている停止時間を分に換算します。
- 99.9% … 年間 約 8 時間 45 分 / 月 約 43 分 / 週 約 10 分
- 99.99% … 年間 約 52 分 / 月 約 4 分 / 週 約 1 分
- 99.5% … 年間 約 43 時間 48 分 / 月 約 3 時間 39 分 / 週 約 50 分
- 99% … 年間 約 87 時間 36 分 / 月 約 7 時間 18 分 / 週 約 1 時間 41 分
「9 が 3 つ並んでいる」という表現は印象が強いものです。しかし月 43 分の停止は、業務時間中に起きれば十分に気づかれる長さです。問い合わせフォームが 43 分開かなければ、社内から連絡が来ます。つまり「99.9% なのに止まった」のではなく、「99.9% は止まることを前提にした数字」だということになります。
小数点 1 桁の差は 10 倍の差
表を縦に見ると、9 が 1 つ増えるたびに許容停止時間が 10 分の 1 になります。99.9% と 99.99% の差は、見た目では 0.09 ポイントですが、月あたりの停止時間では 43 分と 4 分の差です。逆方向も同じで、99% は月あたり約 7 時間を許容します。この水準でも、案内文としては「高い稼働率」と書かれることがあります。
数字そのものより、小数点以下が何桁書かれているかを先に見る。それだけで、案内文の意味はかなり絞り込めます。
母数の定義で数字は変わる — 何を分母にしたのか
分母・分子・判定条件
稼働率は、次の 3 つが決まってはじめて計算できます。
- 分母となる期間（年単位か、月単位か。月単位なら 1 か月の悪い結果が翌月にリセットされます）
- 分子となる停止時間（どの時点から停止と数え、どの時点で復旧と数えるか）
- 停止の判定条件（何をもって「止まっている」と判断するか）
3 つめが特に動きます。ネットワーク機器が応答していれば稼働とみなす場合と、サーバーの OS が動いていれば稼働とみなす場合と、サイトが実際に HTML を返せたかどうかで判定する場合とでは、同じ実態から別の数字が出ます。判定条件が下の層にあるほど、稼働率は高く出ます。
計画停止を含めるか
もう一つ差が出るのが、計画メンテナンスの扱いです。事前に告知した停止を分子に含めない計算方法は一般的ですが、利用者から見れば告知の有無にかかわらずサイトは開きません。告知済みの停止を除いた 99.9% と、すべての停止を含めた 99.9% は、別の数字です。
母集団の取り方も同じです。管理下のすべてのサイトを分母にするのか、死活監視の対象としているサイトだけを分母にするのかで、集計の意味が変わります。母集団が違う数字どうしは、そのままでは比べられません。
停止の記録を、回数と合計時間の両方で見る
継続時間で区切って数える
手元に停止の記録があれば、継続時間で 3 つに区切って数えてみます。
- 5 分未満で復旧したもの
- 5 分以上 30 分未満で復旧したもの
- 30 分以上を要したもの
回数で見ると、短い区分に集まることがよくあります。一時的な応答の遅れや、短時間で自然に解消する事象が、記録の多くを占めるためです。なお、確認の間隔より短い停止は区別できません。5 分おきに確認しているなら、記録の上ではどれも「5 分前後」に見えます。
件数の多さと影響の大きさは別
次に、止まっていた時間の合計で並べ直します。回数では少ない 30 分以上の事象が、合計時間では大きな割合を占めることがよくあります。1 件で数十分から数時間を積み上げるためです。
つまり、稼働率を押し下げるのは、頻発する短い停止より、まれでも長い停止であることが多いのです。そして担当者の負担も同じ方向に偏ります。数分で戻る停止に人の手はほとんど要りませんが、30 分を超える停止では、誰かが原因を判断し、関係者へ連絡する必要が出てきます。
この構図から導けることは単純です。稼働率を上げたいなら、短時間の事象を数えることではなく、長時間化する事象をいかに短く終わらせるかに手を打つほうが効きます。
停止の原因は「サーバーが落ちた」だけではない
保証範囲と体感のずれ
利用者が見ている「サイトが開かない」という状態は、外形的には一つですが、内側では複数の層が重なっています。上から順に書くと、次のようになります。
- ドメイン名からサーバーの住所を引けるか（名前解決）
- その住所まで通信が届くか（ネットワーク到達）
- サーバー上で Web サーバーのプログラムが動いているか
- PHP（WordPress を動かしている言語）が実行できるか
- データベースが応答するか
- WordPress 本体とプラグインが最後までページを組み立てられるか
サーバー会社が示す稼働率は、多くの場合、上の 2〜3（ネットワークとサーバーのプログラム）が動いているかを対象にしています。WordPress やプラグインが原因で起きたエラーは、契約上の停止に数えられないのが一般的です。対象の範囲は、契約ごとに確かめてください。
サーバーは生きていてもサイトは死ぬ
たとえばプラグインの更新に失敗し、PHP が致命的エラーを返している状態を考えます。サーバーは正常に動いていて、リクエストも受け取っています。ただ、返ってくるのがエラー画面だというだけです。この場合、サーバー会社の稼働率は 100% のまま、利用者にとってサイトは完全に止まっています。この種の画面に出くわしたときの切り分けは「重大なエラーが発生しました」と出たときの手順に沿って進めると早いです。
同じことは、名前解決の失敗や証明書の期限切れでも起こります。いずれもサーバー本体は無関係です。担当者が確認すべきなのは「サーバーが動いていたか」ではなく「サイトが返せていたか」で、この 2 つは別の問いです。画面が真っ白になる場合やそもそもつながらない場合は、どの層で止まっているかを表示されないときの切り分けから順に見ていくと、原因の範囲が絞れます。
担当者として確認しておく 5 つのこと
稼働率の数字を他社と比べる前に、手元で答えられるかどうかを確認したい項目が 5 つあります。
- 稼働率の定義が契約書や案内ページにどう書かれているか。分母の期間、停止の判定条件、計画停止の扱いの 3 点です。書かれていない場合は、比較の材料にはなりません
- 停止が起きたとき、誰が最初に気づく仕組みになっているか。利用者からの連絡が第一報になっているなら、気づくまでの時間が停止時間にそのまま上乗せされています
- 復旧の判断を誰ができるか。夜間と休日に連絡が取れる経路があるか。判断できる人が不在の時間帯が、長時間化する事象の温床になります
- 停止が長引いたとき、戻せる状態が手元にあるか。取得できていることと、実際に戻せることは別です。この違いはバックアップは「取れている」と「戻せる」が別物で整理しています
- 過去の停止について、発生時刻・継続時間・原因・対処が記録として残っているか。記録がなければ、同じ原因で何度止まっているかも分かりません
5 つのうち答えられないものがあるなら、稼働率の数字を比べるより先に、そこを決めるほうが効果があります。2 と 3 が決まっているだけで、長時間化する事象の継続時間は短くなりやすいからです。
なお、記録を残す作業は地味ですが、後から分類すると見え方が変わります。警報の記録を一定期間分まとめて分類した例は改ざん検知の警報を全件分類した記事にあります。件数の多い事象と、影響の大きい事象が一致しないという構図は、稼働率の話と共通しています。
稼働率は、サイトの状態を一つの数字に圧縮したものです。圧縮した時点で、何分止まったか・誰が気づいたか・どう戻したかという情報は落ちています。数字を比べることに意味がないわけではありませんが、比べられるのは定義が揃っているときだけです。自分のサイトについて答えるべき問いは、百分率ではなく、止まったときに次に何が起きるかのほうにあります。
