没有使用IaC的DevOps系统都是耍流氓( 二 ) _生活百科

当维护自动化脚本的方式无法适应快速变化的市场需要的时候，如何让开发和运维团队解偶就变成了解决这个问题的核心。在上图左侧的工作模式中，问题的核心是开发和运维团队之间基于“请求-响应”的工作模式，这种工作模式让开发和运维团队相互依赖，无法独立的按照自己的节奏工作。为了解决这个问题，IaC借用了大规模软件架构设计中的分层原则，让那些需要被共享的能力变成通用组件，并在开发和运维之间共享这些组件，从而让本来互相依赖的两个团队变成依赖另外一个第三方组件。如下图：

文章插图
为了能够通过第三方组件协同工作，IaC方式需要遵循几项关键原则

声明式（Declarative）：为能够让所有编排能力独立于开发和运维团队，任何一个团队都不应该将能力的具体操作保留在自己的团队中，采用声明式配置可以确保这一点，因为配置中只有声明没有具体逻辑，就意味着原来的依赖双方都必须将公用能力贡献出去，否则上图中的C就无法生效。
【没有使用IaC的DevOps系统都是耍流氓】幂等性（Idempotence）：进一步来说，声明式配置必须能够在任何时候确保环境编排的结果，也意味着通用组件C中对于环境的操作必须能够在任何状态下执行并且获得一致的最终结果。换句话说，无论目标环境处于初始状态，中间状态，最终状态还是错误的状态，当加载声明式配置以后，都会变成我们需要的理想状态（Desired State）。

IaC的落地方法从本质上来说，IaC是一种做事情的方法，实现IaC的方法和工具只要遵循以上原则，都可以帮助团队落地这种方法。在实际工作过程中，我们需要一些基本条件才能够实现IaC：
文化支撑落地IaC将改变团队（特别是开发和运维团队）的工作模式和协作方式，双方的工作边界和职责都会发生变化。传统模式下，开发和运维团队通过流程进行协作，双方在需要对方配合的时候发起一个流程（发出请求），等待对方按照要求完成操作（给出响应）之后继续这个流程直到目标达成。而IaC则要求双方通过共享能力进行协作，双方需要持续发现协作中阻碍对方独立工作的问题点，一起将解决这些问题的能力贡献给另外一个双方共享的组件（一般是一个工具），在日常工作中不再依赖流程驱动对方，而是使用这个共享的组件（工具）完成工作。IaC的工作模式要求两个团队都接受不确定性思维方式，出现问题的时候要共同解决问题而不是界定和追究责任。如果团队中的文化不允许这种不确定思维方式的存在，IaC将无法落地。
共享工具具备以上文化支撑的团队，需要共同构建一个双方都认可的工具，将双方都需要的环境编排能力全部封装到这个工具中。这个工具的核心目标有两个：

解偶：让双方在日常工作中不再依赖对方，可以按照自己的节奏和工作模式自由的使用，同时确保双方关注的标准，规则和策略都可以被正常落实并可以被监督。
可定制可演进：这个工具存在的目的就是为了能够适应不停变化市场需要，一个静态的工具是无法做到这一点的，只有那些具备了高度可定制性和扩展性的工具才有可能具备这样的能力。因此在设计和实现这个工具过程中做到功能粒度的控制就变得至关重要，如果所有的功能都按照日常业务流程设计，不考虑通用性，最终的结果就是任何的工作流程变更都会造成工具的变更，这样的工具也就失去了通用组件的存在价值。

IaC无处不在实际上，云原生，微服务，容器化和DevOps都是在从各个不同的层面践行IaC 。云原生强调利用云的基本特性赋能团队，其实就是利用上述云计算的底层技术为团队提供实现IaC的基础条件。微服务则是通过组件化的思维让多个团队可以独立自主的工作，不再受到其他团队的影响从而最大化团队工作效率。容器是在云计算技术的基础上，为操作系统以及其上层的环境堆栈提供IaC能力，包括Docker和Kubernetes为代表的主要容器工具都是基于声明式配置和幂等性原则设计的。