MTTR・MTBF・MTTFとは｜違い・計算式と稼働率を障害ログで計算

1回の障害は「発生→検知→着手→復旧→解決」と進みます。どこからどこまでを測るかで、指標の名前が変わります。

flowchart TD
    U[稼働中] --> O[障害の発生]
    O -->|MTTD| D[検知・通知]
    D -->|MTTA| A[対応に着手]
    A -->|修理作業| R[サービス復旧]
    R -->|恒久対策| X[解決]
    R -->|MTBF 稼働| O2[次の障害]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、Python 3.13.18 の標準ライブラリ（csv・datetime・statistics・math・random）だけを使い、自作のサンプルの障害ログ（架空のサービス「サンプル注文API」の 2026年7月1日〜9月30日の8件。実在の会社・障害ではありません）から MTTR・MTBF・MTTF・稼働率・中央値・p90・許容停止時間・故障率と信頼度・直列並列の稼働率を計算し、指数分布と対数正規分布を使ったシミュレーションで式の値と比べました。記事中の数値はすべてこの環境で実行した出力です。言葉の定義は、AWS Well-Architected フレームワーク（信頼性の柱）、Microsoft Azure Well-Architected Framework、DORA の公式ガイド（2026年1月5日更新）、Atlassian のインシデント管理の解説で確かめました。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

MTTR・MTBF・MTTFとは（意味の一覧表）

この節では、MTTR・MTBF・MTTF と、一緒に出てくる MTTD・MTTA の意味が一覧で分かります。

どれも「Mean Time ＝ 平均時間」で始まり、何から何までの時間かが違います。 頭の MT を外して、残りの文字（TR・BF・TF）が何の略かで覚えると混ざりません。

• MTTR：AWS Well-Architected は Mean Time to Recover（平均復旧時間）、Microsoft Azure Well-Architected Framework は「障害を検出してから、コンポーネントを元に戻すまでの時間」と定義しています。同じ略語でも、どこから数えるかは組織で違います（次の節で4通りに分けます）。
• MTBF：Azure は「ワークロードが中断なく期待どおりに動き、故障するまでの時間」と定義しています。修理して使い続けるサーバー・サービス・機械に使います。
• MTTF：電球・ディスク・電池のように、壊れたら修理せず交換するものに使います。Atlassian の解説も「修理できない故障の間の平均時間」としています。

RASISの中での位置づけ

システムの評価の観点をまとめた言葉に RASIS があります。Reliability（信頼性）・Availability（可用性）・Serviceability（保守性）・Integrity（完全性）・Security（安全性）の頭文字です。MTBF は信頼性、MTTR は保守性、稼働率は可用性を数字で表す指標にあたります。基本情報技術者試験などでも、この3つを組み合わせた稼働率の計算がよく問われます。完全性（データが壊れていないか）と安全性（不正に使われないか）は、MTBF・MTTR では表せないので、別の指標で見ます。

ITIL（IT サービス管理の手引き）では、サービスの単位で測る MTRS（Mean Time to Restore Service：平均サービス回復時間）と MTBSI（Mean Time Between Service Incidents：平均サービスインシデント間隔）という言葉も使います。機器ではなく「使う人から見てサービスが使えたか」で数える点が違います。

MTTRとMTBFの違い（向きが逆の2つの指標）

この節では、MTBF と MTTR が何を表し、なぜ2つを組にして見るのかが分かります。

MTBF は「どれだけ壊れにくいか（信頼性）」、MTTR は「壊れたときどれだけ早く直せるか（保守性）」を表します。 良い向きが逆で、MTBF は長いほど、MTTR は短いほど良い値です。

片方だけでは判断できません。たとえば MTTR が5分でも1日に20回止まるサービスは使いにくく、MTBF が1年でも1回止まると1週間戻らないシステムは困ります。2つを組み合わせたものが稼働率で、両方を1つの数字にまとめられます。

MTTFとは（MTBFとの違いと「打ち切り」のある計算）

この節では、MTTF と MTBF の使い分けと、まだ壊れていない部品を含めて MTTF を計算する方法が分かります。

