开门见山DevOps.docx

开门见山DevOps.docx

《开门见山DevOps.docx》由会员分享，可在线阅读，更多相关《开门见山DevOps.docx（9页珍藏版）》请在冰点文库上搜索。

开门见山DevOps

开门见山-DevOps

本文提纲挈领的介绍了DevOps是什么、DevOps与敏捷开发的关系以及成功实施DevOps所需要的准备。

DevOps是什么

在持续流行的、被称为DevOps的现代软件交付方法中，沟通、协作和集成是3个主要原则。

DevOps一词由PatrickDebois创造于2009年，这个术语（开发和运维）是对敏捷开发环境的扩展，它的目的是强化软件交付过程作为一个整体。

DevOps是敏捷的进化

回到2009年，越来越多的IT专业人士开始摈弃传统的瀑布方法，转而拥抱非线性的敏捷方法。

他们实现敏捷方法的途径是，让每个开发阶段独立，在早期就把持续测试纳入进来，并且把持续测试贯穿在整个部署周期中（请参考本文后半部分的术语词汇表以获取更多细节）：

作为这种实践的结果，它提高了效率，同时减少了风险。

之所以能够实现这种结果，是因为它使得开发者可以基于他们收到的持续反馈而在部署到生产环境前做出快速的变更。

虽然敏捷方法通常增强了部署，但是在到达部署的时候，在这个流程中仍然存在着脱节，因为在部署中依然采用的是瀑布方法。

虽然开发通过使用敏捷方法降低了风险和提高了效率，但是部署却停滞在了线性的瀑布结构上，这就减慢了交付，并且把测试留到了这个过程的最后-这个过程错误的划分了所有者关系。

它带来了交付周期中的巨大瓶颈，因为如果在接近部署后期时发现一个问题，那么开发人员需要从头来过。

通过透视在开发和部署中的这种脱节和理解在软件交付的全部方面都拥抱敏捷所带来的好处，Debois想到了DevOps的理念。

把开发和运维嫁接起来，同时采用由敏捷所扩展出来的最佳实践和原则，那么就有可能极大的提高效率并且降低交付的风险。

DevOps需要文化的变化

DevOps不是一个工具或者技术，它是文化的变化。

不管组织的类型是什么，大部分组织都是惧怕变化的，所以采用新方法论可能是极具挑战的。

所以，最关键的，首先要做的是，定义业务需求，是业务需求带来了对潜在变化和相应挑战的讨论。

现在，我们期望业务能够快速的交付无瑕疵的应用，这些应用聚焦在用户体验上。

但是，如果没有恰当的工具、应用和行动，这个看起来简单的任务将会变得团团糟。

最终，有缺陷的交付将导致错失商业机会。

DevOps文化仅仅能够在这样的环境中长存：

每个人都拥抱DevOps理念。

想要获得成功的软件开发和交付，它需要恰当的技术、现状评估和态度。

如果组织内的每一个人都能站在同一个面上，并且理解无歧义的、一致性的沟通所带来的力量，也能够理解业务目标，那么就没有什么可以阻碍这个组织了。

当然，拥有广泛的技能集合是有益于这个过程的任何一个层面的，那些幸运个体也会愿意成为在团队中发挥能量的成员。

DevOps需要统一的、具备多元能力的团队

正如前面所提到的，协作、沟通和集成是把DevOps纳入任何开发和交付设置中的关键元素。

构建具备多元能力的团队能够带来巨大的收益，该团队由人才个体组成（例如开发人员、系统管理员和测试人员）。

但是，如果没有恰当的团队合作和态度，每个人才个体都几乎是没有任何用处的。

当人们知道他可以信赖其他任何人时，这个组织作为一个整体可以更加快速和高效的做出响应，这最终会让客户满意度更高。

实践DevOps方法的第一步包括，识别出软件开发、IT运维和QA是如何相互依赖的。

正如前面所提到的，DevOps依赖于在软件交付流水线上的关键人员之间的跨部门协作和开放沟通，这样才能够提升运维效率、可预测性和可维护性。

在该流程的早期集成和自动化这些元素可以使团队以流式的方式进行软件交付。

DevOps是企业IT的未来

现代企业应用充斥着复杂性，这些复杂性随着使用各种不同的技术、多种数据库和各式各样的终端用户设备而愈演愈烈。

DevOps可能是成功应对这些多样环境的唯一可行的方法。

DevOps词汇表

以下是前面所描述的整体原则中所涉及到的术语和工具，它们是成功的DevOps工程师所需要知道的：

云

IaaS

如果你在IT行业工作，你会听说过公有云。

如果你听说过公有云，那么你会听说过处于领先地位的云厂商，例如AmazonWebServices（AWS）、MicrosoftAzure和GoogleCloudPlatform（GCP）。

他们是基础设施即服务（InfrastructureasaService，IaaS）厂商，他们通过基于互联网的开放链路在虚拟化的环境中向用户提供了计算资源。

这些资源包括，存储、带宽、虚拟服务器、负载均衡器、网络连接和IP地址。

∙厂商和工具的一些例子是：

AWS、GCP、Azure、IBMSoftLayer、DigitalOcean

PaaS

平台即服务（PlatformasaService，PaaS）使得开发人员可以在基于云的平台上构建应用和服务。

PaaS提供的服务可能需要很少或者完全不需要客户方具有托管的专业知识，并且在简化的框架中包含了预配置的功能。

PaaS提供者例行的更新他们的服务，例如升级和新功能，并且在一开始就通过部署为开发者提供支持。

PaaS服务的提供通常是以为每次使用付费的订阅方式进行。

∙厂商和工具的一些例子是：

