|
|
- ★ 本番編 ★
本番開始後のトラブル対応
本番開始後にトラブルが発生すると、
開発部隊よりもユーザー側の対応が大変になります。
私も、全国のネットワーク網によるお客様受注システムや
物流システムを担当していた経験がありますのでよくわかります。
優先されるのは、お客様対応です。
ＦＡＸや電話対応などで現場への連絡や
お客様からのクレーム対応準備及び納品遅れの連絡などです。
ユーザー側の対応手順として（これは一例です）
障害の一報を受け取る
１、システム障害内容の確認
２、上司への報告と関連部署や現場のエンドユーザーへの第一報告
３、お客様への影響がある場合は、Ｗｅｂ掲示
４、長引く場合は、社内関連部署へ状況報告
５、復旧前に社内関連部署へ状況報告
６、復旧後に社内関連部署へ状況報告とＷｅｂ掲示
７、システム復旧後は現場の復旧状況の確認
物流システムなどは、現場の復旧作業に時間がかかります。
物流全体が滞っていたために、倉庫だけでなく、トラック業者にまで
影響がでています。
ピッキング作業のおばちゃんを遊ばせてしまい、復旧に
また余分な経費がかかると怒られることもありました。
システム復旧後は、開発メンバーが反省も込めて現場に出向き
復旧のお手伝いをしたりもしていました。
問題は影響範囲が現場だけに留まらないことです。
お客様請求などにも影響がでている場合には、
お詫び状作成や、請求リカバリや会計処理など故障の影響が
広範囲にわたってしまうこともあります。
ユーザー側にとっては
こうした影響範囲の見極めと対応手順も重要な役割になってきます。
むしろ、トラブルが復旧した後の始末が重要なのです。
影響範囲の確認モレはないか？漏れてしまうと２次災害に繋がります。
この影響範囲の確認も、臨時プログラムの作成を至急行って、
異常データの抽出を行うのです。
臨時プログラムのロジックも複数メンバーによって確認してから
実行して対象データの洗い出しを行います。
この確認も重要な作業になります。
私も過去に、３次・４次災害なんて笑い話にならない経験もしました。
さすがにこの時は、かなり強く怒られましたが。
本番トラブルにおけるユーザー側の動きは大変重要になります。
また開発側にとっては、心強い理解者でもあるのです。
|
