Views: 149
ユーザ系SEにとって最も嫌な業務がシステム障害対応である。
これが起きると土日祝日夜間早朝関係なしにその日の計画すべてが吹っ飛び
とにかく障害から復旧することを第一に行動することを求められる。
なんせ常に動いているべきシステムを止めるだけでユーザに迷惑がかかるのだ。
当然即時調査が必要だし、ものによっては即刻プログラム修正等の対応を行う必要がある。
ただ、障害対応を迅速かつ的確に行う事が出来れば間違いなく評価につながるので積極的にかかわるべきである。
なんせ上司にあたる管理職はシステムの安定稼働に責任を持っている。
システムを早急に復旧させる責任を課せられているからこそ、システム障害対応の
実務にあたるSEの動向は気になってしかたない。
また障害対応に関する顧客への説明責任を管理職は負うので早く正確な情報が欲しくてしかたないのだ。
管理職はシステムの細かい部分までは把握していないので担当SEに何度も障害の状況について
ヒアリングすることになるだろう。
普段は部下のSEには無関心な管理職であっても障害発生時は担当SEへの注目度は何倍も上がる、
そんな状況で正確な情報伝達を行い的確な判断と早急な対応を下すことができれば
「こいつは使える」と思ってもらえるのは間違いない。
逆にオペミスや判断ミスで二次災害を引き起こすと
「ダメだこいつ」とレッテルを貼られてしまう。
思うに障害対応はSEにとっては”試合”のようなものなのだ。
ここでいいところを見せれば上司の評価もおのずと上がる。
もっとも障害対応は出来て当たり前の世界なので、障害対応を何十回と重ね続けてようやく
評価につながると考えるぐらいが良いと思う。
以下、障害対応のコツを列挙
⇒複数のユーザが同じ内容の問い合わせをしてきた場合は裏で何かしらの障害が起こっている可能性がある。即、調査するのが望ましい。
⇒障害対応は時間をかけてはいけない。
異常が検出されたら即刻障害対応にとりかかるべき。
⇒ログに最大のヒントが書かれていることが多い。
⇒どこで障害が起こっているかを正確に読み取るには上記を読み解く必要がある
⇒設計書やソースを読んでもわからない場合は、本番データを開発環境に突っ込んでみて動かしてみるという手もある。これをすればたいていの原因はつきとめられる。
⇒障害対応が終わらず、バッチを止める場合もあるが、止めたことが後続へ与える影響をしっかり押さえること。
⇒障害が起きてもユーザ影響が軽微であれば対応を急ぐ必要はなかったりする。
拙速な対応で二次災害を出すぐらいであれば、おちついて正確な対応をとることが望まれる。
⇒夜間や休日の障害連絡を受けた場合に、バッチ処理の影響を把握するためにジョブネット図は
自宅に持ち帰っておくのが望ましいと思う。
設計書を社外に持ち出すのはよろしくないが、こればっかしは持ち帰らないと仕事にならない。