はじめに
英国のスタートアップ企業であるPineapple Technology Ltd様が運営するincident.ioに関連したブログ The Practical Guide to Incident Management のポイントと解説
ポイント!!
- インシデント対応を対応するマネージャーはオンコールチームが定期的にインシデント情報のアップデートを提供する必要があります。それは、ステークホルダー(利害関係者)がインシデント発生中に信憑性のある情報を得て的確な判断をするためです。
- 社内の最新情報への更新(internal update)は、専門用語を使うことをなるべく避け、インシデントの影響を具体的に説明し、解決策を明示することで情報の提供先にとって理解しやすくする必要があります。
- 定期的かつ明確なアップデートの提供を行うことと、インシデント発生時に多方面に情報伝達を行うコミュニケーターをしていすることは、インシデント対応時の混乱や余計な作業を防ぐために重要です。また、アップデートを行う際のハードルを下げ、容易に送信できるようにすることも欠かせません。
参考:Communicating within your organization
解説
今回はシステム障害に関連する情報発信です。重要な示唆が多くあるので是非確認していきましょう。
この章で最も重要なのは「解決策を明示すること」で、私が悩ましいなと思ったのは「容易に送信できるようにすること」です。
「解決策を明示すること」は、事例にもある通りシステム障害の状態を書くのではなくて、何をすればいいか?を書くべきというものです。事例を抜粋します。
悪い例: AWS の問題により、クラスター ノードのうち 2 つで障害が発生しました。
良い例:お客様がウェブサイトを通じて購入できないことを意味します。
実際に書かれている事例だと解決策ではなく、解決策につながる可能性の高い「どのサービスが使えないか」の情報が書かれています。購入できないならば別のサイトで買うか、復旧を待つか電話で注文を出すかなど。難しいのは承知の上ですが、踏み込んで「何をするべきか」まで書いたほうがよいですね。
「容易に送信できるようにすること」は、定期的に情報更新をするときの話で「アップデートの送信は簡単であるべきです。摩擦が多すぎると頻度が減り、悪い行為が促進されます。(Sending updates should be easy: too much friction will decrease the frequency and encourage bad behaviour.)」
と書かれています。
これは悩ましくて、更新頻度は保ちたいけど、悪い情報は拡散したくない。。。正しい情報だけしか書くな!というと怖がって書かなくなり書く頻度も落ちる。。。
個人的にお勧めしているのは「情報の質」を合わせて書くことです。具体的には「事実」なのか「推察」なのか、100%自信があるものか、50%ぐらいの自信なのかなどです。
特にシステム障害対応時は皆さん多忙で焦っているのでこれを忘れがちですが、どのぐらいの質なのかを明示することで、書く方は「20%ぐらいの自信だけど・・・」と書き込みが促進され、読むほうも「じゃぁ参考程度に・・・」とできます。
更に期待できるのは「私はもっと自信持っていいと思う!」と追認してレベルがあがったり、「この情報は良い情報だ!ただ判断するためには、確度を80%程度まで上げてほしい!」などがあると思います。
この情報の質に関しては、私自身、必要性は理解しているのですがどのように反映すべきかの解を追い求め続けています。もしより良い対応をされている方がいれば是非教えてください!
用語
インターナルアップデート(internal update):社内の最新情報をインシデント情報にアップデートすること。(文脈からの推察)
一般的には以下を指すこともあります。「ソフトウェアやシステム内部の変更や改善のこと。一般的にエンドユーザーが直接目にすることのない、裏側で行われるアップデート。
野村浩司
野村浩司:金融システムの開発保守運用と改善を12年担当。7年にわたり合計約 1000 件の障害事例を分析。システム障害対応の改善では、アラートを9割削減。