MTTF は、修理せず交換する部品の「壊れるまでの平均時間」です。 修理して使い続けるものの MTBF は、1回の「稼働→故障→修理」の繰り返しのうち稼働の部分の平均で、MTTF に近い考え方です。そのため MTBF ＝ MTTF ＋ MTTR（故障の始まりから次の故障の始まりまで）と書く資料もあります。どちらの定義かは、表の注や社内の定義書で確かめます。

壊れた部品だけで平均すると短く出る

同じ型のディスクを10台使い始め、20,000時間観察したサンプルです。4台が壊れ、6台はまだ動いています。

10台を 20000 h 観察、故障4台 [6200, 11800, 15300, 18900], 6台は稼働中
壊れた4台だけの平均 = 13050 h
総稼働時間/故障数 = 172200/4 = 43050 h

壊れた4台だけで平均すると13,050時間、まだ動いている6台の20,000時間も足して故障数で割ると43,050時間で、3倍以上違いました。 観察の途中でまだ壊れていないデータを「打ち切り（センサリング）」と呼びます。壊れたものだけを平均すると、早く壊れたものばかりを数えることになり、MTTF を短く見積もります。故障率が一定（指数分布）と考えるときは、全台の稼働時間の合計 ÷ 故障数 が MTTF の推定値になります。

カタログに書かれた MTBF や MTTF は、多くの台数を短い期間動かした試験から求めた値で、「1台がその時間もつ」という意味ではありません。この点は「MTBFから止まらない確率を出す」の節で数値で確かめます。

MTTRの4つの意味（Repair・Recovery・Respond・Resolve）とMTTD・MTTA

この節では、MTTR の R が表す4つの言葉と、それぞれがどの区間を測るのかが、同じ障害ログで分かります。

MTTR の R は Repair（修理）・Recovery（復旧）・Respond（対応）・Resolve（解決）のどれかを指し、値が大きく変わります。 Atlassian のインシデント管理の解説も、R には4つの意味があり、チームでどれを使うか決めるよう書いています。

自作の障害ログ8件（時刻は発生・検知・着手・復旧・解決の5点を記録）で、4つの MTTR と MTTD・MTTA を計算した結果です（単位は分）。

== A. 1件ごと（分）
id      TTD  TTA  repair recovery respond resolve
INC-01    5    4     27       36      31    1728
INC-02   25   15     50       90      65    2360
INC-03    2    3     15       20      18     180
INC-04   11    9    340      360     349    6630
INC-05    1    4     12       17      16     115
INC-06   13    5     37       55      42    2475
INC-07    4    6     25       35      31     280
INC-08   30   12     38       80      50    1970

同じ8件でも、どの R で数えるかで68.0分から1,967.2分まで約29倍の差が出ました。 他社やツールの値と比べるときは、まず R がどれかをそろえます。稼働率や SLA の計算に使うのは、使う人から見た停止時間である Recovery です。

MTTD（発生→検知）の平均は11.4分、MTTA（検知→着手）の平均は7.2分でした。Recovery の86.6分は MTTD 11.4 ＋ MTTA 7.2 ＋ Repair 68.0 の合計と一致します。MTTR を区間に分けて記録しておくと、どこを縮めればよいかが分かります。 INC-08（証明書の期限切れ）は検知に30分かかっており、修理の手際ではなく監視の不足が長引いた原因だと読めます。

障害ログからMTTR・MTBF・稼働率を計算する（Python）

この節では、障害ログの CSV から MTTR・MTBF・稼働率を計算するコードと出力、平均値だけで判断しない読み方が分かります。

MTTR は停止時間の合計 ÷ 件数、MTBF は稼働時間の合計 ÷ 件数で求めます。 稼働時間は「集計期間 − 停止時間の合計」です。

サンプルの障害ログ（CSV）

