「構造化データを活用したインシデント対応の向上」~世界のインシデント対応~incident.io-Part8

はじめに

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

ポイント!!

インシデント中に大切な情報を引き出すための「構造化データ」は、情報を更新する際に、顧客の必要としている情報や要点を伝え、チームのメンバーだけでなく顧客も含めた全員が素早く理解できるようになります。
「構造化データ」によって得られるインシデントの「顧客に対する影響」「関連技術の情報」「考慮すべき規制」に焦点を当てることで、組織はインシデントに関する十分な理解を得ることができ、これに基づいて効果的かつ効率的な戦略を展開することができます。

解説

　ここでいう構造化データ（Structured data)は、システム障害が起きていない「平時に収集すべき情報の定義をしておこう」という話に読めました。事前に決めておくと「コミュニケーションが改善」「自動化ができる」「考察が得られる」などのいいことがある、というトーンでした。確かにどんな情報を集めるかを事前に決めておくのは重要ですが、もう少しこのブログから発展させます。
　障害時によくある「何でもいいから情報を集めろ！」というのは良くないパターンで、たくさんの情報が来てしまうと受け手も混乱しますし、こういう時に集められる情報は出し手目線の情報になりがちです。情報は量ではなく質、システム視点ではなくサービス視点にすることです。
　具体的には、「何でも」と言われると何を出せばいいか困るか、過剰に情報を入れられてしまいガチです。本当は聞いている人にも目的があってどんな情報が欲しいか決まるはずなのに急な出来事で迷ってしまっていると思われます。
　また、「データベースがダウンしました」というシステム目線の事実よりも、それによって「〇〇サービスから情報登録ができない」など、サービス目線での情報が必要になってきます。
　このブログに書いているような「収集すべき情報の定義」は必要ですが、一歩進めて実際に障害時に必要な質の良い情報をサービス目線で決めておくことが重要です。