书籍保举-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章为第三部分，该部分是 进步服务交付结果的实用指南 。这部分内容包括怎样判断团队的成熟度，确保关键要素到位以实现连贯有效的交付；还提供了一些建议，关于怎样组织和管理工作流程、构建与部署仪表化和自动化解决方案，以及采用法律法规要求的治理方式。
  

▲ 扫码抢购

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。