Heroku、GoogleAppEngine、AWSElasticBeanstalk

SaaS

如果你熟悉Google和Facebook，那么你已经被软件即服务（SoftwareasaService，SaaS）所服务了。

这些云上托管的软件应用拥有多种用途，有些是为个人的，有些是为组织的，例如即时消息、邮件、性能监控、记账和沟通，并且这些工具可以很方便的在线访问到。

和购买传统的软件应用（包含授权限制）不同，SaaS是基于订阅的，应用是在线使用的并且被托管在云上。

敏捷vs瀑布

瀑布是一套方法论，它把软件开发和交付的各个阶段分离开来，然后以线性方式执行这些阶段。

因此，只有当项目顺利进展到尾声时，代码才有可能被部署上去。

而测试和质量保证这2个重要阶段，可能会因为前面一些阶段的延迟而被缩短，甚至被彻底的放弃。

如果在测试和质量保证阶段发现了问题，那么软件必须要重新编码或者会退回到开发过程更早期的阶段。

敏捷也是一套方法论，它在审视业务和软件开发项目时，使用的是非线性的方法。

这样做的结果，显而易见的，就是更高的效率。

测试在早期阶段就被频繁的实施，这样一来，开发人员就可以一边构建一边修复错误和进行调整，因此它就为产品提供了更好的控制，同时减少了瀑布方法所带来的大量风险。

集成和交付

持续集成

持续集成（ContinuousIntegration，CI）-开发人员可以每天把代码集成进共享库多次，对代码的每个隔离的变更可以被迅速的测试以实现检测和防止集成问题的目的。

∙厂商和工具的一些例子是：

Jenkins、Teamcity、TravisCI、CircleCI

持续交付

持续交付（ContinuousDelivery，CD）-作为持续集成的扩展，增量软件交付的下一个步骤就是持续交付。

它保证了在持续集成库中被测试过的代码的任何版本都可以在任何时候被发布。

∙厂商和工具的一些例子是：

Jenkins、Teamcity、TravisCI、ElectricCloud、Go、Codeship、AWS、CodeDeploy

持续部署

持续部署（ContinuousDeployment）也可以被想象成持续集成的扩展，它的目标是让新代码被部署进生产环境并且被在线用户所使用到。

这个功能是由持续集成所支持的，当测试达到发布标准时，代码被立即发布。

配置管理

简而言之，维护硬件和软件最新的、细节的记录-包括版本、需求、网络地址、设计和运维信息-就被称为配置管理（ConfigurationManagement，CM）。

你可以使用配置管理工具来辅助这个过程，例如Chef、Puppet或者Ansible。

你也可以使用Bash和Python来构建你自己的配置管理自动化。

∙厂商和工具的一些例子是：

Chef、Puppet、Ansible、Saltstack、Vagrant、CFEngine

资源编排

当考虑微服务、面向服务的架构、融合式基础设施、虚拟化和资源准备时，计算系统之间的协作和集成就称为编排。

通过利用已定义的自动化工作流，编排保证了业务需求是和你的基础设施资源相匹配的。

容器

容器是轻量级的虚拟化组件，它以隔离的方式运行应用负载。

它们运行自己的进程、文件系统和网络栈，这些资源都是由运行在硬件上的操作系统所虚拟化出来的。

∙厂商和相关工具的一些例子是：

Docker、CoreOs、Kubernetes、Mesos、ElasticBox

源代码（版本）控制

版本控制包括实践和工具，它们帮助研究和开发型组织维护和控制源代码库中的变更。

研究和开发成员也使用源代码控制工具来文档化和追踪系统配置文件。

∙厂商和工具的一些例子是：

GitHub、Bitbucket、JFrog、Artifactory

缺陷追踪

缺陷跟踪系统（BugTracker）是这样一个系统，它汇集和报告软件缺陷或者瑕疵。

它帮助研究与开发型组织进行任务管理，它也是一致性反馈环中的一个组成部分。

一致性反馈环是DevOps方法中所要求的。

∙厂商和工具的一些例子是：

BUGtrack、JIRA、GitHub

测试自动化

通过支持持续的运行多次测试，测试自动化加速了测试工程师的工作。

测试自动化在支持高效的发布周期的同时，也加强了测试覆盖。

例如，测试自动化工具有助于管理、执行和测量功能测试和负载测试。

∙厂商和工具的一些例子是：

Selenium、Cucumber、JUnit、TestNG、JMeter

单元测试

单元测试是这样一个过程，它允许测试人员检查一个应用的某些小部分，例如特定代码或者模块。

这个测试通常是自动化的，并且可以被重用以支持持续测试和集成。

监控

监控是IT性能管理的主要元素，它也是运维在线业务时最重要的方面之一。

监控工具是必须的，它提供了关键信息以帮助保证服务的健壮性（例如可用性、安全和性能）。

应用性能监控

当你的应用框架（包含应用和数据库层）中出现热点时，应用性能监控（ApplicationPerformanceMonitoring，APM）能够让你自动检测到这些情况，并且被报警。

∙厂商和工具的一些例子是：

NewRelic、AppDynamics、DataDog

基础设施监控

这个分类中的工具自动化的对底层物理和虚拟资源的性能和可用性的降级进行检测和报警。

∙厂商和工具的一些例子是：

AWSCloudWatch、Nagios、Zabbix、Sensu、Icinga

日志管理

日志管理（或者叫日志分析）是指处理由计算机生成的巨量消息的实践。

这些消息可能是运维相关的消息（例如当追踪服务性能或者安全时）或者是为了商业智能的目的（例如，当追踪在线用户行为时）。

∙厂商和工具：

Logz.io（ELK）、Splunk、SumoLogic