2. 传统部署模式痛点：停机发布、回滚困难、环境不一致、人工操作风险高

在引入平台工程与蓝绿发布门禁之前，绝大多数团队长期依赖“手动+脚本”的传统部署模式。该模式在业务规模小、迭代频率低时勉强可用，但当发布节奏加快、微服务数量增长后，其固有缺陷会迅速放大，成为研发效率与系统稳定性的核心瓶颈。以下从四个维度剖析传统部署的核心痛点。

2.1 四大核心痛点对比

2.2 痛点一：停机发布——业务连续性直接受损

传统部署模式下，最常见的操作流程是：停止旧服务 → 拉取新包 → 启动新服务。这个过程中，服务完全不可用。对于面向用户的在线业务，停机意味着：

• 用户请求超时或返回 5xx 错误；
• 正在进行的交易、会话、长连接被强制中断；
• 后台定时任务、消息堆积无法被消费。

即使通过“先停一台、再启一台”的滚动方式，在单机部署场景下，流量切换依然存在短暂空窗。更严重的是，如果新版本启动失败，服务恢复时间会进一步延长。

2.3 痛点二：回滚困难——故障恢复缺乏确定性

传统部署的回滚通常依赖以下方式之一：

• Git 回退 + 重新构建： 需要重新编译、打包、分发，耗时与正常发布相当；
• 备份包替换： 依赖运维手动保留上一版本的二进制包，但备份可能缺失或版本混乱；
• 数据库回档： 如果新版本包含数据库迁移，回滚需要逆向执行迁移脚本，极易出错。

这些方式均不具备原子性——回滚过程中服务依然处于不稳定状态，且回滚操作本身可能引入新的问题。

2.4 痛点三：环境不一致——测试失效的根源

环境不一致是传统部署模式中最隐蔽、最消耗研发精力的痛点。常见差异包括：

这种差异导致：测试环境通过的用例，在生产环境可能因内核参数、依赖版本、网络拓扑不同而失败。研发团队不得不花费大量时间“复现环境问题”，而非解决真正的业务缺陷。

2.5 痛点四：人工操作风险高——故障的直接诱因

传统部署依赖运维人员手动执行一系列命令，典型流程如下：

1. SSH 登录到目标服务器；
2. 执行 systemctl stop app 停止服务；
3. 备份当前版本包（手动拷贝到备份目录）；
4. 上传新版本包（scp / rsync）；
5. 修改配置文件（手动编辑或替换）；
6. 执行 systemctl start app 启动服务；
7. 检查日志确认启动成功；
8. 手动修改负载均衡或 DNS 切换流量。

每一步都存在人为失误的可能：

• 输错命令导致停止错误的服务；
• 忘记备份导致无法回滚；
• 配置文件漏改导致启动失败；
• 流量切换顺序错误导致部分用户持续访问旧版本。

2.6 传统部署模式流程示意图

下图展示了传统部署模式下一次典型发布的全流程，以及每个环节对应的风险点：

2.7 痛点总结：传统模式已无法满足现代交付要求

综合以上四个痛点，传统部署模式在以下关键指标上全面落后：

这些痛点并非孤立存在，而是相互关联、相互放大。停机发布导致回滚压力增大，环境不一致导致测试失效进而增加人工干预，人工操作又反过来引入新的停机风险。要打破这个恶性循环，必须从部署模式层面进行重构——这正是蓝绿发布与平台工程门禁要解决的核心问题。后续章节将逐一展开解决方案。