化繁为简还是化整为零?DevOps中的十二关键词
6101
2017-09-18 14:02
文章摘要:DevOps虽然火热,但对于很多刚刚接触其的公司和开发者来说,其概念依然较难理解。本文从DevOps中十二个关键词入手,简单说明DevOps中的一些原则与思想。

编译 T客汇 Felix

在过去的几年里,DevOps在公司IT团队中变得愈发火热。根据最新一份DevOps报告“2017 State of DevOps Report”,三年前只有16%的IT专业者表示他们与DevOps团队一起工作。而在今年这一数字上升到了27%,这说明DevOps正在得以快速的应用。

而根据CA Technologies今年一项针对1770名商业及IT高管的独立调查所示,87%的公司已经应用了DevOps,至少是小规模的使用。同时,在调查DevOps实施带来的明显收益时,74%的受访者表示DevOps提高了他们的客户体验,而77%的受访者认为他们员工入职率和留存率得到了提升。此外,该调查还发现,DevOps还为公司带来了员工生产力提升(43%)、新业务发展(40%)以及IT成本的节约(38%)。

这些统计数据可能会让更多的公司开始审视与研究DevOps。 不过,对于刚刚接触这一下概念的概念,DevOps仍旧是一个谜。

DevOps没有行业标准的定义。 相反,这是一个相对松散定义的方法,其意味着开发人员和IT运营人员将更密切地协作。 它涉及自动化流程以实现更高的效率和改变IT文化,以支持迅速地迭代和频繁地软件更新。

随着DevOps本身的不断发展,相关从业人员已经发展出了自己的展业术语,而这些对于新手来说是具有极大挑战性的。下面本文就会列出有关DevOps最重要的十二个关键词并加以说明。

敏捷开发

DevOps概念的兴起源自于敏捷软件开发的扩展。2008年,Andrew Shafer和Patrick Debois发表了一个演讲,他们讨论了如何将敏捷原则应用于IT业务中。 在演讲中,他们创造了“DevOps”一词来形容他们关于敏捷基础架构管理的想法。

敏捷软件开发有自己的主张和一套明确的基础原则。简单来说,这种方法主张缩短开发周期,加快软件供应速度、提升产品更加与迭代速度、加强业务经理与最终用户的沟通协作等,并提倡业务双方的面对面交谈,同时还具有自组织团队、简单性和持续提升等特点。

自动化

为了提高效率,DevOps团队通常会使用一些自动化软件来最大限度地减少他们必须手动执行的任务数量。例如,当开发人员需要建立新的开发,测试或生产环境时,他们可以使用自动化平台为他们设置环境。这样可以消除手动配置服务器的操作以节省时间,并通过标准化服务器配置从而减少错误。而且,自动化还可以让DevOps更加简便地进行功能的增减。

一些热门的DevOps工具比如:Chef,Puppet,Ansible,Jenkins,Vagrant,Gradle,SaltStack等。

配置管理

在IT环境中,配置管理指的是在IT控制下进行软硬件跟踪的过程。其涉及到系统版本及其安装程序类型、设备序列号、设备所有权以及具体用户使用具体设备进行具体程序安装的情况。

作为一个学科,配置管理本身的理念远远超过DevOps。但是DevOps的做法改变了传统的配置管理实践,更加强调自动化来处理这些平淡的任务。

容器

容器,特别是Docker容器,已经成为DevOps团队中非常受欢迎的一种简化应用程序部署的方式。容器可以将应用程序与其所依赖项(其所需要的其他正常运行的软件)组合在一起。 因而,无论公司进行公有云还是私有云的数据中心中的容器部署,容器本身总是以相同的方式进行运行,公司可以轻易进行容器环境的迁移(对于混合云来说这点尤为关键)。

此外,容器还将应用程序与运行在同一服务器上的其他应用程序隔离开来。 这使得在单个服务器或集群服务器上运行多程序运维变得更加容易。容器技术与虚拟化类似,但容器重量较轻(它们不使用尽可能多的系统资源),并且不需要管理程序。

持续交付/持续集成

在关于敏捷开发与DevOps的讨论中,“持续性”这一词语总是频繁出现,其通常指的是持续交付和持续集成。这两个短语都与敏捷开发中频繁更新的核心原则相关。

具体来说,实行持续交付(CD)的公司将具有更短的开发周期和更多的产品测试,以便他们可以几乎随时向最终用户进行代码发布。采用CD方法时,DevOps团队可能会每周每天甚至于每天向最终发布软件更新。

另一方面,持续集成(CI)与CD相似,但它们略有不同。应用CI时,同一项目中的开发人员每天会至少进行一次的全代码集成(有时将更加频繁)。这有助于最大程度地减少多人同时进行同一代码上独立工作时所产生的问题。通常DevOps团队会通过使用CI / CD应用程序来帮助他们跟踪目前正在开发的软件。

