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

2023-03-23 10:00:49

来自：知乎，作者：taowen
链接：https://zhuanlan.zhihu.com/p/366859735

无论 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 是可以构建一个局部的环境，但稍微大一点规模的环境，就不要指望能让任何一个猴子，今天可以复制一份，明天也一定能复制一份出来。