云计算时代，你所不了解的 DevOps

在本文中，咱们讨论如何快速地从更高的层面理解DevOps，介绍准备改变文化的最佳实践。咱们将讨论DevOps的目标以及从组织管理层获得支持的方法，为DevOps的概念打下基础。咱们将试着从根本上介绍使应用程序生命期管理简单、高效的DevOps实践。

 

DevOps不是一种框架、工具或者技术，理解这一点很是重要。它更多的是与组织的文化有关。DevOps仍是人们在组织中使用预先定义的过程、利用自动化工具，使平常工做更加高效、手工工做更少的一种方法。

 

为了理解DevOps的重要性，咱们在本文中将包含以下主题：

DevOps的必要性；

如何发展DevOps文化；

PPT（人、过程和技术）的重要性；

为何DevOps不全和工具备关；

DevOps评估问题。

1.1　DevOps的必要性

每一个伟大的梦想都源于梦想家。永远铭记，你拥有的力量、耐心和热情，能够令你摘星揽月、改变世界。

改变是生命的法则，也适用于组织机构。若是任何组织或者我的只盯着过去或者现有的模式、文化或实践，他们就确定会错失将来的最佳实践。在动态的IT世界中，咱们必须遇上技术革新的步伐。

咱们能够参考乔治•萧伯纳的名言：

不改变就不可能进步，没法改变本身的想法，就不能改变任何东西。

如今，咱们关注的是应用程序生命期管理方法的改变。重要的是，咱们是否真的须要这种改变？咱们是否真的须要经历改变的痛苦？

答案是确定的。

人们可能会说，这种业务或者文化的改变不能是强制性的。

 

让咱们在图1-1的帮助下，理解现代世界中组织在应用程序生命期管理中面对的痛点。

 

图1-1

考虑到业务中不断变化的模式和竞争环境，改善应用程序生命期管理是当务之急。

在现代，有什么因素可以帮助咱们改善应用程序生命期管理？

是的，云计算改变了游戏规则，为许多开创性的解决方案和创新打开了大门。让咱们来理解云计算的真正意义，以及DevOps和自动化等术语在企业中所起的重要做用。

 

1.1.1　云计算概述

从计算革命来看，云计算是下一个合乎逻辑的步骤。从传统数据中心和虚拟化，到混合环境、私有云、公共云和混合云服务，云计算是向云消费者按需提供多租户或者专用计算资源（如计算、存储和网络）的计算类型。云计算有多种不一样风格，包括不一样的云部署模型和云服务模型。最重要的是其订价模型——现收现付。

云部署模型是云资源部署的方式。

1）私有云：私有云由防火墙后专门用于特定组织的场内云资源组成。

2）公共云：公共云由可用于全部组织及我的的云资源组成。

3）混合云：混合云由可用于一组有相似兴趣或者相似需求类型的组织的云资源组成。

4）社区云：社区云由组合两种或者更多部署模型的云资源组成。

 

云服务模型描述了向各种客户（我的、小型组织、大型企业）提供云资源的方式。

云服务模型包括：云客户或者最终用户能够访问和控制虚拟机的纯基础设施——基础设施即服务（IaaS）；提供运行时服务，云服务提供者提供和管理运行应用所需的全部软件安装及配置的平台——平台即服务（PaaS）；云服务提供者提供整个应用程序，负责基础设施和平台的软件即服务（SaaS）。

 

近几年涌现了许多服务模型，可是IaaS、PaaS和SaaS是基于美国国家标准与技术学会（NIST）的定义，如图1-2所示。

云计算有一些重要的特性，如多租户，相似于电力或者煤气的现收现付模式，提供更高计算、存储和网络资源利用率的按需自助服务和资源池化，用于根据须要自动扩展和收缩资源的快速伸缩，以及用于计费的可度量服务。

 

