查看原文
其他

运维思考:云原生时代下,自动化运维脚本真的没前途了吗?

taowen 高效运维 2022-11-05

无论 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、中通等互联网一线运维经验,扫码解锁更多精彩~

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

近期好文:

运维必备!Linux 远程数据同步工具详解

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

投稿邮箱:jiachen@greatops.net,或添加联系人微信:greatops1118。
点个“在看”,一年不宕机

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存