プロンプトとコンテキスト
頻繁に使用されるインシデント用ランブックに削除済みサービスの手順が含まれており、障害を悪化させる可能性があることに気付きました。現在のオンコール体制を中断することなくオンコールチームを保護し、代替手順を検証し、ランブックを廃止または書き直し、その改善が定着したことを証明する方法を説明してください。
面接官が見ているポイント
- ドキュメントの所有権を議論する前に、安全でないアクションのリスクを低減すること。
- 「ドキュメントが古い」状態を、再現可能で検証可能な移行計画へと変換すること。
- STAR メソッドを用いて、影響、コラボレーション、トレードオフ、フォローアップの指標を説明すること。
最初に明確にすべき質問
- どの手順が無効であり、それらはデータの削除、トラフィックの拡大、あるいは復旧の阻害を引き起こす可能性があるか？
- キャッシュされたリンクやボットを含め、オンコールエンジニアは実際にどこからランブックを開いているか？
- 代替ドキュメントの所有者は誰か、どのようなサンドボックスが存在するか、緊急時のロールバックはどのように機能するか？
30秒での回答
まずランブックの最上部にリスクを明記し、オンコール担当者とインシデントオーナーに通知した上で、無効な手順が繰り返されないよう検証済みの一時的な手順を提供します。サンドボックスで代替手順をテストし、サービスオーナーとともにリンク、権限、ロールバック手順を更新した後、新バージョンを公開して旧バージョンを非推奨化（deprecate）します。定着度の測定は、単にドキュメントの変更がマージされたことではなく、リンクへのアクセス状況、訓練の成功率、誤操作の有無、完了したフォローアップ項目を通じて行います。
ステップごとの詳細解説
1. 危険な手順を隔離する
不可逆的な影響を及ぼすコマンドや判断を特定します。目立つ警告を追加するか、自動リンクを無効化するか、オンコールオーナーによって承認された一時的な手順を維持しつつ、旧バージョンを明示的なアーカイブに移動します。
2. 実際のアクセス経路を再構築する
オンコールのインデックス、検索結果、ボットのメッセージ、権限、キャッシュされたブックマークを調査し、エンジニアが実際に使用しているバージョンを特定します。元のリポジトリだけを編集しても、コピーされたリンクが出回り続けることになります。
3. 代替手順を検証する
サンドボックスまたは低リスクの時間帯で新しい手順を実行し、前提条件、シグナル、停止条件、ロールバック手順を記録します。GitLab では、ランブックを初期の特定や日常的な対応のためのものとし、より複雑なケースにはプレイブックやエスカレーションパスを用いると説明しています。ドキュメントの境界は実際の責任範囲と一致させる必要があります。
4. オーナーチームとともに書き直す
サービスオーナー、オンコール代表者、セキュリティやコンプライアンスのレビュー担当者に変更の確認を依頼します。記憶に頼って重要なコマンドを書き直すのではなく、事実、前提、未確認事項を明確に分離します。各手順には、適用範囲と失敗時のエスカレーション先を明記します。
5. 公開と廃止を計画する
新しいバージョンを候補として公開し、旧バージョンには廃止日と代替リンクを設定します。古い手順が深刻な被害を引き起こす可能性がある場合は、変更プロセスに従う前に実行権限を削除するか読み取り専用にします。ロールバック手順は、デプロイ権限および最新の利用可能バージョンと整合させておきます。
6. 訓練で定着度をテストする
ランブックの作成に関与していない人物に訓練を実施してもらいます。エントリポイントを見つけられるか、前提条件を認識できるか、停止条件でエスカレーションできるかを観察します。作成者自身によるテストで代替するのではなく、所要時間、誤った手順、疑問点を記録します。
7. メンテナンスのトリガーを追加する
オーナー、レビュー期日、ならびにトポロジ、アラート名、権限の変更といったトリガーを設定します。ドキュメントの陳腐化は、変更レビューにおいてドキュメント確認が不足していることを示唆している可能性があります。リリースチェックリストやインシデントレビューのアクションにそれを追加します。
模範解答
無効な手順のリスクを確認し、警告を追加し、オンコール担当者とインシデントオーナーに通知して、確認済みの一時的な手順を提供します。関係者が実際に使用しているリンクを調査し、前提条件、停止条件、ロールバックを含む代替手順をサンドボックスでテストした上で、サービスオーナーおよびオンコール代表者とともにレビューします。その後、新しいバージョンを公開して旧バージョンを非推奨化し、作成に関わっていない人物とともに訓練を実施します。受け入れ基準には、エントリの発見、誤操作の有無、エスカレーションのタイミング、移行の完了を含め、変更プロセス内にメンテナンスのトリガーを組み込みます。
よくある間違い
- 安全な代替手段がないまま古いランブックを削除すること。
- キャッシュされたリンク、ボット、ブックマークを無視してリポジトリのみを編集すること。
- 作成者単独で訓練を完了させただけで成功と判断すること。
- プレイブックやエスカレーションの境界を設けずに、すべての障害対応手順をランブックに詰め込むこと。
- 誤操作の数や訓練の結果ではなく、ドキュメントのマージ数で評価すること。
フォローアップの質問と回答
インシデントがすでに発生している場合はどうしますか？
インシデントリードに一時的な手順とリスクを確認させ、無効な手順の伝播を阻止し、インシデントのアクションリストにドキュメントの修正を追加します。火消し対応の最中に、未検証の大規模な書き直しを行ってはなりません。
サービスオーナーがランブックの陳腐化を否定した場合はどうしますか？
該当する正確な手順、最近の変更点、再現可能な失敗の証拠を提示し、小規模な訓練を提案します。個人を責めるのではなく、ユーザーリスクとメンテナンスの所有権に議論を集中させます。
多くの外部チームが古いランブックを使用している場合はどうしますか？
安定したリダイレクトや互換性に関する注意事項を維持し、利用者に通知した上で移行期日を設定します。まずは高リスクなコマンドの実行権限を制限し、チームごとに順次移行を確認します。
旧バージョンを完全に削除すべきタイミングはいつですか？
代替手順が訓練を通過し、オーナーが存在し、すべての重要なエントリポイントが移行され、ロールバックが利用可能になった後のみです。セキュリティやコンプライアンスで要求される場合は、より厳格な保持ルールに従います。
訓練で代替手順が失敗した場合はどうしますか？
公開を中止し、失敗した前提条件やシグナルを記録し、手順を修正して訓練を再実行します。失敗はリリース基準を満たしていない証拠であり、言い訳をして済ませる理由にはなりません。
この経験を STAR メソッドでどのように伝えますか？
具体的なリスクとタスクを説明し、次いで通知、検証、コラボレーション、公開の各ステップを説明します。最後に、誤操作の減少、訓練の合格率、または移行の完了に加え、新設したメンテナンスメカニズムで締めくくります。