企业技术负责人必须知道的DevOps10个小技巧

Posted 2020-08-16 天府云创

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了企业技术负责人必须知道的DevOps10个小技巧相关的知识，希望对你有一定的参考价值。

DevOps成为越来越多的大型公司和组织的关键，所以参考一些公司成功实施DevOps的一些做法对我们很重要。

很明显，只要正确运用，DevOps会是非常有效的工具。今年6月份，一份Puppet问卷显示，使用DevOps方法的IT部门成功部署软件的次数平均是不使用的200倍。同时，他们的恢复次数比没使用DevOps的同行多了24次，而且修改配置的失败率降到原来的三分之一。

因为这些成功，DevOps变得格外流行，一份2012年以来的真实报告显示DevOps职位比例从不到1%增加到30%。

下面列举技术负责人必须知道的DevOps领域的10个技巧：

企业策略不能干扰开发团队和IT团队间的协作，这一点非常重要。要给予开发部门自由和资源，来加快DevOps的成功应用。这就需要敏捷方法来缩短软件发布周期以及降低部署时机器宕机时间。但是，这需要管理部门支持IT文化变化，减少开发部门与IT部门间的障碍。
不要忽略你为什么正在做这些。通常人们会迷失，只是一味确保正确地执行了任务，却不考虑为什么这么做，甚至不会从整个组织的角度思考。相反，我们要不断地解决瓶颈，通过改进瓶颈，帮助整个组织快速高效运转。
DevOps技术自动化了许多工作，这却不意味着工作减少了。DevOps改变了开发团队和部署团队的工作方式，但是这两个部门不会相互排除。
不断反馈是评估高效率和DevOps成功的关键因素。开发、设计、产品管理等都需要反馈。重要的是不要线性地看待交付过程，你必须不断地从错误中学习，不断成长。
不能低估团队合作与相互尊重。所有的员工应平等对待，为了目标一起工作。管理者要确保没有特权团队为了发布某个版本而打断整体的DevOps流程。使用聊天室，让每个人都能够讨论当前发生的事情会很有帮助。
开发周期中尽早解决安全问题。DevOps前没有考虑安全因素是非常危险的。安全性需要增加到产品特性中，它不是一个可以推迟解决的小事。
考虑第三方供应商，也许您的组织需要他们的服务。为了团队成长，你需要与这些供应商建立良好的关系，来促进彼此的信任、得到良好的反馈。
借助DevOps，仍然需要权限控制，并且开发者不能有生产服务器的root权限。他们也需要类似的机制管理生产和非生产服务器，降低潜在问题的概率。
考虑到DevOps团队每周至少需要25小时监管云环境，因为这会占用其它工作的时间。
信息和进度透明。状态更新与失败通知保证组织内部信息一致，有助于提高生产率和速度。

DevOps在不断发展，它已经向企业和组织证明了自己的价值。每一位技术负责人应该参考这10个技巧并应用到自己的公司中。DevOps并不是那些实现一次就不需要过问的事情，它需要你不断投入与改进。为了加快产品研发速度、提高团队效率，你有无数的事情要做。但参考这十个技巧将是朝着正确方向迈出的巨大一步。

-----------------------------------------------------------------------------------------

大家好，首先感谢社群提供这样一个分享机会，与大家共同进步学习。今天我带来的主题是《从持续部署到统一部署：系统设计思路及要点》，重点探讨DevOps以及统一部署，内容将涉及到：

分析流行运维工具如Ansible
探讨常见的运维系统的架构与实现
DevOps元数据的概念
从开发到上线的软件开发周期的各环节探索DevOps平台的产生
如何构建适合自己的DevOps工具与平台

1统一部署和DevOps各系统的关系

在开始统一部署前，我想先说一下简单的说一下DevOps，并解释一下我对DevOps的看法，以及统一部署和DevOps各系统的关系。

当我们提及DevOps的时候，其实可能在说几个方面：流程和管理，运维和自动化，架构和服务，以及文化和组织。从DevOps的发展历史看，这些提法都有一定的道理。比如，DevOps最初是由敏捷组织开始提出的：

由于敏捷在一开始处理软件开发时，其关注点放在过程和交付上。而互联网的兴起，很多的软件开发是内部运营的。因此，在DevOps提出时，希望为这类软件开发提效，而来自敏捷的DevOps此时强调的是围绕软件开发的不同团队——开发，测试和运维——的协作和沟通。因此，前几年，谈及DevOps时，一定会给出下面的混乱之墙以及团队之间沟通协作的DevOps定义。

我们可以说，DevOps诞生之初其实期望通过沟通和协作加速软件整体的研发速度。然而，当软件的开发从交付转换到部署和运维时，仅仅是过程上的梳理，或者是沟通和协作，其加速的效果是有限的。因为，部署和运维是一个非常技术化的领域。

