システム障害対応演習を実施した話
こんにちは、ネコ派メタラーです。ナビタイムジャパンで地点検索基盤の開発マネジメントを担当しています。好きなバンドは Arch Enemy です。
システム運用に関わる人であれば、「システム障害」というと耳が痛い方が多いかと思います。システム障害は起こさないに越したことはないですが、万が一システム障害が発生したとき、その行動選択はサービスの信頼性を大きく左右することになります。
迅速に復旧させることはもちろんですが、適切な情報公開によってユーザーの不安を払拭するといったコミュニケーションも重要なポイントです。しかし、緊急事態というプレッシャーを受けながら最適な行動を選択することは容易ではありません。
私が所属しているチームでは、Web API サーバソフトウェアから全文検索ミドルウェアまで含めた開発・運用を行っており、幅広いトラブル対応スキルが必要になります。トラブル対応のスキルを持ったベテランメンバーも在籍していますが、一方で経験が浅いメンバーからは、ベテランメンバーが不在のときにシステム障害と向き合えるか不安に思うという声が上がりました。
この不安を解消するため、システム障害発生時にスムーズな役割分担や動き (検知・情報共有・復旧) ができるようになることを目的に「障害対応演習」を実施しました。
演習の概略
演習内容を要約すると「ステージング環境に意図的な不具合を混入し、実際のシステム障害と同じようにコミュニケーションをとりながら検知・復旧する」というものです。災害時の避難訓練さながらです。メンバーからは「レッドチーム演習みたいだ」という声もあがりました。
演習のコーディネーターはベテランメンバーが担当しました。私はトラブル発生時にインシデントコマンダー (障害対応の旗振り役) を担当する機会が多いため、今回はコーディネーターとして参加しました。
演習準備
今回の演習シナリオは「未検証のコードが誤ってデプロイされたことにより、全文検索システムにおいてデータスキーマと検索ロジックの間に不整合が生まれた。その結果、検索 API に特定のパラメータを付与するとレスポンスが期待しないものに変わり、これに気づいたシステム利用者から問い合わせが着信した。」というものです。もしプロダクション環境で起きたらと想像すると鳥肌が立ちますね。
演習問題のシナリオはベテラン作業者が中心となって作成しました。シナリオ作成に際して、トレーニー (トレーニングを受けるメンバー) に身につけてほしいポイントを踏まえ、以下の点を工夫しました。
・ 類似事例が知られているものを採用し、実践的なテーマにすること
・ 複数のパラメータを混ぜ、原因特定の難易度をリアルにすること
・ その不具合によって副次的に発生するトラブルがあること
一方でトレーニーには、事前にシステム障害発生時にどう振る舞うか、少し作戦会議をしてもらいました。理想的な動きを考えてもらい、それを実践する努力をすることで、演習の効果を大きくすることができると考えたからです。作戦会議の結果、今回は作業者とインシデントコマンダーを事前に決めて演習に臨むことにしたようです。
トレーニーはこの演習に対して、大変前向きな姿勢で取り組んでいました。出題者であるベテランエンジニアと一緒に「◯分以内に復旧したらプラチナ、◯分以内でゴールド」などとランク付けして、よい成績を獲得しようと意気揚々と臨んでいました。
いざ、演習開始！
コーディネーターは、利用者役としてトラブル対応者とコミュニケーションをとる役目 (今回はベテラン作業者が担当) と、オブザーバーとしてトレーニーの行動を観察・記録する役目 (今回は筆者が担当) をそれぞれ分担しました。
トレーニーが利用者役から不具合報告を受け、演習開始です。オブザーバーはトラブル対応中にどんな作業・どんな会話をしているか、利用者や周知用チャンネルに対してどんな連絡をしているか、事実およびそれに対する所感を細かく記録していきました。
演習問題の作成において工夫したポイントは、狙い通り演習の進行において重要なポイントとなりました。一例を挙げると、直接指摘された不具合は類似事例を参考にしながら順調に復旧させましたが、副次的な不具合を見落としていました。復旧作業が続く中、利用者役から別の不具合を検知したという連絡を受け、慌てて追加の対応を開始する一幕もありました。
最終的にはトレーニーがすべてのシステム障害を自力で復旧し、復旧完了連絡とともに演習は終了しました。ステージング環境とはいえ長時間不具合を放置するわけにはいかないため、状況によって強制的に復旧させる準備もしていたのですが、杞憂に終わりホッとしました。
ふりかえり
演習が終わったら、少し休憩をとってからふりかえりを実施しました。利用者役のリアルな演技・演出が効いたのか、トレーニーは思っていたよりも緊張感があって疲労を感じていたようでした。特に追加の不具合連絡を受けたときは、かなり焦りを感じたようです。
ふりかえりではまず、演習課題に含めたメッセージをトレーニーと認識合わせしました。一方で、トレーニーから復旧手順についてフィードバックをもらい、チームとして実施すべきアクションを洗い出しました。定型化された手順に対する感覚はベテランほど鈍くなってきますので、経験が少ないメンバーから新鮮なフィードバックを得る貴重な機会となりました。
システム障害対応中のコミュニケーションについては、「必要十分なコミュニケーションをとることは想像以上に難しかった」という意見が上がりました。メンバーはみな技術者ですので、役割分担するつもりでいても、つい手を動かしてしまい、作業とコミュニケーションの両立に苦しんだようです。
一般的に、トラブル発生時のコミュニケーションは様々な立場を考慮する必要があり、想像以上に難易度も負荷も高いものです。作業しながらこの役目を負うことはコミュニケーションの品質悪化につながるため、インシデントコマンダーなど役割を明確にすることでコミュニケーションの質を担保することが重要です。本演習を通して、改めて役割分担の大切さを実感することができました。
コーディネーターの立場としても学びが多い演習でした。演習問題として「良問」を考えることは、システム開発・運用において重視すべきポイントを体現するもので、改めてこれらのポイントを見直すきっかけになりました。
加えて、少人数のチームではほとんど全員が障害対応の当事者となるため、オブザーバーという立場をとること自体が稀です。第三者の立場でチームの実態を見つめ、精緻にフィードバックできる貴重な機会でした。
まとめ
本演習は、経験が浅いメンバーがシステム障害対応をする上での不安を払拭しただけでなく、チーム全体に対してよい影響を与える大変有意義な機会となりました。この演習が、チームが提供するサービスレベルを底上げすることにつながると期待しています。障害対応演習が、緊急事態に備えるアイデアとして参考になりましたら幸いです。
参考文献
障害対応の訓練を実施するというアイデア、および障害対応における役割分担などの基礎知識は、本書を参考にしました。本稿で紹介した「インシデントコマンダー」の役目についても詳しく記述されています。ベテランに依存しがちなシステム障害対応のノウハウが言語化されており、大変重宝しています。