id,occurred,detected,acked,recovered,resolved,cause,deploy
INC-01,2026-07-04 10:12,2026-07-04 10:17,2026-07-04 10:21,2026-07-04 10:48,2026-07-05 15:00,設定ミスのリリース,yes
INC-02,2026-07-15 02:40,2026-07-15 03:05,2026-07-15 03:20,2026-07-15 04:10,2026-07-16 18:00,ディスク満杯,no
INC-03,2026-07-29 14:00,2026-07-29 14:02,2026-07-29 14:05,2026-07-29 14:20,2026-07-29 17:00,遅いクエリのリリース,yes
INC-04,2026-08-09 21:30,2026-08-09 21:41,2026-08-09 21:50,2026-08-10 03:30,2026-08-14 12:00,DBの切り替え失敗,no
INC-05,2026-08-22 09:05,2026-08-22 09:06,2026-08-22 09:10,2026-08-22 09:22,2026-08-22 11:00,環境変数の漏れ,yes
INC-06,2026-09-03 16:45,2026-09-03 16:58,2026-09-03 17:03,2026-09-03 17:40,2026-09-05 10:00,外部APIのタイムアウト,no
INC-07,2026-09-18 11:20,2026-09-18 11:24,2026-09-18 11:30,2026-09-18 11:55,2026-09-18 16:00,マイグレーションの失敗,yes
INC-08,2026-09-27 03:10,2026-09-27 03:40,2026-09-27 03:52,2026-09-27 04:30,2026-09-28 12:00,証明書の期限切れ,no

時刻はすべて日本時間です。deploy 列は、リリース（デプロイ）が原因の障害かどうかで、DORA 指標の節で使います。

計算するコード

import csv
from datetime import datetime, timedelta, timezone

JST = timezone(timedelta(hours=9))
P_START = datetime(2026, 7, 1, tzinfo=JST)
P_END = datetime(2026, 10, 1, tzinfo=JST)
PERIOD_H = (P_END - P_START).total_seconds() / 3600   # 2208 時間

def t(s):
    return datetime.strptime(s, "%Y-%m-%d %H:%M").replace(tzinfo=JST)

def mins(a, b):
    return (b - a).total_seconds() / 60   # .seconds ではなく total_seconds()

rows = list(csv.DictReader(open("incidents.csv", encoding="utf-8")))
for r in rows:
    for k in ("occurred", "detected", "acked", "recovered", "resolved"):
        r[k] = t(r[k])
    r["TTD"] = mins(r["occurred"], r["detected"])        # 発生→検知
    r["TTA"] = mins(r["detected"], r["acked"])           # 検知→着手
    r["repair"] = mins(r["acked"], r["recovered"])       # 着手→復旧
    r["recovery"] = mins(r["occurred"], r["recovered"])  # 発生→復旧（停止時間）
    r["respond"] = mins(r["detected"], r["recovered"])   # 検知→復旧
    r["resolve"] = mins(r["occurred"], r["resolved"])    # 発生→解決

n = len(rows)
down_h = sum(r["recovery"] for r in rows) / 60
up_h = PERIOD_H - down_h
mttr = down_h / n
mtbf = up_h / n
print(f"件数 {n}  停止 {down_h:.2f} 時間  稼働 {up_h:.2f} 時間")
print(f"MTTR = {mttr * 60:.1f} 分  MTBF = {mtbf:.1f} 時間")
print(f"稼働率 = {mtbf / (mtbf + mttr) * 100:.4f} %")

$ python3 calc.py
件数 8  停止 11.55 時間  稼働 2196.45 時間
MTTR = 86.6 分  MTBF = 274.6 時間
稼働率 = 99.4769 %

「発生の間隔の平均」とは値が少し違う

MTBF を「障害の発生から次の発生までの間隔の平均」で求める方法もあります。同じログで比べました。

== D. 発生間隔の平均（別の数え方）
間隔(h): [256.5, 347.3, 271.5, 299.6, 295.7, 354.6, 207.8]
発生間隔の平均 = 290.42 h（7区間）, 期間/件数 = 276.00 h

8件の障害の間には7つの間隔しかなく、最初の障害より前（7月1日〜4日）と最後の障害より後（9月27日〜30日）の稼働時間が数に入りません。そのため290.42時間と、稼働時間 ÷ 件数（274.56時間）より長く出ました。期間 ÷ 件数（276.00時間）は MTBF ＋ MTTR にあたります。件数が少ないうちは、どの数え方かで6%ほど変わるので、社内で1つに決めて書いておきます。

平均だけでは足りない：中央値・p90で見るMTTR