多年以来，不一样云部署模型的使用根据用例而改变。最初，公共云用于非关键应用，而私有云用于关注安全性的关键应用。混合云和公共云的使用随着时间的推移以及对云服务提供商所提供服务的经验及信心而发展。一样地，不一样云服务模型的使用也根据用例和灵活性而有所不一样。IaaS在早期最受欢迎，可是PaaS则凭借其成熟度和自动伸缩、支持多语言和支持端到端应用程序生命期管理工具的易用性然后来居上。

 

图1-2

1.1.2　DevOps概述

DevOps与发展开发和IT运营团队之间的协做，以比现有方式更高效地管理应用程序生命期的组织文化、过程和技术有关（见图1-3）。咱们在工做中每每倾向于根据模式，从相似的问题或者挑战中找出可重用解决方案。

 

图1-3

 

多年以后，成功与失败的试验、最佳实践、自动化脚本、配置管理工具和方法论已经成为DevOps文化中不可分割的一部分。

DevOps有助于定义设计方法、开发方法、测试方法、安装方法、环境管理方法、配置管理方法、应用部署方法、反馈收集方法、代码改善方法和创新方法。

下面是开展DevOps实践的一些明显好处。

 

DevOps是一系列创新，以高效的方法将开发与运营团队整合在一块儿，这些方法包括持续构建集成、持续测试、云资源配给、持续交付、持续部署、持续监控、持续反馈、持续改善和持续创新，按照敏捷方法论的要求，更快地交付应用程序。文化的发展不是一晚上之间就能完成的，须要很长的时间。可是，对于DevOps到底是什么仍存在概念上的混淆，人们每每将单独的持续集成或者配置管理实践当成DevOps实践，这就像盲人摸象，每一个人都将触摸到的一部分当成大象的总体，如图1-4所示。

 

图1-4

可是，DevOps涉及的不只是开发和运营团队。在现有文化的发展中，涉及测试团队、业务分析人员、构建工程师、自动化团队、云团队和许多其余利益相关方。

DevOps和组织文化没有太大区别，它们有共同的价值和行为特征，须要调整心态和过程，与新的技术和工具相匹配。

开发和运营团队面临的挑战

正由于现实中的一些挑战，使DevOps呈向上的趋势，并成为全部信息技术相关讨论中的热门话题。

开发团队面临的挑战

开发人员渴望采用新技术和新方法解决问题。可是，他们面对许多挑战。

竞争激烈的市场形成了按时交付的压力。

他们不得不负责生产就绪代码管理和新功能的实现。

发行周期每每很长，所以，开发团队必须在应用部署最终进行以前作出假设。在这种状况下，修复在模拟环境或者生产环境中部署期间发生的问题须要花费更多的时间。

运营团队面临的挑战

运营团队对资源变化、新技术或新方法的使用老是当心翼翼，由于他们须要稳定性。可是，他们也面对许多挑战。

资源争用：难以处理日益增加的资源需求。

从新设计或者调整：这是在生产环境中运行应用程序的须要。

诊断和改正：他们应该在应用程序部署与外界隔绝的状况下诊断和改正问题。

IT团队面临的挑战

IT团队向各个团队提供运营所需的资源。

基础设施配给：提供基础设施和具有合适安装软件包的运行时环境。

配置管理：根据工具或者技术的可供更新，升级现有基础设施或者软件包。

考虑到开发和运营团队面对的全部挑战，咱们应该如何改善现有过程、利用自动化工具提升过程的效率、改变人们的思惟方式？在下一小节，咱们将了解如何在组织中发展DevOps文化，改善效率和效能。

 

1.2　如何发展DevOps文化

低效的估算、进入市场的时间过长以及其余问题致使了瀑布模型的改变，产生了敏捷模型。文化的演变不是有固定时限或者一晚上之间能够完成的过程，它多是一个步进式的分阶段过程，能够在不依赖其余阶段的状况下完成。

咱们能够在不使用云配给的状况下实现持续集成，能够在不实现配置管理的状况下实现云配给。咱们也能够在没有任何DevOps实践的状况下实现持续测试。图1-5所示是实现DevOps实践的不一样阶段。

 

图1-5

