システム障害対応の改善は、何故進まないのか?(第四部・完結編)

第三部「システム障害対応の改善が進まない真の原因は何か?」では、
「顧客の運用設計ができていないから改善しない」という話をさせていただきました。

なぜ、顧客の運用設計が必要なのでしょうか。

たとえば、顧客がシステム障害発生時にどんなプロセスを取るのかが決まっていなければ、システム障害発生時に「いつ顧客の誰がどんな情報必要としているのか」「なぜそのタイミングでその情報を知りたいのか」がわかりません。

そうすると、顧客とのコミュケーションが円滑に進まず、顧客への連絡遅延や情報不足、アクション決定の遅延などといった問題が表面化するだけとなり、システム障害対応が長期化し顧客から同じことを言われ続けるのではないでしょうか。

では、どう顧客視点で改善を進めればいいのでしょうか。

本記事では、「システム障害対応の改善が必要と考えている」皆様へ
改善方法が進まない理由から実際にどう改善すべきかを提案しています。 

システム障害対応の改善はどうやったら進むのか?

今回の完結編では実際に何を実施すればよいかをご提案させていただきます。

1.システム障害対応の運用設計として、3つを決める。

顧客はシステム障害と、いざ相まみえた時に、「不安」「苛立ち」「恐怖」の感情を抱いた状態で、何の目的でどんな情報が欲しいか、ハッキリとわかっていない状態で要求してしまいがちです。
迷いながら・都度その場で考えてしまわないように以下3つを事前に決めておくべきだと考えています。

おすすめの運用設計要素は、以下3つになります。

①アクションの候補・・・どんなシステム障害時に、どんな行動をとるかの選択肢を考えておく

たとえば、「システム障害のアラートを受領/認知した後に、顧客連絡をするものか、しなくていいものか?」「組織が大きい場合、どこのレベルまでエスカレーションをするべきなのか?」などです。

皆様の担当しているシステム障害における課題が「連絡」にあるのか「復旧」にあるのかによりますが、どんなケースにおいても対応経験が多くないとアクションが浮かばないものです。
今後発生しうる予測がつくようなシステム障害のケースやアクション候補の一覧を作るだけでも、とても大きく変わってきます。

このアクション候補ができると、いざという時の頼り所のひとつとなり、システム障害が発生した際に「都度その場で考える」が減らせます。
大きくても小さくとも、システム障害を経験していく中で、都度アクション候補をブラッシュアップさせていきましょう。

その先には、システム障害対応の品質向上、スピード向上、コスト低減に加え、新たに参画したメンバーへの教育のスピードも速くなります。

改善を進めておけば、企業や組織としての本来の優先度の高い業務を行える事につながると考えております。

②判断情報・・・行動の選択肢を、何の情報をもとに選択するかを考えておく
アクション候補が決まったら、「そのアクションはどのような情報があれば判断や実行にうつせるのか?」を考えていきます。

顧客影響を見るために「SLAに定めている内容」は速やかに知りたいはずです。
SLAやSLOにたとえば、「XX業務サービスエラー時は、故障発生連絡を顧客に30分以内に速やかに行う」とあった場合、「XX業務サービスの影響範囲を見るためには、XX情報が必要」「XX業務を利用している顧客一覧が必要」となるはずです。

判断情報が決まっていると、システム障害時に余計な情報取得での時間ロスや、判断誤りをしなくてよくなくなります。

③判断基準・・・情報をどのような観点で判断するのかの基準を考えておく
情報が集まったらそれを「どのように見て判断するか」を考えておきます。

どのように判断するか決まっていると、その判断するために情報の取り方や取得範囲なども変わってきます。

たとえば「WEBサービスの利用ユーザー数」を判断情報として集めるとします。
今までの業務経験から、だいたいの場合、当日のユーザー数だけを見て判断するわけではなく、
前日のユーザー数と比べてユーザー数が落ちてないか、という判断基準を見たいのではないでしょうか?

いざ集めた判断情報を確認すると、当日のユーザー数しか情報が集まらず、前日のユーザー数情報は改めて取り直しとなり、時間ロスが発生していまいます。

