2006年02月13日

障害報告書のフォーマット

障害が起きたとき、なにが気分を重くするかっていうと、障害を顧客に伝える瞬間です。
ハードウエア不良なら自分の責任は少ないのでまだマシですが、プログラムのバグで、しかも本番機でトラブルとなると、営業や上司に押し付けて逃亡したくなります。

そうはいっても、技術的な話はSEに降ってくる宿命です。
そこで、障害報告書だけ書いて、客への押しつけちゃいましょう。 障害報告書は次の内容を書きます。

  • 概要
  • 現象
  • 原因
  • 対策
  • 経緯
■概要
障害の内容と対策を簡単に記します。顧客側の担当者は障害の詳細を知りたがりますが、上司や役員は概要だけで十分です。 そこで、概要を説明し、詳しく知りたい人には後の部分を読んでもらうようにします。
例:
2006年2月13日 22:00-22:30の間、アクセス過多の影響でXXXサイトが無応答となりました。サーバの再起動、およびデータベースに対する同時接続数の増加を行い、当面の現象は回避。不具合を対策したモジュールの入れ替えを2月20日に行います。

■現象
障害の具体的な内容を記します。
いつ、どこで、なにが、どのようになったかを客観的に説明します。
例:
2006年2月13日 21:50より、XXXサイトへのアクセスが通常の100倍に増加。22:00-22:30の間、アクセス過多の影響でXXXサイトが無応答となりました。 XXXサイトを構成するサーバX、サーバYを調査したところ、サーバXのデータベースにアクセスするプロセスがダウンしていました。

■原因
障害の発生要因を記します。
障害の原因と現象の関連が分かるように書きます。
例:
21:50より、XXXサイトへのアクセスが通常の100倍に増加。同時接続の増加により、データベースでの同時接続アクセス数を超過。 データベースからエラーが返った時点で、エラーを想定しない処理となっていたため、サーバのプロセスがダウン(不良点)。 サーバのプロセスがダウンしたため、XXXサイト全体の処理が停止し、無応答となりました。

■対策
障害の対策を記します。
対策には暫定対策と、本対策の2種類があります。暫定対策は、とりあえず現象を回避するための対策です。回避策とも呼びます。 本体策は、障害の原因を取り除く対策です。
例:
サーバXを再起動し、関連プロセスを再起動することで、プロセスを復旧。同時にデータベースへの同時接続数を増やすことで障害の原因を暫定的に回避しました。
このままでは、アクセスが増大した場合に、全ユーザのレスポンスが悪化します。原因を対策したモジュールを2月20日に入れ替えることで本対策とします。

■経緯
障害の対応経緯を記します。
例:
2006/2/1321:50頃ユーザからのアクセスが通常時の100倍に増大。
22:00データベース接続プロセスがダウン。
22:10監視アプリケーションによりプロセスダウンを検知。御社オペレータに通知。
22:15御社オペレータより弊社に連絡。調査開始。
22:30ログ採取後、サーバXの再起動を実施。サービスを再開。
23:00データベースのログより同時接続数を超過した場合のエラー処理に問題があると判明。同時接続数の上限を変更。
2006/2/14プログラムでの障害発生箇所を確認。同様の不良がないか見直しを実施。
2006/2/20対策完了版への差し替え予定。


posted by まる at 23:34| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス: [必須入力]

ホームページアドレス:

コメント:


この記事へのトラックバック
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。