障害発生時の報告書の書き方

普段、お客さまへ提出する障害時の報告書はどのように書いていますか。
(バグ票等のことではありません)

従来は、問題が発生すると第一報として電話等、即報告をしたうえで正式に障害内容をご報告するものです。そのうえで、対策等についての許可をいただくこともあって、この内容は非常に重要です。

障害が復旧し、問題が解決すると、最後に「顛末書」と言う形で正式に謝罪するケースもありますが、ここではその前段階、「障害報告書」について説明します。

障害やトラブルの報告は、対象システムの利用者や関係者など、デリケートな内容なだけ非常に気を使うものです。

障害報告書というのは、対象システムのトラブルや障害によって、ステークホルダーに価値が提供できない状況が発生した内容について説明するためのモノです。

ステークホルダーが、社内宛なのか、社外宛なのか、エンジニアなのか、非エンジニアなのかなど、様々な要因によって内容が異なります。ですので、まず初めに最大限の情報量をまとめて、提示先に応じて報告書として精査しましょう。

システムの障害において、報告内容の項目は大きく10項目に分けられます。

・概要
・日時と継続時間
・対象システム
・障害内容
・障害規模
・発生原因
・暫定対応
・対応経緯
・恒久対応
・（謝罪）

最後の１項目は社交辞令です。

心の底から謝罪の意思があったとしても、それで問題が解決するわけではありませんから、本当の意味で誠実な人はそこに余計な労力をかけません。ですが、一般的には相手の感情を考慮する上でも、無駄とわかっていても添えることが良いとされています。

【概要】

発生した障害について、その文章を読めば「どこで」「なにが」「どうなった」を大雑把に把握できるように記載する必要があります。上司に相談や報告する時と同じく、まず結果から伝えて、その先の詳細な報告内容をいますぐ見るのか、別途ミーティングするのか、あとで見ておくだけでいいのかを相手が判断できる情報を伝えましょう。

悪い例）発生部分が曖昧
　公開されているサイトの中で問題が発生しましたので報告致します。

良い例）
　〇〇サイトの検索機能が利用できない問題が発生しましたので
　報告致します。

　「あ、あそこのことか！」
　「え、あの機能使えないの？」
　「それは〇〇の時なんかに不便を感じるなぁ」

聞く側も「どこで」「なにが」「どんな影響が出るか」イメージができますよね。むしろそうなるような概要でなければ、無価値です。

【対象システム】

組織やサービス運用において目的や用途に合わせて複数で構成されているケースが多いかと思います。障害が発生したのは、何のサービスまたは業務のどのシステムなのかを明確にし、ステークホルダーが自分に関係のあるものなのかを一目で判断できるようにしましょう。

悪い例）イメージ特定ができない
　ホームページの一部

良い例）
　購入サイトの〇〇検索ページ

報告する相手はおそらく１人ではありません。窓口になるのは１人だとしても、その後ろには上司や役員、経営層までいるのが一般的です。それらの方たちにそのまま報告書が転送されても困らない内容でなければなりません。

目の前にいる窓口担当者との間ではツーカーの中だったとしても、その人にだけ伝わればいいというものではありません。こういった報告書は、その報告を受けて『決定／決裁』する人にまで伝わらなければ意味がない、ということを肝に銘じておきましょう。

【障害内容】

なにが起きていたかが明確であれば、その問題の原因を紐解くことができます。障害内容は原因と対応を説明する上で必ず必要な情報です。障害として起きた事象自体をできるだけ具体的に説明しましょう。

悪い例）どんな障害なのかわからない
　サイトに不具合が発生

良い例）
　高負荷によってデータベースが正常に処理できない状態

ここまで状態がわかれば、「なぜ高負荷がかかっているのか？」「どの程度の高負荷までなら耐えられるのか？」といった原因を特定するまではさほど難しくありませんよね。

「不具合が発生した」というのは間違いではありませんが、その話を聞いた側はそれで何をどのように判断すればいいのかわからない…というのは、聞く側の立場になって考えれば自明のはずです。

【障害規模】

すなわち『障害内容』によって引き起こされた

　・これまでの影響範囲／被害範囲
　・これから予測される影響範囲／想定被害範囲

のことです。その障害が発生した際の被害状況は、サービスが提供するはずだった価値にどのような影響があったのかがわからなければ把握できません。障害発生時の影響範囲やその状況を明確に伝えましょう。

悪い例）どのくらいの影響があったのかわからない
　サーバーの不具合でサイトが正しく利用できない

良い例）
　製品サイトの〇〇検索結果のページが表示できない状況が発生。
　直近３ヶ月の利用ログから、検索機能が使えないことによる購買力低下は
　およそ４割減が予測されます。

といった感じです。具体的にどのような影響があるのかをハッキリさせなければ、しかるべき人（たとえば経営陣など）に報告しても、まともに取り合ってもらえません。そうこうしているうちに被害が広がった時、それは必要な決断をしなかった"しかるべき人"ではなく、しかるべき人に決断させるために必要な情報を適切に提供しなかった"あなた"ということになるのです。

【発生原因】

オペレーションミスや原因特定できないなど、報告する側にとって都合の悪いケース、伝えづらいケースも多々ありますが、原因の隠蔽や虚偽はさらに大きな問題を生むことになりかねませんので真摯に伝えましょう。

ここで一番問題なのは「自分は悪くない」という姿勢をにおわせてしまうことです。自分自身が悪いか悪くないかに関わらず、自分自身が関わってしまった以上は同僚であれ、前任者であれ、あるいは他社の人であっても、一括りに『関係者』ですから、当事者意識が必要になります。

