KAKEHASHI Tech Blog

カケハシのEngineer Teamによるブログです。

🚒 今の組織でもすぐできる、障害訓練ガイド

誰にだって作戦がある。最初にパンチを食らうまでは。

ヘビー級ボクサーとして名を馳せた、マイク・タイソン氏の言葉です。

障害における計画やマニュアルがあっても実際にできるか、衝撃を受けてもうまく動けるかどうかは試してみないとわかりません。さすがにパンチは辛いので、水かけぐらいで定期的に検証してみるのがカケハシにおける障害訓練です。

何を目的にするか

主目的としては障害対応フローの検証と学習と改善です。障害対応は数が少ないこともあり、記憶は急速に忘却され、6ヶ月もすれば対応方法を忘れてしまいます。定期的に訓練することで意識することなく行動できるよう、いわゆる宣言的知識を手続き的知識に変換するとともに、フロー自体の更新とドキュメント最新化もしてもらうことが狙いです。

副目的として、耐障害性の検証および向上と、デバッグの仕方/リリース手順などの学習があります。こちらを副としている理由は、別の手段で代替できるためです。例えば障害試験および障害の机上検証(FMEA等)や、手順や方法なら内部でのトレーニングと共有など。

どれくらい行うか

現在は四半期に一度行っており、各プロダクトで少なくとも一度は実施済みです。カケハシでは障害訓練を2020年から開始し、2022年2月までに8回ほど行ってきました。

どう行うか: 準備

まずは障害シナリオを作ります。発生する(させる)障害の影響範囲を想定し、障害対応フロー上のプロセスを洗い上げ、各ロールでどれくらい人数が必要か考えます。その後協力者を募集し、日程調整です。デブリーフィング(ふりかえり)も当日中に行うので、長めに見て3時間程度を確保しています。社内で実際の障害と混同されると混乱を招くので、予め訓練を宣言しておきます。

どう行うか: 当日

ステージング環境で行います。障害を注入するとともに、常に訓練の旨を宣言しつつ開始します。実地に近づけるため、サポート部門からの声や通常の問い合わせQ&A、実は無関係だった質問、なども(迫真の演技で)再現します。一部のSaaSなど本番のみ存在するものの対応は机上ですませます。

訓練自体に対するやりとりのチャネルと、訓練内でやりとりするチャネルを分けておくと、シナリオに集中できてスムーズです。訓練自体のやりとりの例としては、デブリーフィングの時間を変えてほしい、シナリオ修正といった指摘です。

ときには偶然実環境での不具合検知が重なりますが、むしろ実践に近づく面があります。

*もちろん実環境の対応が優先です。

どう行うか:ふりかえり

話すだけではなく書く時間をとる、参加者中心といった定番の研修設計技法に沿い、経験をシェアし形式化して定着化させることを志向しています。予めふりかえりガイドをもとにしたテンプレートを使い、細かめな時間割を作成しています。 まずは細かく思い出してもらい、だんだん思考を深め、自分なりの考えを書き出していく流れです。

効果について

やるたびにメンバーからは高評価を得ています。プレッシャーの中の行動すると、急速に学習が進みます。また、ふりかえりでは各メンバーに自分の言葉でNext Actionを出してもらっています。「人は自分が口にしたことは受け入れやすい」ことから実際の行動率も高めです。

課題と今後

SREチームが主導していますが、プロダクトチームだけでサイクルを回せるよう、直近一年程度で移譲できればと考えています。まずは独力で行えるよう支援すると同時に、どうモニタリングしていくかを検討しています。

細かい点としては、プロダクトが成熟するほど注入する障害のネタがなくなっていくことがあります。ソースコードにバグを挿入すれば、GitHubとSlackで検知され、AWSの設定を変えればCloudTrailやDatadogで見破られる... 障害の調査は本質ではないので、ここは机上でもよいのかもしれません。

まとめ

いざというときに慌てないようにするには、訓練、訓練、訓練です。まずは試しに一回やってみましょう。そうすれば、雰囲気が変わります。

文責: 高木