1. 为什么“每人一份 .env”会失控？
典型痛点：本地能跑、测试环境另一套、生产再一套；密钥复制粘贴进聊天；谁改了超时参数无人知晓；事故后无法回答当时线上配置是什么。 十二要素应用强调配置与代码分离，但分离不等于“散落各处”——需要单一事实来源（SSOT）与可追溯变更。
图 1：配置治理不是“换个工具名”，而是建立事实来源与证据链。
2. 三类资产：config、secret、feature flag
| 类型 | 特征 | 常见落地 |
|---|---|---|
| Config（非密） | 可进库评审、可 diff | YAML/Helm values、ConfigMap |
| Secret | 高敏、需最小暴露面与轮转 | Vault、SealedSecrets、云 SM + ESO |
| Feature flag | 高频业务开关、与发布解耦 | LaunchDarkly、Unleash、自研 + 审计 |
把业务开关写进普通环境变量，短期省事，长期会出现谁也不敢删的僵尸开关；独立的功能开关体系提供受众、百分比、审计与下线能力。
3. 版本化与回滚：让“回到上一版”是常规操作
非敏感配置走 Git：PR → merge → 自动同步（GitOps 控制器或 CD 流水线）。回滚即 revert commit 或指向上一 tag。 机密通常有版本号或 generation，回滚要同时考虑应用与密钥版本是否兼容。任何变更应留下工单号 / 变更原因，便于事后复盘。
# Example: committed template only — real secrets injected at deploy
# .env.example (safe to commit)
LOG_LEVEL=info
HTTP_TIMEOUT_MS=3000
DATABASE_URL=postgres://user:PASSWORD@host:5432/dbname
底线：含真实口令的 .env 不应进 Git；用 .env.example + 文档说明注入方式。历史若已泄露，先轮转密钥再谈流程。
4. Kubernetes：ConfigMap 与 Secret 的工程实践
ConfigMap 适合非机密键值；Secret 仍会以 base64 存储在 etcd——需静态加密（KMS）、RBAC、限制 etcd 访问。 External Secrets Operator 把云厂商或 Vault 中的秘密同步为 K8s Secret，减少人手 kubectl create secret。 大配置考虑分片与热更新策略：有的应用支持 reload，有的需要滚动重启——要在 SLO 与变更频率间权衡。
图 2：秘密停留在可信控制面；集群内只保留必要的投影与生命周期。
5. 审计与合规：配置也是变更记录
审计要回答：谁在何时把哪个键改成了什么（至少对敏感与关键参数）。 Git 历史、云审计日志、Vault audit device、K8s audit webhook 可以组合。对监管行业，还要保留保留期与不可抵赖策略。
图 3：回滚不是魔法——密钥与应用版本要一起设计。
图 4：三类资产混在一个 .env 里最省键盘，最贵事故。
6. 本章清单
- 盘点所有配置入口：仓库、K8s、云控制台、个人 .env，制定迁移优先级。
- 拆分 config / secret / feature flag，分别选存储与审批流程。
- 为非敏感配置启用 GitOps 或等效的 PR 评审与自动同步。
- 接入密钥管理与轮转节奏；演练一次“误配后的回滚”。
- 预告下一章：渐进交付——用指标驱动发布与自动回滚。