DevOps DevOps 在公司项目中的实践落地

laofo · 2017年11月13日 · 最后由 laofo521@gmail.com 回复于 2017年11月14日 · 6 次阅读

转自:https://www.cnblogs.com/beef/p/7743594.html

DevOps 究竟是什么

DevOps(Development 和 Operations 的组合词)是一种重视 “软件开发人员(Dev)” 和 “IT 运维技术人员(Ops)” 之间沟通合作的文化、运动或惯例。透过自动化 “软件交付” 和 “架构变更” 的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。——维基百科

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

Mike Kavis 是美国 Cloud Technology Partners 公司的副总裁兼首席架构师,他也更加详细地描述介绍说:DevOps 是软件开发生命周期(SDLC)从瀑布式到敏捷再到精益的发展。 DevOps 超越了敏捷,它的关注点是从 SDLC 中移除浪费。通常情况下,发现浪费或者瓶颈的形式包括:不一致的环境,人工的构建和部署流程,差的质量和测试实践,IT 部门之间缺少沟通和理解,频繁的中断和失败的协定以及那些需要珍贵的资源、花费重要的时间和金钱才能保持系统运行的全套问题。

他还看到另一个重复浪费是:一个 DevOps 团队的第一步通常是决定他们是否应该使用 Chef 或者 Puppet(或者是 Salt、Ansible 等其他任何热门的东西)。他们甚至还没有定义自己打算解决的问题,即使他们手头的工具可以解决它们。这些团队通常会紧张地构建数千行脚本,但是这就产生了一个问题:“我们的职责是编写 Chef 脚本还是通过质量更好、更稳定的产品更快地进入市场?”。在大多数情况下,这些团队会将自己逼入绝境,大量的专有脚本实际上是增加了系统的浪费,而隐藏在 DevOps 运动之后的驱动力是从系统中移除浪费,这些团队并没有做到这一点。Mike Kavis 原文

而目前对 DevOps 有太多的说法和定义,不过它们都有一个共同的思想:“解决开发者与运维者之间曾经不可逾越的鸿沟,增强开发者与运维者之间的沟通和交流”。而我个人认为,DevOps 可以用一个公式表达:

文化观念的改变 + 自动化工具 = 不断适应快速变化的市场

其核心价值在于以下两点:

  • 更快速地交付, 响应市场的变化。

  • 更多地关注业务的改进与提升。

当理解了什么是 DevOps 后,那我们为什么需要它呢?它给我们又带来了哪些好处?

为什么需要 DevOps

当今世界改变的速度已与过去不同,而每当经历一个颠覆性的技术革命时,都给这个世界带来了深刻的变化,大数据、云计算、人工智能、VR/AR 和区块链等新兴技术推动着世界不断变化,如何应对这样一个 VUCA 时代,让我们能够在环境变化的时候快速响应呢?

V=Volatillity(易变性)是变化的本质和动力,也是由变化驱使和催化产生的

U=Uncertainty(不确定性)缺少预见性,缺乏对意外的预期和对事情的理解和意识

C=Complexity(复杂性)企业为各种力量,各种因素,各种事情所困扰。

A=Ambiguity(模糊性)对现实的模糊,是误解的根源,各种条件和因果关系的混杂。

接下来我将从 “产品迭代” 和 “技术革新” 两个层面分析介绍如何变化的。

产品迭代

我们不管是做互联网还是做游戏,其实最终都是在做产品,做一款用户喜欢的产品。乔布斯有句非常著名的名言:“消费者并不知道自己需要什么,直到我们拿出自己的产品,他们才发现,这是我想要的东西”。所以乔帮主能够在一开始的时候就设计好了产品最终的效果,然后按照零部件一步步迭代生产,其步骤可以用下图所示:

全世界只有一个乔布斯,而在我们现实的产品迭代中却是这样的,对话如下:

用户:我平时上下班都是走路,每天都要走五公里,好辛苦,有没有办法帮我设计个工具,解决下我的痛点。

我们思考了下,觉得这个不是很难嘛,可以试下,于是我们讨论 -> 设计 -> 开发 -> 测试 -> 交付给用户了一个滑板。

用户:这个滑板不好操控,可以给我加个扶手吗?

然后我们按照用户新的需求,生产了个滑板车。

用户:滑板车得滑着走,能不能让我可以骑着走的。

我们继续改进产品,生产了个自行车。

用户:自行车还得登着走,路程远了也很累。

我们又继续优化,把它变成了电瓶车。

用户:电瓶车倒是解决了的需求,不过就是不太安全,能再优化下产品吗?

经过各种努力我们最后生产出了一辆漂亮的小轿车交付给了用户,终于让用户满意了。

现实中的用户其实一开始并不知道自己想要什么,但是直到看到了我们的产品,他才知道自己不想要什么。

即让现实的产品迭代是如此曲折和反复的,那我们有没有办法快速交付价值、灵活响应变化呢?答案就是 DevOps,它是面向业务目标,助力业务成功的最佳实践。

产品的迭代需要 DevOps,那么技术的革新更加促进了 DevOps 的快速发展和落地实施,下面让我们一起看一下技术又是如何支持产品的迭代而不断革新地呢?

技术革新

在以前的系统中业务单一、逻辑简单、用户量少,项目团队的规模一般在 10~30 人。而现在的系统要面对不同用户的定制化推荐等,互联网连接着人与人、人与物、以及物与物,业务也变得越来越复杂,功能越来越多,如果整个系统耦合在一起,则必定会牵一发而动全身,导致系统维护起来相当困难。

因此 IT 技术架构也随着系统的复杂化而不断地变化革新,从早期所有服务的 All In One 发展到现在的微服务架构、从纯手动操作到全自动化流程、从单台物理机到云平台,下图展示了 IT 技术革新的变化:

