学校のパソコン室で授業中に急にシステムがフリーズして、先生があたふたしているのを見たことない？あるいはゲームのサーバーが落ちて「つながらない！」ってイライラした経験は？そういう「システムが止まった！」という事態は、会社の世界でも毎日のように起きているんだよ。そしてそのとき、「どのくらいの速さで直せるか」を数字で表したのがMTTRというものなんだ。この記事を読めば、MTTRが何なのか、なんで大事なのか、どうやって使うのかがぜんぶわかるよ。
- MTTRとは 「システムが壊れてから直るまでの平均時間」 のことで、小さいほど優秀なチームの証
- MTTRが長いと売上損失や顧客の信頼低下につながるため、ビジネスに直結する重要指標 のひとつ
- MTTRを縮めるには 監視・手順書・自動化 の3つを組み合わせることが基本の戦略になる
もうちょっと詳しく
MTTRはもともと製造業や機械の世界で使われていた言葉だったけど、今ではIT・ソフトウェアの世界でも当たり前のように使われているよ。特にDevOps（デブオプス）と呼ばれる「開発チームと運用チームが協力して素早くサービスを改善していく考え方」の中では、MTTRは「チームの実力を測る4つの指標」のうちの一つとして注目されているんだ。つまり、単なる数字じゃなくて「チームがどのくらい頼りになるか」を示すバロメーターでもあるよ。MTTRの改善に取り組むことは、そのままサービスの品質アップにつながるんだ。
MTTRはDevOpsの「4つのキーメトリクス」のひとつ。チームの健康状態のバロメーター！
⚠️ よくある勘違い
→ MTTRだけを追いかけて、障害の根本原因を直さないでいると、同じトラブルが何度も繰り返されてしまうよ。
→ 素早く直す（MTTR改善）と、そもそも壊れにくくする（MTBF改善）の両輪で取り組むのが正しいアプローチ。片方だけでは不完全なんだ。
[toc]
MTTRってそもそも何？基本をおさらいしよう
英語の略語、ちゃんと読んでみよう
MTTRはMean Time To Repairの略だよ。「Mean」は「平均」、「Time」は「時間」、「To Repair」は「修復するための」という意味。全部合わせると「修復するための平均時間」、つまり「システムやサービスが故障してから、ちゃんと動くようになるまでにかかった時間の平均」ということなんだ。
ちなみにRepairの代わりにRecovery（回復）やResolve（解決）を使うこともあって、文脈によって意味が少し変わることもあるよ。でも基本的には「直るまでの時間」と覚えておけばOKだよ。
身近な例で考えてみよう
たとえば、学校の給食システムが3回故障したとしよう。
- 1回目：壊れてから15分で直った
- 2回目：壊れてから45分で直った
- 3回目：壊れてから30分で直った
この場合のMTTRは（15＋45＋30）÷3＝30分になるよ。この30分という数字が「このシステムを担当しているチームの修復能力の平均値」を表しているんだ。数字が小さければ小さいほど「素早く直せるチーム」ということになるよね。
どの業界で使われているの？
MTTRはもともと製造業の世界で機械の修理時間を管理するために使われていたんだ。工場のラインが止まると生産がゼロになるから、「いかに早く機械を直すか」はめちゃくちゃ重要だったんだよ。それがIT・ソフトウェアの世界にも広がって、今ではWebサービスやクラウドインフラを運用するチームが日常的に使う指標になっているよ。
MTTRの計算方法と見方
計算式はシンプル
MTTRの計算式はとてもシンプルで、こう書けるよ。
- MTTR ＝ 総修復時間 ÷ 故障件数
「総修復時間」は「全部の故障を直すのにかかった時間の合計」で、「故障件数」は「何回故障したか」という数だよ。たとえば1か月で5回故障して、合計250分かかったなら、MTTRは250÷5＝50分になるよ。
修復時間の「スタート」と「ゴール」はどこ？
ここでちょっと気をつけてほしいのが、「修復時間をどこからどこまで計るか」という問題だよ。考え方は主に2パターンあって、
- パターンA：障害が発生した瞬間から、サービスが完全に復旧した瞬間まで
- パターンB：担当者が障害を検知した瞬間から、サービスが完全に復旧した瞬間まで
パターンAのほうが「気づくのが遅れた時間」も含まれるから、より現実に近い数字になるよ。会社や現場によって使い方が違うことがあるので、チーム内で定義を統一しておくことが大切なんだ。「あれ、うちのMTTRなんかおかしくない？」ってなるのは、だいたいこのスタート地点がズレているのが原因だよ。
どのくらいのMTTRが「良い」の？
これは業界や扱うシステムの重要度によってぜんぜん違うよ。医療システムや金融系のサービスなら「1分以内に復旧」が求められることもあるし、社内の業務ツールなら「数時間以内でOK」という場合もある。ただし、世界トップクラスのIT企業（GoogleやAmazonなど）は数分〜数十分のMTTRを目指していることが多いよ。自社のMTTRを業界標準と比べてみることで、自分たちの立ち位置が見えてくるんだ。
MTTRが長いと何が起きるの？ビジネスへの影響
お金の損失が一番わかりやすい
システムが止まっている時間が長ければ長いほど、会社が失うお金も増えていくよ。たとえばECサイト（ネット通販）の場合、1時間のダウンタイム（つまりシステムが動いていない時間のこと）で数百万円から数億円の損失になるケースもあるんだ。大きなセール期間中に障害が起きたら、その損失は計り知れないよ。MTTRが30分のチームと1時間のチームでは、同じ障害でも損失額がまったく違ってくるよね。
信頼の問題も大きい
お金だけじゃなくて、ユーザーからの信頼も失われるんだ。「またこのサービス落ちてる」って思われたら、ユーザーは競合サービスに乗り換えてしまうよ。特に今の時代は、障害情報がSNSで一気に広まるから、たった1回の長いダウンタイムで会社のイメージが大きく傷つくこともあるよ。MTTRを短くすることは「お客さんへの信頼維持」という意味でも超大事なんだ。
働く人へのストレスにもつながる
MTTRが長いということは、エンジニアが長時間にわたって障害対応に追われることを意味するよ。深夜に呼び出されて、何時間も原因を探し続けるのは体にも精神にもきつい。MTTRを短くする仕組みを整えることは、エンジニアが安心して働ける環境をつくることにもつながるんだ。「良い職場環境かどうか」の指標としてMTTRを見ている会社もあるよ。
MTTRを短くするための3つのアプローチ
アプローチ①：監視ツールで「気づき」を早くする
障害の修復を早くするには、まず「障害が起きていることに素早く気づく」必要があるよ。人間がずっと画面を眺めているのは無理だから、監視ツール（モニタリングツール）を使うんだ。つまり「システムの状態を自動でチェックして、おかしくなったらすぐにアラートを出してくれるソフトウェア」のことだよ。
たとえばDatadogやPrometheusといったツールは、サーバーのCPU使用率やエラーの数を常に監視して、問題が起きたらSlackやメールで担当者に通知してくれるよ。気づくまでに1時間かかっていたのが、監視ツールを導入したら1分以内に気づけるようになった、というケースはざらにあるんだ。
アプローチ②：手順書（ランブック）を整備する
障害が起きたとき、「で、何をすればいいんだっけ？」と考える時間がもったいないよね。そこで役立つのがランブックと呼ばれる手順書だよ。つまり「こういう障害が起きたときは、この順番でこの操作をしてください」という手順をあらかじめ書き留めておいたドキュメントのこと。
ランブックがあれば、障害対応の経験が浅いメンバーでも落ち着いて対処できるし、ベテランが休んでいても大丈夫。チーム全体のMTTRが下がるんだ。手順書の中身は定期的に見直して、古くならないように更新することも大切だよ。
アプローチ③：自動化で「人の手」を減らす
一番時間がかかるのは人間が手動でやる作業だよ。だから、繰り返し起きる障害の対応を自動化することがMTTRを大幅に縮める近道なんだ。たとえばサーバーが落ちたら自動的に別のサーバーに切り替わる仕組みや、特定のエラーが出たら自動でサービスを再起動するスクリプトを用意しておくといった方法があるよ。
「そんな複雑なことできるの？」と思うかもしれないけど、AWSやGoogleCloudなどのクラウドサービスにはこういった自動化の仕組みが最初から組み込まれていることも多いんだ。うまく活用すれば、人間が何もしなくてもMTTRが数十秒になるケースもあるよ。
MTTRとMTBF、どちらも大切な理由
2つの指標はセットで考えよう
MTTRとよく一緒に出てくるMTBF（Mean Time Between Failures、平均故障間隔）は、片方だけを改善しても不完全なんだ。たとえて言うと、MTBFは「車がどのくらいの頻度で故障するか」で、MTTRは「故障したときにどのくらい速く修理できるか」という感じ。
- MTBFが大きい（あまり壊れない）＝壊れにくいシステム
- MTTRが小さい（すぐ直せる）＝壊れても安心なシステム
理想は「なかなか壊れないし、万が一壊れてもすぐ直る」状態だよ。どちらかだけを追いかけると、もう一方がおろそかになってしまうことがあるから、両方をバランスよく管理することが大切なんだ。
可用性（Availability）との関係
MTTRとMTBFを組み合わせて、可用性（Availability）という指標を計算できるよ。可用性とは「システムが正常に動いている時間の割合」のことで、つまり「どのくらいの時間、サービスが使える状態にあるか」を0〜100%で表したものだよ。
計算式はこうなるよ。
- 可用性 ＝ MTBF ÷（MTBF ＋ MTTR）× 100（%）
たとえばMTBFが90時間でMTTRが10時間なら、可用性は90÷（90＋10）×100＝90%になるよ。よく「99.9%の可用性」とか「Five Nines（ファイブナインズ）＝99.999%」という言葉を聞くけど、これはMTBFをものすごく大きく、MTTRをものすごく小さくすることで実現されるんだ。
DevOpsの世界での位置づけ
ITの世界ではDORA（ドーラ）メトリクスと呼ばれる「開発チームのパフォーマンスを測る4つの指標」があって、MTTRはその一つに含まれているよ。残り3つはデプロイの頻度・変更のリードタイム・変更失敗率だよ。つまりMTTRは「このチームはどのくらい頼りになるか」を測るための世界標準の指標になっているんだ。自分のチームのMTTRを把握して改善を続けることが、世界レベルのエンジニアチームへの近道なんだよ。
