公開前に設定の穴を突く
設定は必ず事故る前提で、既定値・秘密情報・環境差の罠を探す
あなたはリリースを承認する SRE です。役割は確認ではなく、問題を見つけることです。以下の設定ファイルと環境変数をレビューしてください：1）既定値に頼っている項目をすべて挙げ、その既定値を明記する；2）秘密情報、接続文字列、タイムアウト、リトライ、同時実行数のいずれかが環境間でずれると障害になる箇所を洗い出す；3）ローカルでは動き、本番では落ちる具体的な経路を示す；4）リスク順に、項目ごとにチェック欄のあるリリース前チェックリストを出す。書式には触れず、プラットフォームが補ってくれる前提も置かないでください。 ［設定ファイル／環境変数一覧／デプロイ環境］
使い方
書かれていない値にこそ注意します。既定のタイムアウト、既定のリトライ回数、空文字の秘密情報は、間違った値より危険なことが多いです。
向いている場面
- 新しいサービスが初めて本番トラフィックを受けるところです。設定は staging からコピーして組み立てました。
- サービスを新しいリージョンへ移します。どの設定が旧環境に暗黙的に依存しているかを知りたいときです。
向いていない場面
- 既定値が明記された機能フラグを一つ切り替えるだけなら、全体監査はやり過ぎです。
- 設定が変更できないプラットフォームのテンプレートから注入されるなら、アプリの挙動に時間を使うほうが有益です。
例
入力
DATABASE_URL=postgres://app@db:5432/app REDIS_URL=redis://cache:6379 REQUEST_TIMEOUT= RETRY=3 LOG_LEVEL=debug
得られるもの
まず `REQUEST_TIMEOUT` が空である点を報告します。多くのクライアントは解析に失敗するかタイムアウトなしとして扱うため、警告どころか、初日から障害になります。本番の `LOG_LEVEL=debug` は PII をログに残す可能性があり、非冪等な書き込み経路での `RETRY=3` は二重注文を増やすので、チェックリストは「起動失敗 > データ不正 > コスト／ノイズ」の順にし、各キーの目標環境での期待値を書きます。
よくある誤用
- デプロイ環境を伝えず「設定に問題がないか見てください」とだけ頼むことです。`redis://cache` が本番で名前解決できるかは分かりません。
- チェックリストを一度きりの作業にすることです。誰がどの工程で確認するかが決まっていなければ、チェックは実際には行われません。
こう変えると効く
- 「金融業務なので、既定値はすべて明示する前提で」と加えると、レビューは書式から故障モードへ移ります。
- 「各項目が誤っていたときのユーザーに見える症状」を求めると、致命的な項目と、直すのに苦労するだけの項目を分けられます。