== B. 平均・中央値・p90・最大（分）
TTD      mean=    11.4 median=    8.0 p90=   26.5 max=    30
TTA      mean=     7.2 median=    5.5 p90=   12.9 max=    15
repair   mean=    68.0 median=   32.0 p90=  137.0 max=   340
recovery mean=    86.6 median=   45.5 p90=  171.0 max=   360
respond  mean=    75.2 median=   36.5 p90=  150.2 max=   349
resolve  mean=  1967.2 median= 1849.0 p90= 3721.5 max=  6630

== E. 長い1件(INC-04)を除くと
MTTR mean=47.6 median=36.0
INC-04 recovery = 360 min, 停止合計に占める割合 = 51.9 %

Recovery の平均は86.6分ですが、中央値は45.5分でした。 6時間止まった INC-04（DB の切り替え失敗）1件だけで、停止時間の合計の51.9%を占めています。この1件を除くと平均は47.6分まで下がります。平均だけを見ると「いつも1時間半かかる」と読み違えるので、中央値（よくある障害の長さ）と p90（長引いた障害の長さ）を並べて報告します。 p90 は Python の statistics.quantiles(v, n=10, method="inclusive")[-1] で出しました。

月ごとに見ると、1か月だけ大きく下がる

SLA や SLO は月ごとに判定することが多いため、同じログを月で区切って計算しました（月の長さは各月の日数）。

$ python3 monthly.py
2026-07 件数=3 停止= 146 min MTTR=  48.7 min 稼働率=99.6729 % 99.9%の枠=44.6 min
2026-08 件数=2 停止= 377 min MTTR= 188.5 min 稼働率=99.1555 % 99.9%の枠=44.6 min
2026-09 件数=3 停止= 170 min MTTR=  56.7 min 稼働率=99.6065 % 99.9%の枠=43.2 min

3か月まとめた稼働率は 99.4769% でしたが、月ごとでは 99.16%〜99.67% と開きがあり、8月は件数が最も少ないのに MTTR が188.5分と最も長くなりました。件数が少ない月の MTTR は1件で決まるので、月ごとの数字は件数と一緒に読み、傾向は数か月まとめて判断します。 99.9% の枠（1か月で約44分）は、どの月も超えていました。

稼働率の計算式（MTBF÷(MTBF＋MTTR)）と許容停止時間の早見表

この節では、稼働率の式がなぜ成り立つのかと、99%〜99.999% で1年・1か月・1週間・1日に止まってよい時間が分かります。

稼働率は MTBF ÷（MTBF ＋ MTTR） で、「稼働時間 ÷（稼働時間 ＋ 停止時間）」と同じです。 分子と分母の両方を件数で割っただけなので、前の節のとおり、どちらで計算しても 99.4769% になりました。AWS Well-Architected（信頼性の柱）も、可用性の見積もりにこの式を使い、「MTBF が150日で MTTR が1時間なら 99.97%」という例を挙げています。手元で計算すると 3600 ÷ 3601 ＝ 99.9722% で一致しました。

許容停止時間（その稼働率を守るために止まってよい最大の時間）を計算しました。1年は365日、1か月は30日で数えています。

AWS の表（99.9% で8時間45分、99.99% で52分、99.999% で5分）とも一致しました。9が1つ増えるごとに、許容停止時間は10分の1になります。 サンプルの注文API（99.4769%）は、99.5% にもわずかに届いていません。1か月で止まってよい時間（99.9% なら43分12秒）は、SLO（サービスの目標）のエラーバジェットの考え方と同じです。SLI・SLO・SLA とエラーバジェットの計算は、関連記事「SREとは｜SLI・SLO・SLAの違いとエラーバジェット計算」で扱っています。

式の値とシミュレーションを比べる

稼働時間が指数分布（平均 274.56時間）、停止時間が対数正規分布（平均 86.6分、ばらつきは大きめ）に従うとして、10年分の運用を1,000回シミュレーションしました。

== L. シミュレーション（10年分を1000回）
シミュレーションの稼働率 平均 99.4771 %  最小 99.3288 %  最大 99.6109 %
式の値 99.4769 %

1,000回の平均は 99.4771% で、式の値 99.4769% とほぼ同じでした。一方、同じ MTBF・MTTR でも、10年間の稼働率は 99.33%〜99.61% の幅でぶれています。式で出る稼働率は「長い目で見た平均」で、ある1年の稼働率を約束する値ではありません。

