← エピソード一覧に戻る Episode 168 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 壊すより戻せないほうが痛い
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発の平均復旧時間を扱います。Google Cloud が紹介した METRO.digital の事例では、MTTR を 80% 改善しています。作る速さだけでなく、戻す速さが競争力になる時代なんですね。
ミカ
ミカです。前回の変更失敗率で『壊したかどうか』を見たので、今日は『壊したあとにどれだけ早く戻せるか』ですね。なんだか救急外来みたいで、経営なのにすごく現場感があるテーマです。
タカシ
その感覚で合っています。SaaS は一つの障害が全顧客に波及しやすいので、平均復旧時間が長いほど売上、SLA、更新交渉、紹介まで全部に響きます。障害ゼロを目指すより、まず速く止血できる組織を作るほうが現実的なんです。
ミカ
なるほど。転ばないことより、転んだ瞬間にすぐ立ち上がれる体制が大事なんですね。しかも SaaS だとお客さんは待ってくれないから、復旧の遅さってそのまま信用の借金になりそうです。
Chapter 2 定義 ― MTTRと復旧の言葉を雑に使わない
タカシ
まず定義です。DORA は 2023 年に、従来の MTTR や time to restore service を failed deployment recovery time へ再定義しました。デプロイ起因の障害から、どれだけ早く戻せたかに絞ったわけです。
ミカ
へえ、言い換えじゃなくて対象を絞ったんですね。ということは、クラウド障害とか外部 API 障害まで全部混ぜると、デプロイ品質の指標としてはぶれてしまうってことですか。
タカシ
その通りです。ただ SaaS 経営では、DORA 用の failed deployment recovery time と、サービス全体の MTTR の両方が必要です。前者は変更の質を見るため、後者は顧客影響と運用成熟度を見るため、と役割が違います。
ミカ
同じ復旧時間でも、会議で何を決めたいかで数字の意味が変わるんですね。ひとつの MTTR だけ見て『高い、低い』と言っても、打ち手がずれそうです。
タカシ
さらに GitLab は、impact mitigated と end time を分けて考えています。つまり『止血できた時点』と『完全復旧した時点』は別です。feature flag を切って顧客影響を止めても、データ補正や検証が残っていれば、まだ完全復旧ではありません。
Chapter 3 具体例 ― 速い復旧は仕組みで作る
ミカ
実例で聞きたいです。平均復旧時間を縮める会社って、やっぱりすごいエンジニアが夜中に全部直しているんでしょうか。それとも、もっと再現性のあるやり方があるんですか。
タカシ
METRO.digital はそこが面白いです。17 カ国で 5 万社の B2B 顧客を抱える M.SHOP で、MTTR を 80% 改善しつつ deployment frequency も 43% 改善しました。鍵は、200 超のマイクロサービスを自律チームで疎結合に運用したことです。
ミカ
つまり、障害が起きても被害を小さく閉じ込められる構造があるから、復旧も速いわけですね。全部が一本の大きな塊だと、戻すたびに全社総動員になってしまいそうです。
タカシ
もう一つ、Favor では incident 立ち上げの手作業が 30 分近くかかっていましたが、自動招集や役割付与を整えて MTTR を 37% 削減しました。しかも detection は 214% 増えて、重大 incident はむしろ減ったんです。
ミカ
検知件数が増えたのに健全化した、というのが面白いですね。見つかる障害が増えたというより、小さいうちに拾えるようになったから、大きい事故になる前に止められたと。
タカシ
そうです。Intercom も、PagerDuty と Statuspage を分散させていた体制を集約し、incident time を 40% 削減し、postmortem 公開を 3〜5 日から 24 時間以内へ短縮したと紹介されています。復旧はコードだけでなく、説明責任まで含めて速くする競争なんです。
Chapter 4 失敗パターン ― 直したつもりで終わらせない
タカシ
平均復旧時間でよくある失敗は、復旧を一つの時刻でしか見ないことです。止血、完全復旧、顧客告知完了を分けないと、現場は数字を短く見せるために『とりあえず動いた』時点で終わらせがちになります。
ミカ
確かに、画面は戻ったけど請求データの整合は後回し、みたいな状態で『復旧しました』と言われたら、営業も CS も困りますね。顧客から見たら、まだ終わっていないですもんね。
タカシ
もう一つは、診断と招集を軽視することです。Atlassian は調査と診断に MTTR の 70% が使われやすいと紹介しています。つまり修理手順より前に、誰が集まり、どのログと runbook を見て、誰が意思決定するかが遅い会社ほど長引きます。
ミカ
復旧が遅い原因って、実はコードを書く速さじゃなくて『どこで何が起きているか分からない』『責任者が決まらない』だったりするんですね。ここ、経営の設計ミスでもありそうです。
タカシ
まさにその通りです。毎回同じ SRE しか戻せない属人運用、status page 更新が手作業、feature flag や kill switch がない、といった状態では、会社が伸びるほど平均復旧時間は悪化します。成長前に型を作るのが大事なんです。
Chapter 5 クロージング ― まず最初の10分を短くする
ミカ
今日の話を聞くと、平均復旧時間って『障害対応チームの成績表』じゃなくて、経営がどれだけ止血の仕組みを用意できているかを見る数字なんですね。特に最初の 10 分がすごく大事だと分かりました。
タカシ
実務では、開始、検知、初動開始、止血、完全復旧、顧客告知完了の六つの時刻を残してください。そのうえで rollback、flag off、runbook、自動招集、status page 更新を整える。これだけで平均復旧時間の議論はかなり具体的になります。
ミカ
皆さんの組織でも、最近の障害を一件だけ選んで、その六つの時刻を出してみると良さそうですね。『遅かった』で終わらず、どこが遅かったのか見えるだけで、次の投資先がかなり変わりそうです。
タカシ
今日は SaaS 開発の平均復旧時間を扱いました。次回は、そもそも壊れにくく、速く出しやすい仕組みとしてのテスト自動化を取り上げます。ではまた次回、お会いしましょう。