DevSecOps

DevOps采用敏捷开发原则并将其应用于运营和基础设施的方式大致相同,DevSecOps采用DevOps的原则,并将其应用于安全(Development+Operation+Security)。 DevSecOps是一个更新的概念,但它正在迅速普及。

通过鼓励更密切的协作,DevOps模糊开发和运营之间的界限,而DevSecOps则模糊了安全性与其他IT之间的界限。 DevSecOps的最终目标是使IT团队中的每个人都能在整个应用程序生命周期内对安全性负责 ,但这种思维方式需要在大多数公司组织中进行重大的文化变革。

基础设施即代码

最近,像软件定义的网络,软件定义的存储甚至软件定义的数据中心这样的趋势已经愈演愈烈了。 在所有的案例中,对基础设施的控制 ,无论是基础架构,网络设备,存储阵列还是整个数据中心 ,都已经抽象出硬件,而且由软件控制。

这些软件定义的趋势是基础设施即代码的示例,这是各种使用代码来控制日常环境中硬件方法的总称呼。基础设施即代码在DevOps团队中很受欢迎,因为可编程基础设备可以更轻松地使用自动化来管理和配置系统与设备。

迭代

迭代本身只是一个反复重复的过程, 但敏捷开发和DevOps团队经常涉及到快速的迭代,这是说明更新周期短的一种方法。

在敏捷开发和DevOps变得流行之前,开发人员经常在大量软件大修中工作数月甚至数年。 但是,通过敏捷开发和DevOps的简短迭代,开发者可能仅在一两天内完成软件中的一个功能更改,然后全新功能推送给最终用户。这种方法的优点是它可以更快地完成软件改进与交付。

微服务

微服务架构是一种设计应用程序的方法,其中软件将由众多小型,独立的部分或服务组成。 相比于创建一个巨大的单片应用程序,当开发者以这种方式设计软件时,将可以进行各个部分进行调整和更新,而不会对整个应用程序造成干扰。此外,该架构还允许用户在多个应用程序之间重用或共享服务。

对于DevOps来说,微服务架构并不是必需的,但是两者往往是并行的。 如果公司的理念是对其的应用程序进行频繁,小的更改,这种将应用程序分解成可自行更新的小型独立程序的方式将更能满足公司的需要。

无服务器/FaaS

无服务器和功能即服务本意相同。这两个术语都指的是一种云计算服务方式,应用该服务后开发人员不必再考虑其应用程序中的基础架构。当然,这些云服务并不是真正的无服务器,应用程序仍然运行在某个云计算数据中心的物理服务器上。不过,开发者会感受到这种无服务器,因为他们不必配置、优化或管理基础架构。相反,他们只是进行代码编写。

很多DevOps认为无服务器极具吸引力,因为其可以作为一种额外的自动化方式,并让工作变得更加高效。有些人甚至将无服务器称为“NoOps(无运维)”,因为开发者无需再考虑那些基础架构,也无需与运营与基础架构专业人员进行紧密协作。

技术债务

有时候开发人员会急于完成软件的上市,甚至会走一些“捷径”。他们只是一味地追求速度,而不考虑应当持续性的提供最好的产品。这种方式会带来一个很明显的问题,就是可能会产生额外的工作,因为开发者必须要回归到正确的开发方式上(流程开发者称之为“重构”)。

这种额外的工作即“技术债务”。由于过分强调速度和效率,DevOps团队就会遇到高风险的技术债务。与企业有时需要采取金融贷款以实现扩张与成长的方式大致相同,DevOps团队也可能需要承担一些技术债务才能完成如约交付。 但是,他们不应该以快速交货的方式作为代码质量差的借口,也不应该忽视技术债务而需要付出的代价。

单元测试

所有的软件都需要在交付前进行测试,同时公司也可以应用很多不同的方法以进行测试。单元测试指的是进行小件应用的单独测试。而在所有的单件应用可以正常工作时,团队就可以对整个应用程序进行下一步测试。

这种方法在DevOps团队中很受欢迎,因为它简化了测试自动化,并且可以加快测试的过程。 此外,它符合解决可以快速完成的小件工作的总体原则。 然而,像其他DevOps实践一样,这种测试方法需要与传统测试不同的思维方式,而且需要一些对某些组织来说很具挑战性的文化变革。


版权声明:

凡本网内容请注明来源:T媒体(http://www.cniteyes.com)”的所有原创作品,版权均属于易信视界(北京)信息科技有限公司所有,未经本网书面授权,不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的,应在授权范围内使用,并按双方协议注明作品来源。违反上述声明者,易信视界(北京)信息科技有限公司将追究其相关法律责任。

评论