一、为什么写这篇

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

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

真正的价值是:一键部署是一个组织从"在用别人的系统"到"拥有自己的系统"的拐点。在它之前,系统对团队是黑盒;在它之后,系统的每一寸都被显式地写在了脚本和监控项里。

这是一段大约半年的工作,围绕一套外部采购的实时音视频 PaaS 展开。我接手时,它是一坨"装在那儿、能跑、出问题靠原厂"的东西;半年后,它是一套我们自己能装、能监、能扩、能给业务方按需开账号的平台。

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

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

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

• 来源:外部商用 PaaS,购买授权,带源码但不是我们写的
• 部署形态:几台机器,某个前任在某个时间装上去的,装的过程没人完整记得
• 监控:基本没有,出问题靠"用户反馈 → 登机器看日志"
• 扩容:没人做过,因为没人知道完整装一次需要哪些步骤
• 业务依赖:某个 To B 业务后来要用它做直播,业务方按需要账号、按需要带宽

这是一个非常典型的"用别人的系统"状态。它在我们机房里,但它的心智模型不在我们头脑里。

这种状态有一个很危险的特点 —— 平时看不出问题。系统在跑,业务在用,需求来了就找原厂提一下,日子一天天过。直到某天:

• 某天要扩一台机器,没人会装
• 某天某个组件挂了,不知道是哪个进程
• 某天业务方说"想多支持一种使用场景",改不动,因为不知道改了会不会引发别处的问题
• 某天原厂支持响应慢了,你发现你被锁死在他们的节奏上

这些都不是"性能问题"或"架构问题",这是边界问题 —— 系统跑在你这边,但主导权不在你这边。

一键部署,是把主导权从"原厂手里"挪到"我们手里"的第一个工程动作。不是因为它能省时间,而是因为做一遍一键部署的过程,会强迫整个团队把系统的每一寸都搞清楚。

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

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

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

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

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

• 在哪些机器上跑了哪些进程?用 ps、netstat、systemctl 一个个梳
• 每个进程依赖哪些配置文件?顺着 /etc/、/opt/、/usr/local/ 翻
• 每个配置文件里的参数,哪些是真的影响行为的,哪些是默认值没人改过?
• 各组件之间是怎么通信的?哪几个端口、走的什么协议、是不是 TLS、有没有内部鉴权?
• 数据存在哪儿?有没有定期清理?

这一步看似笨,但它是整件事的真正价值所在。等这一步做完,这套系统在我的头脑里第一次有了完整的拓扑图。在此之前,它对我只是一个名字。

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

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

考古完成之后,才到了写脚本这一步。这一步本身不复杂:

• 系统初始化(用户、目录、依赖包)
• 各组件按依赖顺序安装
• 配置文件按机器角色生成(模板 + 参数)
• 启动、健康检查、依赖联通性验证

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

写到这一步,有一个让我印象很深的副作用:脚本本身变成了系统的可读文档。新人来,不用读 100 页的 PaaS 厂商手册,先把这个脚本读一遍,系统的拓扑就在脑子里了。

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

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

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

• 这台机器是 CentOS 7.x,不是别的
• 这个目录得是空的,不能有残留
• 这个端口得是空的,不能被占用
• 这台机器和那台机器得在同一个内网,延迟低于多少
• 时钟得同步

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

我的做法是在脚本最前面写一段 precheck,把所有假设变成显式的检查项。任何一项不满足,脚本就在第一秒退出,而不是装到一半挂掉留一堆残留。

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

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

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

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

这件事的具体技术做法不复杂 —— 在 zabbix-agent 端 /etc/zabbix/zabbix_agentd.d/ 里加一个 extends_cmd.conf,把自定义命令注册成监控项,zabbix 服务端就能拉到了。

但为什么要做自定义监控项,才是这件事真正的重点。

通用监控项(CPU、内存、磁盘、网络)能告诉你"机器是不是健康",但告诉不了你"这套业务系统是不是健康"。一个实时音视频系统,真正要看的是:

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

这些指标只有懂这套系统的人才知道要监什么、阈值定在哪。原厂的监控方案要么没有、要么不开放,这一步必须我们自己做。

做完之后还有一个意外的副作用:自定义监控项的清单本身,变成了"这套系统健康度的工程定义"。它和一键部署脚本一样,是一份有歧义不容易、被维护得起的"活文档"。

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

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

• 扩容从"找前任问、还问不清楚"变成"在新机器上跑脚本"
• 装新环境(联调环境 / 备份环境)从"不敢想"变成"一下午搞定"
• 新人接手,有脚本和监控项清单两份活文档可以读,不再依赖口口相传
• 业务方提需求,先看监控指标判断现状,不再凭感觉评估
• 出问题第一时间能定位到组件,不再"先打原厂电话"

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

这件事我后来想了很久 —— 同样是装一套软件,装完和装完之间,差距可以是天壤之别。区别不在装的过程,在装的过程中,你有没有被强迫去理解它的每一寸。

一键部署的真正价值,是这个被强迫理解的过程。脚本本身只是这个过程的副产物。

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

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

1. 不要急着写脚本。先花时间做"系统考古" —— 把现状反推清楚,这是整件事 70% 的价值所在。
2. 脚本最前面写 precheck。把所有隐含假设变成显式检查项,这是脚本能不能在新环境跑起来的关键。
3. 把脚本当作活文档维护。新人入职先读脚本,而不是先读厂商手册。
4. 配套做监控。一键部署告诉你系统怎么搭起来,监控告诉你系统怎么活着 —— 这两件事必须配套,只做一件等于没做。
5. 自定义监控项要业务化。CPU 内存只是基础,业务级指标(活跃会话、丢包率、关键队列长度)才是真正决定你能不能掌握主导权的东西。
6. 过程中遇到的所有"不知道"都要记下来。这些"不知道"的清单,本身就是后续技术选型、是否要替换、要不要自研的依据。

七、最后

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

一键部署不是为了省时间,是为了把"主导权"从原厂手里挪到我们手里。

省时间只是表象。真正的拐点是 —— 一个原本黑盒的系统,在做完这件事之后,被显式地写进了团队的工程资产里。

这件事教给我的核心一条是:当你"用着"一个系统但"不拥有"它的时候,你迟早会在某个时刻为此付出代价。代价可能是扩容卡壳、可能是被原厂节奏锁死、可能是新人接不住、可能是出问题查不动。一键部署 + 自定义监控,是用工程动作把这种风险关掉的最直接方式。

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

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

如果答案是"扛不住",那就该做了。理由不是省时间,理由是把主导权拿回来。