障害告知と情シス

　先日、久方ぶりにAWSで大規模な障害が起きました。その時のことは下記の記事にまとめていますが、久方ぶりに告知にも気を使った出来事でした。

　今は障害時のフローや対応はマニュアル化されていますが、何度か苦い思いをしています。そこで思ったことを書いてみます。

第一報を急げ

　原則はこれです。事象がある程度把握出来たら第一報を出します。

　上の記事で、私は、

やることを決めたら、後は全社向けの広報としては「広範囲に障害が起きている」→「バックアップ回線に切り替える（不安定になるかも）」までしか出しませんでした。

と書きましたが、これをしないと障害の内容によっては電話が鳴りっぱなしになるんですよね。。。
　個別の問い合わせに現場の担当者が振り回されて実対応ができないなんていうことも経験していますので「わかってるよ、今対応しているよ！」というのを出しています。

はっきりするまで細かいことは書かない

　以前、マネージャー間で障害対応のフローをまとめたのですが、このときには「第一報」と「詳細報」を定義として分割しました。そのうえで、詳細報はマネージャー判断としました。
　掲載タイミングはマネージャーが決めます。

　障害の状況は往々にして変動的です。サポートに問い合わせて聞いた内容を試してダメだったなんて言うこともあるし、想定外にサービス再開に時間がかかるとか、まあいろいろあります。
　以前あった例でいうと

・ユーザが「いつ復旧できるの？」と聞いてきた
・問い合わせを受けた現場担当者が、ベンダーの現場担当者に問い合わせて、「いつ頃にはできると思う」というのをそのまま回答し、告知にも記載してしまった
・上記は実際にはアプリケーション修正ができるタイミングであり、その後のリリースまでのプロセスは入っていなかった
・言われたタイミングでできないということで大クレームになった

　ユーザは「いつごろできる（だろう）」なんて忖度しないですからね。ここでフル復旧するものと思って業務やサービスの予定を組んでしまいます。

「はっきりしない予定なら、出さないでください！」

なんて言ってもらったこともあり、こうしています。

部内の情報共有ツールを決めておく

　これも大事。弊社の場合、事故や障害対応のBacklogがあり、基本的にはここで逐一情報共有を行うことになっています。どうしても人によっても粒度は変わってきますが、できるだけリアルタイムで状況が見える化できるようにしています。

２種類の読み手を意識する

この記載をするときには、２種類の読み手を意識して記載しています。

現場向けにはリアルタイムで状況を書く
　まず、システムの現場には、誰がボールを持っていて何をしているかがわかるように書きます。これは、現場の担当者が書いていますが、これをしておくことで、問い合わせが入った時に、各自ある程度勝手に対応してくれます。困っていることなどを書くと「こうしたらどう？」とか「これやりましょうか？」なんていう突っ込みが入ることも。

幹部層への報告も意識する
　インシデントの中には、経営層に向けて報告をあげなければならないものもあります。以前私が担当していた部長で、部長に張り付かれて質問攻めにあって対応に支障が出たこともありました。

　今は、上長と相談して、基本はBacklogに記載しています。全体としてどういったことが起きていて、どんな影響が出ているのか、温度感はどうなのかといったことを幹部層に向けたつもりで書いています。私の場合だと、部下が記載した内容をかみ砕いて追記しています。

テンプレートを作っておくのが大切

　インシデントが発生するとあわてるものです。わかっているつもりでも大事なことを落としてしまうことはままありますので、対応フローやフォーマット類はテンプレートを作っておくと楽です。

大規模な障害を経験したことがないという方は、一度書籍に目を通しておくのもよいと思います。

とはいっても忙しい情シス。「いざ」が起きないと、構えはなかなか取れないんですけどね。。。