こんにちは、株式会社Schoo(以下、スクー)でエンジニアをしているタキザワと申します。
サービスが高度化、複雑化する現代において、システムを障害なく運用することは非常に難しく、どのサービス企業でも常日頃システム障害への備えをしているかと思います。
今回は、システム障害への備えとしてスクーで最近行った障害対応訓練の取り組みについて、若手エンジニア育成の観点からご紹介したいと思います。
なお、障害対応訓練自体は他社でも多く事例があります。
実施にあたり、上記の記事を大いに参考にさせていただきました。ありがとうございます。
この記事でわかること
- なぜ若手エンジニア育成の手段としても障害対応訓練がオススメなのか
- スクーでの実践例としてどのような工夫をしているのか
想定読者
- メンターやエンジニアリーダーなど、なんらかの形でエンジニアの育成に関わる方
障害対応プロセスの性質
障害対応プロセスにおける対応は、主体的なものと定型的なものに大別することができます。
主体的な対応は、一朝一夕でできるようにはならないものの、エンジニアとして学習や業務経験を積んでいけば、自然と速度や精度は上がっていきます。
一方、定型的な対応は、意識的な練習を重ねることで速度や精度が上がっていきます。
また、エンジニアとしての知識や業務経験が少なくても、練習を重ねれば確実に習得できます。
障害対応は、限られた時間の中で正確かつ迅速な対応が求められるため、主体的な対応に集中し、定型的な対応は 無意識レベルの行動に持っていく ことが非常に重要です。
スクーでの課題感
障害発生時に、有識者やベテランだけで対処を進めてしまい、 対応者が属人的になりがち でした。迅速正確な対応が求められることもあり、どのサービス企業でも起きがちな課題かと思います。
原因も細分化できるため、いろいろな対処方針が考えられる中で、私は若手（特に生え抜き社員）の関与率の低さに着目しました。
そこで、上記の障害対応プロセスの性質も踏まえ、まずは定型的な対応から、若手も活躍できる部分を作り、より円滑に障害の対応に向き合える体制を作っていくことで、属人化へ対抗することができるのではないかという仮説を持ち、実践してみることにしました。
実施までの流れ
実施までの流れは下記の通りです。
- 準備
- 目的や必要な事前準備などを明確にし、実施計画を練る
- 若手エンジニアに障害対応訓練の主旨を説明する
- 実施（下記を複数回行う）
- 実際に開発環境で障害を発生させて開発用のSlackチャンネルにて障害報告を行う
- Google Meetに集まり対応開始
- 参加者各自のGood&Moreによる振り返りを行う
- 評価者から訓練評価をフィードバックする
実施時の主体的な行動は参加者に委ね、私は、
- チームの行動を観察し、習熟度を評価する
- 事業責任者、上長、カスタマーサポートなど、必要なロールの窓口となり、対応者からの質問に回答する
に専念していました。
工夫したところ
訓練実施にあたり、いくつか工夫した点を紹介します。
計画作りを生成AIに任せる
近年はAIの進化発展も目覚ましく、もはや業務上欠かすことのできない技術となっています。
スクーでも Geminiを活用できる環境 があるため、計画作りはGeminiに助けてもらいました。
（プロンプト例）
若手のエンジニアに向けた障害対応訓練を行いたいと思います。
実施までの計画を立てたいので、必要な準備を教えてください。
実施の段取りはそこまで工夫すべき点もないので一般論に任せ、「課題感にフォーカスし期待した効果を得るために抑えるべきポイント」に作業リソースを集中投下できたため、効率的、且つ、質にコミットした計画を立てられました。
障害シナリオを難しくしすぎない
若手エンジニアの育成を目的とした場合、障害のシナリオは 難しくしすぎない ことが大切だと思い、ここは気を遣いました。
何度も訓練を重ねることを想定した場合、1回1回の実施時間が長くなってしまうと、
反復練習する機会が減ってしまい、効率が落ちてしまいます。
（逆に、対応の核心でないことが無意識のレベルでできるようになってきたら、
様々なパターンのシナリオを練習する方針に変えることを検討しても良さそうです。）
第1回では、特定条件下でトップページにアクセスした際、コールスタックが表示されるような障害を用意しました。
（スクリーンショットはイメージです）
エラーを起点として調査する練習になりますし、対策や暫定対応までの流れをシンプルに考えられるため、一定の効果が見込めたと思っています。
反省点
一方で、上手く行かなかった部分もありました。
「本番障害はリリース時だけでなく、リリース後からタイムラグで発生したり、リリースとは関係なく発生するものもある」と考え、第1回は「◯月△日のコアタイムのどこかで障害が起きる」という設定で進めましたが、これは下記の点で難しかったです。
- お昼休憩をいつ取ればいいのか分からず、取れなくなる
- 同日内の別の会議との調整が難しい
普段は、リリースなどがある場合を除き、本番障害が起きることを前提として日々の計画は立てていないと思ったので、障害発生状況の再現にこだわりすぎず、第2回以降は発生時間を固定して実施するようにしました。
参加者の声
実際に参加いただいた若手5名の方から
- 実際に障害対応の際に意識するポイントを知ることができた
- Datadogの使い方を実践を通して試すことができた
- 毎回、評価と振り返りを全員ですることで成長を感じることができた
- これらの経験を通して、障害対応への恐怖心が少し薄れた
- 実際の障害発生時に障害訓練で学んだ内容を活かすことができた
- 障害対応への他人事感が薄れた
- 障害対応はもっともスキルを伸ばせる場の一つだと思っていたので、こういった場を作ってくれること自体が良い取組みだと思った
- 他の役割の人がどんな情報を必要としているのかについて、振り返りやフィードバックを通じて理解が深まった
- 実際の障害発生時に、一緒に訓練した後輩が率先して対応していてすごく嬉しかったし、この訓練の成果だと思った
- 障害対応のフローを学ぶことができた
- 実際に障害が起きた時に自分にもできることがあると体験できた
- 他のサービスについて知る機会になった
- 実際の障害の補佐は行っていたが、障害オーナーを務めるまでの自信はなかったので、障害訓練によってオーナーを経験することができて良かった
- 障害時のコミュニケーションや障害後の振り返りを通して、チーム全体の行動やそれぞれの考えていたことを内省することができ、回を増すごとに結束力を高めることができた
と、多くのフィードバックをいただけました 
まとめ
これまでに若手エンジニアを対象とした障害対応訓練を3回ほど実施しましたが、回を重ねる毎に、明らかに円滑な対応ができるようになってきており、若手の成長と、さらなる伸び代を実感しています。
- 障害対応時に必要とされるコミュニケーションに粗さや無駄がない
- 対応時の選択や行動に自信を感じられる
- 「対応の核心」に対する会話量が増えている
若手エンジニア育成の一つとしてオススメですので、若手のさらなる成長を期待したいと思っている方は、是非一度、このような方法も検討してみてください！
Schooでは一緒に働く仲間を募集しています！
Views: 0
