当研发团队规模扩大、代码仓库增多，公共代码托管平台的网络体验、权限边界、审计要求和持续集成成本，往往会成为交付效率的瓶颈。把 GitLab 部署在自主管理的香港服务器上，可以让代码、合并请求、流水线、制品和账号策略处于统一控制之下，也便于为中国内地、香港及亚太成员提供相对集中的访问入口。
但“能打开 GitLab”与“可以稳定支撑生产研发”是两件事。真正可靠的私有化平台需要把主服务、数据库、仓库存储、对象存储、容器镜像、Runner、备份与监控作为一个整体规划。本文不绑定某个具体版本，而是从长期运维角度，给出一套适合中小型团队逐步落地的架构方法。
先判断团队是否真的适合私有化部署
私有化适合需要代码与制品自主保存、内网系统集成、定制权限、固定访问入口或专用构建资源的团队。如果仓库很少、没有专职运维、对数据位置没有特别要求，成熟的托管服务通常更省心。自建平台的成本不只是服务器月租，还包括升级、备份、安全、监控和故障处理时间。
评估时应记录活跃用户数、仓库数量与增长速度、每天流水线次数、单次构建时长、制品保留周期、容器镜像容量和可接受的中断时间。不要只按当前人数选配置，因为 CI 作业、镜像层和历史制品的增长速度，往往比代码本身更快。
把平台拆成五个资源层理解
一个可运维的 GitLab 平台至少包含五层：Web 与 API 入口、代码仓库与数据库、缓存和队列、制品与镜像存储、执行 CI 作业的 Runner。小团队初期可以把主服务放在一台服务器，但 Runner 最好从一开始就独立，因为构建任务会突然占满 CPU、内存、磁盘 I/O 或网络。
随着负载增加，可先把对象存储、容器镜像和备份迁出主机，再扩展 Runner 池；只有当可用性目标明确、单机维护窗口无法接受时，才考虑数据库、仓库存储和应用节点的多机高可用。分层扩展比一开始复制复杂架构更容易定位问题，也能减少闲置成本。
主服务器配置要按活跃负载估算
GitLab 主服务同时运行 Web 请求、后台任务、数据库和仓库操作，对内存和磁盘延迟较敏感。小型团队也不宜把内存压到刚好能启动的水平，应为代码索引、合并请求、备份和升级预留空间。CPU 需要关注稳定性能，而不是只看短时突发规格。
容量规划可从峰值并发用户、推拉仓库次数、后台任务队列和数据库大小入手。上线后用监控数据校准：若 Web 延迟正常但后台任务持续排队，应检查任务处理能力；若克隆和提交明显变慢，则重点观察仓库存储与网络；若升级或备份期间出现抖动，说明资源余量不足，而不一定是日常配置完全错误。
存储设计决定长期体验
代码仓库包含大量小文件、对象与元数据操作，稳定的 SSD 或 NVMe 通常比单纯的大容量磁盘更重要。主数据盘应保留足够空间用于仓库增长、数据库维护、临时文件和升级。磁盘使用率长期接近上限时，一次大仓库导入或备份就可能造成服务异常。
制品、作业日志、上传附件、LFS 文件和容器镜像应设置独立保留策略。它们不是同一种数据：代码历史需要长期保存，临时测试制品可能只需保留数天。若团队构建量较大，可把这些对象迁移到兼容对象存储的服务，降低主机磁盘压力，并让容量扩展更平滑。
域名、TLS 与通知邮件要在上线前完成
正式使用前应准备稳定域名和受信任的 TLS 证书，强制使用 HTTPS，并确认 SSH 克隆地址与外部访问地址一致。反向代理、负载均衡或防火墙后的真实来源地址也要正确传递，否则审计日志、访问限制和故障排查会受到影响。
通知邮件常被忽略，但它关系到邀请、密码重置、合并请求提醒和流水线告警。应使用经过验证的发信服务，配置正确的发件域名与认证，并测试邮件失败时的重试与告警。管理员账号若无法收到重置邮件，故障期间可能进一步扩大恢复难度。
账号与权限从最小授权开始
不要让所有成员都拥有创建公开项目、注册任意 Runner 或修改关键设置的权限。根据部门和产品划分群组，项目权限按职责授予，离职或转岗流程要同步回收账号、个人访问凭据、部署密钥和群组继承权限。管理员账号数量应尽量少，并启用多因素认证。
机器人账号与个人账号要分开。自动部署、镜像拉取和外部系统集成使用独立服务账号，限制可访问项目和凭据有效期。定期审查长期未使用的账号、令牌和 SSH 密钥，把权限盘点纳入季度运维，而不是只在安全事件后临时检查。
Runner 必须与主服务隔离
CI 作业执行的是仓库中的脚本，本质上属于可变且可能不可信的计算负载。把 Runner 直接安装在 GitLab 主服务上，会让一次失控编译、磁盘写满或恶意脚本影响代码平台本身。更稳妥的方式是使用独立服务器或独立虚拟机运行 Runner，并通过标签控制哪些项目可以使用。
生产部署 Runner、测试 Runner 和通用构建 Runner也应区分。涉及生产凭据的 Runner只允许受保护分支和授权项目调用，避免与外部贡献或实验项目共享。每类 Runner设置并发上限、作业超时和磁盘清理规则，防止大量任务同时启动造成资源争抢。
Shell、Docker 与 Kubernetes 执行器怎么选
Shell 执行器结构简单、性能开销小，但作业之间隔离弱，依赖和残留文件容易相互影响，适合严格受控的内部项目。Docker 执行器通过镜像提供较一致的构建环境，便于复现和清理，是多数团队的通用选择，但要限制特权模式和宿主机挂载。
Kubernetes 执行器适合任务波动大、已经具备集群运维能力的团队，可按作业创建临时 Pod 并弹性扩缩。它并不会自动降低复杂度：镜像拉取、网络策略、缓存、存储和集群容量仍需规划。选择执行器应以隔离需求、团队能力和作业类型为准，不必为了“云原生”而增加额外系统。
流水线要短、可复现并能快速失败
一条实用流水线通常按代码检查、单元测试、构建、安全扫描、集成测试和部署逐步推进。耗时短、反馈快的任务放在前面，让语法错误和基础测试失败尽早终止；昂贵的镜像构建或端到端测试只在前置检查通过后运行。
构建环境、依赖版本和命令应写进仓库，由版本控制管理，避免依赖 Runner 上人工安装的未知状态。重复逻辑可以抽成模板，但模板也要评审和版本化。流水线失败信息应指出具体阶段与产物，不能只留下一条模糊的退出码，让开发人员反复登录服务器猜测原因。
缓存与制品必须设定边界
缓存用于加速可重新生成的依赖，制品则是某个作业需要交给后续阶段或供下载的结果，两者不应混用。缓存键要包含分支、锁文件或运行环境等必要维度，避免不同项目或版本相互污染；缓存失效后流水线仍应能够完整执行。
制品保留时间应按用途分级：临时测试报告、候选安装包和正式发布物拥有不同生命周期。若没有自动清理，磁盘会被历史作业悄悄占满。建议每月检查增长最快的项目、失败作业残留和长期未引用的制品，并把清理结果纳入容量趋势监控。
容器镜像仓库需要独立治理
使用内置或关联的容器镜像仓库可以把代码与构建产物串联起来，但镜像层增长很快。禁止只使用模糊的 latest 标签，应同时保留提交标识或版本号，保证部署可以追溯。基础镜像由受控流程更新，并对已知漏洞进行扫描。
镜像清理策略要避免删除仍在生产使用的版本。可以保留最近若干个构建、正式发布标签和回滚所需镜像，再清理无标签或过期分支产物。镜像仓库若迁移到对象存储，还要验证访问权限、跨域设置、生命周期规则以及备份边界。
密钥不能写进仓库或镜像
数据库密码、云平台凭据、部署私钥和 API 密钥应存入受保护的 CI 变量或专用密钥管理系统，并限制在哪些分支、环境和 Runner 上可用。变量设为隐藏并不代表绝对安全，作业脚本仍可能把它输出到日志或打包进制品，因此还需代码评审和日志检查。
生产凭据应短期化、可轮换并遵循最小权限。部署任务最好使用面向单一环境的账号，而不是共享管理员密钥。发生泄露时要能迅速定位凭据使用范围、停止相关流水线、轮换密钥并检查历史日志与制品，而不是只删除仓库中的一行配置。
网络设计要兼顾访问和构建流量
研发成员访问、Git 拉取、依赖下载、镜像推送和生产部署具有不同流量特征。香港服务器作为统一入口时，应分别观察到内地办公网络、海外开发者、软件源和目标环境的延迟与丢包。只测试网页首页速度，无法代表大仓库克隆或大镜像上传体验。
主服务、Runner、对象存储和部署目标之间优先使用稳定内网、受控专线或加密连接。管理入口不直接向整个公网开放，可通过 VPN、堡垒机和来源限制访问。若团队分布在香港、美国、新加坡等地区，可按构建依赖和部署目标设置区域 Runner，但仍要统一权限与制品校验，避免形成无人维护的孤立节点。
安全加固要覆盖平台与流水线
基础措施包括及时更新、关闭无用端口、限制管理来源、启用多因素认证、记录管理员操作、定期扫描依赖与镜像。反向代理、防火墙和主机系统的日志要统一留存，并为连续登录失败、权限变更、新增管理员和异常大量克隆设置告警。
流水线安全同样重要。限制外部项目触发高权限 Runner，谨慎使用特权容器和宿主机套接字，不把宿主目录随意挂载进作业。合并请求涉及流水线模板、部署脚本或依赖源变更时，应由具备相应权限的人员复核，防止代码评审绕过基础设施风险。
备份必须覆盖数据、配置与密钥
GitLab 备份不能只复制仓库目录，还要覆盖数据库、仓库、上传附件、LFS、制品、包、容器镜像或外部对象存储中的相关数据。服务器配置、TLS 证书、加密所需的密钥和 Runner 配置通常需要单独保护；缺少关键密钥时，即使数据文件完整，也可能无法正确恢复。
采用多层备份：本机短期副本用于快速恢复，独立存储保存周期备份，异地副本应与主机故障域隔离。备份文件加密并限制访问。至少按季度在隔离环境执行完整恢复，验证账号、仓库、合并请求、流水线配置、制品和镜像，而不是只确认压缩包生成成功。
高可用应从恢复目标反推
小型团队通常先把单机恢复能力做好：准备自动化安装配置、频繁备份、备用服务器规格和明确的恢复手册。如果可接受一段维护窗口，这往往比维护复杂集群更可靠。只有当业务无法接受单机维护或恢复时间，才逐步拆分数据库、缓存、仓库存储和应用节点。
高可用架构还需要负载均衡、会话处理、共享或复制存储、数据库故障切换与仲裁，并保证升级路径受支持。节点数量增加并不自动等于可用性提高；如果监控、隔离和演练跟不上，复杂度反而会制造更多故障点。
监控要同时观察用户体验与后台队列
除 CPU、内存、磁盘空间、磁盘延迟和网络外，还应监控 Web 请求延迟、错误率、数据库连接、后台任务队列、仓库操作耗时、Runner 在线状态、作业等待时间和对象存储错误。对研发团队而言，“流水线排队二十分钟”可能比网页短暂变慢更影响交付。
告警应明确责任和处理动作。磁盘增长异常、备份连续失败、Runner 全部离线、TLS 证书临近过期、邮件发送失败和后台任务大量堆积，都需要不同级别的响应。监控系统与告警渠道不要只依赖被监控的同一台主机，否则服务器故障时恰好无法通知。
升级前先做兼容检查与回退准备
GitLab 组件多、数据结构复杂，跨版本升级不能直接跳到目标版本。应查阅对应版本的官方升级路径、停机要求和已知问题，在测试环境使用生产备份的脱敏副本演练。升级前确认备份可恢复、磁盘空间充足，并暂停可能改变大量数据的自动任务。
先升级低风险环境，再安排生产维护窗口。完成后检查登录、克隆与推送、合并请求、Runner 作业、镜像仓库、邮件和备份，而不只是看到首页正常。保留升级记录、配置差异和回退条件，发生问题时根据既定标准处理，避免在压力下临时决定。
香港服务器与 Runner 配置怎么选
主服务配置重点是稳定内存、低延迟存储和持续网络质量；Runner 则按作业类型配置。编译型任务更依赖 CPU，前端构建和并行测试常需要较多内存，容器镜像任务要关注磁盘空间与 I/O。与其购买一台超大服务器混合运行，不如让主服务保持稳定，再按队列压力增加 Runner。
向服务商咨询时，应确认底层资源是否独享、磁盘类型、内网能力、可用带宽、备份出口、故障更换与技术响应。葵芳电讯可根据团队成员和部署目标所在地区，协助评估香港服务器、独立资源以及香港、美国、新加坡等节点之间的连接方案；实际配置仍应以仓库规模和流水线压测结果为准。
按阶段上线，先把可恢复性做好
第一阶段完成域名、TLS、账号权限、主服务和独立 Runner；第二阶段建立制品清理、对象存储、监控与完整备份；第三阶段进行恢复演练、凭据轮换和安全审查；第四阶段再根据排队时间增加 Runner，或根据 RTO 拆分关键组件。
上线清单应包含责任人、配置版本、数据位置、备份位置、密钥保管、升级记录和应急联系方式。每次重大变更后重新测试克隆、构建、部署和恢复。GitLab 私有化的价值不只是“代码放在自己的服务器”，而是把研发交付链路做成可控制、可审计、可恢复并能持续优化的工程系统。