MTBFから「止まらない確率」を出す（故障率と信頼度）

この節では、MTBF から故障率と「ある期間止まらずに動く確率（信頼度）」を計算する方法と、MTBF の読み違えが分かります。

故障が偶然に起きる（故障率が一定）と考えると、故障率は λ ＝ 1 ÷ MTBF、t 時間止まらない確率は R(t) ＝ e のマイナス t÷MTBF 乗 です。 Python では math.exp(-t / mtbf) と書きます。サンプルの MTBF（274.56時間）で計算しました。

== H. 故障率と信頼度（指数分布を仮定）
λ = 1/MTBF = 0.003642 /h = 2.622 回/30日
1日             止まらない確率 R = 91.6 %
7日             止まらない確率 R = 54.2 %
30日            止まらない確率 R = 7.3 %
MTBFと同じ時間      止まらない確率 R = 36.8 %
MTBF 1000h の機器が 1000h 止まらない確率 = 36.8 %

機器の故障率は、使い始め（初期故障）は高く、安定期（偶発故障）は低く一定で、寿命が近づくと（摩耗故障）また高くなります。グラフにすると浴槽の断面の形になるので「バスタブ曲線」と呼ばれます。上の計算が当てはまるのは安定期です。

直列・並列構成の稼働率

この節では、Web・AP・DB の3層のように部品をつないだときの全体の稼働率の計算と、冗長化の効果が分かります。

直列（全部動かないと使えない）は稼働率の掛け算、並列（どれか1つ動けば使える）は 1 − 止まる確率の掛け算 です。 Web 99.9%・AP 99.9%・DB 99.95% の例で計算しました。

== J. 直列・並列
直列 Web×AP×DB = 99.7502 %  年間停止 21時間52分57秒
Web・APを2台並列 = 99.9498 %  年間停止 4時間23分51秒
全部2台並列 = 99.99978 %  年間停止 1分11秒

3つとも 99.9% 以上でも、直列につなぐと 99.7502%（1年で約22時間停止）まで下がりました。Web と AP を2台ずつにすると 99.9498% になり、残った DB 1台が全体の上限を決めています。AWS Well-Architected も、99.99% のシステムが 99.99% の2つのシステムに強く依存すると理論上 99.97% になる、と同じ掛け算で説明しています。

この計算は「部品が独立に壊れる」「切り替えは一瞬で終わる」という前提です。実際には同じ電源・同じ設定ミス・同じリリースで一緒に止まることがあり、切り替えに失敗すると INC-04 のように長く止まります。k 台中 n 台が必要な構成や切り替え時間を含めた計算は、関連記事「可用性設計と稼働率の計算｜直列・並列の計算式と停止時間の早見表」で扱っています。

MTBFを延ばすか、MTTRを縮めるか（目標からの逆算）

この節では、稼働率を上げるときに MTBF と MTTR のどちらに手を打つかの考え方と、目標の稼働率から必要な MTTR を逆算する方法が分かります。

== K. MTBFを2倍とMTTRを半分
今       99.4769 %  年間停止 1日21時間49分24秒
MTBF×2   99.7378 %  年間停止 22時間58分18秒
MTTR÷2   99.7378 %  年間停止 22時間58分18秒
目標 99.9% に必要な MTTR <= 16.5 min（MTBF 274.6 h のまま）
目標 99.95% に必要な MTTR <= 8.2 min（MTBF 274.6 h のまま）
目標 99.99% に必要な MTTR <= 1.6 min（MTBF 274.6 h のまま）

MTBF を2倍にしても、MTTR を半分にしても、稼働率は同じ 99.7378% になりました。 稼働率は MTBF と MTTR の比で決まるためです。どちらに手を打つかは、かかる手間で決めます。故障を半分に減らす（設計の見直し・冗長化）より、復旧を半分の時間にする（監視・手順書・自動化）ほうが早く効くことが多くあります。

目標から逆算する式は MTTR ≦ MTBF ×（1 − 目標）÷ 目標 です。今の MTBF（約11日に1回止まる）のまま 99.9% を守るには、1回の障害を16.5分以内に復旧する必要があります。99.99% なら1.6分以内で、人が気づいて操作する時間では届きません。99.99% 以上を目標にするなら、自動の切り替え（フェイルオーバー）か、そもそも止まらない構成（MTBF を延ばす）が要ります。