1.2.1　敏捷开发

敏捷开发或基于敏捷的方法论对应用程序构建颇有用，这种方法将权力下放，鼓励互动，重视可工做软件、客户协做——利用反馈改善后续步骤——并以高效的方式响应变化。

敏捷开发最吸引人的好处之一是在短期内（敏捷术语中叫做“冲刺”）持续交付。这样，应用开发的敏捷方法、技术上的改进、破坏性创新和方法在开发和运营团队之间形成了一条鸿沟。

1.2.2　DevOps

DevOps试图经过发展开发和运营团队之间的伙伴关系，弥合这条鸿沟。DevOps活动强调软件开发人员和IT运营部门之间的沟通、协做和整合。

DevOps促进协做，经过自动化和编排改善过程为协做提供方便。换言之，DevOps本质上将敏捷活动的持续开发目标扩展到持续集成和发行。DevOps是利用云解决方案的优点，将敏捷实践与过程组合起来。敏捷开发和测试方法帮助咱们实现应用程序的持续集成、开发、构建、部署、测试和发行目标。

构建自动化

自动化构建运用Gradle、Apache Ant和Apache Maven等构建自动化工具，帮助咱们建立应用程序构建。

自动化构建过程包括将源代码编译成类文件或者二进制文件、提供第三方库文件引用、提供配置文件路径、将类文件或者二进制文件打包成包文件、执行自动化测试用例、在本地或远程机器上部署包文件和减小包文件建立中的手工做业等活动。

持续集成

简言之，持续集成（CI）是一种软件工程实践，在这种方法中，开发人员的每次签入（Check-in）都使用以下任一种方法验证。

“拉”机制：在计划的时间点执行自动化构建。

“推”机制：在存储库中保存更改时执行自动化构建。

这一步以后，对源代码库中最新的更改执行一次单元测试。持续集成是一种流行的DevOps方法，要求开发人员将代码天天数次整合为Git和SVN等代码库，以验证代码的完整性。

而后，自动化构建验证每次签入，使团队能够及早发现问题。

CI（甚至CD）是公司同步DevOps存档的基线。在组织中若是没有很好地实施CI和CD，就没法实施DevOps。

云配给

在本章前面，咱们已经介绍了云计算的基本知识。云配给为架构即代码（Infrastructure as Code ，IAC）敞开了大门，使整个过程变得极其高效，由于咱们在很大的程度上将涉及人工干预的过程自动化了。

现收现付的计费模式使所需的资源更加容易承受，不只对大型组织，对中小规模组织和我的也是如此。

云配给有助于改进和创新，由于之前的资源约束从成本和维护的角度阻碍了组织的进一步发展。一旦咱们在基础设施资源上拥有了敏捷性，就能够考虑自动化运行应用程序所需软件包的安装和配置。

配置管理

配置管理（CM）系统中的更改，更具体地说，就是服务器运行时环境。咱们可使用市场上的许多工具实现配置管理。流行工具包括Chef、Puppet、Ansible、Salt等。

让咱们来考虑一个须要管理多个同类配置服务器的例子。

例如，咱们须要在每一个服务器上安装Tomcat。若是须要改变全部服务器上的端口、更新某些软件包或者为某些用户提供权限，该怎么办？这种情形下的任何修改都是人工的，也就是一种容易出错的过程。由于全部服务器都使用相同的配置，能够利用自动化手段。

持续交付

持续交付和持续部署是能够互换使用的术语。可是，二者之间仍是有一些小的差异。

持续交付是在任何环境中以自动化方式部署一个应用程序并提供持续反馈以改善其质量的过程。持续交付和持续部署中的自动化方法不会改变。可是批准过程和其余小细节可能改变。

持续测试和部署

持续测试是端到端应用程序生命期管理过程当中很重要的阶段，包括功能测试、性能测试、安全性测试等。

Selenium、Appium、Apache JMeter和许多其余工具均可以用于相同的目的。另外一方面，持续部署是部署应用程序，包含对生产环境的最新更改。

