运维思考：云原生时代下，自动化运维脚本真的没前途了吗？

无论 K8s 这些如何鼓吹，自动化运维脚本都无可避免。然而大家都不喜欢写他们：

• 职业上没有安全感：运维代表了薪水低，大家都不喜欢说自己是做运维的。后端程序员尤其不喜欢坠落到运维岗位。脚本代表了不正规，不是正儿八经的语言。这就体现为了“我要写 golang”，和 PHP 程序员喜欢转 golang 一样。

• 技术上不先进：脚本能有什么前途？未来不是属于 Kubernetes 的么？先进的技术应该解决什么样的问题？应该如何解决问题？

都是写业务的，谁也不要瞧不起谁

我在腾讯游戏做过两年运维开发，做过游戏大区的开区脚本，合并大区的脚本，故障之后自动申请机器替换修复的脚本等等。当时我就在想，这个算做游戏开发么。这个和写游戏后台的服务的区别是什么？

最近一年在写微信小程序。发现在微信生态下有很多业务代码是分不清楚是传统的后台开发，还是运维自动化的。比如说你要提供一个一键申请微信小程序的业务功能，这个里面就涉及到给微信第三方平台上传代码，提交审核，审核通过之后触发部署等工作。从业务上这是一个面向用户的功能按钮，但是性质上更接近于传统运维的自动化工作。

一般人们是以是否启动了新进程，部署了新代码，来区分这是一段后台代码，还是运维脚本。

另外一个说法是在网络路由领域，有 control plane v.s. data plane 的区分。似乎运维脚本更接近 control plane 的工作。data plane 的高并发显然更 hard-core 呀。

我觉得无论是让界面弄得更美观，还是处理数据库操作的幂等，还是部署新进程。这些工作都是一个系统的业务，不要瞧不起谁。都是用代码来操作计算机，都是编程。当年大家都还瞧不起切图仔呢，说不好熟悉哪个语言，哪套 API 就一定没前途，或者有前途。真正的工程师只应关注问题是不是业务上高优先级的，问题解决的方式是否恰当，是否高效。只有这样才不会被人以是否熟悉 java/golang 去评判自己值多少钱。

随意能部署一套是注定无法稳定的

部署的目的就是“复制一套环境”。这个包括了

• 我给客户1部署一套，给客户2部署一套
• 我在广州部署一套，在美国部署一套
• 我给开发环境部署一套，给生产环境部署一套

既要保证一致性，又要能兼容差异性的需求。当然主要的诉求，还是要保证像一个模子出来的。常见的技术包括：

• 运维脚本修改已有的软硬件配置

• 维护一套镜像的状态，例如状态数据库，CMDB 这些

• Infrastructure as Code，简称 IaC。主要是要用 git 仓库把散落的运维脚本管理起来

• Immutable server / infrastructure，通过缩短一个 state 的生命周期，来避免 state drift。主要体现为每次都申请一个新的虚拟机来部署

• 镜像状态 + IaC + Immutable：面向 YAML 开发，Kubernetes 这样的模型

我曾经尝试过很多种方案，目前我倾向于认为：无论用什么先进技术，都无法做到随意能部署一套新的环境。不要迷信 Kubernetes，也不要鄙视运维脚本。

• Immutable 是个假象：不是所有的 state 都可以很廉价地变成 immutable 的。比如数据库，比如 s3 的 bucket。我们都无法每次申请一个虚拟机那样，从零开始。绝大多数部署要用的 api，都是 mutable 风格的。Immutable 是建立在 mutable api 上的假象
• All abstraction leaks：所有的抽象在故障的时候都会泄露。YAML 再漂亮。当 YAML apply 的时候报错了，仍然是需要知道里面的每个 resource 代表了什么，实际是怎么被 apply 的。当引擎故障了，引擎盖子就要被掀开。
• 无数不稳定的依赖：你构建依赖了 npm，依赖了 Ubuntu 的 repository。完全 reproducible 是不现实的。今天能运行的脚本，不要指望明天一定能工作。谁也没法隔离所有的依赖变化。

• State + Version 的组合爆炸：如果我们不能完全杜绝 mutable state，也无法拒绝新的代码，新的版本。那就会有无数种组合的可能性。比如一个运行了一半的脚本，你 ctrl+c，然后再执行会怎么样？谁也无法保证一定没有问题。你今天是三个服务，明天变成了四个线上服务，这中间业务再变，部署也一定会跟着变

• 从一个 State 到另外一个 State 的变化过程：比如微信小程序从版本1，要升级到版本2。我们希望先发一个体验版，看看是不是ok。然后提交审核，审核通过之后，再正式升级到版本2。这个 state 的迁移如何用 immutable 的 declaration 来描述？不还是得用脚本的方式来写嘛。

以上种种原因，使得我们无法保证交付一份自动化的脚本，就可以保证每个猴子，都可以点一下就获得一个新环境。这个脚本一定要不断被维护，复杂环境的搭建总是需要有人来不断地维护。每个开发者，通过 docker 是可以构建一个局部的环境，但稍微大一点规模的环境，就不要指望能让任何一个猴子，今天可以复制一份，明天也一定能复制一份出来。

多租户才是终极解决办法

部署脚本自动化肯定是要的，要不然机器全被格式化了，就完全没法快速恢复了。去另外一个地域，开一套新的区服，没有自动化肯定也是不行的。

但是完全指望自动化脚本来复制大量的环境，也是非常脆弱的。每套部署出来的环境需要有人来维护，部署脚本也会报错，不能指望所有人都可以玩得转整套系统的部署。

比较好的平衡是由一个固定的人群来维护部署脚本，和维护部署出来的多套环境。然后再这几套环境上提供“多租户”的能力。新的客户来了，租用一套给他用。新的开发者来了要开发，也是在其上租用一个租户。

这样的多租户系统，更接近一个操作系统的定位。我们写脚本的，要会包装自己，你看我们是商业操作系统的研发人员。

来源：https://zhuanlan.zhihu.com/p/366859735

2022年10月，GOPS 全球运维大会 2022 · 上海站，字节、小红书、ebay、中通等互联网一线运维经验，扫码解锁更多精彩~

<<  滑动查看下一张图片  >>

近期好文：

“高效运维”公众号诚邀广大技术人员投稿

投稿邮箱：[e-mail]，或添加联系人微信：greatops1118。

点个“在看”，一年不宕机