DevOps01-什么是DevOps
- 什么是DevOps？
- “DevOps”是英文单词“Development”和“Operation”的组合，即开发和运维的结合。
- 目前DevOps并没有权威的定义，但得到大部分人认可的是，DevOps已经成为一种文化价值观和实践方法。DevOps价值观的呈现和实践并不依赖于特定的软件，通过合适的软件工具组合可以更容易实现这一价值观。
- DevOps使得业务可以更快地运营，更快地应对变化。
- 在行业内，DevOps的标杆Amazon Web Services（AWS）这样定义DevOps：
- DevOps集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务于客户，并在市场上更高效地参与竞争。
- 维基百科对DevOps的定义是：
- DevOps（Development和Operations的组合）是一种重视软件开发人员（Dev）和IT运维技术人员（Ops）之间沟通合作的文化、运动或惯例。通过自动化软件交付和架构变更的流程，使得构建、测试、发布软件能够更加快捷、频繁和可靠。
1、DevOps简介
- 谈到DevOps，就不得不回顾一下软件开发模型（SoftwareDevelopmentModel）的历史。软件开发模型是指软件开发全部的过程、活动和任务的结构框架。它包括需求、设计、编码和测试等阶段，有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程，明确要完成的主要活动和任务。本章会介绍比较典型的瀑布模型、迭代模型、敏捷模型进行说明，以及如何演进到DevOps。
1.1、软件开发模型
- 爆布模型严格遵循预先计划的需求分析、设计（可细分为系统设计、概要设计、详细设计）、编码、集成、测试的步骤顺序进行。上一阶段的成果输出成为下一阶段的工作输入，阶段之间通过交付大量的文档进行传递。严格的分级、分阶段导致团队的灵活性降低，使项目难以响应需求的变化，难于调整或调整的代价极高。
- 迭代式开发模型每次只设计和实现这个产品的一部分，在迭代式开发方法中，整个开发工作被组织为一系列短小的、固定长度（如4周）的小周期，被称为一系列的迭代。每一次迭代中都会包含完整的需求分析、设计、编码与测试，再通过反馈来细化需求，并开始新一轮的迭代。这种方式弥补了瀑布模型中的一些弱点，加快了对变更的响应速度，可以提前识别问题，从而降低了项目风险，提升了项目成功率和生产率。
- 敏捷软件开发模型，是一种从20世纪90年代开始逐渐引起广泛关注的新型软件开发方法，能应对需求的快速变化。敏捷开发强调开发人员与业务专家之间的紧密协作、强调面对面的沟通、强调频繁交付新的软件版本、强调能够很好地适应需求变化的代码编写和团队组织方法，也更加注重软件开发中人的作用。
- 瀑布式开发，从需求到测试，要求每一个开发阶段都要做到最好，特别是前期阶段，设计得越完美，提交后的成本损失就越少。
- 迭代式开发，不要求每一个阶段尽善尽美，而是先实现主要功能，再通过持续反馈逐步完善。
- 敏捷开发，相比迭代式开发，两者都强调在较短的开发周期交付软件，但敏捷开发的周期可能更短，更强调团队的高度协作，强调适应性而非预见性。
1.2、DevOps发展历史
- 自从人类创造了计算机，就诞生了程序员（Programmer）这个职业，从为计算机编写程序以利用其计算能力，逐渐演变为专职的实现特定功能的开发人员（Developer）。后来由于存在大量的软硬件资源需要维护，又逐渐出现专职的运维人员（Operation）这一职业。
- 开发人员关注怎样更快实现功能并交付开发产品，运维人员关注如何使产品运行得更加稳定。Dev和Ops的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。而DevOps打破了开发和运维两个部门、团队之间的障碍墙。
- 2009年6月，在Velocity大会上，一个名为《10 + Deploys Per Day: Dev and Ops Cooperation at Flickr》的演讲成为本次大会最大的亮点，几乎所有和DevOps相关的资料都引用该演讲作为DevOps出现的标志事件。这个演讲提出：“以业务敏捷为中心，构造适应快速发布软件的工具和文化。”
- 第一届DevOpsDays于2009年10月在比利时根特举行，这次聚会开创了DevOps活动的先河。本次活动尽管只通过推特（Twitter）发起和召集，却出乎意料的成功。世界各地的开发工程师、运维工程师，还有各种IT管理人员、工具爱好者齐聚一堂分享相关技术和实践。从此之后，DevOps在全球开始流行起来。近几年随着微服务和Docker的流行，DevOps得到大规模的应用和实践。
- 敏捷开发和DevOps并不是孤立或对立的关系，其实敏捷是DevOps中的关键组成部分。一般而言，敏捷开发关注于开发过程中的实践，而DevOps包含从开发、持续测试、持续部署到运维的整个过程。
1.3、DevOps生命周期和循环
1.3.1、DevOps的生命周期
-
- 可以更好地帮助我们理解它们在软件开发过程中所处的环节。
- 敏捷开发包含了从规划（涉及需求分析和设计）、代码开发到构建的过程。
- 持续集成CI(Continuous Integration）在敏捷开发的基础上包含了持续构建和测试的过程；持续集成加强了对开发人员的反馈过程，快速验证并解决问题，提升开发效率。
- 持续交付CD(Continuous Delivery）在持续集成的基础上，增加了版本交付的过程；持续交付加强了和测试人员的交互过程，每天都有可用的版本，避免测试阻塞，提升测试效率。
- DevOps在持续交付的基础上，包含了部署和运维反馈的过程；DevOps加强了用户体验，用户所使用的环境每天迭代更新，用户反馈的问题短时间得到更新，用户体验得到持续提升。
1.3.1、DevOps循环
- 经典的DevOps循环如图1-2所示。
- 这个循环包含了开发和运维两部分工作，通过自动化的测试和部署把这两方面的工作进行集成。
- 一份关于敏捷开发和自动化测试的报告显示，有70%的团队采用了敏捷开发，但只有30%的团队采用了CI，至于CD就更少了。
1.4、DevOps价值
- DevOps可以缩短软件发布周期，提升软件质量、安全以及反馈速度。从2016至2017年的DevOps现状调查变化中可以看到，2017年DevOps进一步提升的目标不再是生产效率，而是质量和稳定性。
- DevOps价值有如下：
- 文化：DevOps首先是一种团队文化的转变，团队拥有共同的目标和信仰。
- 沟通协作：沟通在团队工作中非常重要，团队可以通过一些实时工具进行协作，通过持续沟通，团队的任务对所有成员可见，团队成员掌握了最新进展，可以有效进行技能传递，消除由于沟通、依赖导致的无效等待，改进团队全方面的能力，包括设计、开发和监控。
- 信任：是团队的最大特质，没有对团队成员的信任，团队不可能获得成功；成员之间在沟通、协作的过程中增强了相互之间的信任，同时也增强了团队凝聚力，提升了工作质量。
- 减少对专家的依赖：此前大部分组织都是领域专家领导的面向功能的开发团队，比如开发部、质量部、网络管理部、数据库管理部等。DevOps通过取消这些特性团队来减少对专家的依赖；团队的每个成员都是通才，可以解决团队面临的各方面的问题。
- 系统性思考：以业务逻辑的视角来全面理解系统所实现的功能，而不只是局限于深人理解某个领域。
- 精益生产：为组织的纪律、效率和有效性设置标杆；在此过程中努力做到消除浪费、加强质量、延迟承诺、快速发布、尊重个人和全局优化。
- 自动化：所有需要重复的工作都努力做到自动化、代码化，经验可复制、可推广。
- 持续改进：创建一个持续改进的文化氛围，无论是困难还是收获都进行分享，努力打造学习型团队，最终得以持续改善日常工作。
3、DevOps工具链
1、Git
- Git是一个自由且开源的分布式版本控制管理系统，功能丰富、性能出众，但又十分轻量，可扩展性非常好。轻量“廉价”的分支管理使其非常适合于敏捷开发，能及时响应需求和变化，开发人员可以在多任务之间轻松切换。
2、JIRA
- JIRA是项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA提供了一系列敏捷工具，如Scrum和Kanban。
3、Maven
- Maven是一个项目管理和自动构建工具。它强调构建过程中的两个重要方面：如何构建和描述依赖关系。在实际使用中还可以通过一系列的插件来扩展各个阶段的流程。由于Maven包含许多重用性很强的默认规则，往往几行代码就可以完成一个项目的构建。Maven通常用来管理Java项目，但也可以用于管理C＃、Ruby、Scala等其他项目。
4、JUnit
- JUnit是一个Java语言的单元测试框架。多数Java开发环境都已经集成了JUnit作为单元测试的工具。JUnit是一套框架，使用比较简单，只要继承TestCase类，就可以用JUnit进行自动测试了。
5、Jenkms
- Jenkins是基于Java开发的一款开源的持续集成工具，用于代替人工进行重复的持续集成工作，同时也为促进持续交付提供技术支撑。它支持各种版本控制工具，如CVS、Git、ClearCase等，并且可以与多种构建工具进行集成，如Ant、Maven，甚至有自定义的Shell脚本。Jenkins是开发和部署连接的纽带，社区活跃，有大量的插件来扩展其功能，是实现自动化的关键。
6、Puppet
- Puppet是一款集中配置管理工具，使用自定义的DSL描述语言，可管理配置文件、cron任务、软件包、系统服务等。Puppet采用C/S结构，每个客户端周期性（默认半个小时）地向服务器发送请求，获得其最新的配置信息，保证系统和该配置信息同步。
7、Ansible
- Ansible是自动化运维工具，基于Python开发，有批量配置、部署、运行命令、编排复杂任务等功能。与其他自动化运维工具的显著不同在于它只需使用SSH服务(SSH可以说是各种Linux服务器的基本服务），它不需要在被管理节点上安装组件或代理。
- Ansible本身提供了上千种Module可供使用。
8、Nagios
- Nagios是一款开源的网络监视工具，能有效监控Windows、Linux和UNIX等各种主机、交换机、路由器等网络设备。在系统或服务状态异常时可以发出邮件或短信报警，第一时间通知运维人员。
3、DevOps与团队文化
- DevOps团队在内部共享态度、价值、目标和实践，而这些团队通常具有如下特质：
- 团队每个成员都有极大的自主权，可以选择愿意承担的工作、任务和挑战；充分授权让团队成员拥有极大的自信，同时也能够得到快速锻炼。
- 团队成员共担责任，对于错误或失败每个人都有责任，是团队整体的错误，而不归责于某个成员。
- 团队成员在接受不同任务的过程中，可以更全面地了解团队承担的职责，对于团队成员实现的功能也增加了认识和理解，在此过程中，进一步锻炼了自己的能力，可以参与各种角色和功能开发。
- 团队成员分享快乐和痛苦，一同解决技术问题、跨越障碍，收获成功和喜悦，并共同分担在此过程中的痛苦和磨炼。
- 团队成员在解决困难、分担和分享的过程中学会担当，因而，每个成员都会积极处理团队需要承担的事务和需要解决的问题，进一步提升团队的主动性和自治性。
- 如果认为使用自动化的工具把开发和运维工作结合在一起就达到了DevOps，或者某个特定的团队来实施DevOps，其他团队保持传统的开发模式，其实就是打着DevOps旗号的伪实践，DevOps的价值和文化很难在这种模式下表现出来并发挥作用。DevOps是一种文化的转变，团队成员同时负责了开发、部署和运维的工作。在开发过程中不考虑如何部署，不考虑如何运维，仍然是割裂的团队和工作模式。
- 在向DevOps团队转型的过程中，可以把团队分为三个等级：
- 变更前置时间指的是从代码提交到代码在生产环境中成功运行之间的时间。
- 让我们看一下高效能团队和低效能团队在表现上的差异：
- 高效能团队的部署频率是低效能团队的46倍。
- 高效能团队部署变更到生产环境的效率比低效能团队快440倍。
- 高效能团队部署故障恢复时间比低效能团队快96倍。
- 低效能团队部署变更失败率比高效能团队高5倍。
- 高效能团队人工参与的时间相当于低效能团队的60%～70%。
- 高效能团队倾向于使用主干分支，每天向主干分支合入，分支只存在若干小时，而低效能团队则采用长时间的特性分支。
- 高效能团队更倾向于使用松藕合架构，无论是团队独立开发的应用和服务，还是必须与其他团队合作开发需要交互的服务。
4、DevOps转型
- DevOps涉及文化、技术、工具等一系列支撑，业界在这方面有太多的选择，但却没有明显的解决路径，而国内这方面的人才又比较匮乏，在任何一方面的技能缺乏或没有得到合适指导的情况下，目前正在DevOps转型过程中的团队很容易失败。
- 有些服务提供商，已经开始咨询如何进行DevOps转型，但痛苦的是，能胜任这项工作、有经验的顾问太少。许多公司希望寻求一个适合所有人的模式或方法，这往往会造成更多的问题。举个例子，某些公司在既不考虑这个转变是否创造了足够的业务价值，也忽略了必要的、充分的文化转变的情况下，就去构建一个DevOps平台。
- 通信、有线、娱乐和媒体公司为了跟得上市场需求，就需要有能力持续发布新产品和服务。与此同时，随着互联网普及、开源模式得到更广泛的接受，新技术的推广速度越来越快。但在短时间内实现新业务、上线新活动仍然不是一件轻松的事情，这需要强大的IT基础设施的支持。在IT所面临的挑战中可以看到，识别出哪些IT领域需要进行DevOps转型是非常困难的。
- IT领域所面临的挑战大约有十项，例如：掌握开源模型和生态系统、合作伙伴管理、不充分的集成策略、缺乏清晰的技术架构路线图等，其中有16%受访者第一选择都是识别出哪些IT领域需要进行DevOps转型。
# #
