こんにちは。M&A クラウドのエンジニアの鈴木（@yamotuki）です。今回の記事のテーマは障害再発防止についてです。私が会社でロジカルシンキング研修を受けたり、いくつかの関連書籍を読んだ学びを、障害再発防止に適用してみようと検討した内容のシェアになります。

特に参考にした書籍は、「問題解決の全体観上巻」と「ドキュメント・コミュニケーションの全体観上巻」です。

空雨傘 = 事実・解釈・判断

障害再発防止に入る前に、思考の枠組みである「空雨傘」について紹介します。「空雨傘」とは事実・解釈・判断の3ステップを論理的なストーリーを作るための簡単な枠組みです。名前の由来となった「空雨傘」は以下のようなステップのことです。

空（事実）: ある日外出する朝に空模様を見た。西の空が暗く雲行きも怪しい。
雨（解釈）: 一雨きそうだ。
傘（判断）: 傘を持って出かけた方がよさそうだ。

空雨傘を使って考える特に一番の効力は、事実を起点に考えられることです。障害が起こって、再発防止として何かネクストアクションを考える時に、「こうしたらいいのではないか？」と最初からHowについて話が始まることは典型的な落とし穴です。

空雨傘の障害例への適用

例えば、とあるページのレスポンスが遅いと関係者から問い合わせがあったとします。その場合、空雨傘は以下のようになります。

空
- とあるページのレスポンスが遅いと関係者から問い合わせがあった
- 上記をもとに事実収集
  - DBサーバーのCPU使用率が上がっており、100%に張り付いている
  - WebサーバーはCPU使用率が上がっているが、まだ余裕がある
  - 同時刻にユーザーエージェントが明らかなbotである同一のIPアドレスから普段の100倍のアクセスが発生している
雨
- bot アクセスがあり、DBサーバが詰まった
- 弊社にとって不要なアクセスを弾けていない

上記のような空雨をもとに「傘」は例えば以下のようなものが考えられます。

特定のIPアドレスやユーザーエージェントをブロックする
DBサーバーのインスタンスサイズを上げる
Readの負荷をレプリカサーバーに逃す

仮に、「とあるページのレスポンスが遅いとユーザーから問い合わせがあった」だけが最初に情報としてあったとして、アイディアを最初から出し始める「突然の傘」をした場合、こんなアイディアが出てきそうです。

無意識の雨
- Webサーバーが弱いに違いないから落ちたんだ
突然の傘
- Webサーバーの増強をしよう

きちんと事実を集めて解釈していれば妥当な解決案に辿り着けたのに、最初にあった事実だけをもとに直感に頼ったアイディアを出すことにより頓珍漢な方向に進んでいる状態です。

複雑な障害の場合はロジカルツリーを使う

上記の例に出した障害だとまだシンプルですが、実際の障害ではもっと複合的な原因が入り混じることがあります。その場合、文章ベースでの空雨傘だと整理することが難しいことがあります。
一つ目の難しさとしては、空として事実を幅広い原因に対して十分に拾えているか判断しづらいことが挙げられます。例に挙げた障害は単純なbotアクセスの問題ですが、実際の障害では歴史的経緯からデータやコードが複雑な上に、障害防止のための取るべきフローがとられていなかったり、人間の勘違いが関わったりなど、障害原因となる事実がたくさんあります。（この記事でも紹介しようかと思ったのですが、やはり複雑で内容がわかりづらくなるため断念しました）
二つ目の難しさとして、それぞれの空と雨のつながりが分かりにくいことも挙げられます。文章で表現すると、複数の空と複数の雨が1:1で対応しているわけではないので、繋がりが分かりにくいです。

そこで、以下のような障害再発防止を考えるテンプレートを考えてみました。

これに沿って考えてみると上記の障害例は以下のようになります。

このテンプレートの構造を作りにあたり、以下のことを意識しました。

横の論理: 障害原因と再発防止を漏れなく考えられるようにすること。
- あらかじめ障害原因と再発防止策の分類を作っておくことにより漏れなく検討することに意識が働きやすくなります。空いているエリアが可視化されるので、「この部分に本当に何も検討することはないのだろうか？」と考えるきっかけになります。上記の例で言うと、単にサーバーの負荷の問題以外に、以下のような議論も発生するかもしれません。
  - 「IPアドレスでブロックする仕組みはすでに存在したのですぐに利用できた。ただ、属人的だし、発生してからIPベースで止めることになるので、障害再発防止としては微妙だよね」
  - 「障害再発防止として有効で、ROIが高いのは、勝手に外れ値のアクセスがあった時に止めてくれる仕組みでは？」
縦の論理: 空と雨のつながりが分かるように、解釈にできるだけ「事実」を付与できるようにテンプレートに付箋をおいておく。解釈の付箋だけが浮いているところは要注意となります。

評価フェーズ

問題解決の全体観の上巻では、空雨傘の他に「解読・創案・評価・選択」のステップも紹介されています。特に複雑な問題の場合、空雨を「解読」の中にまとめ、傘を「創案」として、その後に「評価」・「選択」をするフェーズがあります。もちろん障害再発防止の文脈でも、たくさん出てきた案に対して評価・選択をすることは重要なところですが、まずは「突然の傘」を多用していたチームにおいては傘に対しては専門家の直感でのROIで選び取ることとし、本記事のスコープ外とします。

空雨傘だけだと実効性がない場合がある

例では「普通のユーザーが通常するアクセスを超える件数のアクセスがあったら自動ブロックする」というアイディアがROIが高そうだ、となっていました。じゃあこれで行こう、とすんなり実行まで行くチームもあると思いますが、そうでないケースもありえます。場合によっては再発防止だけ考えたけど、実際にずっと適用されないで同じ障害が再発なんてこともあるあるです。それは、傘（＝提案）まで考えて、それを具体的にどうやるかイメージできるところまで考えていないことがあるからだと思います。
そこで役に立つのが、「How To Do（どうやるか）」です。空雨傘は「What To Do（何をやるか）」なのです。How To Do は提案のラストワンマイルを埋めるためのものです。

障害再発防止として最低限決めておきたい How To Do としては以下のようなものがあります。

いつやるか？
具体的に使うツールや設定は見えているか？

特に、エンジニアだけで相談している場合には、後者については大体イメージできていることが多いのですが、「いつやるか？」については決めずに終わることが経験上多い気がしてます。MTG直後にやるのか、次の週に差し込むのか、タスクとして詰むだけなのか、それを決めて粛々と対応することが大事だと考えています。考えるだけ考えて無駄になってしまう再発防止ほど無駄なものはありません。弊社においては、今期はやると決めた再発防止については小粒なら原則次の週に差し込み、大型ならロードマップに載せてまとめて実施、という方式に決めました。