技術とか戦略とか

証券レガシーシステムを8年いじってから転職した普通の文系SEによるブログ。技術のみではなく趣味の戦略考察についても。

システム障害が起きた時に元請けSIerの中で起こること(体験談)

二次請けや三次請けで本当に開発しかしない職場だと、システム障害が起きた時にその対応がどれくらい大変なのかが伝わりにくいことがあります。
今回の記事は、システム障害が起きた時に元請けSIerでどのような対応を行う必要があるのかを書きたいと思います。
「緊急対応(手運用やプログラム修正)」「障害発生個所の復旧」「お客様向けの文書の作成」「再発防止策」といった対応が必要になるのですが、客観的なことを書いてもなかなかリアルさが伝わりにくいので、あえてシステム開発者である私の体験談を書くことにします。
(機密情報等があるので、ブログに書いても問題のない形に加工します)
 
システム開発者目線の体験談のため「なんか残業多そうで大変」ぐらいしか伝わらないかもしれませんが、障害を掴まされるお客様も大変な思いをします。業務が滞るためお客様もお客様で色々な所に説明しなければなりませんし、障害の復旧に付き合うことになります。主に経営レベルでお客様からの信頼も失いますし、システム障害を繰り返すと本当に顧客離反を招きます。
 
この記事が、品質向上の機運を高めるきっかけの一つになれば幸いです。
 
-----------------------
 
【n月m日(日)】
機能向上のため、既存システムの改修のリリースを実施。
 
【n月m+1日(月)~n月m+2日(火)】
リリース後の稼働確認を実施し、問題なしと判断。
 
【n月m+3日(水)】
いつも通りに始業した所、お客様窓口の担当者から連絡が来る。
「帳票を使ってるお客さんで、0円になってる項目がいつもより多いって言ってきてるんだけど、見てもらえる?」
 
調査を始める。
開発時のテスト結果の見直しや、再テストを行った所、n月m日のリリースで改修ミスがあったことを発見。
偉い人に報告する。当然怒られる。
そして、それをお客様に報告する偉い人もお客様に怒られる。
(機能向上になるはずが、今まで使えていた機能が使えなくなってしまい業務が滞ったので、お客様から見たら当然怒りたくなる)
 
偉い方々を招集し、緊急で対応会議を行う。
その結果、問題のあったプログラムは緊急で修正・リリースし、翌日以降の影響を防ぐことにした。
問題のある帳票(3日分)は土曜日に再作成し翌週提供することとなった。
(日曜日は予備日)
 
同じ担当の開発者を集めて、プログラムの修正とリリース作業を当日中に緊急で行った。
それとは別にお客様への報告文書も必要になるため、それも作成した。
 
【n月m+4日(木)~n月m+5日(金)】
緊急リリースしたプログラムの稼働確認を実施。問題なし。
 
お客様への報告文書の作成や、土曜日の帳票修正作業の計画に追われる。
自分の担当だけでなく他の担当とも連携するシステムであるため、帳票修正作業の調整で時間がかかる。
他の担当の人から見れば巻き込まれた形なので、当然文句を言われる。
 
【n月m+6日(土)】
土曜日に出勤し、帳票修正作業を実施。
帳票修正作業は終了し、予備日は使わずに済んだ。
 
【n月m+8日(月)~】
お客様に対応完了の報告文書を提出した。
しかし、再発防止策を立てて実行し、その結果もお客様に報告しなければならない。
 
障害対応に追われて先週やるつもりであった開発作業ができなかったため、他のプロジェクトの進捗にも影響を及ぼすことになった。