正因为如此，最近一两年谈及DevOps时，大家更多的关注部署和运维自动化的部分，或者如何构建自动化的持续部署系统。那么，是否我们构建起一个自动化的持续部署系统就做到了DevOps呢？或者我们就接近DevOps了呢？我认为，还差的很远。

2软件开发到底做什么？

在给出我对DevOps的看法之前，我想先让大家思考一个问题：软件开发到底在做什么？

传统的认识上，软件开发作为软件生命周期重要的一部分，其是以产品和项目的交付为目标的。也就是说，软件开发团队，在生产出符合需求的软件制品后，其责任即告完成。

然而，当部署和运行成为新软件生命周期的重要组成部分后，制品的完成并非目的，我们的目的是让满足需求的系统上线并运行起来。因此，我们可以说，在部署和运行的情景下，软件开发不再是交付软件产品，软件开发交付的应该是运行的系统。

请注意，是运行的系统，而不是敏捷所强调的可工作（workable）的软件。

3从软件开发周期的各环节探索DevOps平台的产生

但这是不是DevOps的最终的追求呢？或者说，当我们认为软件的开发是以交付运行的系统为目的时，我们认为的DevOps应该是怎样的呢？

首先，DevOps必须建立高效的开发+运维的完整闭环，请注意高效。

在多角色参与开发+运维的情况下，如何做到真正的高效。在组织结构上，消除不必要的角色，或者说，将相关责任归口到单一团队才是最高效的——无需沟通就比沟通要高效。那么，DevOps下，软件的开发和运维应该由单一团队负责，这个团队就是开发人团队。因此，DevOps应该重塑组织的结构而非通过协作缓和问题。这就是谁构建，谁运维。

部署应该直接产生运行的系统，而不是在运行的系统中装入可工作的软件产品。因此，仅仅是简单的持续部署是不够的，要建立以配置为中心的统一部署，这种部署还应该将所有与研发相关的软件部署行为纳入到管理之中。

最终在系统层面构建出相互支撑的整个系统生态。这个生态中最重要的3部分就是：产生运行系统的统一部署系统，能够实施全链路的资源与业务监控的统一监控系统，以及以报障和轮值为核心的轮值系统。通过这些系统，开发团队可以完成产品系统的生产、监控和运维。

那么统一部署系统中需要哪些支持系统呢？系统间是如何协作呢？关键何在？稍稍探究一下开发。

在开发中会涉及多种数据，这些数据有：业务和功能的描述，用于支持系统开发的，用于支持系统的运行，等等。但我们简化一下，有两类数据是我们特别关心的：描述系统组成的，以及实际组成系统的。

DevOps元数据

我们将描述系统的数据称为元数据。这些元数据在知识层面，组成了一个描述性的逻辑系统，这个逻辑系统在物理世界中，有相对应的实际系统。其实，DevOps的这种元数据并非新鲜的东西，自打有软件开发的那一天开始，这些信息其实一直都是存在的。只不过，过去由于系统能力所限，从逻辑系统到物理系统的转换全部需要人工的干预或完成，而今天，技术已经达到由逻辑系统自动化生成实际物理系统。

要高效的产出系统，其重点在于对系统的抽象描述能力，以及对这些信息的快速处理，而不是直接的操作。

那么，DevOps的部署系统应该做到可配置、可重建、可追溯，并且要自动化、可视化，自服务。这其中：

可配置是指，系统在逻辑层面上配置描述，实际生成根据描述自动化产生。
可重建是指，知道系统的任何时间（或版本的配置），可以重新从代码构建出整个系统
可追溯是指，任何部署可以回溯到构建信息、代码修改信息、评审信息等等

而自动化、可视化，和自服务都是对系统的要求，系统必须简单，能够让开发人员独自完成所有工作。

至此，已经描述了我对DevOps的看法，以及该DevOps下统一部署所应具备的特质。接下来，让我们看看从简单的持续部署，如何一步一步走向我们期望的。

4从简单的持续部署到统一部署

今天，当我们搭建一个简单的持续部署，其实并不困难。比如，最常见的持续部署是在持续集成的基础上实现的。

一个应用会有多个版本，通过应用的部署，在目标机上安装所需版本的应用——应用实例。部署完成后，进行必要的环境操作，完成应用的启动。把这些的概念抽象出来：

如果使用了Capistrano或Deployer这样的部署工具，它们会进一步完善部署工作，比如对部署结构进行规范，引入部署版本，并对回滚进行了一定的支持。