持续监控

持续监控是端到端交付流水线的骨干，开源监控工具就像冰淇淋勺的头部。

 

如图1-6所示，在几乎每一个阶段都设置监控，得到全部过程的透明度是十分可取的作法。这还可以帮助咱们快速检修故障。监控应该在深思熟虑的计划下执行。

图1-6描述了持续方法的所有过程。

咱们必须理解，这是一种分阶段的方法，不必定要一次性完成各个阶段的自动化工做。每次选择一种DevOps实践、实施并理解其好处，而后再实施另外一个，这是更有效的作法。

这样，咱们能够安全地评估组织文化改变带来的改善，消除应用程序生命期管理中的手工劳动。

 

图1-6

1.3　PPT——人、过程和技术——的重要性

PPT在任何组织中都是一个重要的词。等等！咱们说的可不是PowerPoint演示。这里，咱们关注的是人、过程和工具/技术。让咱们来了解一下，为何这些因素在改变任何组织的文化时很重要。

1.3.1　人

引用Jack Cranfield的名言：

无论周围发生什么，成功的人老是积极地看待人生。他们着眼于过去的成功而不是过去的失败，聚焦于使他们更接近目标的下一步行动，而不是生活中令他们分心的其余事务。

为何说人很重要？这是一个有趣的问题。若是咱们想要用一句话来回答，那就是：由于咱们试图改变文化。

那么又如何？

 

人是任何文化的重要组成部分，只有人可以驱动文化的改变，或者改变本身以适应新过程、定义新过程、学习新工具或者技术。

让咱们用变革方程式来理解。

按照维基百科的说法，David Gleicher在20世纪60年代初创造了变革方程式。Kathie Dannemiller在1980年对方程式进行了完善。这个方程式提供了一个模型，以评估影响组织变革倡议成功几率的相对优点。

 

Gleicher（原始）版本为：C= (ABD) >X，其中C=变革，A=对现状的不满意度，B=但愿获得的明确状态，D=达到理想状态的实际步骤，X=变革的代价。

Dannemiller的版本：D×V×F>R，其中D、V和F必须存在，组织变革才能进行：D=对现状的不满意度，V=对可能目标的愿景，F=可用于实现愿景的前几个具体步骤。若是这3个因素的乘积大于R（阻力），那么变革就是可能成功的。

 

本质上说，这个公式表示，必须有对现有事务或者过程的不满，对新趋势、技术和市场方案创新的愿景，以及实现愿景所采起的具体步骤。

关于变革方程式的更多细节，能够访问维基百科网页：https://en.wikipedia.org/wiki/Formula_for_change#cite_note-myth-1

做为经验分享，我认为培训人员适应新的文化很是重要，这是一场须要耐心的博弈。咱们不能在一晚上之间改变人们的思惟方式，在改变文化以前首先须要理解。

在行业中每每能看到，文化的改变从DevOps知识或者DevOps工程师开始，可是在理想情况下，这些不该该是“舶来品”，而应该逐步改变现有环境，并在其中训练人员，以控制阻力。咱们不须要一个专门的DevOps团队，须要的是开发人员、测试团队、自动化实现人员和云或基础设施团队之间的更多沟通和协做。

让全部人都理解彼此的痛点是必不可少的步骤。在我工做过的机构里，咱们习惯于有一个卓越中心（COE）来管理新技术、创新或者文化。做为自动化实现者和DevOps团队的一员，咱们只应该担当促进者的角色，而不是与世隔绝的“竖井”中的一员。

 

1.3.2　过程

Tom Peters曾有一段名言：

几乎全部质量改进都来源于对设计、制造…布局、过程和规程的简化。

在处理文化的发展时，质量极其重要。咱们须要过程和策略，以正确的方式完成工做，并标准化各个项目，使操做的顺序、约束、规则等都有完备的定义，以便对成功与否进行度量。

咱们须要为如下任务创建过程。

敏捷规划。

资源规划和配给。

配置管理。

