devops开发模式

末蓝、 2022-10-01 00:35 182阅读 0赞

在本文中我们将会讨论一些人们对DevOps的误解，同时会介绍一个能够带来DevOps文化转变的流程。

在一篇题为“不，你并不是一个DevOps工程师”的博文中，Cloud Technology Partners公司的副总裁兼首席架构师Mike Kavis谈论了一些与DevOps相关的错误想法。例如，他提到一些团队是如何误用术语DevOps的：

> 企业正在为DevOps苦恼。他们都想得到DevOps，即使很多企业并不知道它到底是什么。在很多情况下，我会看到那些自称DevOps的基础设施团队在领导一个基层倡议。当我问他们开发团队在哪里的时候，他们通常会说“我们并没有邀请他们”，甚至更糟“我们并没有同他们交流”。

一些工程师将自己宣传为DevOps，但是他们并不是，因为根据Kavis所说“DevOps并不是一个人，一个角色或者一个头衔。即使你可以声称自己是一个DevOps工程师，但是这仅是你自己的看法，实际上你并不是。”如果DevOps不是一个角色，一个资格，一个头衔 ，那么它到底是什么呢？Kavis的定义是：

> DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。

然后他详细描述说：

> DevOps是软件开发生命周期（SDLC）从瀑布式到敏捷再到精益的发展。DevOps超越了敏捷，它的关注点是从SDLC中移除浪费。通常情况下，发现浪费或者瓶颈的形式包括：不一致的环境，人工的构建和部署流程，差的质量和测试实践，IT部门之间缺少沟通和理解，频繁的中断和失败的协定以及那些需要珍贵的资源、花费重要的时间和金钱才能保持系统运行的全套问题。
> 
> 我看到的另一个重复模式是：一个“DevOps”团队的第一步通常是决定他们是否应该使用Chef或者Puppet（或者是Salt、Ansible等其他任何热门的东西）。他们甚至还没有定义自己打算解决的问题，即使他们手头的工具可以解决它们。这些团队通常会紧张地构建数千行脚本，但是这就产生了一个问题：“我们的职责是编写Chef脚本还是通过质量更好、更稳定的产品更快地进入市场？”。在大多数情况下，这些团队会将自己逼入绝境，大量的专有脚本实际上是增加了系统的浪费，而隐藏在DevOps运动之后的驱动力是从系统中移除浪费，这些团队并没有做到这一点。

如果说DevOps是一种打算让开发某个产品的多个团队之间能够更好的交流和协作的文化变革，那么下一个问题就是我们该如何实现DevOps，我们如何将这种文化引入到自己的公司中？

DTO Solutions的共同创建者Damon Edwards在2013年的DevOps Days Mountain View上做了题为“如何发起一个DevOps变革”的主题演讲，他推荐通过一个三步走的过程将DevOps文化引入到某个组织中：

## 1.弄清楚“为什么？” ##

根据Edwards所说，首先非常清楚组织成员为什么会聚到一起，知道他们试图实现什么，清楚他们的目的是什么是非常重要的。为了找到这些问题的答案我们应该直接与组织中的这些人交流，询问他们为什么会出现在这里。组织的主要目标是我们实现DevOps文化的唯一原因，除此之外没有其他原因。

Edwards认为DevOps仅仅是达到目标的一种手段，但是它自己本身并没有结束：“DevOps并不是你的为什么，不是你合作伙伴的为什么，当然也不是你业务的为什么”。他甚至建议忘记DevOps团队，而是使用服务交付作为替代，因为“我们的职责是创造服务”。

## 2. 实现组织合作 ##

按照Edwards介绍的过程，接下来需要做的是使整个组织合作，让所有人基于一组共享的条件和规则向一个共同的目标努力。当你能够把同一个目标指定给多个人的时候，一个组织就实现了正确的合作，他们会选择同样的方式去实现各自的目标；他们对于同一个问题有同样的答案。这可能是“组织合作的终极梦想”。

为了完成这种合作，组织内部必须要有人描绘一个DevOps愿景。这并不能通过教学过程实现，因为人们只会尝试着机械性地遵循这些步骤。我们需要的是教会大家一种思维方式。根据Edwards所说，这可以通过遵循下面的几个步骤实现：

1.  教导基本的概念，例如“单件流、批量工作、限制在制品的数量、拉式vs推式、持续交付”以及可以使用的工具等组织将会共享的一些通用词汇的概念。
2.  让所有人目标一致，通过：   
    a. 价值流程图——一个精益概念，它详细描述了一个组织内部发生的信息流和制品流，引导价值创造。   
    b. 时间线分析——试图发现时间花费在哪里，瓶颈在哪里。   
    c. 浪费分析——确定一个组织所产生的各种各样的浪费以便于尽可能地消除浪费。
3.  发展度量链，它的意思是对价值交付链中的各个活动进行度量，发现各个活动相互之间的影响。
4.  针对基线识别项目/ 实验。识别哪些项目或者活动偏离了基线，并且采取纠正措施。
5.  重复第2至4步。这一步构成了持续改进流程。

为了实现这些想法，Edwards建议了一个3天的计划：

*  第1天—— 教导原则，提出一个方案进行研究，模式和反模式
 *  第2天——分析组织当前的状态，提供问题识别技术和改进指标
 *  第3天——讨论解决方案和工具链自动化原则，构建一个路线图

## 3.持续改进循环 ##

这些循环的目的是通过制定计划、实现计划、测量输出和决定如何持续地改进流程。

在最近举行的QCon London 2014上Edwards做了题为“Dev ‘Programming’ Ops For DevOps Success”的分享，其中就讲到了这些原则，稍后这个分享将会发布到InfoQ上。