01.障害報告とは何かを考える

障害報告とは、障害の「発生」「経過」「復旧」更には「事後策(再発防止策)」を、関係者に説明し、理解していただき、(もし必要であれば)システム外での対応をしていただくための報告である。言い訳をする書面ではない。
なお障害報告とは、一義的には「関係者への説明責任」であるが、前広に適切な情報を公開する事により「関係者からの直接照会を防ぐ」効果も期待できる。
障害発生時の個別対応は、マンパワーが不足している際には結構辛いもの。これを防ぐ事により、障害を復旧する立場、それを待つ立場の双方にメリットがある。

02.フェーズ毎に報告すべき事象を意識する

報告のフェーズおよび記載ポイントは、以下のように大別できる。

03.素早く、適宜書く。

• 原因を特定してから報告したい、なるべく正確に報告したいという思いは報告の遅延を招く。でも、特に発生タイミングにおいては、正確さ、うまさより「迅速さ」が肝要。
• 初期状態で関係者が求めるのは「原因」ではなく「事象」と「影響範囲」。すなわち最初から原因を記載する必要はない。

04.迷ったら書く。

• 影響が発生しているかどうか不明瞭な場合は、確定ではない事を申し添えた上で記載してしまう。
• 基本的には「バッドシナリオ」で見積もる。後からシナリオが悪化する方が、影響も被害も甚大になる。

05.簡潔に書く。

• 詳細な説明は最後で良い。治すのは報告者なのだし、障害究明の中で見立てが二転三転する事もある。障害対応中の詳細は報告者がわかっていれば良い。
• 「誰のせいか」は、一部の例外を除き記載してはならない。障害復旧には全く役に立たないし、反感を買うだけだから。
• 一部の例外とは、「あなたのせい」「インフラのせい」「法整備やルールの論理不整合(取り決めのせい)」「自然災害、火災などの突発的事故に伴うもの」。

06.こちらで起こっていることではなく、あちらで起こることを書く。

• 自分がやっている事ばかり喋ってる、専門用語が多過ぎるパターン。事件は会議室ではなく現場で起きている。原因ではなく、事象を意識する事により、「結局何が起こっているのか」「何が起こっていないのか」を説明する。その事により、関係者が不具合を発見してくれることもある。
• 例えば「Apacheが動作を停止している」と書かず、「設置されたウェブサイトが閲覧できない状況にある」と説明する。
• 例えば「ネットワークの不具合により閲覧できない」だけでなく、「ネットワークの不具合によるものですので、サーバに設置されたデータに問題はありません」と併記する。

07.相手が計画できるように報告する。

• 不具合が発生した場合、関係者ができる事は限られている。迅速な復旧も大切だが、それが無理な場合、それとわかるように報告する。
• 具体的には、夜間に差し掛かる場合、「今日はもう諦めて、帰って寝てください」と匂わせる。この「匂わせ」が無いと、無意味に夜間対応する人が増える。そういう人は怒りを募らせる。
• 万が一完全に復旧できない事態が発生する場合(または予見される場合)、関係者はシステム外の対応を迫られる事になる。このリリースの遅れは関係者の社会的信用の失墜に直結するため、道義的にも実務的にも予めバッドシナリオに向けた準備ができるよう説明を行うべきである。

当たり前だけど、障害は発生して欲しくないもの。
でも、多かれ少なかれ起こるものでもある。
有事の際こそ、落ち着いた関係者への報告を心掛けたいものである。

参考

悪い例を紹介しよう。
これは某レンタルサーバ管理会社で実際に発生した障害状況にかかるプレスリリース。

発生日時 ： 2013年06月26日 12時07分頃 – 06月27日 01時50分頃
サーバー ： xxxxxxxxxx(筆者による伏せ字)
障害内容 ： サーバーに接続できない状態
障害状況 ： 筐体交換作業を実施中です。
障害原因 ： 調査中

筐体交換作業に加え、データ保全のためのコピー作業を実施しているため、
復旧見込みが19時半頃を予定している状況でございます。

ご迷惑をお掛けしております事を重ねてお詫び申し上げます。
サーバー復旧まで、今しばらくお待ちいただけますようお願いいたします。

■19:20分追記
データ保全のためのコピー作業に時間がかかっており、復旧見込みが
21時半頃になった旨をサーバー管理元から連絡を受けました。

ご迷惑おかけしており、誠に恐縮ではございますが、
復旧まで今しばらくお待ちいただけますようお願い申し上げます。

■06月27日　06月27日　10:25分追記
筐体サーバーが本日01時50分に起動いたしましたが、
MYSQLが正常に動作できていないようなので引き続き調査中です。
長らくにわたりご迷惑おかけし大変申し訳ございません。
MYSQLに関しましては今しばらくお待ちいただけますようお願い申し上げます。

問題点は以下の通り。

• リリースのサイクルが遅過ぎる

・最初の報告から次の報告が7時間、その次が14時間。その後6時間、営業時間帯にもかかわらず報告が無い。

• 適宜報告されていない

・復旧見込み時間を21:30と設定しながら、それが遅延した際の報告は無い。

• 何が起こっているかが示されていない

・「サーバに接続できていない」の後、唐突に「筐体交換を実施中です」となる。どうして筐体を交換するのかがわからないので、どこまでマズいのかが判断できない。
・「筐体サーバ」などと意味の分からない言葉が出てくる。

• 専門用語のみで説明し、影響が示されていない

・「MYSQLが正常に動作できていない」ではなく、「データベースが正常に動作できていないため、データベースを用いたサイト、システムが利用できない状態にあります」と記載すべき。

• 内部での責任転嫁をしている

・ユーザにとっての「サーバ管理元」はあくまでもこの会社。中で再委託していたとしても無関係(反感だけを買う記載)。

• 記載内容に不整合がある

・障害中にもかかわらず終了時刻が示されている(筐体交換の段階で「終わった」イメージでいる)
・この段階での障害状況は「筐体交換作業を実施中」ではない。

で、最も重大な事。

• 障害を過小評価している

・事実、現時点で発生しているのは「MYSQLの不具合」ではなく、「MYSQL環境の初期化」である。サーバの挙動からこれに気づいているユーザは恐らく結構いる筈だが、運営側はそれを隠せていると誤認している。
・ユーザが知り得ている情報とリリースの内容が相違しており、且つユーザが知り得た情報の方が、リリースの内容より重篤な状態事態となっているため、不信感を募らせている。
・結果、僕はこの会社に再三メールでの照会を行う羽目になっている。明らかに、双方にとって不毛である。

追記:この後、リリースが更新され、そこにはこの文言が追記されていた。

■06月27日　15時58分追記
MYSQL不具合に関しまして現在も復旧作業中でございます。
物理データは存在しており問題はございませんのでご安心ください。

また、進捗あり次第で情報更新いたしますので、誠に恐れいりますが、
今しばらくお待ちいただけますようお願い申し上げます。

概ねここに記載した事について僕がメールで要請した内容が反映された模様である。