インシデント初期対応における「外延・内包フレームワーク」の考え方

本記事は、LAPRAS 夏の自由研究リレーの8/28分にエントリーしています。

筆者は現在、LAPRAS 株式会社にてプロジェクトマネジメントの傍ら「重大インシデント指揮官」という大仰な名前のロール(ホラクラシーにおける役割)を担当しています。このロールは、システムのバグや攻撃によるデータ破損や(考えたくはないですが)個人情報漏洩などのインシデントが発生してしまった場合の初期対応の陣頭指揮を行うことを責務としています。

インシデントは、もちろん起こさないことがなによりも肝要です。しかしながら、システムを人間が作っている以上、100%完全になくすことが不可能であることもまた事実です。

インシデント対応は、発生してしまったインシデントのユーザーやビジネスへの影響を最小限にする最後の砦としての役割を担います。これは、船底に大穴が開いてしまった艦艇の火災を鎮火するようなもので、的確で迅速な措置が求められます。このため、普段からの訓練と、いざというときに困らない一貫した行動指針を準備しておくことが重要です。

CC 表示-継承 3.0 Pharaoh Hound

「インシデント対応フロー」などでググると、発見から再発防止までの全体の流れや、インシデント対応にかかる組織体制などが豊富に出てくる反面、インシデント初期対応における影響範囲や原因の究明、データやコードの修正など、現場レベル・戦術レベルでの行動指針となる考え方がまとまっているものはあまり見当たりません。

本記事では、筆者のこれまでの経験を元に考案した、インシデントの初期対応におけ汎用的に用いることができると考えている「外延・内包フレームワーク」について解説します。

おことわり

本記事ではインシデントの初期対応についての筆者の考えを述べますが、これはインシデントの発生を容認したり、肯定するものではありません。インシデント対応はあくまでもビジネスにおけるダメージコントロール機構の1つに過ぎません。実際のサービス開発においては品質管理や設計・製造時における品質の作り込みなど、より前工程でインシデントの発生原因を作り出さないことが肝要です。

また、本記事は筆者の現在や過去の所属企業において発生したインシデントやその対応方法について肯定ないし弁明する意図はございません。もし読者の中にその節でご迷惑をおかけした方がいらっしゃる場合、深くお詫び申し上げます。

加えて、本記事の内容を実施することによって生じたいかなる損害の責任も負いかねます。本記事はインシデント対応における一般的な考え方を示したものであり、個別の状況においてそのまま適用できるものではありません。本記事の内容を理解した上で、あくまでも読者の判断と責任でインシデント対応に臨んでください。

「外延・内包フレームワーク」の概要

「外延内包フレームワーク」の要点は、以下の規約にまとめられます。

・影響範囲の特定は、発生した事象の具体例(外延)を外側から抑え込む。
・原因の究明は、発生した事象の共通の性質(内包)を内側から広げる。
・外延と内包を一致させることで、影響範囲と原因を確定する。
・外延は内包よりも優先し、データ修正は常に外延に対して行う。

「外延」「内包」という名前は、数学や哲学で用いられる「内包(intension)と外延(extension)」の概念と、「影響範囲の外側と内側」という意味を掛けて筆者が呼んでいるものです。

これらの規約の詳しい意味は後述することにして、ここではまず、これらの規約に従わなかった場合にどのようなことが起こるかをシミュレーションしてみます。

失敗例: 何も考えずに対応するとこうなる

架空の会社Xでは企業向けの業務システムを提供しています。今、そのシステムで障害が発生しています。

問題の発覚は、とあるユーザーから登録情報が破損しているという報告があったことでした。この報告を受けたカスタマーサポート担当は、急いで技術サポートチームに調査を依頼しました。

技術チームが調査をすすめていくと、同様の問題が発生しているユーザーが複数発見されました。また、当該登録情報の部分を変更した直前のリリースが原因の候補として上がりました。

直前のリリースを調べてみると確かにバグが存在していることが判明しました。問題が生じていた複数のユーザーについて、登録情報の破損の問題はこのバグによって説明がついたため、技術チームは今回の問題の原因をこのバグによるものだと結論づけました(原因A)。

技術チームは、直ちに当該リリースを Revert するリリースを実施し、原因Aの影響範囲のユーザーに対して、データ修正用のパッチを作成して適用しました(修正手順α)。

技術チームは、問題の発生を確認していたユーザーのデータが正しく修正されていることを確認し、胸を撫で下ろしました。

・・・

技術チームが今回の障害報告書を提出してから数日後、問題となったリリースの修正版のリリースについて議論しているところに、カスタマーサポート担当が慌てた様子で駆け込んできました。

今回は、複数のユーザーから前回とは別の箇所のデータが破損しているという問い合わせが来ました。しかも、それらのユーザーの一部には、前回のバグの影響の範囲でデータ修正を行ったユーザーが含まれていたのでした。

