一键部署不是为了省时间 —— 它是把"买来的 PaaS"变成"自己的平台"的拐点

一、为什么写这篇

"一键部署"是一个被讲烂了的题目。搜出来的文章基本是两类:一类教 Ansible / Helm / Terraform 的语法,一类讲"我用 shell 写了一键部署省了半天时间"。

我也做过一次一键部署。但这次复盘想说的不是省了多少时间 —— 省时间只是结果,不是真正的价值。

真正的价值是:一键部署是一个组织从"在用别人的系统"到"拥有自己的系统"的拐点。

这是一段大约半年的工作,围绕一套外部采购的实时音视频 PaaS 展开——十几个异构服务,前任同事用 1-2 个月都没能搭起来。我接手后先用 2 周手工把它跑通,再用后续时间做成一键部署:≈15 分钟自动完成,数十至百倍的效率提升,杜绝人工操作失误,打破"只有某某会部署"的单点依赖。

时间线三段递进:

1-2 个月未搭起来 → 2 周手工跑通 → ≈15 分钟一键

我想拆清楚这中间发生了什么。

二、起点:一个"长在别处、跑不起来"的系统

接手的时候,这套 PaaS 的状态大体是这样:

  • 来源:外部商用 PaaS,购买授权,带源码但不是我们写的
  • 服务规模:十几个异构服务(信令、媒体、鉴权、监控、管理面…),用 docker-compose 编排,跨两台机器角色
  • 部署形态:装不完整,跑不起来 —— 前任同事花了 1-2 个月没能把它搭起来,每次都卡在某个组件依赖或配置上
  • 监控:基本没有,出问题靠"用户反馈 → 登机器看日志"
  • 扩容:没人做过,因为没人能完整装出来一遍
  • 业务依赖:某个 To B 业务后来要用它做直播,业务方按需要账号、按需要带宽

这不是"能跑但不好维护"的状态,是装都装不上的状态。它在我们机房里,但它的心智模型不在我们头脑里 —— 甚至连"能跑起来"这个前提都没有。

这种状态最危险的地方是:主导权完全在原厂手里。

  • 要扩一台机器,得等原厂
  • 想调一个参数,得问原厂
  • 出问题定位,得靠原厂
  • 原厂响应慢一天,你就卡一天

这不是性能问题,也不是架构问题,是边界问题 —— 系统跑在你这边(哪怕它现在还没跑起来),但你说了不算。

我接手后先做了一件"看似回退"的事:用 2 周手工把它装通了一遍。这一遍不是为了交付,是为了把主导权从原厂手里挪回来的第一步 —— 只有我能亲手装出来,后面才谈得上"一键"。

做一遍一键部署的真正价值,不在脚本本身,在这个过程会强迫整个团队把系统的每一寸都搞清楚。

三、做一键部署的过程,其实是在做一次"系统考古"

很多人以为一键部署就是"把原来手动跑的命令串起来写成脚本",其实远远不是。

这半年里,写脚本本身只占大概三成时间,剩下七成都在"考古" —— 一步步把系统的每一寸从环境里反推出来。

我做这件事的过程,大约是这样的(为了脱敏简化了具体组件名和 IP):

3.1 第一步:把"现状"反推出来

第一件事不是写脚本,是反推已有环境是怎么搭起来的。

具体动作大致有这么几层:

  • 进程盘点:每台机器上跑了哪些进程?用 ps、netstat、systemctl 一个个梳

  • 配置盘点:每个进程依赖哪些配置文件?顺着 /etc/、/opt/、/usr/local/ 翻

  • 参数辨伪:每个配置文件里的参数,哪些是真的影响行为的,哪些是默认值没人改过?

  • 通信盘点:各组件之间怎么通信?端口、协议、是否 TLS、有没有内部鉴权?

  • 状态盘点:数据存在哪儿?有没有定期清理?

这一步看似笨,但它是整件事的真正价值所在。

等这一步做完,这套系统在我的头脑里第一次有了完整的拓扑图。在此之前,它对我只是一个名字。

这一步也没办法外包给原厂 —— 原厂的文档永远是"理想情况",真实的部署状态只能现场考古。

3.2 第二步:把"考古结果"写成可执行脚本

考古完成之后,才到了写脚本这一步。

