みなさん、こんにちは。
前回はベーシックリカバリという考え方と、それにまつわる故障復旧への備えについて投稿しました。その中で、故障解析で潜らせない仕組みについてリクエストがあったので記事にします。今日の記事は、故障対応の現場で何をすべきか？についてです。
潜る？
故障対応の場面で、
調査に入った人が、調査に入ったっきり出てこない。何をしているのか、何をしようとしているのかわからない。でもあれやこれや試しているぞ。
というシーンに出くわしたことないですか？
いつ復旧するのかわからないし、お客様にめどを伝えることもできないし困ってしまいますよね。
こういうのを我々は「潜る」と呼んでいます。
解析で潜らせない
故障が発生すると、故障対策本部を設置します。
その際には、復旧の作業にあたる人の他、顧客へのアナウンスプランを考えたり、社内外の関連システムとのコミュニケーションを行ったり、さまざまな対応班を立ち上げます。
- 対策本部長、及び各班のリーダを任命し、それぞれがやること、やるべきでないことを明確にする。
- 全体統括を行う班は、タイムマネジメントを行い、各班のリーダを通じて情報収集と共有を行う。
- 全体の情報共有を行う場を定期的に定めて、次のアクションを決定し、次に情報共有を行う時限を定める
ということを行うことで、タスクの過不足、体制の充足性などを確認し、誰が何をやるのか明確にしながら復旧にあたります。
次の報告時限を定めることで潜ることを防ごうとします。
しかし、タスクを明確にしたとて、原因調査が難航するのは常。原因はどこにあるかわからない時は、レイヤや部位ごとに分かれた原因調査班は潜りがちになります。
なので各班のタスクと成果を時限を定めて共有を行い、次のアクションを決めていくわけですが、無情にも時間は経過していきます。そこで我々は、
潜りがちな原因調査を復旧作業と切り離すべく、原因調査班と復旧班を明確に分ける。兼務しない。復旧優先！
という掟を定めました。
二の矢、三の矢を考える必要性
そのように行動しても無惨にも復旧しない。一体どうすれば？という場面もあります。
長時間かけて被疑箇所がわかった。これで治るはず！あれ、復旧しない。という場合です。それでも立ち止まっている時間は我々にはありません。その時は、
これがダメだったら次はこれを試そうという次の一手を持っておく
ことがすごく大事です。これがあると各班が、速やかに次のアクションに移行することができます。でもそんなことどうやってできるのだろうか？
みんなと違うことを考えている人が誰か1人はいる
ことで悪い状況を緩和できるかもしれません。それは潜ってしまう原因調査班や復旧班では難しく、全体を取りまとめている総括班（と我々は呼んでいる）で考えるべきことです。次の一手となる候補を二の矢、三の矢として温めておくのです。
事実と仮説の切り分けを行う
メンバーの思考停止を回避する二の矢、三の矢を増やす工夫があります。
最近取り組んでいるのが、
事実と仮説をリスト化して、次のアクション候補を導きリスト化しておく
手法です。故障が難局に入ると、かなりの情報が集まって情報の整理をしていても、対策本部に参集しているメンバーが状況を正しく理解することが困難になります。そんな時こういうことが起きてませんか？
- 事実や仮説がごちゃ混ぜになって、間違った調査に入ってた
- 過去の事例や思いつきで対処を決めてしまうが大抵ハズレ
ここで活躍するのが事実と仮説の切り分けと、次のアクション候補のリストです。
我々は事実確認マトリクスと呼んでいます。
事実を列挙する狙いは以下の通り。
- 過去の類似事例から直接的にアクションを導くことができる。
- 仮説を導くために事実の列挙が必要
仮説を列挙する狙いは、
- 複数の仮説から複数の対処が導かれる
- 仮説の裏付けのためのToDoが導かれる
- これらToDoや対処に優先順位をつけて評価できる
複数のToDoと優先順位が明確なので、ある案を諦めても次にすべきことがある！つまり
潜らせない！
ということです。当たり前の所作の気もしますが、多くの人数が集まる故障対策本部で議論の方向性を見失わないことと、途中から参集したメンバーがすぐに追いつくために役に立っていると思います。ポストモーテムの役にも立つでしょう。
復旧めどを伝えるために障害レベルを規定した
ここまで解析で潜らず、最短距離でサービスの復旧にたどり着くための工夫を書いてきました。
そもそも潜るのが悪なのは、お客様へタイムリーに情報の発信ができないことだと考えています。これまで故障が起きた時は、わからないなりに情報発信に努めてきましたが、タイムリーにというのは本当に難しいと感じています。そこで、
「わからないなり」も標準化し、速やかに復旧目処を伝える姿勢
として、すぐに判断できる障害レベルを規定して、レベルごとにアナウンス文面の雛形を準備し、故障報を速やかに発出できるようにしています。
| Lv | 復旧方法 | 内容 | 復旧時間 |
|---|---|---|---|
| 1 | 冗長構成による自動復旧 | 回線切替/クラスタ切替など | 数秒〜数分 |
| 2 | リカバリプランの実行 | 予め定めた復旧手順の実行 | 30分〜 |
| 3 | 原因調査と個別の対処 | 原因調査と故障原因特定、故障原因ごとの対処 | 1時間〜 |
レベル1は、故障対策本部が設置された時点で判明していますし、その時点で復旧していないからベーシックリカバリなどのリカバリプランを実行するわけで、これをアナウンスし、これがダメだったらいよいよレベル3をアナウンスするというわけです。
以上、我々が複数の大規模障害を経験して改善してきた事例を紹介しました。
これらの取り組みは、場面場面でいちいちどうする？という判断を減らすこと、共通言語化による情報流通の速度の向上、情報流通の範囲の拡大と正確性に寄与していると感じています。
コメントいただけましたら幸いです。