チームで障害訓練をした話 #障害対応

はじめに

この記事はニフクラ等を提供している、富士通クラウドテクノロジーズ Advent Calendar 2022 の 11 日目の記事です。

昨日は @e10persona さんの青空文庫の小説の表紙を自動生成してみたでした。
今年は小説を読む機会が多かったのですが、何を読もうか悩むこともあったので、ジャケ読み出来ると楽しそうだなと思いました！

本日は、私が所属しているチーム（あるサービスの開発・運用チーム）で初めて障害訓練を行ったので、その内容についてご紹介します。

なぜ障害訓練をやってみたのか

弊社ではコロナの影響もあり在宅勤務が主流となりましたが、そんな中で私が所属するチームではメンバーの変動が多く発生し、結果としてチームの人数がコロナ前の約2倍に増えました。
メンバーが増えることで出来ることが増える嬉しさがある半面、障害対応を行う際に以下のような課題・もやもやを感じるようになってきました。

通常はサーバー運用に関わらないメンバーが増えた
- 少人数だった頃は、全員が色々なジャンルの業務をやらざるを得ない状態でしたが、 メンバーが増えたことで開発がメインの人、運用がメインの人、といった感じで役割が明確になってきました。 障害はいつ、どのメンバーがいる状態で発生するか分からないので、全員が対応出来る必要がありますが、障害対応に必要なスキルを十分に伝えられていないメンバーもいる状態となっていました。
障害対応について教えるフローがない！
- 障害を未然に防ぐ取り組みが功を奏してきたのか最近はシステム高負荷（障害）発生頻度が減ってきました。私がチームに入った当初はシステム高負荷が今より多く発生し、その度に多くのことを学んできました。障害対応についてのドキュメントももちろん用意されていましたが、読むだけではいざというときに動けず、まさに「習うより慣れよ」だと強く感じていました。それを実践できる機会が減ってきた中で、ドキュメントの内容を伝える、以上の対応が出来ていませんでした。
障害発生時、誰が何をしているのか分かりづらい！
- オフラインで働いていた頃は障害が発生するとすぐに一か所に集まって、会話や、大きなモニターで画面共有しながら対応するのが一般的でした。最近では障害発生時にすぐにオンライン会議を開き、会話しながら対応することがメインとなってきましたが、 メンバー全員の在宅勤務が主流になったばかりの頃はテキストベースで対応を進めることも多くありました。 ついつい黙々と調査ばかりを進めてしまって、連絡・連携するといった不足している対応に気付けなかったりしました。

こうしたもやもやとした内容をチームに相談した結果、障害訓練を行ってみることになりました。

実施方法

流れ

私が所属するチームで扱っているサービスは共有サービスであるため、特定のユーザーが大きな負荷をサービスに与えてきた場合、他のユーザーにも影響が及んでしまいます。
特定ユーザーの負荷起因による障害が、比較的多く起こる障害でもあり、かつ、原因調査が難しい障害だったりします。
そのため、障害訓練ではこのケースの訓練を行うことに決めました。
サービスのテスト環境（検証環境）もあったため、テスト環境を使って疑似的に障害を発生させ訓練を行う、という方針もすぐに決まりました。

実施方法の決定まで色々と悩む部分は多くありますが、結論からお伝えすると、以下の流れで訓練を進めようと決めました。

負荷が発生するリクエストを実行するシェルスクリプトを作り、cronでそのシェルスクリプトを定期実行させることで、テスト環境でシステム高負荷を発生させる
システム高負荷を監視にて検知し、メンバーが対応を開始する
- 調査などはもちろん、営業メンバーへの連絡等も行っていただく
メンバーの原因調査が完了したあたりで、ユーザーから問い合わせがあった設定にする
- 調査し特定した原因が正しいことの証明代わりに問い合わせがあった体にする
対応メンバーが対処法を実施
再度、最初に実行したシェルスクリプトを実行する
対応メンバーが同一リクエストが来ているが負荷が発生しなくなったことを確認

負荷が発生するリクエストを実行するシェルスクリプトについてですが、テスト環境には検証用に作られたユーザーは多くいますが、実際に発生したことのある障害を再現できるようなデータはテスト環境には無かったため、データを流し込むスクリプトを用意し実行し、データを用意しました。
テスト環境の方がスペックが小さいおかげで、本番環境ほど多くのデータを用意しなくても済んだのは助かりました。
シェルスクリプトについては、実際の障害を参考にしたため、すぐに用意することが出来ました。

ただ、すぐにシェルスクリプトが用意できたとはいえ、事前確認のため実行してみるとスペックが小さいため想定していなかった高負荷も発生したりして、思い描いた通りのことを完璧に実現する、というのが難しかったです。
チームに相談もしたりした結果、厳密に障害を再現することはあまり本質ではないため、 テスト環境で再現出来る部分だけ再現し、難しい部分はシナリオを伝えることで訓練を行う ことにして、先ほど伝えた流れでやってみることにしました。

