DevOps学习 | 如何应对IT服务交付中的问题？_交付摩擦

目录

前言

DevOps是什么？

DevOps发展历程

DevOps与微服务、容器的关系

书本推荐

---

前言

作为一个热门的概念，DevOps这个名词在程序员社区里频频出现，备受技术大佬们的追捧。甚至网络上有了“南无DevOps”的戏言（南无在梵语的意思是“皈依”），也侧面反映了DevOps的风靡。

然而，一旦有人问起什么是DevOps，大部分人就会扯起类似“之乎者也”等玄之又玄的东西，一部分人说它是工具，一部分人说它是平台，一部分人说它是方法，一部分人甚至说它是哲学。所以今天，我就想和小伙伴们好好聊聊这个DevOps。

本文会分为：DevOps是什么？；DevOps发展历程；DevOps与微服务、与容器的关系；华为云CodeArts。

DevOps是什么？

从字面来理解，DevOps一词由单词Development（开发）和Operation（运维）组合而成。因此，很多人认为，DevOps不就是把开发和运维两个团队合并了嘛。

但是，DevOps的实际意义其实远超字面的理解。它相当于是一组过程、方法与系统的统称；通过一系列手段来促进开发（应用程序/软件工程）部门 与 技术运营和质量保障（QA）部门之间的密切沟通、高效协作与整合；通过自动化地软件交付和架构变更流程，让规划、开发、构建、测试、发布、部署、维护都能更快、更频繁、更可靠，保障开发结果的稳定可靠。

DevOps可以给团队带来什么呢？技术层面上，DevOps可以促进研发与运维团队的协作；业务层面上，DevOps提供的一致容器镜像，持续集成，持续交付，持续部署，持续测试可以更快地交付客户价值。

DevOps发展历程

最开始，程序还很简单的时候，工作量不大，程序员1个人就可以完成所有开发阶段的工作，也就不需要什么额精细化分工了。

接着，随着软件规模越来越庞大、复杂，程序员也开始了细分：研发、测试、运维。研发人员开发完代码交付给QA团队进行测试，测试完毕之后交给运维团队去部署。这一套“等上一个阶段所有工作完成之后再交付给下一个阶段”的流程也被称之为“瀑布模型（waterfall）”。下图是比较详细的流程分类【需求-设计-开发-测试-部署-维护】：

然后，团队发现瀑布模型并不适用于真实的开发环境。为什么呢？因为客户的需求很可能一开始并不明确后面要改动，或则要加上一些新的需求，或则产品中途出现了新的问题，这些都是需要改进的。再加上用户期望团队交付的时间变得越来越少，这时候，笨重工序化流程的瀑布式模型就不适用了。于是，敏捷开发（Agile Development）这个概念就在2000左右开始被关注（而华为则是在2000年左右引入了IPD开发模式，下一段进行讲解），它是一种可以应对需求快速变化的软件开发能力。其实简单来说，就是把大项目变成小项目，把大时间点变成小时间点。简单点来说就是从原先的“设计-开发-测试-部署”模式变为了“设计-开发-测试-开发-测试-开发…-开发-测试-部署”的模式：

敏捷开发这种模式可以大幅提高开发的工作效率，让版本的更新变得更快更频繁（可以更快交付给用户，更快得到用户的反馈从而更快的进行响应），风险也变得更小（可以更快发现问题，修复更容易，版本变化小风险也小）。 

敏捷开发模式既然好处这么多，为何我们还需要推DevOps呢？那是因为敏捷开发模式仅作用于开发阶段。而运维那边依然没有什么改动。但是在我们说DevOps之前，我们先把坑填了。上一段提到的“华为则是在2000年左右引入了IPD开发模式”又是什么呢？Integrated Product Development 集成产品开发，一个基于市场和客户需求驱动的集成产品开发流程管理体系。简单来说就是，将企业的思维从“做出来什么再去卖什么”变成“我们把能卖出去的东西做出来”。这个模式运用成功的企业有IBM、华为。

