私有化部署研发管理平台运维与升级实践：版本、备份与性能

私有化部署研发管理平台把系统和数据放进企业自己的机房，权限、合规与业务连续性都更可控，代价是运维责任一并转移到自己手里：服务器、数据库、附件存储、升级节奏，都要有人接住。

不少团队把精力集中在部署阶段，平台上线之后却把运维放到次要位置。真正的问题往往在两三年后才暴露：版本落后于安全修复，备份做了却从没验证过能否恢复，性能告警响了没人跟进。下面按版本、备份、性能三条主线，把可以照着做的运维与升级动作拆开讲。

私有化部署之后，运维责任落到谁身上

私有化部署与 SaaS 的差别首先体现在责任边界。SaaS 模式下，版本更新、安全补丁和可用性由厂商承担；平台进了自己的机房，私有化部署之后，这些工作全部回到企业侧。那些从 SaaS 转向私有化部署的团队，最先感受到的就是这一点。

运维不只是「系统别宕机」。对一套研发管理平台来说，需要持续盯住的是版本可控、数据可恢复、性能可预期。三者缺一个，平台在研发流程里的价值都会打折。

常见的做法偏差是把运维当成故障响应：出问题才动手，平时没有例行动作。更稳妥的方式是先把角色和变更窗口定下来——谁负责平台管理、谁负责备份、什么时间段执行变更。角色清楚之后，版本、备份、性能这三件事才有稳定的执行基础。

版本怎么管：从版本演进规律到升级节奏

禅道按产品线区分版本，开源版、企业版、旗舰版、IPD 版等分别迭代，官方持续发布新版本并附带升级日志。判断要不要升级，先读升级日志，再对照自己的使用场景。

有一个环境门槛需要提前知道：从 20.0 版本开始，禅道不再支持 PHP 5.x。如果平台是早期用一键安装包部署的，直接升到 20.0 之后可能跑不起来，需要先更新一键安装包所带的运行环境。

升级节奏可以按信号走，而不是追最新：

• 出现影响使用的安全修复时，优先安排；
• 遇到已知缺陷或阻塞性问题时，评估对应的修复版本；
• 需要新能力支撑业务时，再考虑整体升级。

需要谨慎的情况同样明确：对代码做过深度二次开发、写了自定义插件，或准备跨操作系统迁移时，升级前要单独评估兼容性，不能按标准流程直接覆盖。

升级怎么做：备份、预演、执行、验证、回退

官方对升级给出了三条前提：升级前详细阅读升级日志、先做好下载新版本的源码包?? ，避免备份或升级过程影响正常访问。

按部署方式，升级分为三类，操作要点并不相同：

• 源码包升级（通用）：下载新版本源码包（zip 格式），解压后覆盖到原程序目录，再访问 .../zentao/upgrade.php，按向导选择旧版本完成升级；
• 一键安装包升级：按对应平台的升级文档替换程序文件，再执行升级向导；
• Docker 镜像升级：拉取新版本镜像，停止并移除旧容器，用新镜像挂载同一持久化目录启动，浏览器按提示完成升级。

源码升级有两个容易踩的坑。要下载新版本的源码包，而不是一键安装包或 exe 程序，否则会覆盖原有数据；目录是覆盖，不是先移走旧程序再解压新版本，解压层级也不能多套一层。

正式执行前，值得在测试环境或快照上预演一遍。预演能提前暴露插件不兼容、自定义代码被覆盖、数据库升级脚本报错这类问题。

回退方案要在动手前就准备好：保留升级前的完整程序目录快照，外加一份可用的数据库备份，异常时按快照恢复。升级完成的验证信号是可观察的——能正常登录、需求与 Bug 列表能打开、附件能预览下载、定时任务能触发。

备份与恢复：备什么、多久备一次、怎么验证

对私有化部署研发管理平台来说，备份常被简化成「导一份数据库」，但官方的定义更完整：一套禅道的备份包含配置文件、修改过的代码、数据库和附件四部分，少任何一块，恢复到新环境都可能出问题。

下面按对象拆开，便于对照检查有没有漏备：

四部分里，附件和已改代码最容易被漏掉，却往往是恢复后才发现的问题所在。

以一键安装包部署的环境，最省事的做法是先停掉 Apache 和 MySQL 服务，再整目录备份 /opt/zbox（Windows 对应 xampp 目录），四部分一次覆盖。数据量不大时，也可以在后台「系统设置 → 备份」里手工触发；Docker 环境的数据量超过 10G 时，官方建议改用命令行备份脚本，把数据库与附件分别导出。后台「系统设置 → 定时」还能配置计划任务，自动执行数据与附件备份。

频率和保留策略按变更强度定：数据变动不频繁的团队，每周或每月一次全量即可；迭代密集的团队可以缩短周期，并把备份文件放到与生产机不同的位置，避免一次故障同时破坏原件和副本。

比备份更容易被忽略的是恢复验证。备份任务显示成功，不等于能恢复：文件可能已损坏，或缺少某一部分。定期在测试环境做一次恢复演练，确认能登录、能打开附件，才算真正验证过。还有一种情况需要留意——MySQL 服务停止时，数据库是无法备份的，备份脚本会因此缺失关键数据。

性能怎么盯：从可观测指标到调优动作

性能问题很少突然出现，多数是几个指标长期偏移后的结果。日常值得固定的基线包括：页面平均响应时间、慢请求占比、服务器磁盘占用、数据库体积，以及附件目录的增长速度。

常见瓶颈基本集中在三处。磁盘被附件占满会直接导致服务异常，而附件正是增长最快的一类数据。数据库表随业务累积变大后，搜索和列表查询会明显变慢。PHP 的内存上限、执行时间和上传大小不足时，大附件上传或复杂页面会直接报错。这些参数在 Docker 部署中可以通过环境变量调整，例如内存上限、最大执行时间和上传大小。

版本本身的性能改进也值得纳入升级决策。禅道 17.5 起把数据库引擎从 MyISAM 调整为 InnoDB，并优化了地盘与全局搜索的访问速度。长期停留在旧版本的平台，可能因此错过这类底层优化。

架构选择上，官方在 Docker 部署文档中提示：推荐使用外部数据库部署，内置数据库主要供测试使用。把数据库独立出来，既便于单独备份和调优，也降低了应用与数据同机故障的风险。监控告警建议先覆盖最关键的几项：服务是否存活、磁盘剩余空间、备份任务是否按时成功。

上线前的运维验收清单

把上面的动作收成一份清单，上线或每次变更后逐项确认：

• 版本：记录了当前版本号与最近一次升级时间，升级日志已读；
• 备份：数据库、附件、配置、已改代码四部分齐全，备份文件异地留存；
• 恢复：至少完成过一次恢复演练，确认能登录并打开附件；
• 回退：升级前保留了完整程序快照与数据库备份；
• 性能：磁盘、数据库、响应时间有基线，关键告警可触达负责人；
• 定时任务：备份、燃尽图、提醒等计划任务运行正常。

曾遇到报错或异常的环境，也可以先对照部署步骤与常见报错处理排查历史遗留问题。

私有化部署研发管理平台在数据可控和业务连续上的优势，最终取决于这些例行动作能否稳定执行。版本、备份、性能三件事本身都不复杂，难点在于把它们从「出事才做」变成固定节奏。稳定跑起来的平台，才算真正兑现了私有化部署的初衷。