1. 質問と背景
プラットフォームチームは、ファイアウォールルール、決済限度額、またはサービスルーティングを変更する必要があります。申請者が自身の変更を承認することはできず、承認は正確なバージョンを対象としなければならず、実行が失敗した際に部分的な更新が残ってはなりません。目標は、検証可能で監査可能、かつ復旧可能なワークフローです。
2. 面接官が評価している点
- 提案、承認、実行、ロールバックの各状態を分離しているか。
- 承認者が独立しており、承認された内容が不正にすり替えられないようになっているか。
- 同時承認、重複リクエスト、タイムアウト、失効、および権限変更を処理しているか。
- リスクを制御しながら、小規模なロールアウトと安定した復旧を提供しているか。
NIST SP 800-128 では、構成変更を申請者から独立した権限を持つ人物によってレビューすることを求めています。Google SRE では、構成バージョンのコードレビューを行い、新しい構成がチェックに合格しなかった場合は以前の構成の提供を継続することを強調しています。これらの原則をデータと状態遷移に落とし込みます。
3. 回答前の明確化のための質問
- どのリソースおよびフィールドが高リスクであり、環境やテナントによって異なりますか？
- 承認は1名、複数人のうちの誰か、それともロールと人数にわたる閾値ですか？
- 実行は一括切り替え、バッチロールアウト、それとも対象インスタンスごとの確認ですか？
- ロールバックは最後に正常稼働が確認されたバージョンですか、それとも申請者が選択したバージョンですか？
4. 30秒の回答フレームワーク
イミュータブルな提案、ポリシーマッチング、承認の分離、エグゼキュータ、ロールバック、監査を使用します。
私はすべての変更をイミュータブルなバージョンとして凍結し、ポリシーがリソース、リスク、環境から独立した承認者を選択するようにします。承認にはバージョンのダイジェストとポリシーバージョンが記録され、申請者が承認閾値を満たすことはできません。冪等なエグゼキュータがヘルスチェックを行いながらバッチ単位で変更を適用します。障害が発生した場合は即座に以降のロールアウトを停止して最後に検証されたバージョンを復元し、すべての状態と決定事項は追記専用の監査ストレージに送信されます。
5. ステップごとの詳細解説
ステップ 1: エンティティとステートマシンの定義
提案には、リソース、差分、作成者、バージョンダイジェスト、対象環境、有効期限が含まれます。承認には、承認者、ロール、決定、時刻、ポリシーバージョン、提案ダイジェストが含まれます。実行レコードには、バッチ、対象、結果、ロールバックバージョンが含まれます。状態は DRAFT、PENDING_APPROVAL、APPROVED、EXECUTING、SUCCEEDED、FAILED、REVOKED、または EXPIRED となり、サーバー側のルールのみがこれらを遷移させることができます。
ステップ 2: 承認の独立性とバージョンへのバインド
ポリシーサービスは、必要なロール、対象者、自己承認の禁止、および承認の有効期間を計算します。承認者に表示される差分は、実行バージョンとハッシュが一致しなければなりません。提案に対するいかなる編集も承認を無効化し、新たなレビューを開始します。後からのロール剥奪を回避できないように、承認時と実行時の両方で権限を再チェックします。
ステップ 3: 冪等なエグゼキュータによるリリースの制御
提案と対象ごとに冪等性キーを生成し、外部からの応答確認を記録します。構文、依存関係、安全性のチェック後に小規模なバッチを適用し、ヘルスシグナルを監視します。不明な結果のみをリトライし、非冪等な操作を決して盲目的に繰り返さないようにします。キューまたはワークフローエンジンが、タイムアウト、リトライ、および同時実行数の制限を処理します。
ステップ 4: 安全なロールバックと監査
リリース前に最後に検証されたバージョンを保存します。障害発生時は後続のバッチを停止し、そのバージョンを復元します。ロールバックの操作者と理由を記録します。高リスクな緊急ロールバックには独自の承認が必要になる場合があります。少なくとも提案ダイジェスト、承認チェーン、実行バッチ、構成バージョン、失敗理由、およびロールバック結果を監査し、削除や変更を制限します。
6. 高品質な回答例
システムを提案API、ポリシーサービス、承認サービス、実行キュー、構成アダプター、および監査ストレージに分割します。提案はイミュータブルであり、リソースの差分、環境、作成者、有効期限を含みます。ポリシーサービスは、作成者を除外し、リスクに応じて必要なロールと承認者の人数を計算します。
>
承認者にはバージョンのダイジェストと差分が表示され、承認は提案のハッシュとポリシーバージョンにバインドされます。いかなる編集が行われても、提案は承認待ちの状態に戻ります。閾値が満たされると、エグゼキュータは提案IDと対象IDから冪等性キーを作成し、静的チェックを実行してから、ヘルスシグナルを読み取りつつ小規模なバッチを適用します。重複リクエストには既存の実行結果を返し、不明な結果はレビューに回します。
>
各提案は最後に検証されたバージョンを保持します。バッチが失敗した場合、後続のバッチは停止され、古いバージョンが復元されて理由が記録されます。緊急の高リスクロールバックには引き続き独立した承認が必要です。監査イベントは追記専用であり、誰がどのダイジェストをいつ承認したか、どの対象で実行されたか、ロールバックが発生したかを記録します。これにより職務分掌が強制され、承認された構成が密かに置き換えられるのを防ぎます。
7. よくある失敗パターン
- 正確な差分やバージョンダイジェストではなく、リソースIDのみに承認をバインドすること。
- 作成者が別のロールを介して自己承認できるようにすること。
- 実行状態や確認応答なしに、構成ストアに承認を直接書き込むこと。
- 障害発生後にロールアウトを拡大したり、非冪等な操作を無制限にリトライしたりすること。
- バージョン、権限、監査証跡を記録せずにロールバックすること。
8. フォローアップの質問と回答
フォローアップ 1: 承認後に作成者が離職した場合はどうなりますか？
決定はイミュータブルな提案にバインドされており、作成者がオンラインである必要はありません。実行にはサービスアカウントと現在のポリシーが使用されます。作成者の権限を剥奪しても、有効な監査チェーンは消去されません。
フォローアップ 2: 2つの承認フローが同じリソースを実行するのをどのように防ぎますか？
リソースと環境に対するロックまたはリースを使用し、実行前に現在の構成バージョンを再チェックします。競合が発生した場合、より新しい提案は差分と承認を再計算します。
フォローアップ 3: 緊急変更で承認をバイパスできますか？
二者承認、最小特権、短い有効期間、変更後レビュー、および完全な監査を備えた、厳格に制限されたブレイクグラス（緊急対応）パスを定義します。これを通常の近道にしてはなりません。