最后，就是到了我们的DevOps。前面讲到敏捷模式将开发环节的问题解决了，但是开发和运维之间的矛盾则变深了。因为开发和运维天然就有着完全不同的逻辑，开发接了客户的需求肯定要加新功能/新特性，就要做出改变，更不要说在敏捷模式下这改变更多更频繁了；而运维的核心需求则是稳定，不要出问题。DevOps的目标就是让开发人员和运维人员可以好好沟通好好工作，不要掐起来。

在DevOps的模式里，运维和开发是紧密关联的。在项目开发期间，运维人员就会介入到开发过程中来了解技术路线和架构系统，提前制定相对应的运维方案。而在运维的初期，开发人员也会接入到系统部署中来，提供相关的优化建议。理想的情况下，双方的沟通可以增进彼此的理（gan）解（qing）。此时的流程图变为了：

DevOps与微服务、容器的关系

DevOps在微服务/云原生时代，为何会这么炙手可热呢？什么是微服务：把整体的服务拆分成一个个小的服务；每个小型的服务可以独立运行在自己的进程中，服务之间互相协调。

容器化则是在硬件资源、操作系统上，将各个应用程序和类划分为不同的“运行环境”（也就是容器），占用资源变得更少，部署速度变得更快。

微服务和容器化，可以说为DevOps提供了很好的前提条件：业务整体变小变多了，开发环境和部署环境互相之间的影响也变小了。这简直就是为DevOps的理念“加快一个需求从规划到上线部署的过程”量身打造嘛。

 

书本推荐

按需交付服务从来都不容易。成功的交付是以一种符合客户预期的一致性、可靠性、安全性、隐私性和成本效益的方式交付客户所需的服务。无论服务提供商提供的是 IT 服务，还是更传统的快递或电力公用事业服务，这都同样适用。

与传统服务相比，IT 服务提供商因具有快速可部署的工具和云能力，在组织规模或物理位置方面受到的限制要少得多。现在小型 IT 服务提供商也能立即扩展规模，应对全球几乎任何已识别的市场需求。然而，由于在交付服务和管理服务方面存在认知差距，IT服务提供商很难做到可预测和可靠地交付符合客户期望的服务。

随着 IT 服务体系变得越来越复杂，确定服务组件和交付生态系统之间的动态关系是否符合客户预期便越发困难，更别提确保这些动态关系完全符合预期了。交付团队没有采取措施提高对这些动态关系的认识和理解，而是将重点放在了其他因素上，如提高交付速度、使用最新的云技术和架构方法，或采用当前最流行的流程或方法。这样做反而造成了上述动态关系和客户预期的进一步脱节。

随着脱节日益严重，交付团队声称所能提供的服务与实际交付的服务之间的差距越来越大，团队也不再能做出有效决策。为了弥合差距，交付团队又会进一步增加流程，使用更多的工具，然而这对于有效弥合差距并没有太大帮助，反而会形成一个恶性循环，使得交付团队提供的服务离满足客户期望的目标越来越远。这时交付团队就需要学会洞察。

学会洞察是为了提高交付团队的态势感知能力，这能让团队中的每个人仿佛获得了一种从未知晓的新感官或超能力。 《精益DevOps》 的首要目标就是帮助交付团队弥合认知差距，交付能让客户实现预期目标的服务。

本书在内容逻辑上分为三部分。

• 第1、2章为第一部分，介绍了 如何应对IT服务交付中的问题。 该部分描述了IT服务从业者过于关注消除交付摩擦和降低交付风险的问题，这反而使得他们的态势感知能力，以及学习和改进的能力下滑。了解这个问题对于任何IT服务交付组织都很重要，尤其对于那些希望实现DevOps承诺的组织。

• 第3～7章为第二部分， 详细讲解了服务交付中每个关键要素及其所起的作用 ，该部分探讨了这些要素的重要性、要素被误用的场景，以及误用对服务交付和团队的后果。我个人认为这是本书中最重要的部分。

• 第8～14章为第三部分，该部分是 提高服务交付效果的实用指南 。这部分内容包括如何判断团队的成熟度，确保关键要素到位以实现连贯有效的交付；还提供了一些建议，关于如何组织和管理工作流程、构建与部署仪表化和自动化解决方案，以及采用法律法规要求的治理方式。

▲ 扫码抢购