“実践”システム障害対応：6週目：アクション判断に向けた判断情報・判断基準の仮説立案

12週にわたり「”実践”システム障害対応」と題して、システム障害対応の改善のプロセスを約3か月で実行できるように、各週ごとに何を実践すればよいか？を考えていきたいと思います。

「システム障害対応の改善は、何故進まないのか？（第四部・完結編）」でも記載しましたが、システム障害におけるポイントは、以下2点を定めることだと考えています。

• 顧客の運用設計を起点に、自分たちの運用設計
• 運用設計はアクション・判断情報・判断基準

6週目は、5週目で決めた「システム障害発生時のアクション」に対して、アクションを判断するための「判断情報・判断基準」について考えていきましょう。

システム障害時の判断情報・判断基準の仮説

前回、システム障害時ケースごとにアクション候補の内容が何かを、アクション実行決定者が認識した状態です。
今回は、そのアクションに「どんな情報があれば」判断できるかを考えましょう。

こんなシステム障害時は、こんなアクションが必要だから、判断するための「判断情報」「判断基準」を決めておけば、システム障害時の影響が小さくなっていくと考えています。

私のマネージャー経験として、過去システム障害時に「とりあえず情報を出して！」と
エンジニアにお願いした際には、ほとんど私がほしかった情報は出てきませんでした。

しかし、これには私にも落ち度がありました。
エンジニアはエンジニア視点で必要だと思う情報を集めてきてくれたのですが、マネージャーとしてアクションを判断するために必要な情報が集まることは、あまりない印象です。

もし、私が「XXの判断をしたいので、XXについてXXな情報を知りたいから情報を出して欲しい。それはXX分以内に欲しくて、XX%の正確さでよい」と伝えることができていればいいのですが、
マネージャーはシステム障害時だけを気にして業務を行ってはいないので、パッと出てこないのも当たり前の事です。
システム障害対応する場面では「不安」「苛立ち」「恐怖」「困惑」の感情があり、指示に迷ったり、調査時間が長引いたり、判断が遅くなった結果、システム障害影響が大きくなる構造があります。

そして、役割や立場によって視点が変わりますし、役割や立場によって重要視する部分も違ってきます。そのため、「事前に認識を合わせておきましょう」というのが今週のお話になります。
では何故、判断するための「欲しい情報」がすれ違ってしまうのか？というのを考えていきましょう。

”目的「why」”が合っていないため

1つ目の理由は、何を目指して情報収集をしているかという”目的″が共通認識として持てていないためです。

これは私の過去の経験から来る偏見かもしれませんが、エンジニアの方はだいたい原因調査に向けた情報を調べてくれます。
「XXログにこんな情報が記録されていました。それはこんな原因と思われます。」などを教えてくれます。もちろんこれも大事です。
しかしマネージャーである私は、影響極小化のために「どんなアクションをするか」を決定したいと考えています。

”何wha”が合っていないため

2つ目の理由は、”何を集めればよいか“がわかってないためです。
たとえば、前週記載したシステム障害「決済端末が使えず、お会計ができない」の場合のアクション候補の1つに″全店舗へ一斉連絡″を記載しました。

もしあなたが100店舗のマネージャーであった場合、この”全店舗へ一斉連絡”を判断をするときに何があったら判断できるでしょうか？

エンジニアならばおそらく原因を調べて、″システムの原因″や推測した″復旧見込み″を教えてくれることがあると思います。

ただマネージャーの立場からは、たとえば「現時点の店舗ごとの取引数」に対して、

• 本当に店舗で取引ができていないのか？
• 店舗ごとに偏りがないか？

が知りたいはずです。そして、

• 本当に全店舗に連絡指示をする場合、連絡した後が大変になる事が想像できます。
• 連絡した指示内容が明確でない場合、本部に来る問い合わせが多くなり苦しくなります。
• 取引できている店舗からは、「うちは問題ないけどこのアクションを実施する必要があるの？」と少なからず混乱するでしょう。

それが、100店舗となると本当に全店舗へ連絡することは、実際の現場ではかなり躊躇すると思います。

ただ、一方で躊躇してしまった結果、アクションの選択・実行が遅くなってしまうでしょう。
だからこそシステム障害が発生していない平時で落ち着いている時に、「そのアクションはどんな判断情報・判断基準から選ぶか」を関係者の方と一緒に決めておくべきなのです。

判断情報・判断基準の整理（必要精度・どのように集めるか）の確認

必要な精度を決めておく

たとえば「決済端末が使えず、お会計ができない」システム障害事象において″復旧見込み時間″がどのくらいなのか？
その答えが、すぐ直るならば連絡しないし、すぐ直らないならば連絡しようと判断すると思います。

ただ、その情報はどの程度正確なのか？という精度の問題が出ます。
これを事前に決めておかないと情報を集めてくるエンジニアは100％の精度を目指してしまいます。
そのため情報が出るまでに時間がかかってしまいます。
100％の精度を目指して情報を出すまでに時間を要した結果、システム障害で困る人が多くなり、困っている時間が長期化しては元も子もありません。

いつ復旧するのか？の″復旧見込み時間″の精度を高めるのは、原因によって異なる事も想像できるため、出すのはとてもむずかしい事だと思います。
しかし、マネージャーの立場としては影響極小化の観点があるため「XX分以内に情報が欲しい」という判断実行するまでの時間期限があるのも事実です。

判断基準を決めておく

もし、あなたが100店舗のマネージャーだった場合に、″全店舗に連絡をするか″を判断するとき、欲しい情報が「XX時間以内で、XX％ぐらいの確率で復旧する」という情報だとします。

具体的に数字を入れてみた形で一例で表現してみますと ″30分以内に復旧する見込みが70％以上あるか″ぐらいが妥当ではないでしょうか？

マネージャーが欲しい″復旧見込み時間″は30分など、”一定時間を超えるならば連絡する” という判断も多いかと思います。
エンジニアの判断として「30分以上はかかりそうだ」とわかっているなら、マネージャーはその時点でその報告がほしいのではないでしょうか？

エンジニアの立場からすると、30分以内に70％の確率で復旧するかどうか？が”YES”か”NO”かの回答を出して欲しいともし急に言われたら、「そんな短い時間で確度の高い情報は出せない」という事は、ごもっともでしょう。

そのため、

• 事前に見るべきログはどれか？
• どんな手順で調査するか？
• 確率の根拠となる観点はどうすべきか？

を、まとめておく必要があります。

全店舗連絡する内容としても個人的には、情報確度を含めた連絡でいいと思っています。
「決済端末が使えない可能性がある（情報確度XX%）。もしそうなった場合は、こうした案内をお客様に出して欲しい」それであれば各店舗は、その可能性もある事を考慮しつつ接客する事ができると思っています。

何事もそうですが、一度で全てはうまくいきません。
ですが、この取り組みがあったことでお互いの立場も少し理解が進み、次回のシステム障害時は必ず前回よりも必要情報が早く出てくると信じています。

忘れていけない事は、誰もが失敗したくないという心理であるという事です。
ですが人は失敗して学び続けるものであるという事を理解して改善していきたいものです。
そして何故このような改善をやっているのか？
それは「システムを利用するユーザーや顧客がシステム障害時に少しでも困らないようにする」という同じ方向を向いて改善していきたい所です。

何か思う事ありましたら、ご遠慮なくお手数ですがコメントいただけますと幸いです。
次回は「システム障害の定義・障害フローの整備・実現性確認」などに触れていきたいと思います。
ここまで、ご覧いただきありがとうございました！