DORA指標とMTTR（失敗したデプロイからの回復時間）

この節では、ソフトウェア開発の DORA 指標で MTTR がどう扱われているかと、障害ログからの計算が分かります。

DORA（Google Cloud の研究チームが続ける調査）の指標では、以前の「サービス復元時間（MTTR）」が「失敗したデプロイからの回復時間（Failed deployment recovery time）」に置き換わっています。 DORA の公式ガイド（2026年1月5日更新）は、ソフトウェアデリバリーの5つの指標を次のように定義しています。

違いは対象の範囲です。MTTR はディスク満杯・外部 API・証明書切れも含めたすべての障害が対象ですが、DORA の回復時間はリリースが原因の障害だけを数えます。サンプルのログの deploy=yes の4件で計算しました。期間中のデプロイ回数は120回と仮定しています。

== F. DORA（リリース起因だけ）
対象: ['INC-01', 'INC-03', 'INC-05', 'INC-07'] [36.0, 20.0, 17.0, 35.0]
失敗したデプロイからの回復時間 mean=27.0 min median=27.5 min
変更失敗率 = 4/120 = 3.33 %

リリースが原因の障害は平均27.0分で戻っていて、全体の MTTR（86.6分）の約3分の1でした。リリースの障害は「前の版に戻す」で直せることが多い一方、ディスク満杯や DB の切り替え失敗は戻す先がなく、時間がかかります。原因の種類で分けて集計すると、どの対策が効くのかが見えます。

MTTRを短くする具体策（監視・Runbook・ロールバック）

この節では、MTTR を区間ごとに縮める具体的な打ち手と、どこから手を付けるかが分かります。

MTTR は「気づく → 着手する → 直す」の3つに分けて縮めます。 サンプルのログでは、INC-02・INC-08 は検知（25分・30分）、INC-04 は修理（340分）が長く、効く手段が違いました。

1. 1外から見る監視を入れる（MTTD）使う人と同じ URL を定期的に叩く外形監視・エラー率の監視。ディスク残量・証明書の期限は「止まる前」に通知する
2. 2通知の宛先と当番を決める（MTTA）誰が受けるか、何分で応答がなければ次の人へ回すかを決める。鳴りすぎるアラートは減らす
3. 3Runbook（手順書）を書く（Repair）「この通知が来たら、このコマンドで確かめ、この操作で戻す」を書いておく。夜中でも同じ手順で動ける
4. 4切り戻し（ロールバック）を1コマンドにするリリース起因の障害は、原因を調べる前に前の版へ戻す。ブルーグリーン・カナリアで影響を小さくする
5. 5よくある復旧を自動化するプロセスの再起動・ヘルスチェックで外す・容量の自動拡張。手順書で繰り返し使う操作から順に
6. 6振り返りで再発を防ぐ（MTBF にも効く）誰かを責めずに原因と遅れた理由を書き、恒久対策を Resolve まで追う

対策ごとの効果を障害ログで試算する

同じ8件の障害に、対策を1つずつ当てはめたら MTTR と稼働率がどう変わるかを計算しました。「検知を最大5分に」は監視を足して発生から5分以内に気づく、「切り戻し」はリリース起因の4件が検知から10分で戻る、「DB 切り替え」は INC-04 の修理を着手から30分で終える、という仮定です。

$ python3 whatif.py
今                            MTTR=  86.6 min  稼働率=99.4769 %  停止合計=693 min
検知を最大5分に                     MTTR=  79.2 min  稼働率=99.5214 %  停止合計=634 min
+リリース起因は検知から10分で切り戻し         MTTR=  72.2 min  稼働率=99.5637 %  停止合計=578 min
+DB切り替えを着手から30分で             MTTR=  33.5 min  稼働率=99.7977 %  停止合計=268 min

