社内SEの障害対応という仕事
社内SEをやっていると、避けてとおれない仕事。それが障害対応です。
障害が発生すると、予定してスケジュールをすべてひっくり返して、最優先で対応しなければいけません。
障害対応になると、イキイキとして対応する人もいます。
今回は社内ＳＥの障害対応とそれを次期基幹システムにどう活かすかです。
障害とは何か？システム障害の定義
システム障害を社内ＳＥの私が定義すると、「想定している状況、ではない状況」は障害です。ちょっと捉えづらい表現ですが、「想定外の状況」＝「システム障害」と定義してよいです。
なので、「整合性チェックでエラーメッセージが出力された」というのは障害ではないです。整合性が取れなかったためエラーが発生するという想定している。それをエラーを検知できるようにしていたのですから、想定内の状況です。
システム障害と判断されないケースもあります。私としては障害として扱いたいのですが、一般的には障害ではないです。どのようなケースかというと、「２時間かかる処理が、３0分で終わった。」このケースは一般的にはシステム障害とは呼ばれません。なぜなら他に悪い影響をあたえていないためです。むしろ良いケースとして何もしません。記録も残りません。これが後々影響をあたえるので、想定外の状況が発生したら記録するようにしましょう。
システム障害が発生した時の対応は、別の機会に書こうと思います。「システム障害 対応」などで検索すれば、フローチャートや対応方法検討、二次災害の防止策などいろいろ書いてあります。参考にしてください。
システム障害は、そのシステムを知るチャンス
システム障害は、そのシステムがどのような処理をして、いつ処理をしているかを知るチャンスです。新規メンバーであれば、何が起きるかすら把握できないと思いますが、できるだけ関わるようにしましょう。どういう点が障害なのかを把握するためには、正常なケースを知る必要があります。
現システムの障害が次期基幹系システム再構築に与える影響
現在の基幹系システムで、障害が多々発生するシステムや障害が発生すると影響が大きいシステムがあると、社内でそのシステムのノウハウがたまります。つまり、次期基幹系システム再構築時に、そのたまったノウハウを十分に活かすことでき、障害が発生しにくいシステム、発生しても理リカバリしやすいシステムになります。
しかし、現時点で優秀なシステム（＝障害が発生しないシステム）は、次期基幹系システムでグレます。荒れます。社内でノウハウがないシステムなので、再構築時にどう構築すればいいかの不明です。もちろん、そのまま構築すればいいですが、再構築時にそのまま構築するケースはないです。なので、今のうちからちゃんと面倒を見ておきましょう。
一番まずいパターンは、システムそのものの存在を忘れるケースです。これは、次期基幹系システムで完全に忘れられます。
システムもやんちゃな子を覚えやすく、優秀な子は忘れやすい。
