DevOps 所需的行为

观看完本文后，你将能够区分传统运维和 DevOps，描述开发人员和运维人员对彼此的看法，并列出 DevOps 所需的行为。
DevOps 与传统企业的思维方式截然不同。企业围绕端到端的流程构建，在这些流程中，“新事物” 被视为复杂、高风险、成本高昂且耗时的。他们将任何新事物都当作一个一次性项目，要在固定的时间框架内、按固定预算完成，然后让人员投入到下一个项目中。而 DevOps 试图颠覆这种模式，将大型项目分解，持续交付一系列更易于管理的小变更。较小的变更可以在较低风险下完成，因此 DevOps 降低了大型项目的风险。问题在于，小变更无法承受企业给所有事务增加的传统管理成本。像变更评审委员会这样的流程在 DevOps 中就行不通，因为它们无法以小变更所需的速度推进。
我们看到传统运维和 DevOps 之间存在工作文化冲突。在传统运维中，我们对关键基础设施进行手动配置变更。在 DevOps 中，我们实现了对所有环境的自动化部署。这就是传统运维需要变更评审委员会的原因。所有操作都是手动完成的，而人是会犯错的，即使变更获得批准，也不能保证其会被正确实施。
在传统运维中，应用架构由网络设计决定。在 DevOps 中则恰恰相反，网络设计由应用架构决定。我们有软件定义网络，可以根据架构需求进行调整。
在传统运维中，定制化的基础设施构建一次后便会一直维护下去。在 DevOps 中，会为新的部署创建临时性基础设施。我们不会维护基础设施，而是将其拆除并完全替换。除非一切都实现自动化，否则无法做到这一点，手动操作的管理成本会使效率大幅降低。
在传统运维中，风险是通过变更窗口来管理的。变更只在特定的、预先指定为变更窗口的时间段内进行，也就是说，在这些窗口之外不能进行任何变更。在 DevOps 中，风险是通过渐进式激活来管理的。我们可以在任何时候对系统进行变更。我们使用部署技术根据需要激活或停用变更。最后，传统运维的流程倾向于 “构建一次”。传统运维手动构建所有内容并一直维护，至少维护到不再需要为止，这通常是数年时间。有时他们构建一次后，却无法再次以相同方式构建，因为构建过程没有记录下来。在 DevOps 中，流程经过重新设计，以实现大量、快速的变更处理，使构建具有可重复性，并利用基础设施即代码的理念，确保我们所做的任何操作都能再次构建。
当文化发生冲突时，这是一个两败俱伤的局面。开发工作的衡量标准是开发人员能产生多少创新成果。他们通过开发和部署新的增强功能来跟上用户不断变化的需求。运维则追求稳定性。他们要确保用户能够使用这些服务和应用程序，并保证用户的数据和信息安全。这两个目标相互对立，鱼和熊掌不可兼得！安德鲁・克莱・谢弗（Andrew Clay Shafer）将开发和运维之间的这种情况称为 “困惑之墙”。我们需要做的是打破这堵墙。第一步是改变开发和运维人员对彼此的看法。
那么，运维人员对开发人员的看法是什么呢？嗯…… 运维人员认为开发人员就像是在隔墙乱扔 “死猫”（意为随意交付质量不佳的成果）。开发人员手动实施变更，缺乏回滚计划，也没有进行充分测试。他们的开发环境与生产环境差异很大。而开发人员觉得运维人员会在变更窗口的深夜进行非成即败的变更操作。运维人员离代码最远，所以他们不理解代码。运维人员只是从操作手册或 Word 文档中复制粘贴内容。
部门壁垒会滋生冷漠情绪。让人们在两个目标截然相反的部门各自为政是行不通的。必须让这些人走到一起，为他们设定一套能为客户增加价值的衡量标准。如果网站运行正常，开发人员会受到赞扬；如果网站宕机，运维人员则会受到指责。我之前提到过这是两败俱伤的局面吧？这可不是一个健康的工作环境。
以下是一些 DevOps 所需的行为。DevOps 颠覆了很多传统做法。你需要打破组织壁垒以及由此产生的工作交接问题，转向一种共享所有权和高度协作的文化。船上没有 “你的一边” 这种说法，每个人都必须意识到大家是为了共同目标而同舟共济。
你必须从害怕变更转变为通过接受变更来管理风险，管理小的变更。大的变更总是会让所有人感到害怕，那就把变更变小并加以管理。
从构建一次性、手工打造、独一无二（就像雪花一样，每一个都不一样，再也找不到完全相同的）的服务器，转变为使用基础设施即代码技术部署的临时性基础设施，使其具有可重复性。每次构建 Docker 容器或虚拟机时，都要构建得完全一样。如果代码没有改变，构建结果也会完全相同。
从手动执行（工单队列、人工手动操作）转变为实现自动化自助服务。我见过有些公司采用了云服务，却在前面设置了工单队列，导致只有 IT 人员能从云端进行资源调配，这就完全违背了自助式云服务的初衷。自助服务才是快速行动的方式。
最后，你必须从依赖警报、回拨和问题升级，转变为建立数据驱动的快速反馈循环。确保你能获取生产环境中出现问题的信息，并在需要时做出反应。
为了全面转型为 DevOps 组织，这些行为必须做出改变。在本文中，你了解到企业认为变更是复杂且耗时的，而 DevOps 将大型项目分解为一系列易于管理的小变更。传统运维构建一次后持续维护，DevOps 则为每次新部署创建临时性基础设施。开发追求创新，运维追求稳定。DevOps 所需的行为包括共享所有权、协作、接受变更和数据驱动的响应。