だからこそ、「自分自身が発生させた」ものとして扱ってみてください。

悪い例）どんな問題がおきたのかわからない
　ミドルウェアの動作に問題があったため

良い例）
　データベースに処理に数十分かかるクエリーが多発したため

「問題があった」なんてのは報告せざるを得ない状態になった時点でわかっていることです。それをここで復唱しても何の意味もありません。

　「で？」

と言われるのがオチです。ここでは、問題の根本原因を述べるのではなく、発生した原因…つまりはトリガーを報告しましょう。「プログラムのどこどこに誤った処理があった」というのは、あくまで実装レベルの原因です。その処理を利用しなければ問題として気付かなかったはずです。

ここで報告上必要としているのは「そのプログラムをどのような使い方をしたのか」という点です。もちろん根本原因もわかるのであればそれに越したことはありませんが、少なくとも第一報の報告書に記載する必要はありません。仮に聞かれれば、口頭で報告する程度で十分でしょう。

【暫定対応】

障害状態を復旧させた一時的な対応は、再発や似たような問題が発生した際の参考となります。暫定対応として実行したオペレーション内容も含めて詳細に記載しておきましょう。

悪い例）どう回避したのかわからない
　データベースの問題を一時的に回避し復旧

良い例）
　データベース上にあるクエリーキャッシュを削除し復旧

ここでは内容そのものは相手に伝わらないかもしれません。ですが必要です。なぜなら、この報告によって

　①とりあえずの復旧が可能なことを知らせ、安心させる
　②再発時に暫定対応ができるという証明となる
　③運用マニュアル等に記載すれば現地担当でも対応できる

と言ったことが判明するからです。だからこそ、できるだけ具体的…できれば別紙で手順等に起こしておくといいかもしれません。

【対応経緯】

対応経緯を細かく記録し共有することによって、ステークホルダーとの信頼関係を維持することができます。障害内容によっては時間がかかるケースも多いので、時系列に沿って伝えられるようにしましょう。

悪い例）時系列に記述されてない。
　障害検知後に、調査原因特定し対応しました。

良い例）
　XX:XX　監視システムよりアラートを検知
　YY:YY　運用担当者にて調査を開始
　　・
　　・

こちらも運用マニュアルや保守マニュアルに転記する必要があるかも知れないれっきとしたログですので慎重に扱いましょう。ほんの少しでもアバウトな内容になっていると、再発時に別の担当者が誤った操作、処理等を起こしてしまうことにもなりかねず、二次災害の元となってしまいます。

【恒久対応】

発生した障害が、再発の可能性がある場合には原因を追求し解決しなければ、枕を高くして寝ることができません。

恒久対応は改修箇所を見つけるまで長期間に及ぶものもあります。そのため、対応内容だけではなく必要な期間や実施時期など、マイルストーンを立てた上で共有しましょう。

悪い例）いつ具体的に何をするのかわからない
　原因となった問題を特定し対応

良い例）
　１週間程度で原因となったクエリーを実行している箇所を特定し
　問題箇所の改修計画を立てる

あたりまえですが、暫定対応でいかに問題が解消されたかのように見えても、それだけで完了となることはありません。なぜなら、再発する可能性を残しているということだからです。

たとえば、発生時に復旧までにおよそ２時間を要するとして、再発可能性が年に４度あったとしたら、年間８時間。システムのライフサイクルが１０年だとして、計８０時間の稼働停止を余儀なくされるということになります。

もしもこの間に数千万、数億の損害が発生するとしたらどうでしょう？

あるいはシステム障害そのものではなく、その際に利用できない顧客に愛想をつかれて離れていってしまうと、潜在利益を一体いくら失うことになるでしょう？

　『お客さまの身になって考える』

とはそういうことです。それができないのであれば、ビジネスに深く関わるようなポジションの仕事はしない方が身のためです。

【謝罪】

障害は「想定外」であり「不測の事態」なのは周知の事実です。障害によってそのシステムを利用できなかったユーザの方々や、障害が起きた際にご協力頂いた関係者への謝罪と感謝の気持ちはしっかり伝えましょう。

悪い例）障害自体にたいして平謝りになっている。
　問題が発生し障害となってしまい申し訳ありません。

良い例）
　製品サイトをご利用のユーザ様ーへご迷惑をお掛けしました事、
　深くお詫び申し上げます。

エンジニアは技術にプライドを持ちすぎるせいか、技術的な問題を起こしたことに対して誤ればいいと思っている人も多いのですが、お客さまにしてみれば「そんなこと」はどうでもいいのです。お客さまにとって正しく認識してほしいのは

　『迷惑が掛かってしまったこと』

です。しかも、今回の例示でいえば、製品サイトを利用した購買ユーザーにこそ迷惑が掛かっているわけですから、そのことを意識して取り組んでほしいと思っているのです。

謝罪したところで何一つ解決するわけではありませんが、どうせ謝罪するならお客さまはきちんと誠意をもって謝罪してほしいと思っていることでしょう。少なくとも、勘違いした謝罪なんて何一つ嬉しくは思いませんし、むしろ今後も信用していいか悩むのではないでしょうか。

最後に

対策中の場合は、こうした報告書を書かないケースもあるかと思いますが、実は対策をしている担当者ではなく、管理者や管理職の人がこうした一手間をかけるだけで、お客さまの怒りを抑え、信頼を損なわないようにすることが可能なのです。

また、会社の中でもこうした情報はデータベース化して蓄積しておくと、類似の問題が発生した際などにも対策そのものの再利用が可能になり、より短期間、低コストで解決できるようにもなります。