1. 环境首先是“治理对象”，其次才是资源
同一套 Helm chart 可以部署到任意名字空间；差别在于谁有权改、数据是否真实、故障影响谁、是否受变更窗口约束。 平台团队应把环境定义成策略包：身份、网络、密钥、配额、观测、回滚期望——而不是只给一张 IP 表。
图 1：越靠右，越像真实世界——权限与流程要同步“升压”。
2. 多租户与权限边界：不止 namespace
在 Kubernetes 上，“租户”可能对应业务线、客户、或团队。边界手段分层：云账号/订阅（最强隔离）、VPC/VNet、 集群/控制面、namespace + ResourceQuota、NetworkPolicy、Admission 策略。 小团队可以共享集群 + 多 namespace；金融或多租户 SaaS 往往要硬隔离。关键是把身份（谁）映射到可操作的资源集合（什么），并定期做权限评审。
图 2：隔离是成本曲线；用风险驱动选层级，而不是用口号。
3. 发布与审批：把“谁能推 prod”变成可审计规则
典型控制包括：双人审批、变更窗口（避开业务高峰）、冻结期（大促/财报季）、紧急通道（break-glass）事后补单与复盘。 与工具无关的原则是：默认路径慢而安全，例外路径快但有记录。CI/CD 平台上的 environment protection、GitHub/GitLab 审批、ServiceNow 变更单，都是实现载体。
反模式：人人能直接 kubectl apply prod；或审批流程存在但永远点同意——两者都会让合规与真实风险脱节。
4. 非生产数据：别用真库当玩具
staging 若灌入全量生产数据，一旦发生泄露，风险接近生产。常见做法：合成数据、抽样 + 脱敏、仅元数据、或只读副本 + 严格访问控制。 数据治理团队应参与环境设计，而不是事后补锅。
图 3：发布不是“最后一步点一下”，而是证据链上的多个关卡。
5. 环境对照表（便于团队对齐语言）
| 维度 | dev | staging | production |
|---|---|---|---|
| 主要目的 | 功能迭代与联调 | 集成验证与预演 | 对外服务与收入 |
| 数据 | 合成/假数据为主 | 脱敏或子集 | 真实数据，强合规 |
| 变更节奏 | 高频率 | 中频率，贴近发布节奏 | 受控，必要时冻结 |
| 权限 | 较宽（仍要审计） | 角色分离 | 最小权限 + 审批 |
图 4：环境策略要可审计——口头约定在事故调查里站不住。
6. 本章清单
- 画一张当前 dev/stg/prod 的拓扑 + 数据 + 权限三列表，找出缺口。
- 为 prod 定义发布审批与变更窗口；为紧急发布写 break-glass 流程（含事后复盘模板）。
- 评估多租户隔离层级：namespace 是否足够，还是必须账户级隔离。
- 与数据团队协作，明确 staging 使用的数据策略与脱敏标准。
- 预告下一章：配置管理——把 .env 从“个人咒语”变成平台能力。