「障害発生時の顧客への情報提供の重要性」~世界のインシデント対応~incident.io-Part11

はじめに

英国のスタートアップ企業であるPineapple Technology Ltd様が運営するincident.ioに関連したブログ　The Practical Guide to Incident Management　のポイントと解説

ポイント!!

システム障害時に「効果的なコミュニケーション」をとることは、極めて重要なものになります。取引先への外向きのコミュニケーションを怠ると、継続的に不利益を及ぼします。
「コンテキスト（障害情報:context）」を提供することは顧客の不安を抑えます。システムの障害が発生した際に何も情報を提供しないと、顧客は最悪の事態を想像してしまいます。簡潔な情報だとしても、顧客に提供することは心配を和らげるのに大いに役立ちます。
復旧見込み時間を設定することは、顧客の不満を最小限に抑えることに役立ちます。特に長時間のサービス停止(outage)の場合、復旧見込み時間を共有することは顧客に対する誠実なアプローチです。

解説

今回は、「何をどんな頻度で伝えるか」　と　「復旧見込み時間」について触れようと思います。

　ポイントの中で要約してしまうと消えてしまいましたが、「今何を取り組んでいるかの説明」と「いつ更新するかを知らせる」のが重要。という点はその通りです。
　情報を発信する側からすると、復旧に時間を割きたいので後回しにされがちですが、情報を受信する側からすると「活動をしてくれているのか」「次いつわかるのか」は聞きたいものです。私もそうですが発信者側としては聞き手に意識を向けるのは重要です。

　復旧見込み時間の共有については、この記事とは意見が割れました。「復旧見込み時間」は「ある程度の予測を立てて発信する」のには反対で、なぜなら、そこから外れた時は情報受信側の影響が大きいためです。
　例えば、「１時間で復旧って言ってたから１時間待って３０分で作業をしよう」となった時に「復旧見込みが２時間になりました」となった時に影響が大きいです。
　ただ、復旧見込み時間を正確に出すのは難しい、、、そんな時は「受信側がどんなアクションに向けて復旧見込み時間を求めているか」を判断して情報を出すのがおすすめです。例えば、復旧見込みが1,2時間と思ったら「３時間以内」「３時間以上」という粒度です。
　ここでいうアクションとは利用者側の暫定対応を言います。例えば、Web会議サービスの場合のアクションは「他Web会議サービスを使う、復旧を待つ、自分のPCを再起動してみる」などです。
　提供しているITサービスの特性を考慮する必要はありますが、Web会議サービスの場合利用者が「会議相手と他Web会議サービスに切り替えて会話を続けるか」「復旧を待つか」の判断が重要になります。数分の瞬断ならば再度入りなおしてみようというアクションになります。ただ、数時間単位であれば他Web会議に切り替える判断を下せます。この「利用者のアクション選択」に必要な質を保つことが重要で、普段エンジニアが復旧見込みを出す時に悩む1時間なのか2時間なのか、は重要じゃない場合が多いです。（一方で１時間見込！といって２時間たつと怒られがちですが・・・）