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

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

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

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

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

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

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

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

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

• 镜像状态 + IaC + Immutable： 面向 YAML 开发，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 是可以构建一个局部的环境，但稍微大一点规模的环境，就不要指望能让任何一个猴子，今天可以复制一份，明天也一定能复制一份出来。

多租户才是终极解决办法