いちばん効いたのは、6時間止まった INC-04 の DB 切り替えを30分で終える対策で、停止時間の合計が578分から268分に減りました。 検知の改善と切り戻しは、どちらも1回あたりの短縮は数分〜十数分ですが、件数が多いほど効きます。このように、障害ログに区間ごとの時刻が残っていれば、対策の順番を数字で決められます。 それでも今の MTBF のままでは 99.9%（MTTR 16.5分以内）に届かないため、次は障害の件数を減らす（MTBF を延ばす）対策も並べて検討する、という判断になります。

監視の項目としきい値の決め方は関連記事「監視設計の項目一覧｜死活・リソース・ログ監視のしきい値例とテンプレート」で、障害が起きたときの連絡の流れと重大度の決め方は関連記事「インシデント管理のフローと重大度レベル定義｜連絡テンプレート付き」で扱っています。

• 1障害ごとに5つの時刻を記録している発生・検知・着手・復旧・解決。どれかが欠けると区間に分けられない
• 2「発生」の時刻を後から確かめている通知の時刻ではなく、ログやエラー率のグラフで最初に異常が出た時刻を入れる
• 3「復旧」を使う人から見た時刻で決めているサーバーが起きた時刻ではなく、外形監視が正常に戻った時刻
• 4原因の種類（リリース・基盤・外部）を付けているDORA の回復時間や、対策の優先順位を分けて出せる
• 5平均・中央値・p90 を並べて報告している長い1件に引っぱられた平均だけで判断しない

MTTR・MTBFの計算でよくある間違い（エラー原文つき）

この節では、障害ログから MTTR・MTBF を計算するときに起きやすいエラーと、エラーにならずに値だけ間違う落とし穴が、実行した原文で分かります。

1 文字列のまま引き算 -> TypeError: unsupported operand type(s) for -: 'str' and 'str'
2 naive と aware -> TypeError: can't subtract offset-naive and offset-aware datetimes
3 障害0件でMTBF -> ZeroDivisionError: division by zero
4 障害0件でmean -> StatisticsError: mean requires at least one data point
5 1件でquantiles -> [36.0, 36.0, 36.0, 36.0, 36.0, 36.0, 36.0, 36.0, 36.0]
7 timedelta.seconds（2日超の解決時間） -> 870.0
7b total_seconds -> 6630.0
8 UTCで書かれた検知時刻をJSTとして読む -> -535.0
9 重なりをそのまま足す -> 100.0 min / 2件
9 区間をまとめる -> 70.0 min / 1 件 [('16:45', '17:55')]

重なった障害は区間をまとめる

同じ外部 API の障害で、16時45分〜17時40分と17時10分〜17時55分の2本のアラートが出た場合です。そのまま足すと100分・2件ですが、使う人から見て止まっていたのは16時45分〜17時55分の70分・1件です。区間を時刻順に並べ、前の区間の終わりより早く始まるものをつなげてから数えます。

iv = sorted(incidents)                      # (開始, 終了) の組
merged = [list(iv[0])]
for a, b in iv[1:]:
    if a <= merged[-1][1]:                  # 前の区間と重なる
        merged[-1][1] = max(merged[-1][1], b)
    else:
        merged.append([a, b])

このほか、計画メンテナンスを停止時間に入れるか、一部の機能だけ止まった障害をどう数えるかも、値を大きく変えます。計算の前に「何を障害として数えるか」を文書にしておくと、月ごとの比較がぶれません。 障害を記録として残す書き方は、関連記事「障害報告書の書き方｜例文つきテンプレートと再発防止策の立て方」で扱っています。

判断表：MTTR・MTBF・MTTF・稼働率をどう使い分けるか

この節では、目的ごとにどの指標を使い、どう測ればよいかが表で分かります。

よくある質問

Q. MTTRとは何の略ですか？ A. Mean Time To Repair（平均修復時間）または Mean Time To Recovery／Restore（平均復旧時間）の略です。Respond（対応）・Resolve（解決）の意味で使うこともあり、どれを指すかで測る区間が変わります。

Q. MTBFとMTTRの違いは何ですか？ A. MTBF は直ってから次に壊れるまでの平均稼働時間で、壊れにくさを表し、長いほど良い値です。MTTR は止まってから直るまでの平均時間で、直る速さを表し、短いほど良い値です。

Q. MTTFとMTBFの違いは何ですか？ A. MTTF は修理せず交換するもの（ディスク・電池など）が壊れるまでの平均時間、MTBF は修理して使い続けるものの故障の間隔の平均です。

