約束できるのは解決時刻ではなく次の報告時刻だ

一言でいうと

FDEの障害対応は、システムではなく報告書で終わり、技術的に完璧に直しても、報告が遅かったりあいまいだったりすると、顧客の記憶には不安だけが残ります。

なぜ必要なのか

8つの技術ドメインのうち、顧客とのコミュニケーションだけは技術ではありません。ところが、残りの7つを顧客に届ける経路がこれなので、ここが詰まると、診断が合っていてもプロジェクトが失敗します。

最もよくある失敗は、期待値の管理から出てきます。そして、その失敗は、たいてい約束の単位が間違っているために起きます。

原因がわからない段階で「午後までに解決します」と言うのは、約束ではなく賭けです。約束できるのは、解決の時刻ではなく、次の報告の時刻です。「1時間後に、わかっていることとわかっていないことを整理して報告します」は、いつでも守れて、守られるたびに信頼が積み重なります。

音沙汰のない20分は、顧客の想像の中で、障害を2倍に大きくします。そのため、障害中の最初のメッセージに、周期が入っている必要があります。「復旧まで30分ごとに報告します。」

どう動くのか

障害報告書の構造は、平常時の文書と順序が違います。平常時は背景から書きますが、障害報告書は影響から書きます。

영향     : 결제 API 5xx 비율 평시 0.1% → 최대 7% (14:10–15:40)
현재 상태: 완화 조치 적용 완료, 오류율 평시 범위로 복귀 확인
잠정 원인: 14:05 설정 배포에서 DB 커넥션 풀 크기 축소
다음 단계: 원복 완료. 재발 방지로 배포 전 설정 diff 점검 절차를 제안 예정

このコードブロックの韓国語は、4行の項目名と内容を示しています。影響(決済APIの5xx比率が平常時の0.1%から最大7%に)、現在の状態(緩和措置の適用が完了し、エラー率が平常範囲に戻ったことを確認)、暫定原因(14:05の設定デプロイで、DBコネクションプールのサイズを縮小)、次のステップ(元に戻し済み。再発防止として、デプロイ前の設定diffの点検手順を提案する予定)です。

読む人が最初に知るべきことは、「いま誰が何をできないのか」と「いまは大丈夫か」です。原因の分析は、気になっても、その次です。原因から書いた報告書は、3段落を読まないと今の状態がわからず、役員が読む文書では、その3段落は読まれません。

そして、ルールがあと3つあります。

数字で書きます。「多くのユーザーが影響を受けました」ではなく、「500の応答が、平常時の33件から、1分間で70件に」です。形容詞は、読む人ごとに違う解釈をされ、その差があとで紛争になります。

人を主語に書きません。「担当者が設定を間違えて変更したため」ではなく、「設定の変更以降」です。顧客企業の報告書に特定の担当者が名指しされると、次の障害で、その人は情報を隠します。非難のない報告書は、道徳ではなく、次の診断の速さを買う投資です。

専門用語を翻訳します。「Podが再起動ループに陥りました」ではなく、「サーバーが停止と起動を繰り返している状態なので、接続が切れます」です。ステータスコードも同様です。500という数字は、エンジニアにだけ意味があり、顧客には「決済が失敗しました」が必要です。

現場での姿

同じ状況で、信頼を削る文と、積み上げる文が分かれます。

原因がまだわからないときに、「こちら側の問題ではないようですが」は、防御です。「いままでに、ネットワークと認証は正常であると確認しており、データ層を見ているところです。30分後に中間結果を共有します」は、同じ状態を述べながら、信頼を積み上げます。

違いは3つの要素です。確認された事実、いま行っていること、次の報告の時刻。この3つが入っていれば、原因がわからない状態でも、報告が成り立ちます。

最後にエスカレーション。これは失敗の自白ではありません。30分以内に進展がなければ上げるという自分のルールを、あらかじめ決めておけば、上げる決定が感情ではなく手続きになります。顧客の前で「専門の人員を投入しました」は、無能のシグナルではなく、対応のシグナルとして受け取られます。

障害が終わったあとの対話

復旧が終わると、対話の性格が変わります。障害中は「いまどうなっているか」でしたが、終わったあとは、「なぜ起きて、再び起きないのか」になります。この問いに答える文書は、障害中の報告とは別のものである必要があり、数日以内に出す必要があります。1週間が過ぎると、人々の記憶がお互いに食い違ってきて、事実確認そのものが難しくなります。

入れるものは4つです。時系列の記録、原因、なぜ発見が遅れたのか、そして何を変えるのか。3つ目が最もよく抜けますが、実は、ここから出てくる改善が最も価値があります。30分で直せたのに、気づくのに2時間かかったなら、直す手順ではなく、気づく仕組みを手入れする必要があります。

改善項目を書くときは、誰がいつまでに行うかが、一緒に書かれている必要があります。担当と期限のない改善リストは、次の障害報告書に、まったく同じ形で再び書かれます。そして、項目が10個あると何も実行されないので、本当に効果が大きい2、3個だけを残し、残りは書いておきつつ、やらないと明記するほうが、誠実です。

ここで、FDEの立ち位置を押さえておく必要があります。改善を実行するのは、たいてい顧客企業の役割で、こちらは根拠を作る側です。そのため、「こうしなければなりません」より、「この値がこう出ていて、これをアラートに設定すれば、次回は30分以内にわかります」のほうが、はるかに受け入れられます。判断の材料を渡して、決定は顧客にしてもらうことが、結果的に、より多くの改善が実際に実行されるようにします。

最後に、うまくいったことも書きます。ロールバックが5分でできたなら、それは誰かがその手順をあらかじめ作っておいたおかげで、その事実が記録されなければ、次にそのような準備をする理由がなくなります。障害報告書が悪いことだけを集める文書になると、人々はその文書を書くのが嫌になり、そのときから、記録そのものがなくなります。

次のラボですること

前の3つのコースで見つけた値を材料に、必須の節が揃い、数字が入り、人を名指しせず、顧客向けの要約が技術用語なしで書かれた、障害報告書1枚を作ります。採点は、文の良し悪しではなく、その条件を満たしているかどうかだけを見ます。