**良い回答は、顧客への被害を減らし、不完全な情報で判断し、再発を防いだ方法を示します。**チーム全体の成果を自分だけの仕事として語らず、自分の役割を明確にします。
実際に経験した障害を使ってください。以下は構成を示す架空の例です。面接では実際の行動と検証済みの結果に置き換えます。時間区分は説明用であり、すべての障害対応に共通する期限ではありません。
リリース直後に購入失敗が増えたとき、自分が当番のバックエンドリードだったとします。閲覧はできても、一部の顧客は注文を完了できません。この時点では、時間が近いことからリリースが仮説になるだけで、原因と確定したわけではありません。
技術的な復旧の調整、調査の割り当て、障害責任者への報告という自分の責任を説明します。障害全体も指揮したなら明示し、自分が詰まりにならないよう連絡や実作業の調査を委任します。
購入エラー、遅延、成功した注文を調べ、誰が影響を受け、問題が続いているか確認します。連絡先を1つにまとめ、役割を決め、無関係な変更を止め、観測と操作の時系列を記録します。
理由は実務的です。複数人が独立して変更すると、原因が見えなくなったり悪化したりします。状況報告では確認した事実と仮説を分け、次の報告時刻を示します。Googleの障害対応ガイドも参照できます。
DB接続が飽和し、今回のリリースで高負荷のレポート経路が追加されたと分かったとします。ロールバックと、その経路だけ一時停止して購入を維持する方法を比較します。
判断は入手済みの根拠と取り消し可能性に基づきます。顧客が止まっている間に根本原因の完全な確定を待つことはしませんが、選んだ操作がなぜ効くと考えたか記録します。
CPUグラフが下がるだけでは不十分です。実際の購入が成功し、遅延が許容範囲に戻り、滞留が新たな負荷を生まず減っているか確認します。1回成功しただけで復旧宣言せず、緩和後も観察します。
結果が曖昧な支払いは、再課金の前に決済システムと照合します。タイムアウトの裏で決済が完了している可能性があります。根拠のない復旧時刻を作らず、戻った機能、不明点、顧客がすべきことを伝えます。
この架空の例では、レポートと購入が接続枠を共有し、レポートの処理量に有効な上限がなかったと判明するかもしれません。「注意する」で終えず、その仕組みを改善します。
実際の面接では、復旧結果と、その後のテストや運用で得た根拠で締めます。測定していないなら、見栄えのよい数値を作らずそう伝えます。教訓は、自分が実装と検証に関わった変更に直接結び付けます。
ジュニアからシニアまで、詳細な回答付きのIT面接質問ライブラリ。
寄付する