下請けCOBOLERとして生きていた頃のノウハウ Advent Calendar 2016の16日目ぐらいの記事です。
皆さん、エクセル.xlsを書きますよね？
僕は保守チームにいたのでよく、障害報告書を書いていたのでその際のノウハウだけ書きます。
(面倒なので.xlsは作りません)
なるべくA４縦一枚に収まるように書こう！
プロパーさんが読んだりスクリーンに投影した資料を説明する際にあっちこっちに移動すると分かりにくくなります。
なるべく、A4縦一枚で書くのがコツです。余計なものはどんどんそぎ落としましょう
章立てのパターンを決めよう
自分なりのテンプレートを作ってしまえば章立てや話の流れを考えなくて済みます。
ちなみに自分の章立てはこんな感じです(2年以上昔の話なので若干怪しいですが)
■きっかけ
事件のきっかけをかく(12月20日 ABC１２３４のジョブでABENDが発生 とか 12月20日 お客の凸凹様より不正なデータがあると問い合わせ)
■直接原因
問い合わせが来た直接の原因を書く、ようするにバッチが落ちた理由、変なデータをセットしている直接の原因を書く
(数字型を想定していたところに文字列が来た、ジョブの先行関係がきちんとかかっていなかったので前日のデータで処理を行った・・など)
■根本原因を書く
ここは直接原因と根本原因が同一であれば書かなくても良いです。が、だいたい巨大システムに触れていると、直接原因と根本原因はだいたい別物です。ここではできればソースも交えて説明すると分かりやすいと思います。
(例：オンラインの処理で数字しか受け付けない想定の所にaなどの文字が入るようになっていた。
3つ前のバッチ処理での条件分岐とデータセットがおかしかった等)
■修正案を書く
上の根本原因で修正するべき箇所が分かると思うので、それの修正案を書きます。
ちょっとした直しならこう直しますって宣言しても良いと思います。
また、それに伴う単体テスト/結合テストの工数(目安の日数)なんかも出せればかっこいいですね
■今のデータの復旧案を書く
でかいところだと原因が判明して一瞬で直せるような修正でも早くて一週間かかります。
お客さんに説明→人員の調整→要件定義的なもの→結合試験書→詳細設計書・単体テストケース→製造→単体テスト→結合テスト→お客さんテスト・確認→リリース準備(疎通確認・初動確認方法など)→リリース
この流れは絶対でしたので紙ペラ一枚でもとにかく積み上げるものは作らなければいけません。
なので、今おかしくなっているデータを何とかしなければいけません。
その為にデータをアップデートするSQLとかホストのデータの修正用ジョブの作成、外部連携してしまったデータをリリース後に全部作り直して送り直すなどの作業も必要になります。
筆者は異常なデータを外部連携してしまったことが分かったケースでは問題の修正後に数ヶ月分のデータを再生成して送り直すという作業をしたこともあります。
■当面の逃げ方を考える
たとえば夜間バッチを落とすような障害の場合、落とさないようにしなければなりません。
そのために、オンライン終了後にSQL文を流して変なでーたがないか確認するとかジョブのインプットのデータを修正してバッチが正常に流れるようにする、などの当面の逃げ方も決めなければなりません。
とりあえず上記のテンプレにはめればもてもて間違いなしです！