DevOps核心实践,从敏捷文化与配置文件的困惑说起

作者介绍

DevOps是当前炒的很火热的概念,实践DevOps的方法涉及两个方面,一是如何持续管理需求、变更和及时处理用户反馈,通过工具固化一定的流程,有效的管理需求和变更。另一方面就是如何持续交付。
作为DevOps流程的核心实践持续交付(Continuous Delivery)在这其中能够为软件项目带来什么价值呢?本文将结合持续交付的具体实践展开分析与讨论。

  • DevOps是什么
  • DevOps与敏捷开发
  • DevOps成功实践需要哪些条件

王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者,曾供职于大智慧测试负责人,建立大智慧数据平台“云测试平台”。个人公众号:吃草的罗汉(kidd_w

入手持续交付

持续交付最基本的原则是:

提前并频繁地内部交付,将几乎所有事情自动化

持续交付最核心的实践是自动化,通过将每一次改动都提交到一个模拟产品环境中,使用严格 的自动化测试,确保业务应用和服务能符合预期,使用完全的自动化过程来把每个变更自动的提交到测试环境。
实现自动化的持续交付基于部署流水线模式。

图片 1

CD pipeline

部署流水线的目的是让软件交付过程中的每个人都能看到每个构建版本从提交到发布的整个过程,将开发机构的文化、流程和工具整合到一起,这也符合了DevOps的核心理念将开发机构的文化、流程和工具整合到一起
下面讨论部署流水线的细节。

DevOps是什么

图片 2

DevOps是一种持续增长、现代化的应用交付方式,强调开发(Dev)与运维(Ops)之间的沟通(Communication)、协作(Collaboration)和整合(Integration),以上三点同时也是DevOps的三个主要原则。DevOps由Patrick Debois在2009年提出,我们可以将其理解为敏捷开发环境的扩展,旨在整体加强应用交付的过程。

现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。

脚本化构建与部署

脚本化构建与部署应以迭代的方式来识别最困难的步骤,并将其自动化,沿着部署流水线,逐步完善自动化构建和部署能力。脚本化构建与部署应该遵循如下原则:

  • 为部署流水线的每个阶段创建脚本,表达构建流程。
  • 使用同样的脚本向所有环境部署,保证在所有环境上都能运行。
  • 确保部署过程是幂等的。
  • 增量式部署。

DevOps是新一代的敏捷

早在2009年,许多IT从业人员便已逐渐放弃传统瀑布流的应用交付方式,转而采用非线性敏捷方法,使每个开发阶段相对独立,并在开发周期的早期和整个时间内结合持续性的测试:

图片 3

挑战一:敏捷文化1、切换敏捷之前的过渡区

提交

提交阶段发生在像版本控制库提交代码,是流水线的入口。提交阶段应遵循如下原则:

  • Dev保证本地构建成功后提交
  • 测试不通过令提交失败,并记录错误信息,反馈Dev尽快修复,Dev对自己的问题负责
  • 提交失败后可以回滚版本
  • 降低构造测试环境的复杂性,保证测试代码整洁有效性。

这种方法允许开发人员根据持续的反馈,在应用交付至生产之前进行快速修正,从而提高应用交付效率并降低风险。此时,开发得到了优化,但在部署方便并未有太大改观,仍然遵循了传统瀑布流的方式,换句话说,虽然开发通过敏捷方法得到了风险的降低和效率的提高,但采用瀑布流方式的部署减缓着整体的应用交付,导致测试环节依然停留在整个交付过程的最后进行

这是错误的所有权分割过程。对于应用交付来说,这是一个巨大的瓶颈,一旦我们在部署时发现问题,开发人员还是需要重头来过。

对比开发和部署之间的断裂,DevOps概念在应用交付各个方面的优势是很实在的:提高效率、降低风险。

对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。

自动化验收测试

单元测试不能保证捕获所有问题,因此需要验收测试来保证软件质量。频繁的手工测试带来高昂成本,采用自动化验收测试便于频繁发布软件。
自动化验收测试使得团队成员都关注于真正的工作:业务价值,为软件能否满足标准提供了更高得信心,快速向开发团队反馈问题,便于软件大规模重构。

DevOps需要文化的转变

DevOps既非工具,亦非技术,而是一种文化的转变。对于任何类型的组织来说,变革都不是一件容易的事,变革所采用的新方法往往是极具挑战的。因此,企业首先应该明确变革可能带来的业务需求变化及挑战。企业都期望能够快速地为用户提供完美的应用和体验,但如果没有合适的工具、应用、行动,这个看似简单的目标很可能会变得极其复杂和混乱,最终导致交付失败而错过商业机会。

当企业内部人员理解一致时,DevOps将发挥出最大的作用。正确的技术、清晰的目标和一致的态度有助于落地DevOps,并实现成功的应用开发和交付。这是一个需要“齐心”和“协力”的团队工作。

不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?

非功能性需求测试

非功能需求测试包括容量、吞吐量以及性能测试。
将非功能性需求加入到部署流水线上,便于软件设计执行实验场景来帮助诊断预测问题。
对于非功能需求,过早地关注容量优化是低效且昂贵的,有可能造成过度设计,除非性能有问题,不在代码可读性上让步

DevOps需要统一的多技能团队

如上所述,沟通、协作和整合是将DevOps落地任何开发和交付环境的关键要素。建立多技能团队(如开发、运维和测试人员)可以增加巨大的收益,但没有正确的团队合作精神和态度,人才几乎是无用的。而身处DevOps之中,人们可以互相依靠,整个团队也会更加快速有效地运转,最终带来更高的客户满意度。

DevOps方法的第一步包括理解应用的开发、运维及质量保障如何相互依赖,通过跨部门的协作和交付流程中关键角色之间的开放式沟通,以提高效率、可预测性、可维护性。在整个流程的早期将这些因素整合并自动化,使得团队可以真正像“流”一样快速交付应用。

行,就按照你说的做,我写个需求规格说明书给你

好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下

……

开发结束啦,已经提测了,你问问测试吧

……

问问测试吧,什么时候可以发布仿真环境

……

又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发

……

发布

频繁地将软件发布到不同的测试环境中,能够降低发布的风险,降低上线压力。
发布过程将组织各部门联系起来:运维团队,开发团队,测试团队,技术支持团队,交付团队,促进交流合作。

DevOps是企业IT的未来

现代化的应用相对更复杂,使用多种技术、多个数据库和各种终端,DevOps很可能是应对如此趋势的唯一可行办法。

图片 4

对于长期适应于「需求 - 设计 - 开发 - 测试 - 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。

持续交付对于运维的改变

DevOps将敏捷方法引入到系统管理与运营,有两点主要原则:

  • 强调合作
  • 利用敏捷技术对基础设施进行有效管理

运维负责将代码部署到生成环境中,持续交付从一开始就让运维参与进来,两者共同的利益是
让发布有价值、稳定得软件成为一件低风险的事
持续交付的核心实践 尽可能频繁的发布 保证了这一点,从而成为了DevOps的关键步骤。

DevOps要点

以下是DevOps工程师需要知道的术语和工具:

先用迭代让业务快起来,敏不敏捷不着急

自动化环境管理

对于运维人员的工作,关键的痛点在于部署系统到不同配置的大量基础设施上,对基础设置的管理往往利用脚本管理,修改基础设施的技术也应该是发布的一部分。
将基础设施的配置自动化,纳入流水线并配置测试会大大便于运维的部署管理工作。

IaaS:时至今日,不知道公有云,不知道AWS、Azure、GCP的IT从业者几乎不存在。IaaS(基础设施即服务)供应商通过互联网在虚拟化环境中的公共连接向客户提供计算资源,包括存储、带宽、虚拟服务器、负载平衡器、网络连接和IP地址等。

PaaS:平台即服务(PaaS)使开发人员能够在基于云的平台上构建应用程序和服务。合格的PaaS产品可能需要很少甚至没有运维,支持多种架构并提供各类预置工具。PaaS提供商通过升级和新功能定期更新其服务,并向开发人员提供从源码到部署的支持。PaaS服务通常以按使用付费的方式提供。

无服务器PaaS:好雨云帮ACP

SaaS:托管在云端的应用(如即时消息、电子邮件、性能监控、财务会计)如果允许个人和组织在线轻松访问和使用。与购买包含许可限制的传统应用相反,SaaS是基于订阅的。

对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。

另一种方案,使用docker进行持续集成

在业务不断增长过程中,企业的组件也随之不断扩张,随之带来了对基础设施的复杂配置管理工作。采用自动化部署配置管理无疑产生巨大成本,使用Docker——以“容器化”的方式去部署应用。 Docker像集装箱一样,打包了所有依赖,再在其他服务器上部署很容易,不至于换服务器后发现各种配置文件散落一地,这样就解决了编译时依赖和运行时依赖的问题。
利用Docker进行持续集成的流程如下:

  • 开发者提交代码;
  • 触发镜像构建;
  • 构建镜像上传至私有仓库;
  • 镜像下载至执行机器;
  • 镜像运行。

敏捷 vs. 瀑布流

“瀑布流”是一种分离应用开发和交付各个阶段(例如分析、设计、开发、测试)并以线性方式执行每个阶段的方法。因此,项目进行不顺利的话可能会导致代码无法开发;如果某一阶段有延迟,则可能会需要缩短或省略测试和质量保证阶段;如果在测试或QA中出现问题,代码很可能需要重写。

“敏捷开发”是一种以非线性方式查看业务和软件开发项目的方法,相比“瀑布流”更有效率。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。

价值

贯穿持续交付始终的是自动化手段,这也恰恰是软件行业所追求的,自动化的交付过程带来了诸多益处:

  • 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。
  • 快速发布。能够应对业务需求,并更快地实现软件价值。
  • 编码->测试->上线->交付的频繁迭代周期缩短,同时获得迅速反馈;
  • 高质量的软件发布标准。整个交付过程标准化、可重复、可靠,
  • 整个交付过程进度可视化,方便团队人员了解项目成熟度;
  • 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。
  • 更平滑的开发过程,减少上线风险,增强团队信心。

集成和交付

持续集成(CI) - 开发人员将代码(每天多次)整合到一个共享存储库中,每个代码的独立更改都会立即进行测试以便检测和防止集成问题。

持续交付(CD) - 作为CI的扩展和增量应用交付的下一步,持续交付(CD)可确保在任何时候都可以发布在CI存储库中测试的每个版本的代码。

瀑布 迭代 敏捷,三者的差异是啥呢?

配置管理(CM)

简单来说,维护硬件和软件并详细记录(包括版本、要求、网络地址以及设计和操作信息)的过程被称为配置管理(CM)。有很多工具可以帮助我们实现CM,也可以使用Bash和Python来构建自己的配置管理自动化。

2、大家都缺乏敏捷文化

资源编排

在微服务、面向服务架构、融合基础设施、虚拟化和配置方面,计算机系统之间的协调和集成被称为编排(orchestration)。通过利用定义的自动化工作流,编排确保业务需求与IT基础架构资源保持一致。

从某种角度来讲,目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的,开发和运维部门经常会坐在一起探讨,就运维流程如何改变、自动化能力如何建设等,然而自始至终无法突破的终极问题就是:无论我们如何改变,如果万一生产环境出了问题,谁承担责任?因为DevOps能力的建设需要一个过程,开发团队不敢承诺完全承担责任;而运维因为弱化审批和控制力,也认为不该为其承担责任。最终不了了之。

容器

容器是一种轻量级、可移植、自包含的软件打包技术,使应用程序可以在几乎任何地方以相同的方式运行。开发人员在自己笔记本上创建并测试好的容器,无需任何修改就能够在生产系统的虚拟机、物理服务器或公有云主机上运行。

其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。

版本控制

版本控制包括帮助R&D维护和控制其源代码存储库中的更改的实践和工具。R&D使用源代码管理工具来记录和跟踪系统配置文件。

现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的,每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。

如果系统发生失败,例如生产环境出现问题,这必然是由于系统各个部分相互作用产生的结果,对其中任何局部进行惩罚无非是寻找替罪羊,有害而无益。这时候组织真正应该做的,是相信每一个人都已经做出了最大努力,将相关干系人拉到一起对问题的根因进行分析,找到能够有效避免类似问题再次出现的解决方案,并确保该方案得到实施,对其效果进行验证。

Bug Tracking

Bug tracker是汇总和报告软件错误和缺陷的系统,帮助R&D进行任务管理,是DevOps方法所需一致反馈循环的一部分。

这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。

测试自动化

测试自动化通过支持持续运行的多个测试来帮助测试工程师工作,它可以提高测试覆盖率,同时支持有效的释放周期,例如测试自动化工具有助于管理、执行和测量功能测试和负载测试。

单元测试 - 单元测试是允许测试人员检查应用程序的小部件(如特定代码或模块)的过程。该测试通常是自动化和重用的,以支持连续测试和集成。

再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;

监控

监控是IT绩效管理的主要内容,是运行在线服务时最重要的方面之一。监控工具至关重要,并提供关键信息,有助于在可用性、安全性和性能方面确保服务的健壮性。

应用程序性能监控(APM) - APM允许您自动检测并收到应用程序框架中包含应用程序和数据库层的热点。

基础设施监控 - 此类别中的工具会自动检测和警告基础物理或虚拟资源性能和可用性的降级。

有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定;

日志管理

日志管理(或日志分析)是处理大量计算机生成的消息的做法,可以是操作消息(例如,当跟踪服务性能或安全性)或用于BI目的(例如当跟踪在线用户行为时)。

Author Idan Zioni

然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;

好雨 - DevOps / 开发运维一体化

DevOps是一种理念,鼓励开发和运维之间沟通、协作、集成和自动化,以便更快捷、更频繁、更可靠的构建、测试、发布应用,而云帮ACP通过对CI/CD、高效运维、微服务架构等功能特性的设计和打磨,为DevOps的实现提供了一个可靠平台。

这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。

所谓敏捷文化是个啥?抄袭一张图吧,简单点:

挑战二:配置文件的困惑1、没有DevOps之前,配置文件是怎么玩的呢?

在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:

配置文件位于classpath下

使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:

如果有多个配置文件加载,则:

配置文件位于外部目录

但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:

这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。

当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:

…………

配置文件的版本如何与程序版本对应?

配置文件的管理如何更加简便?

配置文件的修改该有谁来操作?

配置文件的更新是否可以不影响正常服务?

…………

无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。

撸起袖子,不要怂,咱们搞个配置中心吧。

2、有了DevOps之后,配置文件又是怎么玩的呢?

其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。

随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具,轻松地完成升级或发布;

这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。

如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?

维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;操作风险:配置修改随意,无操作痕迹,易出错;版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?

图:配置中心在DevOps快速交付通道中

你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。

的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一

无法满足我要求的,我不接。

这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。

三种适配器

图:适配器Trade,满足原有使用Properites的诸侯们

图3:适配器Native,满足已使用过自研独立配置服务的诸侯们

图4:适配器Ccms,满足使用Key/Value的诸侯们

两种推进器

图:希望采用 “文件被动加载” 的诸侯们

图:希望采用 “Key/Value实时推送” 的诸侯们

从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。

有了配置中心,诸侯们的确享受到了福利:

配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;配置控制台提供鉴权、操作日志等服务;配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;配置发布后,实时通知应用端,无须重启即可使用;配置版本支持一键回滚;配置控制台实现了整体复制、导出、批量修改等功能;

3、小结

本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。

原文来自微信公众号:DBAplus社群

本文由澳门威斯尼人平台登录发布于服务器&运维,转载请注明出处:DevOps核心实践,从敏捷文化与配置文件的困惑说起

相关阅读