信頼性理論：MTBF・MTTR・可用性の数理

可用性とは「動いている時間の割合」

可用性（Availability） A は、ある期間のうちサービスが正常に稼働していた時間の割合です。「9 の数（ナイン）」で語られる 99.9% などはすべてこの A の値です。SLO の中心的な指標であり、その計算根拠を確率と期待値から押さえるのがこの記事の目的です。

土台になる2つの量があります。

• MTBF（Mean Time Between Failures）：故障から次の故障までの平均稼働時間。「平均してどれだけ連続して動くか」。
• MTTR（Mean Time To Repair / Recovery）：故障してから復旧するまでの平均時間。「落ちたとき、どれだけ早く戻せるか」。

長い目で見ると、システムは「動いている時間（MTBF）」と「直している時間（MTTR）」を交互に繰り返します。1サイクルの長さは MTBF + MTTR、そのうち動いているのは MTBF 分です。よって時間平均としての可用性は次のように導けます。

A = （動いている時間の期待値） / （1サイクル全体の期待値）
  = MTBF / (MTBF + MTTR)

不可用性（落ちている割合）U はその補数で、U = 1 - A = MTTR / (MTBF + MTTR) となります。

故障率と指数分布：なぜ平均だけで語れるのか

「平均だけで A が決まる」と言えるのには前提があります。多くの信頼性モデルは、故障が一定の率でランダムに起きる（記憶を持たない）と仮定します。このとき故障間隔は指数分布に従い、故障率を λ（ラムダ）とすると MTBF = 1/λ が成り立ちます。

指数分布の鍵は無記憶性です。「いま100時間連続稼働している」という事実は、「次の1時間で故障する確率」を変えません。だから過去の稼働履歴によらず、瞬間故障率 λ だけで将来を語れます。バスタブ曲線の真ん中（偶発故障期）がこの一定 λ に対応し、初期故障期・摩耗故障期では λ が時間変化するため、この単純モデルは外れます。

ナインの計算：A から許容ダウンタイムへ

可用性を「9 の数」で表すのは、不可用性 U = 1 - A が**桁（オーダー）**で効くからです。年間の許容ダウンタイムは 年間秒数 × U で計算できます。1年を約 31,536,000 秒として求めると次の通りです。

可用性 A	不可用性 U	年間の許容ダウン	月間の許容ダウン
99%（ツーナイン）	1e-2	約 3.65 日	約 7.2 時間
99.9%（スリーナイン）	1e-3	約 8.76 時間	約 43 分
99.99%（フォーナイン）	1e-4	約 52.6 分	約 4.3 分
99.999%（ファイブナイン）	1e-5	約 5.26 分	約 26 秒

ナインが1つ増えるごとに U は1桁小さくなり、許容ダウンも約1/10になります。ここで重要なのは、A = MTBF/(MTBF+MTTR) を変形すると U ≈ MTTR/MTBF（MTTR が MTBF より十分小さいとき）になる点です。つまり同じ可用性は「滅多に壊れない（MTBF大）」でも「壊れてもすぐ直る（MTTR小）」でも達成できる。多くの現場では MTBF を1桁伸ばすより MTTR を1桁縮める方が安価で、障害対応・ポストモーテムによる復旧時間の短縮が可用性向上の主戦場になります。

直列構成：依存は可用性を必ず下げる

複数のコンポーネントがすべて動いて初めて全体が動く関係を直列と呼びます。リクエストが「ロードバランサ → アプリ → データベース」と全段を通る構成がこれです。各段の故障が独立なら、全体の可用性は各可用性の積になります。

A_直列 = A1 × A2 × ... × An

積なので、要素を足すほど全体は必ず悪化します。例えば各 99.9%（A=0.999）の独立サービスを3段直列にすると、0.999^3 ≈ 0.997、つまり 99.7% に落ちます。要素数 n に対し全体は約 1 - n×U で近似でき、不可用性が足し算で積み上がると捉えると直感的です。

並列構成：冗長化は不可用性を掛け算で潰す

同じ役割の要素を並べ、どれか1つでも動けば全体が動く関係が並列（冗長化）です。全体が落ちるのは「全要素が同時に落ちる」ときだけなので、可用性ではなく不可用性の積で考えます。

U_並列 = U1 × U2 × ... × Un
A_並列 = 1 - U_並列 = 1 - (U1 × U2 × ... × Un)

各要素が独立で同じ U なら U_並列 = U^n です。99%（U=0.01）のサーバーを2台並列にすると U = 0.01^2 = 1e-4、つまり一気に 99.99%（フォーナイン）まで跳ね上がります。冗長化が強力なのは、不可用性がべき乗で小さくなるからです。キャパシティプランニングで台数を決める際は、この可用性の観点も同時に効いてきます。

限界逓減：3台目はなぜ効かないのか

並列で U^n が効くということは、冗長化の効果は急速に逓減することも意味します。U=0.01 の要素を増やすと、不可用性は 0.01 → 0.0001 → 0.000001 と桁で減りますが、得られる「ナインの増分」は次第に意味を失います。1台目から2台目で 99% → 99.99% と劇的に改善しても、すでにフォーナインに達した先で3台目を足しても、可用性の改善幅は人間の体感やコストに見合わなくなります。

そして現実には、独立性の仮定そのものが崩れることが天井になります。

この CCF を意図的に炙り出すのがカオスエンジニアリングです。「2台あるから安全」という机上の U^2 を、実際に1台落として残りで本当に捌けるか（容量・依存・フェイルオーバーの自動性）を検証しないと、独立性の仮定は絵に描いた餅になります。

まとめ：可用性は掛け算で設計する

• 可用性は A = MTBF/(MTBF+MTTR)。U ≈ MTTR/MTBF なので、MTTR短縮が安価で効く向上手段になりやすい。
• ナインが1つ増えるごとに不可用性 U は1桁、許容ダウンも約1/10になる。
• 直列は A の積で悪化、並列は U の積で改善。依存段数を減らし、冗長で U^n を作るのが基本戦略。
• 冗長化の効果は逓減し、最終的には共通要因故障 p が天井。台数より独立性への投資が効く。

MTBF/MTTR と直列・並列の合成は、SLO に「いくつナインを置けるか」「どこを冗長化すべきか」を確率から根拠づける道具です。感覚の「たぶん大丈夫」を、掛け算できる数字に置き換えるところから始めましょう。