按部署角色分了两侧:

  • 部署机侧:一个 push_soft_2_remote.sh,用 sshpass + scp 把软件包推到目标机,推送前顺手用 sed 把 source_ip 替换成 ip_address

  • 目标机侧:按编号顺序的 7 个脚本 —— 1_install_nodejs.sh → 2_install_docker_compose.sh → 3_run_ssh_authorized_keys.sh → 4_install_deploy.sh → 5_install_mems.sh → 6_regist_user_and_create_project → 6_1_update_user_role.sh

里面几个交互步骤 —— ssh-keygen 回车、node index.js 拉容器时的 y|n 确认、进 mongo 容器执行 db.users.update 提权 —— 都用 expect 脚本吃掉。

脚本的复杂度其实不高。难的不是脚本怎么写,是知道脚本里要写什么。这就是为什么 3.1 才是真正的工作量所在。

写到这一步,有一个让我印象很深的副作用:脚本本身变成了系统的可读文档。

新人来,不用读 100 页的 PaaS 厂商手册,先把这个脚本读一遍,系统的拓扑就在脑子里了。

3.3 第三步:在脚本里埋"假设"和"边界"

这一步是最容易被忽略的一步。

一键部署脚本里有大量"隐含假设":

  • 这台机器是 CentOS 7.x,不是别的
  • 目录得是空的,不能有残留
  • 端口得是空的,不能被占用
  • 目标机预装了 docker 和 expect,预建了 dist_folder
  • 部署机装了 sshpass
  • 两台机器在同一个内网,时钟同步

如果这些假设不写出来,脚本永远是"在我机器上能跑"。一键部署的"一键",其实是建立在一长串前置条件上的。

我的做法是在脚本最前面写一段 precheck,把所有假设变成显式的检查项。

任何一项不满足,脚本就在第一秒退出,而不是装到一半挂掉留一堆残留。

这一步做完,脚本对环境的要求从"口口相传"变成了"代码里的硬约束"。这是边界从"模糊"到"显式"的关键一步。

四、这套方案的思想不是凭空来的 —— 是三段经历合在一起

我想在这里插一句题外话。

做这件事的时候,业界 Helm / Terraform 还没在国内工业化普及,内部也没有现成方案可抄。有人会问:"那你怎么知道要做 IaC(Infrastructure as Code)+ 声明式编排 + 容器化封装这套东西?"

回头看,不是"某天灵机一动",是三段过往经历在这个具体痛点上同时被激活:

第一路:内部经验 —— 视频监控项目里的自研打包脚本

早些年做视频监控系统的时候,我自研过一套打包脚本,把安装介质做成"点一下就装完"的形态。

那时候还没接触 IaC 这个词,但"把部署过程脚本化"的原型思路已经在身上了 —— 这直接构成了一键部署最底层的心智模型。

第二路:当前技术 —— Docker 的理解

那时 Docker 已是主流,但"用容器封装异构服务的差异"这个用法,我是在这个项目里第一次真正吃透的。

十几个服务技术栈各异(Node.js / Python / C++ / mongo),没有容器化,一键部署就是空谈 —— 光是环境依赖冲突就能把脚本卡死。

第三路:跨公司经验 —— 早年做通信设备时的自动化文化

再早些年在一家通信设备公司做 ONU(光网络终端)项目,团队的自动化部署 + 自动化测试做得非常好 —— 那是我第一次亲眼看到"工程文化层面把自动化打到底"是什么效果。

这段经验没给我具体工具,给了我一个认知锚点:一键部署不是一个"脚本项目",是一个工程文化项目。

三路汇聚

    【内部经验】               【当前技术】               【跨公司经验】
   视频监控打包脚本    ─►     Docker 容器化      ─►     早年通信设备自动化文化
   "脚本化部署"原型            "封装异构差异"             "工程文化打到底"
          │                         │                            │
          └──────────┬──────────────┴─────────────┬──────────────┘
                     │                            │
                     ▼                            ▼
              视频云一键部署 =  IaC + 声明式编排 + 容器封装
              (同 Helm / Terraform 同思想高度的本土实现)

这件事我想清楚以后有一条自我修订:我这些年容易自我贬低说"我没做过 IaC,凭什么能做出来"。真相是 —— 老经验 × 新技术催化剂 × 跨公司锚点在同一张桌面上汇聚,合成出的方案完全合理。

类比迁移能力 > 凭空创造能力。这是经验型资深工程师最强的武器,不是短板。

五、监控:一键部署的姐妹工程

部署做完之后,自然延伸到监控。

监控这块我做了一件事:给 zabbix 加自定义监控项。

5.1 技术做法