どの情報をどんな観点で見て判断するかを事前に決めておく事が大事だと考えています。

2.顧客(関係者)の運用設計を起点に、自分たちの運用設計をする。

大事なのは、「顧客や関係者の運用設計を起点に、自分たちの運用設計をする」です。
お客様へ提供しているサービスには、関連システムや顧客は必ず存在します。
そのため当たり前ですが、システム障害対応にも必ず相手(顧客や関係者)がいます。

もし皆様が改善を頑張っているのになかなか進まない…となっている状況でしたら、チーム内だけで運用設計にとどめず、顧客の運用設計を一緒に考えて見てください。

相手の欲しい情報は想像し、近いものは提供できたとしても、直接聞いて意思疎通を行った方がより確度が高い顧客にとって役だつ情報になります。
相手がしたい事、欲しい事は聞いた方が早くて確実です。

システム障害時に、顧客が取りうるアクション候補を決めて、その時には「どんな情報があれば判断できますか?」というのを一緒に決めたら自分たちが出すべき判断情報がわかり、それを顧客がどのような観点で見るかの判断基準がわかってきます。

顧客の目的とアクション候補がわかっていれば、顧客が欲しい観点で情報まとめるやり方や取得方法の事前準備ができ、いざという時には早く情報が出せます。

これは顧客だけじゃなくて、関係者に対しても言えます。

たとえば、あなたが担当者であれば上司の運用設計を一緒に考えてみると、いざエスカレーションする時に上司がどのように判断しているかをわかった上で、どんな情報を出すべきかも明確になります。開発・保守担当者の方であれば営業の運用設計を一緒に考えてみると、営業から顧客へのアクションの内容がわかり、出すべき情報のまとめ方や取得方法の早期化など事前準備が行えます。

私の今までの業務経験の中、多くはシステム障害発生時の大混乱の中、何も決まっていないと、その場で話し合いながら運用設計にあたることが多い印象です。

最近システム障害対応うまくいかなかった方や、あまり関係者と話し合ったことなかったなという方など、ぜひ一度相手と話をしてみるだけで大きく改善が前進すると思います!

3.顧客視点で運用設計をしてから管理ツールを選択する。

顧客視点で運用設計ができた後は、世にたくさんあるインシデント管理ツールや自動化ツールなどを用いて、更にうまくやる方法を探っていけるとよいのかと思います。

よく言われるのは「目的によってツール選ぶ事が大切」と言われますが、特に大事だと思っているのは”顧客”の目的だと考えています。
ツールの話を先にしてしまうと、手段先行でツールに合わせた設計になり、目的を失いがちです。
(ツールの選択については、「モダンなインシデント管理ツールの選び方」で書いておりますので、
ぜひ併せてご参照ください。)

実際に、お客様や関係者と運用設計を考えてみて、こんな変化があったよ!とか、やってみたけどうまくいかなった経験など、コメントいただけけますと幸いです。
引き続き、システム障害対応や運転監視、保守運用をやっている中での考え方を発信していきながら、平行してツールのご紹介もしていければと思います。

ここまで全四回にわたり「システム障害の改善はなぜ進まないのか」を
お読みいただき誠にありがとうございました!

野村 浩司

金融系システムを中心に開発・保守・運用を6年実施、その後、事業部・社内改善を5年しており、大規模障害時は300人ほどの障害対応の統括を実施、事業部の故障数を30%削減などに取り組んだ。 他にも、原価削減はBPRで8000万/年、システム監視改善で3600万/年、申込運用改善で2500万/年など実績あり。

The following two tabs change content below.

野村 浩司

金融系システムを中心に開発・保守・運用を6年実施、その後、事業部・社内改善を5年しており、大規模障害時は300人ほどの障害対応の統括を実施、事業部の故障数を30%削減などに取り組んだ。 他にも、原価削減はBPRで8000万/年、システム監視改善で3600万/年、申込運用改善で2500万/年など実績あり。
是非フォローお願いしますm(_ _)m
NO IMAGE