役割分担

当時のチームメンバー7名について、訓練での役割を事前に決めました。

役割分担
- 全体進行役: 1名（私）
  - 訓練自体を進行
- シナリオ実行役: 1名
  - 負荷（障害）を発生させる
- リーダー役: 1名
  - 障害対応中のリーダーへの状況報告等も練習するため、状況報告先の役割を務める
- 対応者: 2名
  - 発生した障害への対応を行う

こちらの役割で対応者を変えて、2回訓練を実施しました。
なお、訓練がなるべく円滑に進むようにするため、対応フローをまとめているドキュメントの内容で原因特定出来るシンプルな事例にしました。
そして、対応者にはなるべく対応フローをまとめているドキュメントを参考に進めてもらうよう伝えました。
というのも、ドキュメントはかなり昔から存在するものでしたが今でも十分に使える内容のものであると感じたので今後も有効活用したい、と思ったのと、ドキュメントに微妙な部分があれば分かりやすく更新する機会になると感じたためです。

役割の無いメンバーが2名出てしまいますが、そのメンバーには訓練後の振り返りのために、対応時の状況で良かった点・気になった点あれば、メモしておいていただきました。

各回毎に、その回の障害対応方法についての振り返りを行いました。
そして、2回の訓練が終わった後、障害訓練自体の振り返りを行いました。

1回の障害訓練と、その回の振り返りに1時間、2回の訓練後の障害訓練自体の振り返りに30分程度を当初見込んで実施しました。

実施結果

さて、2回の訓練を実施しましたが、中々計画通りには行きませんでした…！

私自身の一番の反省点は、各回振り返りを含め1時間を想定していましたが、対応者2名に頑張って対応していただくというのを強く意識しすぎた結果、振り返り前の訓練までの部分に1時間半以上かけてしまった点です。
調査フローを全て自力でこなしていただけた半面、色々なところで細かいつまづきがもちろん発生しますが、それらの積み重ねで長丁場の訓練となってしまいました。
調査したいことと、その調査に使うツールも特定出来ているが、上手く調査出来ない場合（例として、kibanaでレスポンスが特定時間以上かかっているリクエストを検索したい、など）などは、対応者以外のメンバーがフォローする等して訓練が時間内に終わるようにすれば良かったと思いました。

訓練をして良かったと感じた点は以下の通りです。

ドキュメントの分かりづらい部分が洗い出された
- 分かりやすく更新することが出来ました
分かっていなかったことが分かった！
- 今回該当したのがkibanaなのですが、普段問い合わせ対応の際には使いこなせていても、障害時に調べたいことの検索方法が共有出来ていなかったことなどが分かり、ノウハウを共有できました
原因調査、影響調査で分かれることの重要性を学べた
- 過去に少人数でサービス運用していたせいか、障害が発生した際、思い思いに調査を進める傾向がチームにありました。それでもどうにかなっていたものの、 障害が発生したらすぐに役割を決めて動くことの重要性を訓練で理解することが出来ました
画面共有の重要性を感じた
- 最近ではシステム高負荷（障害）発生時にすぐにオンライン会議を開き会話しながら対応することが増えた、というのを冒頭で記載したのですが、こちらは訓練の際に画面共有したことで、訓練がやりやすかった、という意見があった影響でもあります。緊急時の対応自体はテキストベースでなんとかなったとしても、メンバー間のナレッジ共有のことを考えるとコミュニケーションをとり、時には同じ画面をメンバーで見ることの重要性を感じました。

今回初めてだったことも大きく関係していますが準備が大変だったのと、やはり環境間の違いなどからシナリオを増やすのは大変そうだという点については、 同じシナリオであっても定期的に災害訓練のように行うのも良さそうだという意見をいただきました。
また、障害の対応方法を学ぶための回ではありましたが、今回疑似障害を起こした方法を共有してもらうことも、アンチパターンを知ることができるため勉強になる、という意見もいただきました。

まとめ

今回の障害訓練を通して、実際に手を動かしてみることの重要性を感じました。
そこから、分かってなかったことが分かった！というのが一番大きな訓練の成果だと思います。

なお、まだ訓練を実施して1年経過していませんが、チームのメンバーが増えたため、もう一回訓練をやってみようとチームで計画しています。
訓練の実施方法やフローについても、今後改善していければと思います。

この記事は富士通クラウドテクノロジーズ Advent Calendar 2022 の 11 日目の記事でした。

明日は @HanchA さんの「katalon recoderについて書く予定」です。
UIテストを自動化するのは中々難しく、私たちのサービスでは実現出来ていないので気になります・・・
明日もぜひお楽しみに！