私有化代码托管平台怎么运维？备份、扩容与升级
从资产盘点、备份恢复、容量扩容和版本升级四条线，拆解私有化代码托管平台的日常运维方法，给出备份对象表、扩容顺序、升级回退边界与季度演练节奏。
私有化代码托管平台上线后的第一年，故障往往不是功能不够用，而是备份从没恢复过、磁盘在周五写满、升级卡在数据库迁移。GitFox 这类把代码托管、流水线和制品库放在一套底座里的平台，运维对象更集中，但备份、扩容和升级也更不能靠临时救火。
这篇文章按资产、备份、扩容、升级四条线，给一套能落地的运维方法。先记住三个判断：备份是否有效，看恢复；扩容是否及时，看增长；升级是否安全，看退路。
私有化代码托管平台在运维什么？
很多团队把代码托管理解成一组 Git 仓库，备份时只打包仓库目录。真正要管的资产至少有四类：Git 对象、元数据、制品与缓存、配置与密钥。
Git 对象：提交、分支、标签、LFS 大文件，是代码资产的主体。
元数据：用户、权限、合并请求、评审记录、流水线定义、审计日志，通常落在数据库。
制品与缓存：构建产物、镜像、依赖包、构建缓存，决定历史版本能不能重新部署。
配置与密钥：服务配置、证书、Webhook 密钥、外部系统对接凭据。
四类资产的恢复要求不同：仓库要完整，元数据要一致，制品要可追溯，密钥要可用且不泄露。运维基线也应围绕它们建立，包括磁盘和数据库容量、clone/push 延迟、流水线排队时长、失败率、证书到期时间。DORA 的变更失败率和服务恢复时间，同样可以借来观察平台自身的稳定性。
GitFox 是禅道 DevOps 的内置核心组件，底层引擎自研，不依赖海外开源内核；禅道负责需求、任务与 Bug，GitFox 负责代码托管、流水线、制品与发布，边界清楚，出问题时更容易判断落在代码层、流水线层还是数据库层。对 50～300 人的研发中心，这种一体化底座能减少多套工具的对接；对大型组织和信创环境，则要把权限、审计和离线升级单独纳入运维范围。
备份做得对不对，看私有化代码托管平台能不能恢复
备份常被误解的地方，是把“任务成功”当成“数据可恢复”。Git 官方文档对 git bundle 的说明很直接：git bundle create backup.bundle --all 能覆盖所有 refs 可达的对象，但不包含索引、工作区、stash、仓库配置和 hooks。仓库备份不等于平台备份。
按资产分层做，恢复时才不会缺件：
资产 | 备份内容 | 建议方式 | 恢复验证 |
|---|---|---|---|
Git 仓库 | 对象、分支、标签 | 平台备份、 | 抽样 clone，跑 |
数据库 | 用户、权限、MR、流水线定义、审计 | 数据库原生备份或存储快照 | 恢复后检查登录、权限和关联关系 |
制品与缓存 | 构建产物、镜像、依赖包 | 对象存储快照、制品库导出 | 按版本拉取并核对校验和 |
配置与密钥 | 配置文件、证书、Webhook 密钥 | 加密备份，密钥单独托管 | 预发环境能正常加载 |
运行环境 | 容器镜像、部署清单、版本号 | 镜像仓库与 IaC 仓库 | 能重建一套同版本环境 |
策略按 RPO 定频率，不必所有资产一个节奏。仓库和数据库要求更短窗口，制品按保留策略做全量加增量；至少保留一份异地或离线副本，避免主机故障和勒索软件同时带走生产和备份。数据库和仓库尽量取同一时间点，否则恢复后可能出现“代码在、合并请求不在”的错位。给制品库设置保留期时，也要把追溯和合规要求一起考虑。
比备份频率更重要的是演练。每季度挑一个非核心项目，从备份恢复到隔离环境，记录实际耗时，检查提交数、标签、权限、流水线定义和制品是否完整。恢复失败的备份，等同于没有备份。
私有化代码托管平台的容量如何扩？
磁盘告警只是结果，增长来源通常在别处。先看四类数据：仓库对象和 LFS 的增长速度、制品库的版本堆积、流水线构建缓存、日志与审计表。只加磁盘而不处理增长源，几个月后还会回到同一个告警。
扩容顺序建议是先清理、再分离、最后加资源：
清理：执行仓库 GC，给制品库设置保留策略，日志轮转，清理过期构建缓存。清理前确认保留期和合规要求，不要删掉仍在追溯期内的制品。
分离：把流水线执行节点从核心服务拆开，把对象存储、数据库放到独立资源池。Runner 通常无状态，扩容和替换更灵活；代码托管和数据库有状态，不能按无状态服务的思路随便加节点。
扩容：云盘优先在线扩容，物理机则规划停机窗口和数据迁移。磁盘水位可设 70% 预警、80% 安排扩容、85% 限制大文件写入，具体比例按团队维护窗口调整。
存储迁移不要改完挂载点就结束。顺序是：挂新盘、同步数据、停写或切只读、增量同步、校验文件数和校验和、切换挂载、启动服务、抽样 clone 和 push。切换前保留旧盘只读，出问题能切回去。若平台支持多节点或对象存储，按官方拓扑实施；不支持时不要自行拼一套“高可用”，有状态服务的锁、会话和仓库一致性很容易出问题。
私有化代码托管平台的版本变更怎么排？
升级的风险不在安装包，而在数据库迁移和版本兼容。动手前先做四件事：读发布说明和升级路径，确认是否需要逐版本升级；核对操作系统、数据库、浏览器和客户端兼容性；在生产备份之外，再做一份可独立恢复的数据库快照；在预发环境用脱敏副本完整演练一次。
升级窗口要配合研发节奏。避开版本发布日和月末结算日，提前通知冻结推送和大批量合并，把升级、验证、回滚时间一起写进变更单。顺序通常是先边缘节点、再核心服务，先非核心团队、再全量；平台不支持灰度时，就缩短窗口、把验证项做细。
回滚边界必须提前说清楚：应用版本通常可以回退，数据库迁移往往不可逆。一旦新版本完成不可逆迁移，退回旧版本真正可靠的路径就是恢复备份，而恢复意味着丢失升级后的数据。不要把“能回滚”当成默认选项，备份可恢复才是底线。
升级后至少验证：SSH 和 HTTPS 克隆、push、合并请求、流水线触发、制品拉取、Webhook、权限继承、审计日志。观察一到两个工作日，重点看 clone/push 延迟、流水线成功率和数据库慢查询。功能正常但性能下降，也算升级未完成。
运维日历：备份、扩容、升级
备份、扩容、升级不是三个独立任务，最好放进同一张日历，按固定节奏检查：
周期 | 重点动作 | 产出 |
|---|---|---|
每日 | 磁盘与数据库水位、备份任务、证书、流水线队列 | 异常清单 |
每周 | 容量增长趋势、失败备份重跑、日志与审计表增长 | 容量趋势记录 |
每月 | 制品 GC、权限与密钥检查、抽样恢复 | 恢复报告 |
每季度 | 全量恢复演练、升级评估、容量预测 | 演练记录与升级计划 |
小团队不必一开始就做得很重。先把“备份可恢复、磁盘有水位线、升级有回退方案”这三件事固定下来，再逐步补监控和自动化。运维机制的价值，不是让故障永远不发生，而是故障发生时，团队知道先做什么、数据从哪里来、多久能恢复。
常见问题
私有化代码托管平台只备份 Git 仓库够吗？
不够。仓库只覆盖代码对象，用户权限、合并请求、流水线定义、制品和密钥分别在数据库、对象存储和配置里，缺一层都可能恢复不完整。
备份频率怎么定？
先定 RPO，再定频率。代码提交频繁的团队，仓库和数据库要更密；制品可以按版本保留策略做全量加增量。频率不是越高越好，要保证备份窗口不影响正常 push 和流水线。
磁盘快满了，能直接扩容吗？
云盘可以在线扩容，但要先确认文件系统和分区是否支持，以及扩容后是否要调整挂载。物理机通常需要停机迁移。无论哪种方式，先定位增长源，避免扩完继续被同一类数据填满。
升级失败能直接回滚吗？
应用层通常可以，数据库迁移不一定。升级前必须确认迁移是否可逆；不可逆时，回滚等于恢复备份，会丢失升级后的数据。把这一点写进变更评审，比事后争论更有用。
私有化代码托管平台的运维，说到底是把不确定性关进流程：备份要能恢复，扩容要跟得上增长，升级要留得住退路。GitFox 提供私有化安装与版本获取入口，团队可以先用非核心项目做一轮备份恢复和升级演练，再决定全量推进的节奏。