对云资源和自动化中使用的其余工具的基于角色访问控制。

编程语言的静态代码分析规则。

测试方法论与工具。

发行管理。

这些过程对于度量DevOps文化发展的成功也很重要。

 

1.3.3　技术

史蒂夫•乔布斯有以下的名言：

技术并不重要，重要的是你对人们有信心，他们都很好、很聪明，若是给他们工具，他们就能作了不得的事。

科技帮助人和组织产生创意、完成创新，同时改变文化。没有科技，在平常例行的自动化操做中，就很难实现速度和效率。云计算、配置管理工具和构建流水线在资源配给、安装运行时环境和编排中颇有用处。它们从根本上提升了应用程序生命期管理中不一样方面工做的速度。

 

1.4　为何说DevOps不全和工具备关

是的，工具什么都不是，在任何组织的文化变革中，它们都不是重要的因素。缘由很简单。无论咱们使用哪种技术，都必须实施持续集成、云配给、配置管理、持续交付、持续部署、持续监控等。

按照类别，可使用不一样的工具集，可是全部工具执行的都是相似的操做。工具执行某个操做的方式可能不一样，但结果是相同的。表1-1所示是按照分类列出的一些工具。

 

表1-1

让咱们来看看在不一样运营工做的不一样阶段使用的不一样工具。这可能根据不一样组织中的环境数量或者DevOps实践数量而变化，如图1-7所示。

 

图1-7

若是咱们须要根据不一样的DevOps最佳实践分类工具，能够将其分类为开源和商业。表1-2所示为一些例子。

 

表1-2

1.5　DevOps评估问题

DevOps是一种文化，咱们对此已经很了解。可是，在实施自动化、制定过程和发展文化以前，咱们必须理解组织文化的现状，以及是否有必要引入新过程或者自动化工具。

咱们必须很是清楚，咱们须要的是使现有文化变得更加高效，而不是输入文化。

建立须要提出的问题类别，并根据具体应用得出答案。

下面是几个问题的例子。

1．你是否遵循敏捷原则？

2．你是否使用源代码库？

3．你是否使用静态代码分析工具？

4．你是否使用构建自动化工具？

5．你使用场内基础设施仍是基于云的基础设施？

6．你使用配置管理工具、安装应用程序软件包的脚本仍是运行时环境？

7．你是否使用自动化脚本在生产和非生产环境中部署应用程序？

8．你是否使用应用程序生命期管理的编排工具或者脚本？

9．你是否使用功能测试、负载测试、安全性测试和移动测试的自动化工具?

10．你是否使用应用程序和基础设施监控工具？

一旦问题就绪，就准备答案，并根据上述问题的每一个答案肯定等级。

保证框架的灵活性，即便咱们改变任何类别中的一个问题，也可以自动地管理。

评出等级以后，在框架中引入不一样的条件和智能，捕捉答案并计算整体等级。

建立各个分类的最终等级，根据最终等级建立不一样类型的图表，使其更容易理解。在这里，须要注意的是，组织在应用程序生命期管理各领域中的专业能力。这将为评估框架提供一个新的维度，以增长智能，使其更为高效。

 

1.6　小结

在本文中，咱们设定了本书要实现的许多目标。咱们介绍了持续集成、云环境中的资源配给、配置管理、持续交付、持续部署和持续监控。

设计目标是将愿景清晰化的第一步。

咱们已经看到，云计算是如何改变过去对创新的认知方法，它如今已经变成了切实可行的方案。咱们还简要介绍了DevOps的必要性和各类不一样的DevOps实践。人、过程和技术在改变组织现有文化的过程当中也很重要。咱们试图指出它们的重要性。工具很重要，但不能止步于此；能够利用任何工具集，改变文化并不须要特定的工具集。咱们也简要地讨论了DevOps的评估框架，它将帮助你沿着文化变革的道路前进。

 

若是您以为不错，请别忘了转发、分享、点赞让更多的人去学习， 您的举手之劳，就是对小编最好的支持，很是感谢！