在本文中，我们讨论如何快速地从更高的层面理解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的评估框架，它将帮助你沿着文化变革的道路前进。