技術チームが改めて前回のリリースを調査したところ、バグがあったコードは別の場所からも参照されており、そこで別の問題を誘発していたということがわかりました(原因B)。

もっと悪いことには、原因Aと原因Bの両方の影響を受けているユーザーに原因Aに対する修正手順αを行ってしまった事により、これらのユーザーデータの一部が完全に失われてしまったのでした・・・。

何がいけなかったのか？

上記の初期対応の何がいけなかったのでしょうか？
様々な点が挙げられるかと思いますが、以下の2点が致命的であったと考えられます。

・影響範囲と原因究明をどちらも発見的な手法に頼っている。
　→ 結果として影響範囲を見誤り、原因Bによる問題が放置された。

・影響範囲も原因も判明しないまま、解決策に飛びついている。
　→ 結果として不適切な解決策(修正手順α)を講じ、二次被害が発生した。

どうすればよかったのか？

インシデントの初期対応の困難さは、初期には原因も影響範囲もわからないという不確定性にあります。しかも事態は刻一刻を争うなか、焦りと認知バイアスが担当者の判断を誤らせ、目の前の安易な解決策に飛びつかせてしまいます。

「外延・内包フレームワーク」は、この原因と影響範囲の不確定性に対処することを目的とした行動指針です。確実な情報を積み重ねていくことで、不確定な領域を狭めていきます。

上記の例では、影響範囲を発見的な方法に頼ってしまったことで、影響範囲を過小評価してしまいました。このように、影響範囲の特定においては、第二種の過誤 (偽陰性: 問題があるのに無いと判断してしまう) がよりクリティカルな問題となります。このため、影響範囲については「確実に影響範囲外のものを除外していく」という「外側からのアプローチ」が必要になります。

一方で、原因の調査においては、ありえる可能性を検討してみては当てはめてみるという発見的(帰納的)手法に頼らざるをえません。すなわち、「確実に原因が説明できる範囲を広げていく」という「内側からのアプローチ」を取ることになります。

この「影響範囲の外側からのアプローチ」と「原因の内側からのアプローチ」との間に実際の影響範囲が存在しています。すなわち、「外側からのアプローチ」と「内側からのアプローチ」を進めていき最終的に両者が一致することで、影響範囲と原因がそれぞれ確定します。

非常に当たり前のことを言っているようですが、インシデント対応の混乱した状況においては、現在内側と外側のどちらのアプローチを行っているのかを明らかにすることが重要です。

そして、この考えを推し進めたのが冒頭の規約になります。

・影響範囲の特定は、発生した事象の具体例(外延)を外側から抑え込む。
・原因の究明は、発生した事象の共通の性質(内包)を内側から広げる。
・外延と内包を一致させることで、影響範囲と原因を確定する。
・外延は内包よりも優先し、データ修正は常に外延に対して行う。

4つの規約のうち、上の3つが上記で述べたものです。
外側からのアプローチは、データの1つ1つを見ながら「確実に影響範囲から除外されたもの」を明らかにしていく必要があるため、具体例(外延)による記述が必要です。一方で、発生原因はそれぞれの事象を説明するために共通の性質(内包)による記述が必要になります。

・影響範囲 = 具体例(外延) = 外側からのアプローチ
・原因 = 共通の性質(内包) = 内側からのアプローチ

という関係になっています。

規約の最後の1つは、実際にこのフレームワークを用いてインシデント対応する際の運用に関する指針です。常にインシデントの影響範囲の上限を表している外側(外延)は、内側(内包)よりも優先的に処理していきます。また、実際のデータを扱う際は、修正時のデータと処理の保全の観点から、外延に対して行わなければなりません。

上述の失敗例では、外延による影響範囲の囲い込みを行う前に、内包(原因)による事態収集を図ったために、問題の見逃しや二次災害が発生してしまったのでした。

「外延・内包フレームワーク」を用いた初期対応の手順

それでは、本フレームワークを用いた具体的な初期対応の手順を紹介します。

1. 外延リストの作成
　影響範囲を確実に含む具体的な対象のリスト(外延リスト)を作成する。
2. 外延抑止の実施
　外延リストに対して、被害拡大のための機能制限措置を実施する。
3. 外延調査の実施
　確実に問題がないレコードを調べることで、影響範囲を絞り込んでいく。
4. 内包調査の実施
　原因を発見的に調査し、問題の原因が説明できている範囲を広げていく。
5. 原因と影響範囲の確定
　外延・内包調査を進めて一致させることで、原因と影響範囲を確定する。
6. データ復旧と顧客への説明
　確定した原因と影響範囲に対して、処置や説明を行っていく。
7. 内包抑止の実施と外延抑止の解除
　確定した問題の原因の修正を行った後、外延抑止を解除する。
8. 根本解決と再発防止策の実施
　初期対応が終了した後、根本解決と再発防止策を実施する。

以下では、各手順の詳細を、具体例や実運用上の注意点をまじえながら解説していきます。
(以下有料ですが、LAPRAS社員は無料なので nunuki に声をかけてください)