以Capistrano为例，其会在目标机建立一个本地的Repository，通过版本系统（git或者svn）将指定版本的代码同步到目标机上，之后通过版本系统的导出或打包功能将无历史信息的代码导出到发布（releases）目录下，并标记时间戳，即部署版本。而后通过修改current软链指向所需的版本。这样，Apache或nginx中的配置只需使用current这个应用占位符，实际的应用程序由具体的releases子目录提供。回滚时，回滚命令只要修改current的指向就可以。抽象一下这种部署结构。

这种形式的部署给我们最大的启发在于目标机上应用实例和部署版本的抽象，但其将软件运行的环境独立出来维护，从根本上看，仍旧是将软件的开发工作作为交付可工作的产品。与我们期望交付运行的系统还有一段距离。

运维工具Ansible

现实中，软件运行的环境通常由运维团队负责，对环境的处理，近几年也有越来越多的优秀工具，如Chef，Puppet，SaltStack，Ansible，下面以Ansible为例。

这是Ansible的一个简单组成，在Ansible中，比较重要的部分是Inventory，Playbook和Module。Ansible通过Inventory对主机进行分组管理，而playbook可以当做环境的承载，比如，可以将不同环境的配置放在对应的Playbook中，这些Playbook就代表了这些环境。而通过Module来描述主机的状态，从而实际屏蔽操作的复杂性。

这是playbook的一个具体例子，其中tasks部分是通过Module对主机的所处状态声明。值得注意的是，这些Module要尽量做到幂等，以便多次执行的过程中没有副作用。另外，如同puppet的Manifest文件，Ansible的文件以及有了元数据描述环境的意味。让我们把Ansible的概念抽象出来。

这里，一个应用运行所依赖的环境，从Playbook的视角看，就是主机（组），对包的处理，如果是系统包可能使用apt Module，如果是应用包，可能使用composer处理，相关的配置，以及一些文件操作。实践中，可以将Ansible文件放入Git，并通过Jenkins来自动实施。那么，环境就有了版本的信息。多说一句，版本在配置管理中非常重要，没有版本就不可能有可追踪性。

通常而言，由于环境的维护的频率远没有应用部署来的频繁，也就是，环境准备好了可能长时间不会发生改变。因此，我们会倾向于将环境的准备和应用部署当做两个概念来对待，前者的变化是通过运维变更来控制。但实际是，既然环境的准备涉及到软件的安装与配置，我们就应该将环境的配置管理实施看做一次部署。

当我们将环境的准备看做部署后，仿照对应用部署的抽象，同时借鉴Ansible的抽象概念，我们大致形成了一个环境部署的抽象。在逻辑层面，环境概念抽象的描述了环境所应具备的包、配置、主机等等信息，通过环境部署会产生环境实例，目前，这个环境实例还是一个假想的东西，与应用部署不同，我们还不能在目标机上同时存放多次环境部署的历史产物。环境的配置都是现在进行时……

将环境部署与应用的部署结合起来。

这已经抽象出大部分企业中应用部署的情况。仔细看一下抽象的概念图，不难发现系统中存在两种部署：应用部署和环境部署，而这两种部署有依赖关系。通常，我们在开发中会通过变更管理来协调这两种部署，比如，系统A上线时，提供运维变更，让运维人员在指定时间升级或安装系统A依赖的包，或者是修改某个环境变量，保证其依赖的环境按需要进行同步改变。由于这连个部署的不协调性：变更频率不一致，实施方式也不同，因此，流程的设置上是为了减少为题的发生（求稳），并非追求效率，而且即使如此，这个部分依然是比较容易出问题的地方。那么，我们能不能尝试将这种部署同步呢？

我们可以将环境描述的代码放到应用代码中，但这样有两个问题：

1、环境的管理不能统一进行

2、环境部署的逻辑会污染项目的功能代码

反过来，我们可以将应用部署逻辑合并到环境部署中——这要求环境的部署必须幂等。也就是说，将应用看做环境的组成部分。看抽象图。

这时，应用部署的处理成为环境描述的一部分，对于Ansible而言既可以开发自定义的Module，也可以使用具体的操作声明来进行。而每一次应用的部署，环境也会同时部署（不一定会改变），保证两者的同步改变，另一个好处是环境的版本会关联应用的版本，对环境的回滚就可以对应用回滚。此时，环境在概念层面以及可以作为运行系统的代表。

此时应用的单独回滚已经失去了意义。这时，环境和应用也应该同步回滚。我们能否实现类似Capistrano的部署思想？在之前的图中，部署实例仍然是虚线标注的一个假想存在。在部署发生的一刻，我们实际上可以确定一个概念上系统的快照，这个快照是一次部署的信息，这个信息可以被单独的记录下来，成为系统生成的一类元数据。带着这样的一个认识，让我们看看回滚。