システムエンジニアが、コンピュータシステムのトラブルを対応する際、テキストファイルに対応状況の報告内容を書いておくと、後に客先への最終報告書を書くのに大変便利です。すぐにメモ帳等のテキストエディタで「システムトラブル対応状況報告書」が書けるよう、フォーマットと具体的な書き方を紹介します。
システムトラブル対応状況報告書のフォーマット
システムトラブル対応状況報告書
■報告年月日、時刻
20 年 月 日( ) 00:00
■システム名
■発生日時
20 年 月 日( ) 00:00
■発生サーバ
■発生事象
■業務への影響有無
■業務への影響内容
■業務への影響回避策
■原因
■暫定対処
■本格対処
■対応経緯
/ ( )
00:00 (客先○○様→△△:メール)
事象発生の連絡を受領
■特記事項
以上
スポンサーリンク
システムトラブル対応状況報告書書き方の具体例
実際の書き方をイメージできるよう、書き方の事例とポイントを解説します。
システムトラブル対応状況報告書の書き方事例
システムトラブル対応状況報告書
■報告年月日、時刻
2014年11月10日(月) 15:00
■システム名
某会社OCRデータアップロードシステム
■発生日時
2014年11月10日(月) 12:00頃
■発生サーバ
OCRサーバ3号機
■発生事象
·メールデータをアップロード画面からアップロードしたところ、「アップロードデータに誤りがあります」というエラーメッセージが表示された。前日に同画面でのアップロードは正常に処理された。
·アップロードエラーとなったときのデータは、13, 047件。
■業務への影響有無
有り
■業務への影響内容
アップロードデータに「ユーザへの還付金金額」が記載されており、当該金額が把握できないことから、ユーザへの還付金支払ができない。
■業務への影響回避策
客先で管理する還付金額の台帳を参照の上、手作業で還付金支払い作業を行う。
■原因
エラーとなったアップロードデータを受領し、保守マシンでアップロードしたところ正常にアップロードは完了した。ご担当者及び客先の許可を得て、実機へアップロードしたところ事象が再現した。エラー画面の表示までに3分8秒かかっている。
ちょうど3分でエラーとなったこと、並びに保守マシンでは正常となっていることから、「データ量が増えたため、客先のネットワークだけ3分でタイムアウト」になっていると想定される。
■暫定対処
なし。
■本格対処
現状は、「未更新データも含めて、全量アップロード」であるが、データ量が多いことが原因でエラーとなると想定しているため、「更新データのみアップロード」する運用で依頼。更新データのみアップロードすることでも、運用に支障は無いことは確認できている。
■対応経緯
11/10 (月)
17:26 (客先の加藤様→鈴木:メール)
事象発生の連絡を受領。
18:00 (鈴木→客先の加藤様:メール)
再現性を確認するため、送付された基準適合品データを開発マシン及び実機へアップロード。開発マシンは正常、実機はエラーが再現。
18:30(客先の加藤様→鈴木:メール)
開発マシンで正常、実記はエラーであることを報告。必ず3分でエラーとなることから、タイムアウトの可能性が高く、アップロードデータを「更新したデータのみ」でアップロードするよう依頼。
11/11（火）
9:30 （鈴木）
テストの結果、原因が判明。
10:00 （鈴木→客先の加藤様：電話）
原因を報告。調整の結果、18:00に修正版モジュールを適用することで合意した。
18:00 （鈴木）
修正版モジュール適用作業を開始。
19:00 （鈴木）
修正版モジュール適用作業が完了。
19:30 （鈴木→客先の加藤様：電話）
適用作業の完了を報告。操作画面で正常にアップロードできたことを確認。
■特記事項
なし。
以上
システムトラブル対応状況報告書を書く時のポイント
ちょっとしたポイントを抑えるだけで、報告書の出来が向上します。
「対応経緯」はなるべく細かい方が後で楽になる
トラブル報告は会社の上司も受けることから、トラブルの対応状況を細かく知りたい上司からすると、「対応経緯」に細かく書いていると口頭での報告が省略できて対応が楽になります。上司が複数人居ると、いちいち口頭で報告することが余計な時間となるので、文章にしておくことが大事です。
トラブルの調査はまっさきに「業務への影響」を確認すること
客先の業務に影響があるのか、あるならばどのような影響なのか、その回避策を客先と話し合い、まずは業務への影響を最小限にすることが、トラブル対応のポイントです。
