はじめに
こんにちは、ニジボックスに勤務しているエンジニアの芹沢と申します。
本日は、リクルートとニジボックスで開発・運用している横断データプロダクト「Crois（クロイス）」で、2025年9月に行った障害対応訓練について書かせていただきます。
チーム内で運営側、参加者側に分かれており私は参加者側で参加しました。
扱っている社内システム（Crois）の概要
Crois とは、ワークフローエンジン・ジョブスケジューラ機能を提供する横断データプロダクトです。
様々な事業領域において、機械学習の学習・推論やETL をはじめ、多様なジョブが実行されています。
Crois は1日あたり2万件以上のジョブと8万件以上のコンテナタスクを実行しています。
ジョブとは Crois で作成したワークフローを実行したものであり、詳細画面 (図1) ではジョブのステータス (実行中、成功、失敗など) や開始時刻、タスクのログを確認することができます。
ワークフローには複数のタスクが含まれており、それぞれのタスクはコンテナタスクとして実行されます。
コントロールプレーン（管理機能）は AWS 上に構築され、コンテナタスク実行環境は AWS/Google Cloud の両方を提供しています。
図1 ジョブの詳細画面
Crois は2019年にリリースされました。
この6年間で各事業領域でのデータ利活用の拡大を経て、年々利用量が増え続けています。 (図2)
図2 四半期ごとのジョブの実行数の推移グラフ
Crois については本記事以外にも関連記事が公開されているため、興味がある方はそちらもご確認ください。
障害対応訓練の背景と目的
今年に入ってからもいくつか障害が発生して対応したのですがその際に以下のような課題が見えてきました。
- 障害対応の知見を持つメンバーが減ってきており、経験豊富なメンバーに負担が偏る。
- 特定のメンバーがいないと対処できない恐れがある。
- 技術力のあるメンバーが中心となるため、他のメンバーが障害対応の経験を積みにくい。
- そのため全体の練度を高める必要性がある。
再び障害が発生した際に技術力のあるメンバーがいない場合どうするかという懸念があり、
またチーム全体に対しても障害への経験を積ませたいという考えから、今回の障害対応訓練が開催されました。
実際の訓練の内容
ここでは実際の訓練について記載します。
なお、今回の訓練は壊してもいい開発環境を用意してその上で行われました。
訓練の設定
参加者・運営者のチーム編成
最初に記載した通り、Croisチームの中で運営者と参加者に分かれました。
運営者は比較的知見が深いメンバー、障害対応に慣れているメンバーが行いました。
それ以外のメンバーが参加者となり運営者が発生させた障害に対応していきます。
運営者がやること
障害のシナリオ作成、当日のCroisユーザーやAWSサポートの役割を行います。
訓練前の期間はシナリオの作成やアラート、動作チェックを行います。
当日には以下のようなことを行いました。
- 障害を発生させる役
- Croisユーザー役としてどのような障害が起きているかの問い合わせ役
- クラウドベンダーのサポートデスク役（使用しているクラウドサービスの技術的な質問や仕様に回答）
- エスカレーション先のGM（グループマネージャー）役
- 制限時間を超えた時のタイムキーパー役
- 完全に詰まってしまった時のヒント役
参加者がやること
通常の障害対応プロセスに従って、アラートに応じて素早くメンバーが集合し、Slack上に専用の対応チャンネルが作成されます。
その後各メンバーに以下の役割が割り当てられ各々対応を行います。
- 現場指揮官
- 暫定対応者
- 書記
- 広報
- 外部調整者
- プラットフォームへの問い合わせ
ただし、実際の対応の様子でも触れますが、この役割分担はうまくいかない部分もありました。
基本的に行うこととしては以下の通りです。
- Croisユーザー対応
- エスカレーション
- 障害の原因調査・復旧
- 上記内容の広報
訓練のルール
業務に大きな影響を起こさないように以下のような決め事をしていました。
- 予め日付、大まかな時間帯の指定を行う。
- 制限時間に達した際、他の大規模障害が起きた際などは中止する。
- ただし今回に関しては対応完了までやりきれそうな状況だったので、制限時間を少し延ばし最後まで対応しました。
- 訓練中の通常業務（問い合わせ・アラート対応など）は運営側が対応する。
- 完全に詰まってしまった場合は運営側からヒントがある。
訓練のシナリオ
シナリオ
シナリオの概要はCrois開発者の手動オペレーション中に、誤ってデータベース上のワークフローのテーブルを全て削除したという内容です。
削除された箇所を発見してバックアップからリカバリするというのが想定される対応であり、実際に起きた場合でもCroisユーザーの日次ETL処理などが止まり大きな業務影響が出る障害となります。
上記シナリオは参加者には事前に伝えられておらず、アラートやCroisユーザー（役）からの問い合わせなどで発見して始まります。
参加者に期待されていること
参加者がやることに記載していた通り、以下の対応をスムーズに行うことが重要です。（再掲）
- Croisユーザー対応
- エスカレーション
- 障害の原因調査・復旧
- 上記内容の広報
上記を更に具体化するとこうなります。
- Croisユーザー全体への影響調査
- 問い合わせしたCroisユーザーに対しての説明
- GMへのエスカレーション
- 削除されてしまった原因の発見
- 今回の場合はテーブルが全削除されてしまったこと
- 復旧の可不可、復旧方法の技術的な調査
- 今回の場合はバックアップからのリストア
- 影響が大きいため素早い広報
単に障害を解消するだけではなく、役割分担や技術力でこれらをいかにスムーズにしていくかが鍵となります。
実際の対応の様子
今回のケースでもほぼ日常的に起きた障害の対応フローに沿っていました。
ただし、口頭ベースで会話をしていたため役割分担については対応できず、特に書記については設定すらできていませんでした。そのため、体制構築の部分で段取りが悪く遅くなってしまった部分があります。
復旧作業については、運営側が想定していた手順（想定解）とは多少違うアプローチでしたが、
バックアップからのリストアは無事にできており、結果的に障害を収束させることができました。
振り返り
訓練の後に、運営側からシナリオを全員にネタバラシしつつ全員で振り返りを行いました。
結果としては以下のような改善点が挙げられました。
- 役割分担が口頭ベースになってしまい、書記（議事録担当）が明確に設定できていなかった。
- 復旧作業にリソースを割いてしまい、Croisユーザー影響の考慮や対応が後手に回ってしまっていた。
- 対応の際にCroisユーザー目線での視点が抜けており、情報の共有が遅れてしまった。
- 過去事例に似たような対応が残っていたが参照できていなかった。
特に役割分担やCroisユーザー対応、障害対応の基本であり普段から行うべきでありこれらは強く改善したい点として認識されました。
通常のフローにはありませんが、DBの復旧という作業であるためメンテナンスモードへの切り替えも考慮に入れるべきだったと思います。
課題が多く見つかりましたが、訓練としては非常に有意義だったと思います。
Croisチームでは今後も半年に一回このような大規模な訓練を行う予定を立てており、定期的にポストモーテムという形で記録を残すことで知見を蓄積していく方針です。
この記事も当時の記録を残したポストモーテムを参考に作成しました。
図3 障害対応訓練ポストモーテム
学び
個人的に訓練の流れを振り返ると、調査や復旧作業の基本的な対応・流れについては踏襲できていたのですが、役割分担やCroisユーザー対応が上手くできておらず、その影響で最終的な解決まで時間がかかってしまったという結果でした。
普段の業務では基本的な技術やシステムの理解などの「技術力」の部分に重点が置かれがちで今回も復旧作業の部分ではそこがネックになった部分があるのですが、「体制構築」の重要性についても改めて認識させられ、運用という観点で見ると障害発生時に迅速かつ的確な対応ができる体制の整備が非常に重要だと改めて感じました。
特に、役割分担や情報共有の仕組みが明確になっていることで、混乱を防ぎ対応をスムーズに進めることができます。
今後も定期的な訓練を通じて、チーム全体の対応力や運用体制の強化を図っていきたいです。
まとめ
まずはここまで読んでいただきありがとうございます🙇
記事の背景の部分で触れた通り、実際の障害発生時は知見のあるメンバーが中心に動くことが多いためこういった訓練の機会でしか積めない経験も多く、非常に有意義なものとなりました。
余談ですが、タイミング良く（？）訓練を行った一ヶ月後に普段活躍しているメンバーが不在で人員が少ない状況で、比較的大きめの障害が発生するという、まさに訓練で想定していたようなケースが発生しました。
しかし、その際は訓練の反省を活かしたためか、体制構築・Croisユーザー対応についてスムーズに動くことができ、無事に対応を完了できました。
普段からの訓練は本当に大事ですね。