障害報告書の書き方

要点

専門用語を極力使わず、わかりやすい言葉で書く
原因(または推測原因)を書く
それに対する今回行った対策
実施の影響
恒久対策

謝罪、言い訳、責任回避に見える報告書はだめ。

お客さんは原因と対策、復旧の目処を知りたい。

報告書は安心させるため。
障害は責任持って復旧を行う。

重要

ただ損害賠償問題にならないように。そういう責任はこないようにする。
作業実施前に開発ベンダーに相談したり、色々対応を行っておく。

復旧対応する前にやるべきこと

タイムラインの記録
ログ, 障害メモリダンプデータの保全
show系コマンドによるミドルウェア等のステータスのキャプチャ
監視サーバのリソースグラフの取得
障害のトリガーが把握できるとベスト
ユーザ使用が起因の場合、顧客にヒアリングを行いどういう操作をした時に起きたのか。

上記を行わないとまともな報告書が作れない、どこに問題がおきているかを特定する。

また、障害復旧を優先すると、障害時の情報がふっとんで報告書を作ることが困難になる場合がある。状況の保全を迅速に行う。そのためにはミドルウェアに関するケース毎のshow系の情報を把握している必要がある。

障害原因と復旧方法が明らかな場合は即時復旧を優先させる。

実施

グラフからおおよそのクリティカルな障害日時、前兆の特定
日時からログの確認
ログやバージョンから似た症状を探す。またはバグや脆弱性がないか、似た事象を探す

根本原因の把握したら復旧の一時対応を行う。

根本原因の改善は恒久対策として実施する。

経験重要よく触っておく

Linux系のミドルウェアはSHOWやログ、症状からすぐに原因がわかることが多いです。

経験も重要で、構築を何度も行ったり、運用方法、ディレクティブやミドルウェアやシステムの挙動に精通していることが重要。

オリジナルのシステムなら、

仕様の把握は勿論、プログラムやクエリが読めないといけないです。

関わるシステムのプログラム言語やフレームワークは読み書き、アプリが作れるようにしておく。

障害の復旧はシステムを俯瞰して、切り分けを行って論理展開が大事。

腕の見せ所。

復旧や対策がすぐに実施できない場合

復旧の目処や根本対策の目処を必ず書く。
それがわからないとお客さんは安心できない。

ブラックボックスになっているWindows系ミドルウェアの不具合は、アップデートの実施などで最新に保つ。バックアップやメンテナンスの定期実施などを行うとする対策を説明するしかない場合がある。

報告書の注意

報告書によりお客さんを安心させれないと仕事を失ってしまうこともありうる。

また逆に、信頼に繋がることにもなるはず。

メモ

単純な現状の記述や、責任逃れの言い訳に終始しており、とても報告書と呼べるものではありません。これでは、信頼回復の糸口になるどころか、さらに先方の不信感を増大させてしまうでしょう。

簡潔で、きちんと伝わる報告書にするには、状況を整理して、伝えるべきことを順序立ててきちんと記述することです。トラブル報告書には主に次の事項を記述します。

この報告書を作成した趣旨・目的

トラブルの状況や内容

トラブルが発生した原因

今後の対応策（または対応方針）と対応完了時期

以上の事項を、下記の例のように、それぞれ別々の項目に分けて構成し、読みやすい文書にします。トラブル発生時に、応急処置的にトラブルを拡大させないように対処した（あるいは一時的にトラブルを回避するように対処）のであれば、状況・内容と一緒に、その対処も記述します。

　貴社ますますご清栄のこととお喜び申し上げます。

報告書の趣旨・目的を記述する
（例：ここに、今回のトラブルの原因、対応策につきまして下記のようにご報告申し上げます。）

1　トラブルの状況

発生したトラブルの状況や内容を簡潔に、顧客が把握できるように記述する

2　トラブルの原因

発生したトラブルの原因となる事象を簡潔に記述する

3　対応策と今後の方針

完了した対応策、現在取り組んでいる対応策、今後実施する対応策を簡潔に記述する