YO茶の足跡残す日記

日々感謝の気持ちで、思う事をいろいろ書いていきます。

障害原因がわからないときの報告書の書き方

はい、わたくしは長期休暇に入りました。なんと!2週間もお休みでございます!


イヤッホォォォーーーー!!!!



とはいえ、土日はそれほど大きな行動はできません。家族との時間となりますので。今週は沖縄へ行ってきます。そこでかねてから訪問したかったいろんな場所へ行ってきたいと思います。



さて、タイトルの件。これはすべての場合に当てはまるのではないですが、通信機器やソフトを扱うメーカーの方には多少参考になるのかなと思います。


ずいぶん前のことですが、あるお客様で大トラブル(本当に大トラブルでした)に見舞われました。あるシステムが、日本国内全拠点の半数で全く使用できなくなるというトラブルがありました。これによって、お客様からの発注が午前中できないという状況となってしまい、それはお客様にとっても、メーカーとしての我々としても、とんでもない危機的な状況となったのでした。



お客様は上層部レベルまで報告が上がる第一級の障害となり、24時間態勢で対応がはじまりました。



当然ながら、障害対応部隊にエスカレーションがかかりました。現地で取得していたログの解析がはじまります。すると、発生した原因(事象)はログからつきとめられたのですが、なぜその事象を引き起こしてしまったのかというトリガーがログからはどうしてもわかりません。実は、お客様があるイベントを行われ、それが原因で引き起こした可能性が限りなく高いのですが、再現検証を行っても全く再現できないのです。



そんな状況でも報告書は出さないといけません。チームメンバーは悩みに悩んで報告書を仕上げました。その最終報告書はどのような組み立てのレポートとなったか。こんな感じとなりました。




1.お詫びの言葉:
 →これは枕詞みたいなもので、この手の文章には必ず最初に書きますよね。


2.事実の整理:
 →実際発生した現象、そして実施した対応などの事実を時系列に記載する。


3.ログの解析結果:
 →収集したログから確認できた内容について、上記時系列の事実を補足する。


4.原因の考察:
 →発生した問題について、論理的に考えられる想定原因をここで記載する。
 →これは、エンジニアがログ、状況証拠などから頭をひねらなければならない腕の見せ所です。ここの推論がしっかりしていないと、この後の展開がうまく進みません。


5.内在するソフトウェア不具合:
 →上記推論によって問題が発生するということに関係しそうな、現在使っているソフトウェアバージョンに内在する不具合を調査する。
 →うちの会社の場合、ソフトウェアバージョンによって内在する不具合の管理がしっかりしていて、比較的検索がしやすいツールがあったりします。そこで、関係しそうな不具合を探して列挙する。(ここでは、実際にそれが真犯人だ!という不具合を探し当てるのではなく、同じような現象が発生する不具合を探すのです。その発生条件はこの際関係ありません。)


6.結論:
 →4.で推論した想定原因がなんらかの理由で発生し、それによって、5.で列挙したソフトウェア不具合にヒットした。
 →この結論を出すために4.と5.の項があるのです。


7.今後の対応策:
 →5.で列挙したソフトウェア不具合が修正されたバージョンのSWにバージョンアップする。



もちろん、このパターンがすべての報告書にあてはまるとは思いません。SWも最新のものを使っていたら開発サイドに改修を依頼しなければなりません。今回は、限りなく「これをやったから」というイベントがあったのですが、それがクロだという裏取りができなかったのでこういう報告書となりました。



一番の肝は、4.です。結局ここをロジカルに理屈つけられるかが一番のポイントです。エンジニアの技量が問われるところです。



また、この手の報告書を書くときは、Powerpointを使うよりもWordの方が良いです。フォントも、ゴシック体ではなく明朝体を使った方がかしこまった感じになって、お詫びをしているような雰囲気が出ます。



またこういうことを書かないといけないかもしれないときの自己メモとして書いておきました。



エンジニアの皆さん、何かの参考になれば幸いです。




#日々感謝 m(_ _)m