以前「社内SEの業務内容をざっくりまとめ。情報システム部って何してるの？」で触れたトラブル対応について解説します。
トラブルが起きたそのとき
まずはトラブル自体と発生時に情シスがどのように対応するかを解説します。
トラブルの定義
何がトラブルなのかという定義は非常に難しいです。
私が所属している情シス部では、トラブルの1つの基準として、
エンドユーザーの業務に影響が少しでも出たらトラブルとみなす
としていますが、「少しでも」という微妙な判断に依存します。
（ITILなどでは「インシデント」として定義されています)
いつからがトラブルなのか
当然ながらトラブルは予見できません。
トラブルが起き始めた時は、それがトラブルなのか判断できません。
以下、例として、メールの送信が遅延する(こちらが送っても受信まで時間がかかる)というトラブルをあげて説明します。
まずは、電話で
経験上、ユーザの操作ミスの可能性の方が高いので、まずはメールサイズの有無やエラーメールの有無を確認します。
（送付先のサイズ制限などのエラーメールを見てもスパムメールとしか思わないユーザは結構多い！）
そうこうしているうちに、もう一本電話がかかってきて「メール送信遅いんだけど」ってなると、
ああ、トラブルが始まったな。さて、やるか。
となるわけです。
トラブルが起きているよ！という電話
ユーザ申告の場合は、影響範囲の把握が第一です。
(システム監視によって検知した場合はある程度特定できます）
やっかいなのはクラウドサービスでの障害です。
システム構成や直近の構成変更について情報がないため、影響範囲のアタリがつかないのです
影響範囲の確認をしている間にも、トラブル報告の電話はひっきりなしに鳴ります。
意外と大事なのは「情シス部がトラブルを把握していて対処を行っている」という事をエンドユーザに周知することです。
（エンドユーザは対処方法を求めるだけでは無く、通報のために連絡してきてくれます）
事象の把握とユーザ周知のジレンマ
ただ、情シス部としてはできる限り、多くの情報をエンドユーザに伝えたいわけです。
- 事象
- 影響範囲
- 対処方法
- 原因
の優先度で伝えますが、最悪１のみでユーザー周知（ポータルサイト掲載やメール展開）することもありますが、これは苦渋の決断です。
なにかが起きていることは把握しているけど、どこまで大変なのかわかってません。とりあえず頑張ってますから、電話しないでね！
って言ってるだけなんですが。わからないからしょうがないんですよ。
周知しないならしないで、「とりあえず把握したことだけは周知しろ」って人もいるので。
1ヶ月に丸1日は付き合わされる
そんな後、下記の流れでトラブルに対応します。
- 事象の把握
- ベンダへの連絡
- 原因究明（できない場合もあり）
- 対処（リカバリ）
- ユーザへの収束報告
- 再発防止対策の実施
担当しているシステムの多さにもよりますが。おおよそ2週間に半日くらい取られます。
(処置がシステマチックでない）場合によっては、1週間の半分くらい対応に追われる事になります。
通常業務のリスケの調整を含めるとかなりの痛手になります。
書き始めた時は原因究明まで書こうと思ってたのですが、長くなったので別投稿にします。
以上です。