← エピソード一覧に戻る Episode 172 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 23分で883サイトが消えた
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発のインシデント対応を扱います。Atlassian の公開 PIR では、2022 年 4 月の障害で 883 サイトが 23 分ほどで削除され、775 顧客が製品へアクセスできなくなりました。復旧力だけでなく、指揮と説明の型が問われた事例です。
ミカ
ミカです。23 分でそんな規模になると、技術トラブルというより会社全体の非常事態ですね。しかも SaaS って、止まった瞬間にお客さんの業務も止まるから、復旧だけじゃなくて連絡の遅れもかなり痛そうです。
タカシ
その通りです。前回の SLO 設計が『どこまで守れれば十分か』を決める話だとすれば、今回は『割れそうなときに誰がどう動くか』を決める話です。SaaS のインシデント対応は、ヒーローが頑張る話ではなく、混乱を組織化して信用を守る経営オペレーションなんですね。
ミカ
なるほど。障害対応ってエンジニアだけの話だと思いがちですけど、実際は CS、営業、広報、経営まで巻き込む総力戦なんですね。今日は、severity の決め方や Incident Commander の役割、それから顧客告知の勘所まで知りたいです。
Chapter 2 原則 ― インシデント対応はヒーロー戦ではない
タカシ
Google SRE では、主要な役割を Incident Commander、Communications Lead、Ops Lead に分けています。重要なのは、いちばん詳しい人が全部を持たないことです。司令塔は優先順位を決め、技術担当は復旧に集中し、コミュニケーション担当は社内外の説明を担う。これで初めて復旧速度が安定します。
ミカ
よくあるのは、詳しい人に質問が全部集まって、その人が Slack と Zoom とコード修正を同時に回している状態ですよね。現場では頑張っているのに、いちばん重要な人の手が止まる。あれは仕組みの問題なんだと分かります。
タカシ
もう一つ大事なのが severity です。SaaS では CPU 使用率より、『何社に影響したか』『ログインや課金が止まったか』『データ損失の疑いがあるか』で P1、P2 を切るべきです。GitLab も incident management で、機能停止やサービス劣化を基準に即時対応レベルを分けています。
ミカ
サーバーの中だけ見ていると、顧客の痛みとズレるんですね。社内では『一部機能だけ』でも、お客さんから見たら請求が止まっているなら完全停止に近い。SaaS の severity は、技術障害の大きさより事業インパクトで決めるべきなんだなあ。
タカシ
その視点が重要です。さらに Google SRE は、ライブの incident document と明確な handoff も重視しています。夜をまたぐ障害では、誰が今の Commander なのか、何が事実で何が仮説なのかを残さないと、朝になるたびに同じ議論をやり直すことになります。
ミカ
『昨日の夜に分かっていたこと、どこ行ったの』ってやつですね。特に海外拠点やオンコール交代がある SaaS だと、引き継ぎの雑さがそのまま復旧遅延になりそうです。口頭の雰囲気じゃなくて、残る形にしておく必要があるわけですね。
Chapter 3 具体例 ― AtlassianとGitLabに学ぶ
ミカ
実際の SaaS 企業は、障害の中で何に苦しんでいたんでしょう。技術的な復旧が難しいのは想像できますけど、経営目線だと『どこで信用を失ったか』が気になります。公開事例から見えるポイントを知りたいです。
タカシ
Atlassian の 2022 年障害では、major incident process を起動して 24 時間体制のチームを組成しました。それでも PIR では、広い外部告知の最初のメッセージが 4 月 7 日 00 時 56 分 UTC だったと明かしています。しかも影響顧客の主要連絡先を取るのに日単位で苦戦しました。つまり、復旧だけでなく連絡網が弱かったんです。
ミカ
技術的には必死に動いていても、お客さんから見たら『何が起きているか分からない時間』が長いわけですね。しかも連絡先が取れないと、CS や営業も個別回答に追われて、現場の混乱がさらに増える。告知の設計って、本当に障害対応そのものなんですね。
タカシ
PIR でも、その反省から large-scale incident communications playbook の整備、複数チャネルでの早期告知、主要顧客連絡先のバックアップを明示しています。SaaS では status page だけ置いて終わりではなく、誰にどう届けるかを事前設計しないと、重大障害ほど伝達が崩れます。
タカシ
GitLab の 2017 年データベース障害も象徴的です。公式 postmortem では、長時間の停止に加えて、約 5,000 projects、5,000 comments、700 new user accounts に関わる更新を失ったと公表しました。痛いのは事実ですが、CEO 名義で謝罪し、何が起きたかと再発防止を詳しく公開した点は学ぶ価値があります。
ミカ
失敗を公開するのは怖いはずなのに、そこまで出したんですね。でも SaaS って、隠した瞬間にもっと信用を失いそうです。『完全に防げる会社』より、『失敗したときに事実を出して学べる会社』のほうが、長期では強いのかもしれません。
タカシ
現在の GitLab Handbook では、Incident Lead、Responder、Communications Manager を置き、incident channel、Zoom、共有ドキュメント、status.gitlab.com 更新まで運用化しています。重要なのは、良い対応を個人の経験則にしないことです。事故の後に、仕組みに変えられる会社が強い。
Chapter 4 失敗パターン ― 司令塔不在と沈黙
ミカ
逆に、インシデント対応が弱い会社って、どこで崩れやすいんでしょう。障害そのものより、運用の悪さで傷口を広げているケースが多そうです。経営者が先に見抜いておくべき危険信号があれば知りたいです。
タカシ
典型例は五つあります。severity が曖昧で招集が遅れる、司令塔がいない、顧客告知が遅い、handoff とログが弱い、postmortem が犯人探しになる。このどれか一つでもあると、障害の技術原因より組織原因のほうが復旧を遅らせます。
ミカ
『詳しい人が全部やる』と『偉い人が途中で口を出す』も危なそうです。現場ではよかれと思っていても、指揮が二重になると、誰の判断で何を優先するのか分からなくなる。火事場でハンドルが二つある車みたいなものですね。
タカシ
PagerDuty はまさにそれを Executive Swoop と呼んでいます。障害中に上位者が善意で介入しても、指揮系統を乱せば復旧は遅れます。大口顧客の問い合わせや役員報告は大事ですが、それを Commander 以外へ直接投げると、最も価値の高い復旧時間を奪ってしまうんです。
ミカ
あと、SaaS だと『まだ原因が分からないから黙っておこう』も危ないですね。原因不明でも、影響範囲と次回更新時刻だけ出せば、お客さんは少なくとも待ち方が分かる。沈黙は不誠実に見えるし、CS と営業の負担も一気に増えそうです。
タカシ
その通りです。SaaS のインシデント対応で守るべきなのは uptime だけではありません。顧客の意思決定材料も守る必要があります。だから一次報告では『何が起きたか』『誰が影響を受けるか』『次回はいつ更新するか』を短くても必ず出す。これが信頼を削らない最低ラインです。
Chapter 5 クロージング ― 明日から整える5つの型
ミカ
今日の話を聞くと、インシデント対応って『障害が起きたら頑張る』ではなく、『起きた瞬間に迷わない型を先に作る』ことなんですね。最後に、経営者や開発責任者が明日から着手できることを整理してもらえますか。
タカシ
まず、P1 から P3 までの severity を顧客影響で決めること。次に、Incident Commander、技術対応責任者、顧客コミュニケーション責任者を当番表まで落とすこと。さらに、30 分以内の一次報告テンプレート、status page 更新フロー、48 時間以内の blameless postmortem をセットで用意してください。
ミカ
テンプレートや当番表って地味ですけど、いざという時にはむしろそこが信用を守るんですね。派手な監視ツールより先に、誰が何を言うかを決めておく。SaaS では、その地味な準備が『止まった後の継続率』まで左右するんだなと感じました。
タカシ
今日は、SaaS 開発のインシデント対応を見てきました。SLO が平時の約束だとすれば、インシデント対応は非常時の約束です。障害をゼロにはできなくても、混乱を減らして信頼を守ることはできます。ぜひ皆さんの組織でも、次の障害が来る前に型を整えてみてください。
ミカ
ミカでした。次にサービスが揺れたとき、『誰が指揮を執るのか』を今すぐ答えられるか、ぜひチームで確認してみてください。それでは、また次回お会いしましょう。