本日土曜日は休日出勤の予定でしたが、延期。
今週は出張こそあったものの、システム障害等は発生せず、平穏無事でした。
土曜日は一週間を総括する記事を書こう、と思っていたのですが、
なんとなくシステム障害のお話をします。
私も成否がまちまちで本質を理解しているとは言えないのですが、
システム障害の発生時、お客様やシステムに対して
実施するべき行動はパターンが概ね決まっています。
大枠としては、
以下の３点を報告しようと考えて
正確な情報を集めるように行動すれば、
間違いがなさそうです。
(1) 事象の概要
いつ、どのような障害が発生し、
誰がどのように対応したのか。
また、現在はどのような状況なのか。
(2) 調査結果
原因追求のための調査において
判明したことを、事実に沿い列挙。
(3) 恒久対応案
今後に発生した場合に備え、どのような対応を行うのか。
例えば、OSの不具合が原因であるためパッチを適用する、
プログラムのバグが原因であるため修正モジュールをリリースする、
原因がわからなかったため、追究のためログを追加採取するよう設定を行う、など。
うち、報告において重要なのは(1)と(3)で、
(2)はその繋がりを補強するイメージです。
ただし、費やす時間としては
(2)を得るために要する時間が障害対応の大半を占めます。
そのため、もしも(2)を一度誰かに任せるのであれば、
調査結果を導出するまでの過程はしっかりと管理する必要があります。
それでもあえて簡単そうに言うと、障害対応は
「何が起こっているのか？」を正確に知るだけの作業です。
要は、発生状況による微妙な違いを察知し、
いかに適切な対応を迅速に行うか、ということに集約されます。
障害の事象そのものもアプリケーション動作環境によって
微妙に違うことがありますし、お客様への報告の仕方はお客様によって当然違う。
ある程度のパターン化はできるけれど、作業品質の一律化は難しい。
でも、マニュアルは作っておきたい。そんな分野なのだなぁーと感じています。
終わりや終わり！ 終了！！
書いた人: 久世うりう (kuzeuriu) お問い合わせ
コメント