ダイニーの urahiroshi です。
昨今のプロダクト開発では、開発チームが開発だけではなく運用も行うというDevOpsのプラクティスが浸透してきたように感じます。一方で、開発と運用を同じチームが扱う場合はインシデント対策に関して以下のような難しさもあるかと思います。
- プロダクト開発の機能開発スケジュールに、インシデント対策のアクションを組み込むのが難しい
- 対策が必要なことは理解しているものの、何から優先して着手すべきか分からない
- そもそも、どのようなインシデント対策をすれば良いのか分からない
このような課題は、多くの組織で共通して見られます。この記事では、ダイニーでの実例を用いて、インシデント対策の計画を立てるための戦略についてご紹介します。
インシデントの3分類
情報セキュリティの分野において、セキュリティは Availability (可用性), Integrity (完全性), Confidentiality (機密性) の３つの要素からなると言われています。自分は、インシデントのリスク分類にも同じ分類が適用できると考えています。なお、以下の記述における対策の部分について、セキュリティ文脈でのリスク・対策も別途必要となりますが、この記事では割愛します。
- Availability のリスク: 特定の機能が使えなくなることによって起きるインシデントです。
- 例: POSレジがインシデントにより機能しなくなる
- 特性と対策:
- 一般的に可観測性が高く、HTTPエラーやAPIのエラーレートなどで容易に観測できるケースが多いです
- ネットワークやサーバー負荷などインフラの要因によって生じることも多く、未然に防ぐのが難しい場合があります。その場合は発生時のフォールバック戦略を取ることや早期復旧のためのオペレーションを運用に組み込むことで影響を最小化するアプローチが必要です
- 負荷テストやカオスエンジニアリングによってインシデント発生時の対策を検証することができます
- Integrity のリスク: 値が誤っていることによって起きるインシデントです。
- 例: 誤った給与計算によって、給与の振り込みが行われる
- 特性と対策
- ロジック的なバグが要因の場合、テストの拡充によって未然に防ぐことができます
- 並列処理の実行タイミングなどにより発生するケースは通常のテストでの検出は困難となりますが、並行処理専用のテストや、モンキーテストなどによって検知できる可能性はあります
- 可観測性は低く、発生してもモニタリングツールから気づきにくいです
- 金銭を扱う処理などは金額の誤りがより致命的になるため、値の突合によりデータの不整合を未然に検知すること、値の誤りが発覚した場合のリカバリ方法を事前に用意しておくといった追加対策などが検討できます
- Confidentiality のリスク: 不適切な人が個人情報などを見えてしまうリスクです。
- 例: 管理画面で、所属していない組織のデータまで閲覧できる
- 特性と対策:
- 基本的にIntegrityのリスクと同様で、テストの拡充によって未然に防ぎやすい一方で、可観測性は低いです
- クライアント (ブラウザもしくはアプリ) から直接APIを呼び出す形式の場合、API単位でテストを実行しなければリスクを完全に検証できているとは言えないため、APIテストが必要になります
このようにリスクを３つに分類することで、考えられるリスクを洗い出しやすくなるとともに、取るべき対策の方向性も見えてくるようになります。
インシデントの重要度を測るスコアリング
インシデントに対して優先度を立てて計画的に対策していくには、インシデントの重要度をスコアリングできると良いでしょう。ダイニーでは、各プロダクトで想定されるインシデントのリスクを洗い出したうえで、それぞれのインシデントに対して以下5つの観点でそれぞれスコアをつけ、それらのスコアをかけ合わせた値をインシデントスコアとして算出しました（なお、こちらに掲載する例はあくまで例で、ダイニーで利用しているものではありません）
- 影響範囲
- インシデントが発生した場合、どれだけ広い範囲に影響が及ぶかによってスコアリングを行う
- 例:
- 5: 半数以上のユーザーに影響する
- 3: 10以上半数未満のユーザーに影響する
- 1: 10未満のユーザーに影響する
- インパクト
- インシデントが発生した際に、その影響範囲の各主体にどのような影響を与えるか
- 例:
- 3: ユーザーに対して実損害が生じる (POSシステム障害により注文・会計不能で飲食店舗が売上機会を失うなど)
- 1: ユーザーに対して実損害は生じないが、場合によってサービスの解約に発展する可能性もある
- 発生可能性
- そのインシデントが発生する可能性
- 例:
- 3: すでに発生しているインシデント
- 2: ヒヤリハットがあった
- 1: 発生する可能性がある
- 可観測性の対策状況
- インシデントが発生した際に、モニタリングによって自動的に検知できるようになっているか
- 例:
- 4: インシデントが発生しても検知できない
- 3: 一部のパターンは検知できるが、検知できないパターンがある
- 2: 検知できる
- 1: 検知でき、かつ短期間で復旧可能なプロセスがある
- 予防状況
- インシデントを未然に防ぐための予防策がどれだけ講じられているか
- 例:
- 3: 全く予防できていない
- 2: 一部の予防はできているが、予防できていないケースもある
- 1: 可能な限り予防できている
これらの値をもって、以下のようにインシデントスコアが計算でき、数値が高いほどリスクの高いインシデントとして考えることができます。
- 影響範囲: 5
- インパクト: 3
- 発生可能性: 2
- 可観測性: 3
- 予防状況: 2
⇒ インシデントスコア: 5 * 3 * 2 * 3 * 2 = 180
インシデント対策計画への落とし込み
インシデントスコアを数値化できれば、対策計画への落とし込みは容易になります。ダイニーでは、以下のようなプロセスで対策計画への落とし込みを行いました。
- しきい値の設定: 特に優先的に対処したいインシデントリスクを抽出するため、インシデントスコアのしきい値を設けます
- コストの見積もり: 優先的に対処したいインシデントリスクに対し、対策にかかるコスト (労力) を見積もります
- 最初からすべてのインシデントリスクに対してコストを見積もって計算式に組み込んでも良いのですが、リスクが多いとコストの見積もり自体に労力がかかるため、抽出したリスクに対してのみコスト見積もりを行いました
- 対策もどこまでの段階まで行うかによってコストが変わるため、それぞれの段階の対策により可観測性・予防状況のスコアがどれだけ変化するかを見極めたうえでコスト算出できると良いです
- ロードマップへの組み込み: 対策コストが許容範囲内であれば、リスクの高いインシデント対策をチームのロードマップに落とし込みます
- 対策コストが非常に高い場合、段階的な対策を実施するなどのアプローチを検討します
数値化のプロセスは、精度の高い対策計画を作ることだけが目的ではありません。
- ダイニーのようなマルチプロダクト体制でプロダクトをまたがって共通のインシデントスコアの算定ロジックを作ることで、経営レイヤー含めてインシデント対策に対して妥当な意思決定を行うことができる
- チーム内外での議論を通じてインシデントスコアの算出ロジック自体を継続的に調整・改善できるため、インシデントの重要度判断が属人化せず、組織の資産として残り続ける
インシデント対策は、プロダクトの信頼性を高め、ビジネスを守る上で不可欠な活動です。この記事に記載したのはあくまで一例ですが、一つの組織として計画と戦略を持って進められると良いでしょう。
Discussion