Q. 稼働率の計算式は？ A. 稼働率 ＝ MTBF ÷（MTBF ＋ MTTR） です。稼働時間 ÷（稼働時間 ＋ 停止時間）と同じ値になります。MTBF 999時間・MTTR 1時間なら 99.9% です。

Q. 稼働率99.9%だと、どのくらい止まってよいですか？ A. 1年（365日）で8時間45分36秒、1か月（30日）で43分12秒、1日で1分26秒です。99.99% なら1年で52分34秒です。

Q. MTTRの目安はどのくらいですか？ A. 決まった目安はありません。目標の稼働率と MTBF から MTBF ×（1 − 目標）÷ 目標 で逆算します。サンプルの MTBF 274.6時間で 99.9% を守るなら16.5分以内です。

Q. MTBFが1,000時間なら、1,000時間は壊れないのですか？ A. 違います。故障率が一定と考えると、MTBF と同じ時間を止まらずに動ける確率は約36.8%です。MTBF はたくさんの台数や長い期間で見た平均です。

Q. 障害が0件の月のMTBFはどう書きますか？ A. 割り算ができないので「集計期間より長い（期間中の障害なし）」と書きます。複数の月をまとめた期間で計算すると、値が安定します。

Q. 計画メンテナンスは停止時間に入れますか？ A. SLA・SLO の定義によります。契約で計画停止を除くと決めていれば除き、使う人から見た稼働率を見たいなら含めます。どちらにしたかを報告に書きます。

Q. DORAの指標にMTTRはありますか？ A. DORA の公式ガイド（2026年1月5日更新）では、MTTR に代わって「失敗したデプロイからの回復時間（Failed deployment recovery time）」が使われています。リリースが原因の障害だけを対象にする点が違います。

Q. MTTRは平均値だけ見ればよいですか？ A. 長引いた1件で平均が大きく動くため、中央値と p90 も並べます。サンプルでは平均86.6分・中央値45.5分で、1件で停止時間の51.9%を占めていました。

Q. MTTRとMTTDの違いは何ですか？ A. MTTD は障害の発生から気づくまでの平均時間で、MTTR（Recovery）の前半の一部です。サンプルでは MTTD 11.4分・MTTA 7.2分・修理 68.0分の合計が MTTR 86.6分になりました。検知が遅い障害は、監視を足すと MTTR が縮みます。

まとめ

• MTTR は止まってから直るまで、MTBF は直ってから次に止まるまで、MTTF は修理しないものが壊れるまでの平均時間。稼働率は MTBF ÷（MTBF ＋ MTTR）。
• MTTR の R は Repair・Recovery・Respond・Resolve の4通りで、サンプルの8件では68.0分〜1,967.2分まで変わった。稼働率に使うのは Recovery。
• 平均だけでなく中央値・p90 を並べる。サンプルは平均86.6分・中央値45.5分で、6時間の1件が停止時間の半分を占めた。
• 99.9% の許容停止時間は1年で8時間45分36秒。MTBF を2倍にしても MTTR を半分にしても稼働率は同じ 99.7378% になり、99.99% 以上は自動の切り替えが要る。
• DORA では MTTR が「失敗したデプロイからの回復時間」に置き換わった。障害ごとに5つの時刻と原因の種類を記録すると、どの指標も後から計算できる。

参考・出典

確認日はいずれも 2026年10月29日です。

• AWS「Availability - Reliability Pillar（AWS Well-Architected Framework）」：https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html
• Microsoft「Architecture strategies for defining reliability targets（Azure Well-Architected Framework）」：https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics
• DORA「DORA's software delivery performance metrics」（2026年1月5日更新）：https://dora.dev/guides/dora-metrics/
• Atlassian「Common incident management metrics（MTBF, MTTR, MTTA, and MTTF）」：https://www.atlassian.com/incident-management/kpis/common-metrics
• Python ドキュメント「statistics — 数理統計関数」：https://docs.python.org/ja/3.13/library/statistics.html
• Python ドキュメント「datetime — 基本的な日付型および時間型」：https://docs.python.org/ja/3.13/library/datetime.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。