4. 环境规划与拓扑验收

GitLab 不是单一进程，而是一组协同工作的组件集合。环境规划的本质，是把这些组件按“用途、风险、成本”分配到开发、测试、预生产、生产四类环境中，并让每类环境的拓扑、网络、存储、计算与高可用配置与其承载的职责匹配。验收时不能只看“服务起来了”，而要逐项核对拓扑是否落地、链路是否连通、容量是否达标、故障切换是否有效。

四类环境的职责与拓扑定位

开发环境面向日常提交与快速迭代，通常采用单节点 Omnibus 或 Docker 部署，组件合并在一台主机上，允许短暂中断，不要求高可用。测试环境用于功能验证与集成测试，可拆分为应用节点与数据库节点，但仍以低成本为主。预生产环境必须尽可能贴近生产拓扑，用于发布前验证、性能压测与升级演练，其组件角色、网络分区、存储类型应与生产一致或等比缩小。生产环境承载正式业务，要求组件分离、多副本、跨故障域部署，并具备明确的 RPO/RTO 指标。

一个可落地的拓扑分层如下：接入层负责负载均衡与 TLS 终止；应用层包含 GitLab Rails（Puma）、Sidekiq、Gitaly；数据层包含 PostgreSQL、Redis、对象存储；辅助层包含 Container Registry、GitLab Pages、Prometheus 监控。四类环境的差异主要体现在副本数、是否跨可用区、存储是否共享，而非组件种类本身。

网络验收：连通性、延迟与安全边界

网络验收要覆盖三条链路：客户端到负载均衡的入口链路、应用节点到数据节点的内部链路、以及跨可用区或跨机房的复制链路。入口链路需验证 HTTPS 证书链完整、HTTP 自动跳转、WebSocket 可用（用于实时日志与终端）。内部链路要确认 Puma 到 PostgreSQL 的 5432、到 Redis 的 6379、到 Gitaly 的 8075 均放通，且延迟在可接受范围。跨区链路要测量复制延迟，生产环境建议主从延迟持续低于 1 秒。

安全边界上，数据层不应暴露在公网，仅允许应用层网段访问；管理端口如 SSH、PostgreSQL 应通过跳板机或安全组限制来源。验收时可使用 nc -zv、curl -I、openssl s_client 逐项确认，并记录实际返回码与延迟数值。

存储与计算验收：容量、性能与余量

存储验收关注三类数据：Git 仓库数据（Gitaly）、数据库数据（PostgreSQL）、对象存储数据（附件、制品、镜像）。Gitaly 对随机 IOPS 敏感，建议使用 SSD，并预留至少 30% 容量余量。PostgreSQL 需要独立数据盘，避免与系统盘争抢 IO。对象存储要验证上传下载吞吐与跨区冗余策略。

计算验收关注 CPU、内存与并发。Puma 的 worker 数通常按 CPU 核数配置，Sidekiq 并发按队列压力调整。验收时应记录基线水位：例如生产环境 Puma 节点 CPU 峰值不超过 70%，内存使用不超过 80%，Sidekiq 队列积压不超过 5 分钟可消化量。这些数值应作为后续扩容的判断依据。

高可用验收：故障切换与数据一致性

高可用验收不能停留在“配置了主从”，而要实际触发切换。对 PostgreSQL，可模拟主库宕机，观察从库是否在设定时间内提升为主，并确认应用自动重连。对 Redis，验证 Sentinel 或 Cluster 的故障转移。对 Gitaly，验证副本节点在主机故障后仍可提供仓库读写。对负载均衡，验证后端节点摘除后流量是否自动转移。

验收记录应包含：切换触发方式、检测时间、切换完成时间、数据丢失量（RPO）、服务恢复时间（RTO）。生产环境一般要求 RPO 接近 0、RTO 在分钟级。若切换后出现数据不一致或应用未自动恢复，需回到拓扑设计阶段修正，而不是仅调整监控阈值。

验收清单示例

完成上述验收后，应形成一份环境验收记录，明确每个环境的拓扑图、组件清单、网络策略、存储配置、计算基线和高可用切换结果。这份记录既是交付依据，也是后续扩容、排障和升级的基线。只有四类环境的拓扑与配置都被逐项确认，GitLab 平台才算真正具备可交付、可运维的基础。