障害対応シナリオ面接の対策：原因究明より先に安定化する

障害の設問は意図的に情報が不足しています。影響する利用者と地域、開始時刻、データ整合性やセキュリティの可能性、切り戻し・流量停止・他チーム招集の権限を聞きます。

証拠から暫定重大度を置き、最初の目的を言います。リリース後に購入処理が壊れたなら、ログを残しながら切り戻しや流量制御で失敗を減らすことが優先になり得ます。

インシデント責任者、技術責任者、連絡担当を決めます。小さなチームでは兼任しても、責任には名前が必要です。全体責任者が優先順位と判断を保ち、技術担当が調査に集中します。

時系列を一つ作り、観測、対応、担当、結果、時刻を残します。並行作業は、それぞれに問いと担当者がいる場合だけ有効です。

最初の15分は影響確認、役割決定、有害な自動処理の停止、安全な影響低減を行います。次の30分で、効果確認、障害時間の絞り込み、直近変更の比較、関係者更新を行います。復旧後は指標監視、データ照合、後続作業の引き継ぎへ進みます。

影響低減と原因究明は別です。切り戻しでサービスが戻っても、原因を証明したとは限りません。可逆的な復旧を、完全な説明が出るまで遅らせないようにします。

影響、現在、対応、次回報告の4行にします。例：「日本の利用者で購入失敗が発生しています。原因は未確定です。直近リリースを停止し、回復を計測しています。次回は14時30分に報告します」。

根拠のない復旧予定時刻を約束しません。経営層と顧客で技術詳細は変えても、事実を揃えます。

リリース10分後にAPIエラーが通常値から18%へ上がったとします。バージョンと利用者経路で相関を見ます。旧バージョンが正常なら、権限範囲内で切り戻しを提案します。同時に一人がログと依存先を確認し、相関を原因と決めつけないようにします。

切り戻し後はエラー率と利用者操作の両方で回復を確認します。影響した書き込みを特定し、データ補正の要否を決め、時刻つきの記録を残します。

復旧後は、検知、影響低減、連携、連絡、再発防止を責任追及なしで振り返ります。各対応に担当と確認可能な完了条件を付けます。「監視を改善する」ではなく「購入成功率が合意値を5分下回ったら通知する」なら検証できます。

5分ごとに新しい情報を出す机上演習を行い、最終時系列と変えたい判断を保存します。次の回答を略語の暗記ではなく、経験から作れます。