📚 课程目录第4章环境部署基础

4. 环境部署基础：开发环境、测试环境、预发布环境、生产环境的定义与用途、环境一致性挑战

在平台工程的交付流水线中，环境是承载软件制品运行的基础设施单元。每个环境对应软件开发生命周期中的一个特定阶段，拥有独立的配置、数据和访问策略。本章将系统定义四类核心环境，并剖析导致环境不一致的根本原因。

标准 CI/CD 流水线通常串联四个环境：开发 (Dev)、测试 (Test)、预发布 (Staging) 和 生产 (Production)。每个环境承担不同的质量门禁职责。

环境	核心用途	数据特征	访问权限	稳定性要求
开发环境	编码、本地调试、单元验证	模拟数据 / 脱敏子集	开发者个人	低，允许频繁重启
测试环境	集成测试、接口测试、自动化回归	结构化测试数据集	QA 团队 + CI 系统	中等，需保持可用
预发布环境	生产镜像验收、性能摸底、配置验证	脱敏全量 / 生产副本	运维 + 核心开发	高，接近生产
生产环境	对外提供服务、真实用户流量	真实用户数据	严格审批 + 自动化	最高，SLA 保障

平台工程建议： 在服务目录中为每个环境注册独立的 Environment 资源对象，包含集群、命名空间、变量组和数据库连接串等元数据，实现环境维度的声明式管理。

下图展示了制品（Artifact）在四个环境间的晋升路径。每个环境部署前必须通过上一阶段的质量门禁。

  关键原则： 制品在流水线中只构建一次（Build Once, Deploy Anywhere），环境差异仅通过外部配置注入，避免因重新编译引入二进制不一致。

环境不一致是导致“在我机器上能跑”问题的根源。平台工程需要系统性地识别并消除以下四类差异：

基础设施差异： 开发使用 Docker Compose，测试使用 Kubernetes 单节点，生产使用多可用区集群。操作系统内核版本、CNI 插件、存储类不同。
配置差异： 数据库连接串、缓存地址、第三方 API 端点、日志级别、JVM 参数等硬编码或手动修改导致环境间行为不同。
数据差异： 开发环境只有 100 条记录，测试环境有 10 万条脱敏数据，生产环境有 1 亿条真实数据。数据量级差异会暴露不同的性能瓶颈和 SQL 问题。
依赖差异： 中间件版本（Redis 6 vs Redis 7）、操作系统库（glibc 版本）、Sidecar 代理版本不一致，导致运行时行为偏差。

下表总结了四类差异在典型场景中的具体表现与影响等级：

差异类型	典型表现	影响等级	平台工程应对策略
基础设施	测试通过，生产部署失败（内核参数、网络策略）	严重	基础设施即代码 (IaC)，环境模板化
配置	预发布正常，生产出现鉴权失败	高	集中配置中心，环境变量注入
数据	分页查询在测试环境正常，生产超时	高	生产数据脱敏副本，数据量级压测
依赖	Redis 序列化兼容问题，仅在预发布暴露	中等	容器化 + 统一基础镜像

平台工程通过以下手段系统性解决环境一致性问题：

环境即代码： 将环境定义（集群、网络、中间件、变量）声明在 Git 仓库中，通过 GitOps 同步到所有环境。
不可变基础设施： 禁止手动登录服务器修改配置，环境重建基于镜像和 IaC 模板，确保每次部署从已知状态开始。
统一服务目录： 在服务目录中为每个环境注册标准化资源模板，开发、测试、预发布使用同一套 Terraform / Crossplane 定义。
环境一致性流水线门禁： 在 CI 阶段自动校验环境配置差异，例如使用 kustomize diff 或 helm diff 对比预发布与生产的配置差异。

常见陷阱： 不要试图让所有环境 100% 一致（成本过高且无必要）。平台工程的目标是 可控差异——明确哪些差异可接受（如数据量级），哪些差异必须消除（如中间件版本、内核参数）。

在服务目录中为每个环境部署设置以下检查项，作为流水线质量门禁：

通过将上述检查项自动化集成到 CI/CD 流水线，平台工程团队可以显著降低环境不一致导致的发布故障，提升交付信心。