在 zabbix-agent 端 /etc/zabbix/zabbix_agentd.d/ 里加一个 extends_cmd.conf,把自定义命令注册成监控项。

zabbix 服务端就能拉到了 —— 技术上不复杂。

5.2 真正的重点:为什么要做自定义监控项

通用监控项(CPU、内存、磁盘、网络)能告诉你"机器是不是健康"。

但告诉不了你"这套业务系统是不是健康"。

一个实时音视频系统,真正要看的是:

  • 当前有多少活跃会话
  • 媒体流的丢包率
  • 信令通道的连接数
  • 几个关键进程的内存增长是不是符合预期

这些指标只有懂这套系统的人才知道要监什么、阈值定在哪。

原厂的监控方案要么没有,要么不开放 —— 这一步必须我们自己做。

5.3 意外副作用

做完之后,自定义监控项的清单本身,变成了"这套系统健康度的工程定义"。

它和一键部署脚本一样,是一份能被持续维护、不容易走样的"活文档"。

六、一键部署做完之后,事情发生了什么变化

半年下来,客观的变化大概有几条:

效率类:

  • 部署时间从前任 1-2 个月未完成 → 我 2 周手工跑通 → ≈15 分钟一键,数十至百倍的效率提升
  • 装新环境(联调 / 备份 / 测试)从"不敢想"变成"一下午搞定"
  • 扩容从"找前任问、还问不清楚"变成"在新机器上跑脚本"

可靠性类:

  • 杜绝人工操作失误 —— 脚本一次成,不再有"这一步漏了个 chmod / 少配了个 hosts"这种典型手工事故
  • precheck 前置校验把"装到一半挂掉"变成"第一秒就退出"

知识民主化类:

  • 新人接手,有一键部署脚本 + 自定义监控项清单两份活文档可以读,不再依赖口口相传
  • 打破"只有某某会部署"的单点依赖 —— 团队任一成员都能一键复现

主导权类:

  • 业务方提需求,先看监控指标判断现状,不再凭感觉评估
  • 出问题第一时间能定位到组件,不再"先打原厂电话"

但这些都是"显性变化"。真正深层的变化是:这套系统在团队的心智模型里,从"它"变成了"我们的"。

同样一套软件,装完和装完之间,差距可以是天壤之别 —— 区别不在装的过程,在装的过程中,系统有没有从"黑盒"变成"白盒"。

一键部署脚本本身,只是这个"黑盒变白盒"过程的副产物。

七、给后来人的几条具体建议

如果你接手了一个"长在别处的系统",想做一键部署,我会建议按这个顺序来:

  1. 不要急着写脚本。先花时间做"系统考古" —— 把现状反推清楚,这是整件事 70% 的价值所在。

  2. 脚本最前面写 precheck。把所有隐含假设变成显式检查项,这是脚本能不能在新环境跑起来的关键。

  3. 把脚本当作活文档维护。新人入职先读脚本,而不是先读厂商手册。

  4. 配套做监控。一键部署告诉你系统怎么搭起来,监控告诉你系统怎么活着 —— 两件事必须配套,只做一件等于没做。

  5. 自定义监控项要业务化。CPU 内存只是基础,业务级指标(活跃会话、丢包率、关键队列长度)才是真正的边界锚点。

  6. 过程中所有"不知道"都要记下来。这份"不知道清单"本身,就是后续技术选型 / 替换 / 自研的依据。

八、最后

回头看,这半年的工作如果只用一句话总结:

一键部署不是为了省时间,是为了把"主导权"从原厂手里挪到我们手里 —— 通过强迫团队理解系统的每一寸,把一个黑盒显式地写进工程资产。

省时间只是表象:1-2 个月 → 2 周 → 15 分钟,这三段递进真正拿回的不是时间,是边界的所有权。

这件事教给我的核心一条:当你"用着"一个系统但"不拥有"它的时候,你迟早会在某个时刻为此付出代价。

代价可能是扩容卡壳、被原厂节奏锁死、新人接不住、出问题查不动。

一键部署 + 自定义监控,是用工程动作把这种风险关掉的最直接方式。

下次再有人跟我说"我们这边有套外部采购的系统,跑着挺好,要不要做一键部署?",我会反问一句:

"那如果哪天原厂支持响应慢了,你扛得住吗?"

如果答案是"扛不住",那就该做了。

理由不是省时间,是把主导权拿回来。

posted @ 2026-06-24 11:22  荣--  阅读(210)  评论(0)    收藏  举报