无论 K8s 这些如何鼓吹，自动化运维脚本都无可避免。然而大家都不喜欢写他们：
- 职业上没有安全感：运维代表了薪水低，大家都不喜欢说自己是做运维的。后端程序员尤其不喜欢坠落到运维岗位。脚本代表了不正规，不是正儿八经的语言。这就体现为了“我要写 golang”，和 PHP 程序员喜欢转 golang 一样。
- 技术上不先进：脚本能有什么前途？未来不是属于 Kubernetes 的么？先进的技术应该解决什么样的问题？应该如何解决问题？
我在腾讯游戏做过两年运维开发，做过游戏大区的开区脚本，合并大区的脚本，故障之后自动申请机器替换修复的脚本等等。当时我就在想，这个算做游戏开发么。这个和写游戏后台的服务的区别是什么？
最近一年在写微信小程序。发现在微信生态下有很多业务代码是分不清楚是传统的后台开发，还是运维自动化的。比如说你要提供一个一键申请微信小程序的业务功能，这个里面就涉及到给微信第三方平台上传代码，提交审核，审核通过之后触发部署等工作。从业务上这是一个面向用户的功能按钮，但是性质上更接近于传统运维的自动化工作。
一般人们是以是否启动了新进程，部署了新代码，来区分这是一段后台代码，还是运维脚本。
另外一个说法是在网络路由领域，有 control plane v.s. data plane 的区分。似乎运维脚本更接近 control plane 的工作。data plane 的高并发显然更 hard-core 呀。
我觉得无论是让界面弄得更美观，还是处理数据库操作的幂等，还是部署新进程。这些工作都是一个系统的业务，不要瞧不起谁。都是用代码来操作计算机，都是编程。当年大家都还瞧不起切图仔呢，说不好熟悉哪个语言，哪套 API 就一定没前途，或者有前途。真正的工程师只应关注问题是不是业务上高优先级的，问题解决的方式是否恰当，是否高效。只有这样才不会被人以是否熟悉 java/golang 去评判自己值多少钱。
随意能部署一套是注定无法稳定的
部署的目的就是“复制一套环境”。这个包括了
- 我给客户1部署一套，给客户2部署一套
- 我在广州部署一套，在美国部署一套
- 我给开发环境部署一套，给生产环境部署一套
既要保证一致性，又要能兼容差异性的需求。当然主要的诉求，还是要保证像一个模子出来的。常见的技术包括：