现在 DevOps 已经成为发展的趋势了,那它又是怎么实现落地的呢?

如何实现 DevOps 的落地

知之真切笃实处即是行,行之明觉精察处即是知 —— 明•王守仁《传习录》

在些我引用了圣贤王阳明的一句名言,他提倡 “知行合一”,通俗的讲就是做事情要理论与实践相结合。我们在实现 DevOps 落地时也一定要遵循 “理论与实践相结合” 的方式进行,理论就是我们做事的指导思想,而实践就是具体做事的方法,接下来我就从我在公司中是如何按照理论与实践相结合来推动 DevOps 落实地。

落实 DevOps 的指导思想

首先我们还是要回到什么是 DevOps,如果大家忘记了可以回到之前再温故一下,包括我总结的 DevOps 公式。

其实 DevOps 核心思想就是:“快速交付价值,灵活响应变化”。其基本原则如下:

  • 高效的协作和沟通;
  • 自动化流程和工具;
  • 快速敏捷的开发;
  • 持续交付和部署;
  • 不断学习和创新。

然而这些基本原则又是如何与项目研发息息相关的呢,也就是它们在我们的开发过程中的各个环节是如何体现的?请看下面一张来自《success with enterprise dev-ops - whitepaper》的介绍图:

敏捷管理:一支训练有素的敏捷开发团队是成功实施 DevOps 的关键。

根据康威定律:软件团队开发的产品是对公司组织架构的反映。

所以根据公司情况调整组织结构是首要条件,它将直接影响到需求、设计和开发阶段的效率、以及沟通的成本。

关于团队的沟通成本在《人月神话》中有个很好的计算公式:沟通成本 = n(n-1)/2,其中 n 为人数,所以沟通成本将随着组织人员的增加而呈指数级增长。而小而快的敏捷团队如何划分,我将在后面 “DevOps 的具体实施方法” 一节中详细介绍。

持续交付部署:实现应用程序的自动化构建、部署、测试和发布。

通过技术工具,把传统的手工操作转变为自动化流程,这不仅有利于提高产品开发、运维部署的效率,还将减少人为因素引起的失误和事故,提早发现问题并及时地解决问题,这样也保证了产品的质量。下图展示了 DevOps 自动化的流程:

此图来自我的新书《分布式服务架构:原理、设计与实战》,书中也有具体介绍持续交付部署的细节内容。

IT 服务管理:可持续的、高可用的 IT 服务是保障业务正常的关键要素,它与业务是一个整体。

IT 服务管理(ITSM)直接影响产品运营的整个生命周期,传统的 IT 服务管理(像 ITIL)在生产中做的非常好了,但是它对于 DevOps 来说又显得过于繁琐,所以有必要为 DevOps 创建一个只关注业务持续性的 ITMS,它只需要很少的必要资源来为相应的业务提供服务,ITMS 更多地从业务角度考虑了。

注:白话解释下什么是 IT 服务管理(ITSM),它是传统的 “IT 管理” 转向为 “IT 服务” 为主的一种模式,前者可能更关注具体服务器管理、网络管理和系统软件安装部署等工作;而后者更关注流程的规范化、标准化,明确定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标、有关人员的责权利,以及各个流程之间的关系等,比如建立线上事故解决流程、服务配置管理流程等; 而光有流程还不够,因为流程主要是 IT 服务提供方内部使用的,客户对他们并不感兴趣,所以还需将这些流程按需打包成特定的 IT 服务,然后提供给客户使用,比如在云平台上购买一台虚拟云主机一样。

精益管理:建立一个流水线式的 IT 服务链,打通开发与运维的鸿沟,实现开发运维一体化的敏捷模式。

精益生产主要来源于丰田生产方式 (TPS) 的生产哲学,它以降低浪费、提升整体客户价值而闻名,它主要利用优化自动化流程来提高生产率、降低浪费。所以精益生产的精髓是即时制(JIT)和自动化(Jidoka)。

JIT(Just In time):JIT 用一句话描述就是消耗最少的必要资源,以正确的数量,生产和运送正确的零件。在这种模式下工作,可以最大程度上降低库存,防止过早或者过度生产。大多数公司更倾向用库存来避免潜在的停线风险,而丰田却反其道而行之。通过减少库存 “逼迫” 对生产中产生的问题做及时且有效的反应。当然 JIT 这一模式对解决问题的能力是相当大的考验,在能力不足的情况下,会有相当大的断线风险。

Jidoka(Build in quality):自动化,日语表示为 “自働化”,字面含义是自动化,日语里表示为 “自動化”,而在丰田 TPS 系统里,特意给 “動” 字加上了 “人” 字旁变成了 “働”,换句话说,TPS/精益生产渴望生产的过程控制能像 “人” 一样智能,在第一时间就异常情况下自动关闭。这种自动停机功能可以防止坏件流入下游,防止机器在错误的生产状态下造成损坏,也可以让人更好的在当前错误状态下进行故障分析。当设备能够做到自动分析故障时,就可以将监管机器的 “人” 真正解放出来,做到对人力成本的节省。 ——来自知乎

下图展示了丰田 TPS(Toyota Production System)手册中的精益小屋:

而精益软件开发是精益生产和实践在软件开发领域的应用,总结为如下七条原则:

  • 消除浪费
  • 增强学习
  • 尽量延迟决定
  • 尽快发布
  • 下放权力
  • 嵌入质量
  • 全局优化

精益管理贯穿于整个 DevOps 阶段,它鼓励主动发现问题,不断的优化流程,从而达到持续交付、快速反馈、降低风险和保障质量的目的。接下来让我们看看 DevOps 具体的实现方法。

需要 登录 后方可回复。