标准三环境
| 环境 | 用途 | 数据 | 谁能改 |
|---|---|---|---|
| dev | 开发 / 调试 | 假数据或脱敏小集 | 任何工程师 |
| staging | 上线前演练 / QA | 准生产（脱敏后的 prod 拷贝） | 受控（CI/CD 自动） |
| prod | 真实用户 | 真数据 | 极少数人，或仅 CI |
部分公司还会加：
- preview / PR env：每个 PR 一个临时环境（Vercel / Render 自带）
- canary：小流量真实环境，验证新版本
- DR：灾备，平时不用
隔离的几个层次
环境之间应该隔离到什么程度？三档：
浅隔离 · 同账号不同命名
- 都在一个 AWS 账号 / 阿里云账号下
- 用 tag / 子网 / 命名前缀分
- 易出问题：误操作可能影响全部
中等隔离 · 同账号不同 VPC
- 各环境独立 VPC、独立网段
- 网络级别不通（除非显式打通）
- 用 IAM 限制人员权限
强隔离 · 完全独立账号
- prod 一个 AWS 账号、staging 一个、dev 一个
- 账单分开，权限分开，资源完全分开
- AWS Organizations / Control Tower / 阿里资源目录管理
生产推荐至少中等隔离；监管行业（金融、医疗）通常要强隔离。
一致性：三环境应该多像
理想：只有数据和容量不同，配置一致。
现实：
| 维度 | 应该一致 | 可以不一致 |
|---|---|---|
| 操作系统 / 运行时版本 | ✓ | |
| 应用配置文件 | ✓（差异由环境变量驱动） | |
| 服务部署方式 | ✓ | |
| 网络拓扑 | ✓ | |
| 资源规模（CPU/内存） | dev < staging < prod | |
| 数据量 | 各环境不同 | |
| 第三方服务的环境 | dev 用 sandbox，prod 用真账号 |
配置怎么管
环境差异不要 hardcode 在代码里。三层：
1. 默认值 写在代码里（dev 友好的最小默认）
2. 环境变量 .env / dotenv / SystemD Environment / K8s ConfigMap
3. Secret Vault / AWS Secrets Manager / K8s Secret（不要 .env）
12-Factor App 第 3 条：Config in environment。
数据流向：永远 prod → 下游
prod →（脱敏后）→ staging →（截取小集）→ dev
反方向是禁忌：dev 数据不能混进 prod，否则就是数据污染（GDPR / 个保法风险也来自这）。
脱敏方案：
- 替换姓名 / 手机号为伪造（faker 库）
- 删除支付字段 / 身份证号
- 时间字段保持相对关系
部署顺序
通用：
任何代码变更
↓
PR：自动跑 CI（build + test + lint）
↓
PR Review：人工
↓
merge 到 main：自动部署到 staging
↓
QA / 自动回归 / 业务验收
↓
打 release tag：触发部署到 prod（可能要审批）
这条流水线越自动，发布越敢。详细见 ops-corp/14–17（CI/CD 与发布）。
反模式
- "我们没 staging，直接 dev → prod"：小项目可以；团队项目早晚被坑
- "prod 数据直接 dump 到 dev"：合规炸弹
- "staging 和 prod 完全不同的配置"：staging 通过不代表 prod 通过
- "环境变量都 hardcode 在 docker-compose.yml"：换环境 = 改文件 = 出错
推荐阅读
- The Twelve-Factor App — 配置 / 环境平等的源头
- HashiCorp: Multi-environment Patterns — Terraform 视角的多环境模式
- Spotify: Test Data Management — 数据脱敏与生产数据下游使用
- AWS: Account Strategy — 多账号策略白皮书
至此完成"序章 + IaC"基础（01–07）。 下一批进入容器化与编排：Docker 生产级实践 → K8s 核心概念 → Helm。