云原生时代下,自动化运维脚本真的没前途了吗?
无论 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
相关文章
- 【自动化测试】如何在jenkins中搭建allure
- Web端自动化测试失败的原因
- 接口自动化你不懂?听HttpRunner的作者怎么说
- 干货|app自动化之如何参数化用例
- 年薪30w大佬聊自动化测试框架
- 3种python自动化测试框架推荐,看看哪个适合你?
- 测开大佬的10条建议,让你在自动化界立住脚跟
- 微店MySQL自动化运维体系的构建之路
- Python自动化运维--系统基础信息模块
- pug 自动化运维平台
- Bigops 自动化运维平台
- 自动化运维
- 《PowerShell V3——SQL Server 2012数据库自动化运维权威指南》——1.2 在你开始之前:使用SQL Server和PowerShell工作
- 《PowerShell V3——SQL Server 2012数据库自动化运维权威指南》——1.5 安装SMO
- 《PowerShell V3——SQL Server 2012数据库自动化运维权威指南》——2.13 创建视图
- 《PowerShell V3——SQL Server 2012数据库自动化运维权威指南》——2.17 执行查询语句/SQL脚本
- 《PowerShell V3——SQL Server 2012数据库自动化运维权威指南》——2.21 使用bcp实施批量导入
- 《高性能Linux服务器构建实战:系统安全、故障排查、自动化运维与集群架构》——1.5 Linux后门入侵检测工具
- 《高性能Linux服务器构建实战:系统安全、故障排查、自动化运维与集群架构》——2.4 网络探测和安全审核工具nmap
- 《Python自动化运维:技术与最佳实践》一第1章 系统基础信息模块详解
- 《Python自动化运维:技术与最佳实践》一1.1 系统性能信息模块psutil
- 《Python自动化运维:技术与最佳实践》一3.3 生成动态路由轨迹图
- 《Oracle高性能自动化运维》一一
- 《Puppet权威指南》——第1章 运维工程师的利器——自动化运维工具
- 自动化测试析疑——WebDriver启动时白屏挂起问题解决方法
- 有赞MySQL自动化运维之路—ZanDB
- 如何写更好的自动化测试用例
- GUI功能测试自动化模式