为什么写这篇一键部署是一个被讲烂了的题目。搜出来的文章基本是两类:一类教 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、内存、磁盘、网络)能告诉你机器是不是健康,但告诉不了你这套业务系统是不是健康。一个实时音视频系统,真正要看的是:当前有多少活跃会话媒体流的丢包率信令通道的连接数某几个关键进程的内存增长是不是符合预期这些指标只有懂这套系统的人才知道要监什么、阈值定在哪。原厂的监控方案要么没有、要么不开放,这一步必须我们自己做。做完之后还有一个意外的副作用:自定义监控项的清单本身,变成了这套系统健康度的工程定义。它和一键部署脚本一样,是一份有歧义不容易、被维护得起的活文档。五、一键部署做完之后,事情发生了什么变化半年下来,客观的变化大概有几条:扩容从找前任问、还问不清楚变成在新机器上跑脚本装新环境(联调环境 / 备份环境)从不敢想变成一下午搞定新人接手,有脚本和监控项清单两份活文档可以读,不再依赖口口相传业务方提需求,先看监控指标判断现状,不再凭感觉评估出问题第一时间能定位到组件,不再先打原厂电话但这些都是显性变化。真正深层的变化是:这套系统在团队心智模型里,从它变成了我们的。这件事我后来想了很久 ——同样是装一套软件,装完和装完之间,差距可以是天壤之别。区别不在装的过程,在装的过程中,你有没有被强迫去理解它的每一寸。一键部署的真正价值,是这个被强迫理解的过程。脚本本身只是这个过程的副产物。六、给后来人的几条具体建议如果你接手了一个长在别处的系统,想做一键部署,我会建议你按这个顺序来:不要急着写脚本。先花时间做系统考古 —— 把现状反推清楚,这是整件事 70% 的价值所在。脚本最前面写 precheck。把所有隐含假设变成显式检查项,这是脚本能不能在新环境跑起来的关键。把脚本当作活文档维护。新人入职先读脚本,而不是先读厂商手册。配套做监控。一键部署告诉你系统怎么搭起来,监控告诉你系统怎么活着 —— 这两件事必须配套,只做一件等于没做。自定义监控项要业务化。CPU 内存只是基础,业务级指标(活跃会话、丢包率、关键队列长度)才是真正决定你能不能掌握主导权的东西。过程中遇到的所有不知道都要记下来。这些不知道的清单,本身就是后续技术选型、是否要替换、要不要自研的依据。七、最后回头看,这半年的工作如果只用一句话总结,大概是这样:一键部署不是为了省时间,是为了把主导权从原厂手里挪到我们手里。