到底该怎么领悟DevOps这几个词,你真正通晓呢

作者: 万金

  1. 以下问题有没有解?

“如何实施DevOps目前正成为众多企业迫切面临解决的问题,本文作者刘相,有10多年的从业经验,他结合自身企业实施DevOps的经验,梳理出DevOps在企业的组织、技术、流程等方面的最佳实践与价值,以及如何搭建DevOps平台来支撑DevOps的落地工作。本文内容包括:

编辑:济萌

“快速将产品推向市场” 与 “提供稳定、安全并可靠的IT服务” 是否可以兼得?

  什么是DevOps及误区

作者简介

用更少的资源完成更多的业绩,既要保持竞争力,又要削减成本?

  DevOps企业实践

万金ThoughtWorks 高级顾问

10年+知名外企与中国企业的IT从业经验,包括IBM,华为,中兴,Thomson. 具有7年云计算相关经验,多系统的研发和运维经验,熟练掌握敏捷和DevOps方法论和实践,具有软件研发生命周期工具与流程改进丰富经验。

如何解决任务交接出现的问题,例如业务与开发,开发与运维之间?

  DevOps架构支撑

序言

运维人员能否和其他人一样,正常上下班,而不用在夜里或者周末加班?

  实施DevOps价值

在软件吞噬时间的时代,在IT基础设施多样性与分布式趋势中,部署的复杂性与规模日益增加,而大部分的软件崩溃都发生在部署过程中。目前提高部署效率与稳定性成为了一个严峻的挑战。本文讨论在原生云应用的场景下如何将软件高效稳定的发布到用户手中。在本文的末尾会畅想智能运维给软件发布与运维工作带来的新能力。

  1. 什么是DevOps? 众说纷纭

  老司机简介刘相, 来自普元,十年IT行业经验,专注于企业软件平台。在SOA、分布式计算、企业架构设计等领域有一定了解。著有《SpringBatch批处理框架》一书。

本文的四个部分:

WikiPedia上说:”DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解。“

  欢迎扫描二维码加入由作者主持的“普元云计算研发开放群”,讨论更多微服务、DevOps、容器相关内容,加群暗号“DevOps”。

数字化转型的趋势与挑战;软件发布的各种坑;云原生应用如何发布软件;下一站智能运维。(一)数字化转型的趋势与挑战1.1.分工协作提高效能达到增长极限

百度百科说:“DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营 和质量保障部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。”

  什么是DevOps及其误区

如果说到DevOps的精益,就不得不说亨利•福特将流水线引入到汽车生产当中。为什么要说流水线呢?我们在传统企业转型中所使用的成功经验,在现代数字化转型的环境里没有办法继续复制成功。

IBM这样说:DevOps是企业必备的持续交付能力,通过软件驱动的创新,保证组织抓住市场机会,同时减少反馈到客户的时间。

  DevOps概念从2009年提出已有8个年头。可是在8年前的那个时候,为什么DevOps没有迅速走红呢?即便是在2006年Amazon发布了ECS,微软在2008年和2010年提出和发布了Azure,DevOps的重要性似乎都没有那么强烈。我分析其原因主要有:

原因主要有以下几点:第一,单一产品的竞争优势被行业外颠覆:传统汽车产品积累了多年的竞争优势,在电动车出现后被颠覆。比如特斯拉,不使用机械引擎,竞争优势不再可持续。

  1. DevOps不只是开发与运维的问题

  第一个很重要的原因是因为那时候云计算还是小众产品,更多的与虚拟化、虚拟机相关,它们还是重量级的IT基础设施。

第二,低价高质不再是客户选择的关键因素:消费水平提高和体验差异导致成本竞争不再是竞争的主要因素。相同的东西只要便宜一分钱都可能造成市场份额的巨大差距。如果一款手机卖十块钱会有市场吗?在同学聚会的场合你会用十块钱的手机拍照发朋友圈吗?这种赋予商品的个性标签属性,使得价格为主要竞争手段的情况已经不复存在了。

一般而言,开发与运维有着不同的文化;开发部门的驱动力通常是“频繁交付新特性”,而运维部门则更关注IT服务的可靠性和IT成本投入的效率,降低风险。两者目标的不匹配,在开发与运维部门之间造成了鸿沟,从而减慢了IT交付业务价值的速度。运维从维稳出发,自然希望生产系统部署上线次数越少越好,而上线频度降低,对开发人员是一个负激励:反正我发布的版本也不会上线,反正我再积极也不能实时的体现出来,团队积极性和人员士气都会受到打击。

  第二个很重要的原因是容器相关技术(Docker为代表)还没有横空出世,直到2013年7月。

第三,人的延伸价值观局限。现在的主流产品,可以参考结婚时候需要的几大件商品。现在的住房里需要的大家电数量都是有限的,并且每一个电器品类的市场容量都是有限的。世界就就这么大,人口就这么多,市场总量也是有限的。如果业务已经达到饱和,还有什么办法可以扩大市场?一个企业如果没有增长是个非常大的问题,如何来刺激业务持续增长成为新的挑战?

与此同时,业务部门则希望业务需求尽快的推向市场,而维稳的要求导致价值交付用户的速度被延缓,价值无法迅速得到反馈验证。

  第三个很重要的原因是,Martin Fowler在2014年3月提出了Micro Service,这为DevOps的推广也打了兴奋剂。

1.2.追求个性化用户体验带来新的增长

当发布列车变成3个月一趟车次时,业务人员习惯于自己的需求无法快速得到满足,能想出的的方法就是把所有的业务需求都设置成最高优先级,去抢占发布窗口。所有人都这样想这样做,拥堵就此产生,真正高价值的需求无法得到快速交付。(试想,如果每天有十次发布,大家还会拼得头破血流去抢一个发布窗口么?)

  可以看出,当前DevOps概念的深入人心,离不开云计算、容器/Docker、微服务、敏捷等相关概念和实施的成熟发展。

怎么解决市场增长乏力的问题?答案是追求个性化的体验,因为人的体验有无穷多种。女生都有这样的感受,衣柜里永远都缺那么一件衣服,就是你明天要穿的那一件衣服。我们买衣服并不是买纺织品这个产品,我们买的是穿衣服的体验,或者我们买的就是我有很多衣服的感觉。

上线频度低的另一个副作用是,单次上线中包含的变更规模变大,风险也随之增加。事实上,减少上线次数不仅不会降低风险,反而让每一次上线都变得像一个火药桶,危机四伏。

  另外,随着互联网对传统企业的冲击,需要更快的业务试错与业务创新,其背后本质是企业IT的精益运营,让软件的生产、交付、获取、升级、遥测变得自动与自助,近两年,DevOps在传统企业也开始备受关注与各种尝试。

硬件和软件的分离就提升了软件的使用体验。以前IBM的邮件软件使用体验不是很好,作为IBM的员工自己也说 Lotus notes 邮件软件使用体验不是很好。这个是没办法的事情,在市场充分竞争的情况下,一个有着优秀硬件基因的公司很难同时把软件做到最好。展开来说,一个公司很难让服务于消费者的终端手机生产与销售业务做得很好;同时也在服务于全球前50的运营商的电信设备市场也做得很好,并且2B和2C同时成功。这样的的成功非常少见,即使是诺基亚做到的也只是暂时的成功。

  1. 从大处着眼

  对DevOps的理解,可能千人千面。先来看下对DevOps的狭义理解。

服务与产品的分离,也提升了使用体验。就是说,做产品但不把这个产品直接卖出去,而只把产品提供的服务租出去。比如亚马逊的云计算,亚马逊拥有这个云计算的平台,但是只以云计算的方式给客户提供服务。对于卖硬件服务器的厂商IBM、戴尔、惠普来说亚马逊卖的服务是不一样的体验,有不一样的体验就带来新的市场。

究其根本,DevOps目的是提升业务交付能力:如何快速的交付想法;如何让客户进行尝试;如何快速响应客户反馈。

  图片 1

业务与实现分离,提供了比内部所提供的服务更专业,更便捷。这样就有了IT外包市场,一个企业如果生产一个产品或服务的成本高于采购成本就会采购该产品或服务。只有当自己生产一个产品或服务低于采购成本才会自己生产该产品或服务,甚至向市场提供该产品或服务。

DevOps不应该只是IT内部的几个部门玩的游戏。必须跳出IT的角度,端到端分析,才能弄清公司需要依靠IT的哪些工作来支撑业务目标,支撑企业战略 ,从而实现更完整、真正的DevOps。

  维基百科对DevOps的定义比较拗口。其实往简化里讲DevOps是提倡开发和IT运维之间的高度协同,从而在完成高频率部署的同时,提高生产环境的可靠性、稳定性、弹性和安全性。

使用与拥有的分离就是共享经济。由于维护一辆自行车比较麻烦,人们可能不会买一个自行车,但可以通过刷一下手机直接得到自行车交通服务。消费者买的是这种交通服务,把存放,维修,防盗的事情交给共享单车公司。

需要将IT变成一种能力,融入公司的日常运作中,融入业务活动中。在快鱼吃慢鱼的时代,需要快速试错,不断整合来自市场的反馈。

  从另外一个维度,广义上来说,DevOps不仅需要打通开发运维之间的部门墙,我们认为DevOps更多的需要从应用的全生命周期考虑,实现全生命周期的工具全链路打通与自动化、跨团队的线上协作能力。

我们说软件架构来自于建筑的概念,但是软件研发的过程和建筑施工过程有着非常迥异的地方。对于建筑来说,工程师有了图纸后就确定完工后的样子,即使换一个开发商结果也没有明显区别。而对于软件研发过程来说,我更愿意类比原型车的开发。当一个原型车设计完成,到买到这个原型车的量产车型,你会发现它们之间有很大的差别。这就是软件的特点。即使按照软件设白纸黑字签下合同,当拿到软件发布时使用时候,由于技术与业务的不确定性,实际软件与设计阶段差异很大。

所以最终,DevOps是一个端到端的问题,是产品管理部、开发部、测试部、IT运维部、信息安全部协同工作,共同支持。

  图片 2

总而言之,企业把一部分业务外包出去,满足个性化用户体验,在这个过程中产品/服务价值获得了提升。

图片 3

  第一,纵向集成,打通应用全生命周期(需求、设计、开发、编译、构建、测试、打包、发布、配置、监控等)的工具集成。纵向集成中DevOps强调的重点是跨工具链的「自动化」,最终实现全部人员的「自助化」。举个例子,项目组的开发人员可以通过DevOps的平台上,自主申请开通需要的各种服务,比如开通开发环境、代码库等。

1.3.传统行业面临数字化转型的两个挑战

DevOps尝试建立一个业务价值交付管道,业务规划、需求梳理、计划、开发、构建、测试、部署、运维、监控 ,在此交付过程中涉及到的部门、过程、系统、方法都归属于DevOps关心的内容。

  第二,横向集成,打通架构、开发、管理、运维等部门墙。横向集成中DevOps强调的重点是跨团队的「线上协作」,也即是通过IT系统,实现信息的「精确传递」。

数字化转型对传统企业会带来哪些挑战?以下两点揭示了答案所在:

  1. 从小处下手

  举个例子,传统的系统上线部署方式,可能是一个冗长的说明文档,上百页都有可能,但在DevOps的平台下,就应该是通过标准运行环境的选择、环境配置的设置、部署流程的编排,实现数字化的「部署手册」,并且这样的手册,不仅操作人员可以理解,机器也能够执行,过程可以被追踪和审计。

第一点,从内部看是通过互联网的工具提升内部协作效率。比如说:减少沟通的成本,并进行可视化以及各部门之间的信息共享和协作,提高这种协作的效率。

理解了DevOps是一个端到端的过程,整个交付链条涉及太多的领域,问题也层出不穷,无从下嘴。实际操作中,需要有一个切入点。

  DevOps是通过工具链与持续集成、交付、反馈与优化进行端到端整合,完成无缝的跨团队、跨系统协作。

第二点,如何把握用户需求。这分为两点:首先是精确。在不同场景下人们需要的产品是不一样的。比如:早上起来打开微信我可能看谁更新了什么东西,而晚上可能要看还有什么事情没有做完。一个产品在不同的场景、时间、地点、环境下所需的特性是不同的,这就是需求的准确。其次是准确。其实很多时候为什么我们的客户都不知道自己要什么?因为一般的通用的需求完全被满足了。这是一个生产过剩的时代,你要挖掘客户的需求,通过不断与客户沟通,去了解客户心里说不出的潜在需求,然后通过跟他不断地互动,达到他在那个时间那个场景下相对可以达到的服务。

DevOps的思想以精益与敏捷为核心,通过暴露问题,解决问题,从而实现持续改进。从精益的角度看,在代码投产之前,实际上未产生任何价值,都只是半成品。 要限制半成品,即在制品数量,让其尽快流过生产线,让投入产生交付价值。

  在团队使用DevOps时,存在误区是必然的。在我们同大量的客户交流中,大致有这几种误区认知:

(二)软件发布的各种坑

DevOps是一个复杂问题,我们希望可以把一个复杂的问题简单化:正如装修时通过加压检查管道是否泄露,是否有阻塞;我们也通过加压的方式来暴露软件交付管道的问题。

  图片 4

本章节主要是介绍一下软件发布过程中各种坑。上图可以简化地去看第一块,即:Codebase。所有的代码和分支都在代码库中。

如何加压?以终为始,我们选择业务价值交付的那个点,也就是部署与发布来对整个交付管道进行加压。

  没有使用云相关产品(IaaS、PaaS),组织很难开展DevOps;

第一个动作是Build,研发人员工作最终结果是以软件包的形式交付一个可以运行的软件环境。

可以简单的问自己一个问题:“能不能一天部署10次?”如果没有办法,那么原因何在?流程不规范?自动化不够?沟通导致效率低下?过程无法复用?环境差异导致回归出错?逐一的暴露问题,解决问题,交付能力自然提升。

  微服务架构开发的应用适合DevOps,传统SOA应用不适合;实施DevOps和应用架构无关,无论是微服务架构,还是SOA类型应用,都可以开展DevOps工作;

第二个是Verify,测试人员所有的工作都是在众多可运行的软件中找到达到发布质量的软件。

  1. 通过加大部署/发布频度来撬动整个交付过程

  认为将一组自动化工具的运用等同于DevOps的成功,那就太小瞧DevOps了。采用自动化工具本身不是DevOps,只有将这些工具与持续集成、持续交付、持续的反馈与优化进行端到端的整合时,这些工具才成为DevOps的一部分;

最后是将软件发布到生产环境中去。

以应用部署自动化作为切入点,由部署自动化,往前倒逼测试自动化、构建自动化;进一步往前,配置管理、变更管理是基础要求;再往前,业务需求与敏捷计划同步关联,通过短周期迭代交付与反馈,加强业务与开发的协作沟通;

  设立独立的DevOps团队是很多组织开启DevOps之旅的另外一个误区。事实上,如果这么做,将会导致更多的竖井。在责任没有清晰定义的情况下,成立这些团队,会创造更多的混乱,不要试图把。

上面各种复杂的分支、构建、和可以测试的环境,下面是研发,测试,和发布,只有达到质量要求才能进入下一个环节。这个过程里面其实有非常多的手动的工作,就导致了在研发过程中很多低效和没有必要的动作,或者不产生价值的动作。怎么去识别,如何避免研发过程中这些复杂的过程不会影响最后的Release?

同样的,往后端与运维衔接,更小、更频繁的变更,需要让开发人员更多地控制生产环境,更多地以应用程序为中心来理解基础设施;需要定义简洁明了的流程,尽可能地自动化;从而在完成高频率部署的同时,提高生产环境的可适应性,与此同时,可靠性、稳定性、弹性和安全性也同时提升;

  DevOps不仅仅是自动化。毫无疑问,自动化是DevOps非常重要的一部分,但不是唯一的部分,一定程度的部署自动化往往会与DevOps混为一谈,实施DevOps需要从敏捷、持续、协作、系统性、自动化五个维度进行建设与改进。

那么对于上述过程,我们可以简单的理解为以下三点内容:

由此也促成了开发与运维的协作,通过不断缩减批量规模,实现快速工作流,确保了部署环境时刻准备就绪,按需投产。频繁的发布、意味着每次发布包含的变化更少,每次部署不会对生产系统造成巨大影响,应用程序会以平滑的速率逐渐生长。逐步协调和弥合开发与运维之间的技能鸿沟和沟通鸿沟。

  在DevOps实施过程中,团队经过总结积累,制定了团队的DevOps宣言,支撑团队从敏捷型组织转向DevOps(企业敏捷)。

1. 软件编译复杂:• 软件编译第三方依赖关系复杂;• 多技术栈解决方案复杂性高;• 多分支并行开发策略复杂;

  1. DevOps要实现:自动化、标准化、配置化

  图片 5

2. 测试经历软件测试环境类生产境等迁移:• 测试环境搭建;• 测试数据准备;• 界面测试无法自动化;

自动化:全面自动化,构建、部署、测试、升级、扩展、维护、数据卫生、监测、安全和策略管理。通过自动化,倒逼团队高效沟通,倒逼流程规范。自动化手段确保部署任务的可重复性、减少部署出错的可能性。

  DevOps企业实践

3. 软件发布过程无法保证不出问题:• 发布流程与过程时间长;• 手动或配置过程导致发布失败;

标准化:基础环境标准化,运行环境标准化,应用环境标准化/多样化 。

  实施DevOps的核心目标是加速团队、企业的IT精益运行,从根本上提升IT的生产效率,加速部门、企业的业务创新能力。让团队从IT支撑部门,转向为IT创新部门。

打个比方:原来研发几个月的产品,最后上线的话可能要持续两三天上线。这就像看一个美剧连续剧,我看了一年的连续剧到年底要出一个电影版,在最后的电影版里哪些环节没有做,哪些环节铺垫的不够好,都会在剧场版里发现问题。如此复杂的过程要在短的时间内重现一遍,这就是发布容易出现问题的根源。所以一个版本研发的功能越多,最后部署的风险就越大。发布过程就是把手动的过程全部重新再现一遍,所以非常容易出错。

配置化:通过配置,尽量避免代码,通过功能开关或者参数设置,来支持A/B testing、灰度发布。

  实施DevOps过程中,需要从组织、技术、流程三个维度进行持续的优化与改进。

(三)云原生应用如何发布软件3.1.Application Pass项目背景与挑战

  1. DevOps实践

  图片 6

首先,说一下Application Paas的项目背景。我公司的客户是欧洲的汽车制造企业。其中一部分的IT项目是外包给了供应商,这样就会有很多的问题。因为这个外包做这个项目,那个外包做那个项目;所以不能有效把过往的项目整合起来形成合力。

不做什么比做什么更重要:相比起向系统中投入更多的工作,将无用的工作剔出系统更为重要;无用的工作,无用的项目,无用的产品;排优先级,哪些是重要的工作。

  实施DevOps,可以参考总结的“DevOps实践模型”,从组织、技术、流程三个维度中选择关键的活动项进行最佳实践活动。

客户的痛点是,缺乏新技术新平台的运营能力。随着项目的增多,管理成本也会增加,管理一个供应商和管理十个、一百个带来的复杂性差异是巨大的所以成本奇高。在全球上线多个供应商研发的不同销售系统,其运维复杂程度可想而知,同时也很难实现功能的快速开发和上线。

运维参与研发评审:常见的现象是,运维人员很少被邀请参与架构决策或代码评审,开发代码是否会影响运维环境前期无人知晓,需要让运维人员参与架构评审,从运维角度提出对系统的要求。

  可以梳理出目前团队中欠缺但又容易改进的点,逐步将更多的实践活动纳入团队当中。团队实施DevOps的目的在于,将重复、价值低的事情交由DevOps平台实现,让团队成员做更有创新、更有价值的事情。

最后就是之前说到转型的最后一个挑战:我们如何掌握最终客户的需求。我怎么和客户互动?我们不是通过人工发放调查问卷,而是要通过平台的方式收集相关信息。这有利于研发出符合多样化的用户需求,并且成本可接受的产品。

非功能性需求同样重要:偿还技术上的债务。每个人都像重视功能性要求一样重视非功能性要求QoS(质量,稳定性,可维护性,持续性,可扩展性,可管理性,安全性,可操作性),非功能性需求对于实现业务目标同等重要。要把非功能性需求设计到产品当中。

  根据我们的实施经验,在传统企业中,技术方面的实践最容易在团队中实现、流程次之、组织的优化与变革最为艰难;大家尝试的时候,可以由易入难。

3.2.DevOps软件研发实践

整体协作:产品所有者,开发部,QA,IT运维部以及信息安全部通力协作,帮助彼此乃至整个企业取得胜利。

  图片 7

对于下DevOps实践来说,其中最主要的实践是要做自动化的部署。首先要建立信任,并提供可见性。运维人员收到一个版本,却不知道是新增的功能还是只是一个补丁。如何能让运维人员安心的部署到生产环境中去呢?通过开放监控给研发人员可以提高修改缺陷的速度的,最后是让大家的上下文一致,让研发和运维工作在同一个上下文中。通过相同的考核指标要求研发与运维人员来达到相互配合相互信任的目的。

质量为先:上游团队不再给下游团队造成麻烦,开发部将20%的时间用于帮助确保工作顺利的通过整个价值流,加快自动化测试,改进部署基础架构,并确保所有应用程序建立有用的产品遥测;

  组织方面

然后是文化。首先要尊重工程师的文化,要有责任共担。一些创业的企业主说遇到的最大的问题就是:招聘的研发人员只管开发代码,上线的稳定性和他们无关,这个就没办法玩下去了。最后就是试错,因为没有人可以保证软件转换一个环境就一定好用。我们如何从错误当中学习,或者说可控的失败。在不会造成很大风险的错误当中学习,让我们的软件从长期的角度来看既具备功能快速上线能力又有高可用性,这就是我们最终的目标了。

基础架构即代码(Infrastructure as a Code):把创建和部署流程自动化,把基础架构当成代码一样对待;各套环境之间,代码版本、运行时、环境配置需要匹配;需要将基础环境配置化、版本化管理。

  全栈团队:按照RDT(需求、开发、测试)模式组建交付小团队(团队中以虚拟的方式将交互设计、运维、DBA包含进来),团队大小按照「两个披萨原则」进行组建。全栈团队负责整个项目从需求、开发到上线运维的全生命周期管理,打破部门的篱笆;

3.3.部署与功能分离:从项目到平台

运维服务化:DevOps会让开发部门承担更多的代码部署和维持服务水平的责任。要求把许多IT运维任务转变为自助服务。

  特性团队:基于特性的交付意味着工程团队将构建最终产品的特性;让团队关注价值交付,减少团队依赖,打破职能团队;

本小节主要一下思路:

版本化一切(Versionlize Everything):应该把所有东西都进行版本控制,不只是代码,而是创建环境所需的每一样东西。

  技术方面

平台部署能力与项目功能的分离。开始我们讲了很多的分离,如软硬件的分离。而现在来说的是部署与功能的分离。比如:CRM软件。为什么不能把软件的部署抽取出通用的部署能力,并通过不断的迭代来升级平台的部署能力呢?满足平台上每一个项目的自动化部署,这样就提升部署的体验。对于研发和运维来说,这种要求的体验是不一样的。因为对于研发来说,要具有应对变化的弹性和适应性。在金融行业里有很多的规则需要满足,流程需要弹性,不能违反红线规则。每个研发的检查点,转到下一个流程规则是什么,都需要要满足。运维在生产环境需要稳定性,又要随时可以上线新功能,对于研发的适应性和运维稳定性要求都需要满足。3.4.Dev和Ops需要两个PaaS平台

ITIL:为了适应DevOps更短的交付周期和更高的部署频率,ITIL流程的很多方面都需要自动化,特别是变更、配置和发布流程等。

  集成工具链:打通应用应用开发工具链:需求、项目、代码、构建、测试、打包、发布、配置、监控;

就如上图所示的一样。对于Dev和Ops来说,他们需要两个PaaS平台:Application PaaS平台和Production PaaS平台。一个负责适应性一个负责稳定性。

云计算:有效的利用云技术,可以为开发和测试人员动态设置基础架构资源,快速获得测试环境。

  基础设施即编码:将基础环境服务化、可编程化,基础设施让项目团队可以自助获取;让基础设施从物理机、虚拟机、走向容器;

3.5.Application PaaS架构

针对类生产系统进行开发和测试,利用可重复的可靠流程进行部署,监控并验证运维质量。

  一键编译、测试、部署:开发人员可以从代码开始,一键获得可访问的环境,根据需要可以推送开发、测试、预发、生产环境;

从Application PaaS的架构的角度来讲,底层是的资源层对接云计算资源层。在这上面,我们可以构建两层虚拟网络。在研发虚拟网络中的里,我们有Web层和App层,其实就是对Jenkins做封装。在App层有代码管理,自动构建,环境管理,软件包管理,发布管理,部署管理的核心能力工具。

放大反馈回路:快速反馈回路,防止问题代码进入生产环节,并且让代码能够迅速部署投产,从而迅速发现并修复任何产品问题。(编写代码时,单元测试、集成测试、验收测试一直在类生产环境运行,不断确认,代码和环境奖会按照预先设定的运行,并且总是处于可部署状态)。

  ChatOps:开发以及运营人员在内的团队成员将沟通、工具和过程整合在一起的协作模型。基于对话驱动开发,将工具植入对话中,保障团队能够自动执行任务与协作。最近比较流行的hubot可以认为是ChatOps的探路者。

这么多的核心功能,通过Web层的代码流水线与用户互动。核心能力在下面,融合下面的核心能力,通过Web层定制来满足客户的多样化的需求用以实现适应性。为了保证生产环境稳定,需要把研发和运维要分开,前面是研发的PaaS,后面是运维的PaaS。在运维PaaS下面是监控和洞察的核心能力。

  1. DevOps与云

  流程方面

3.6.开源技术选型实现

DevOps要支持云,虚拟化与云技术可以带来DevOps要求的标准化以及自动化。

  看板:在DevOps中不能仅仅把看板当做任务协调沟通的机制;把看板作为在制品管制平台,量化组织生产能力的工具;

我们公司的客户还有一个需求就是不能被技术绑定;同时还要引入一些多样性,在相同的团队使用不同的工具去完成任务。为了达到这种灵活性,我们可以选择一些开源软件。这就是我们在做这种咨询的时候,会给客户提供的可定制性,也是客户对Thoughtworks的认可的一个原因。

环境标准化,无论是基础设施还是运行时环境,并把这些环境投入开发、QA和IT运维的日常使用,就能消除大部分在部署流程中因为差异而导致的问题。不仅应该拿出可部署的代码,还应该拥有部署这些代码的确切环境,并在版本控制中一并控制与检查。

  MVP:采用MVP(最小可行产品)原则,快速拥抱变化。最短时间内快速交付产品原型,然后通过测试并收集用户的反馈,快速迭代,不断修正产品,最终适应市场的需求。

3.7.试验性发布-灰度发布关键环节

混合云下的DevOps诉求:在云的场景下,如何利用虚拟化、容器等加速环境的创建以及标准化,如何通过自动化的方式加快环境搭建;如何在On-Prem、私有云、公有云,不同厂商不同类型的云的混合模式下,统一流程,统一DevOps的用户感受。

  发布:建立持续发布机制,形成自动化、自助化两种能力,支持常见的灰度发布、金丝雀、蓝绿、回滚、A/B测试等;

首先,说一下灰度发布的定义。它是在从0到1平滑过渡的方式完成软件发布,有点像蓝绿部署,也有点像金丝雀发布,对客户是有筛选的分流机制。最后可以达到让我们在安全的环境下让软件发布的风险在可控的范围内,这样做不能保证不出错,但是会把出错的影响降低到可控范围内,并不会对生产环境的用户造成影响。

同时,由应用层的自动化部署,同样可以发现Infrastructure层, Runtime层的问题,虚拟化与云的技术也与DevOps相辅相成,相得益彰。

  软件度量:通过软件度量(包括过程度量、质量度量、用户度量、成本度量),推算出组织的各种有效指标;一则掌控组织的生产力水平,二则通过度量数据,反向优化组织瓶颈点;

对于灰度发布,有这样的三个环节:

  1. DevOps与精益、敏捷

  一切皆代码:文档(用户故事、用户场景、功能特性等)、配置(应用配置、环境配置、脚本等)、环境(基础设施、中间件环境等)、发布包(二方库、三方库、部署包)需要统一看待成代码,纳入版本管理,同时建立5者间的关系,提供全视角的链路追踪。举个例子,每个发布的版本,可以追溯其对应的配置,代码、文档,发布的功能点。

应用监控数据;用户分流规则;递进发布策略。3.7.1.应用监控数据:Kibana应用监控

DevOps是基于敏捷与精益原则的方法。DevOps是软件开发生命周期从瀑布式到敏捷再到精益的发展。

  组织、技术、流程三个维度中,技术、流程可以通过平台或者工具进行最佳实践的固化。

的监控考量。

DevOps超越了敏捷,它的关注点是从SDLC中移除浪费。通常情况下,发现浪费或者瓶颈的形式包括:不一致的环境,人工的构建和部署流程,差的质量,IT部门之间缺少沟通和理解,频繁的中断和等待,部分完成的工作,额外的功能,任务切换等。

  基于此,我们规划了DevOps平台,支持广义的DevOps,帮助客户快速实现DevOps建设。

首先是功能测试阶段。功能测试阶段提交到生产环境的边缘节点环境,但是没有真实客户上来。这个阶段会监控错误请求的返回。比如我测试阶段有没有反回404这样的错误,没有错误的话我们就进入下一个阶段。

博明信德作为业内领先的企业级管理系统和解决方案供应商,利用容器云PaaS平台和Docker容器技术,能够解决持续集成/持续发布的问题,打破开发和运维团队之间的障碍,提高应用开发、部署、维护效率。通过统一界面,管理应用和集群,可随时监控每一个应用,集群,主机的运行健康状态,快速实现 DevOps,为客户提供高效快捷的应用交付和安全稳定的运维服务。

  图片 8

然后是兼容性测试。兼容性测试主要是测试接口是否有正确的返回结果。

目前,博明信德开发运维一体化平台已在国资委、财政部管辖的128家大型央企中得到了广泛应用,行业涉及金融、能源等领域,赢得了客户的深度信任和广泛好评,应用效果显著。

  平台建设第一步,梳理出DevOps的整体概念模型。从角色、规划设计、开发交付、运营反馈四个维度进行梳理。

最后在性能测试阶段,对比新旧版本的性能延迟数据。如果不存在性能恶化的现象就可以全网上线了。

  以产品为核心,将代码、配置、环境进行严格分离,同时覆盖产品全生命周期。

整个灰度发布过程从功能测试到兼容性测试,再到性能测试,在生产环境下逐步地升级扩大范围的过程,就是来保证在安全可控的前提下来做灰度发布,做到对客户零影响。

  这里面概念看似简单,其实很多:比如:部署包=介质包+配置,这和传统的CI和CD体系就有点不一样;

3.7.2.用户分流实现:k8s边缘节点

  再比如:环境分开发、测试、预发、生产,我们觉得即使公有云上,也应该给客户将这些做物理或逻辑隔离,因为大家的配额需求不一样,容器replication需求也可能不一样;

对于用户分流实现来说,我们要使用K8S边缘节点的能力,用它作为生产环境持续交付的最终环境。有人会问:持续交付直接到生产环境中,那么你真的敢上线吗?上线之后对客户有影响怎么办?解决办法是:我们用前端的负载均衡把边缘节点的用户流量屏蔽掉,不会让真实客户进来。这个实践与之前的类生产环境是不同的,它真的是生产环境的服务器,配置完全一样;但是区别是没有真实客户使用。

  再比如:运营反馈,既然要做DevOps,那整个过程导出都应该可以有检查点插入,为运营提供有效数据,我们把检查点至少分成了四类,包括过程的、安全的、性能的、业务的。

通过功能测试,性能测试环境,然后我们来一步步把最新版本升级到全网。首先边缘节点环境用来做自动化功能测试。通过了功测试后,在新版本和旧的版本共存的情况下测试兼容性的问题,最后兼容性没有问题的话,就进入下一步性能测试阶段,直至全网发布

  DevOps架构支撑

3.7.3.递进发布:Kubernetes滚动升级

  图片 9

最后,本小节从总体解释灰度发布的三个阶段:

  基于领域模型梳理DevOps平台业务架构,目前共建设18个领域系统来支撑,比如:软件产品的管理、软件各阶段环境的管理、质量的管理、部署包、二进制包的管理、资源管理、监控中心、认证中心等。

Phase-0 进行功能测试,当发布包通过持续交付测试环境的验证后,部署到生产环境的边缘节点。配置发布包在生产环境下测试是否能正常工作,这是生产环境下安全地做持续交付的方式。Phase-1我们来做兼容性的测试,要做数据的隔离。举个失败的例子,某个网站在做生产环境上的测试时,真的产生了购买两百台洗衣机的订单,并且快递员打电话要求收货最后是性能没问题了,我就慢慢滚动部署到全网环境了。

  每个领域系统严格按照AKF扩展立方体的Y轴进行拆分,采用微服务架构模式进行平台建设。

总结一下,灰度发布是什么?在生产环境最小范围内没有真实用户流量情况下,验证功能问题;以及在较小的范围内,验证兼容性和性能问题;同时是在控制范围内保障用户体验。那么在验证功能,兼容性和性能之后我们再全网发布。这样就大大降低了风险,提高发布质量。

  “DevOps业务架构”,是我们基于对企业IT管理的理解,所进行的平台化设想。从图里还可以看到,红色字部分,是我们对现有DevOps的落地实现。

而以前的传统发布过程是非黑即白的过程。如果功能,兼容性和性能出现问题会直接导致对所有用户造成影响,造成严重的后果。那么通过灰度发布方式把风险控制在可接受的范围内,才是实践落地的可行性方案。

  Portal(DevOps门户),自研,提供给用户使用的统一操作门户,包括用户管理、产品看板、产品全生命周期(设计、开发、测试、预发、生产、监控、故障处理)管理等;

3.8.通过平台能力开放,从单一产品竞争走向生态竞争

  IAM(身份识别与访问管理),自研,提供用户身份识别和访问控制的能力,包括用户管理、Token管理和用户授权等功能;

下图讲述的是:通过生态,大家的合作来达到整体的价值提升。比如:有做平台的公司,有做平台上特定业务的公司,有去把握这种用户需求销售产品的公司。有了很多最终服务客户的公司之后,反过来平台也不断发展壮大,同时用户的体验也得到了提升。

  SPM(软件产品管理),自研,提供产品、组件的基准定义和管理能力,包括产品类型、产品管理、组件管理、依赖产品管理及产品投放市场等功能;

为什么要有一个平台?现在有很多开源的或商业的技术,但是多的技术能不能为你所用呢?答案是依靠简单的集成是不能满足企业要求的。因为企业有很多的限制条件,我们要把这些限制条件定义成平台的流程和自动化的过程。这样平台构成了引入技术的能力,就是我们的第一个客户挑战。

  SCM(软件配置管理),自研,提供产品、组件配置管理能力,包括配置项的定义和在各个不同环境下的配置信息的管理维护能力;

有一次客户对我说:我们不太担心Thoughtwork的技术顾问解决不了客户的问题,而是担心当顾问完成工作后自己的外包员工技术水平搞不定这些新技术,这才是客户最担心的问题。那么很多客户的普通员工或者外包人员如何掌握新技术呢?答案是通过平台降低新技术推广的难度。

  SRM(软件资源管理),自研,提供产品和组件自动编译、打包和部署的能力,提供部署模板管理,支持编译和部署流程编排,编译和部署进度跟踪以及日志查看;

总之,通过Application Paas平台,公司内部团队来控制业务的方向;然后,把业务的实现和交付外包给在这个平台上的供应商。这就提升了业务实现和交付的体验。

  SEM(软件环境管理),自研,提供租户和产品环境资源配额、负载均衡,以及运行容器的管理能力,包括租户可用资源的配额,以及基于租户资源的产品和组件在各种环境下的资源配额(如开发环境、测试环境、生产环境等等)和负载均衡;同时,还提供运行容器的创建、销毁、调度、复制以及持久化卷管理等能力;

举一个小团队控制业务方向的例子。一家服装企业”韩都衣舍“,负责设计团队只有三个人,一个负责广告,一个负责设计服装,一个负责后面的与制造平台对接。这个团队如果能设计出爆款的话,一年几百万的奖金就拿到了。当然你要有平台,在制造效率提升的前提下,才能来满足服装市场不断化的多样化的需求,以及用户的精准的需求。

  QAF(质量保证反馈),自研,提供产品的质量管理和监控能力,包括测试用例管理、缺陷管理、质量监控等;

再则,公司存在的意义是什么?公司存在的意义是:如果产品的生产成本低于购买成本那就自己生产;但是,如果采购成本低于制造成本,那就采购,这就是公司存在的意义。比如说Kubernetes,我需要对资源进行调度,但是我们不能自己做出一个Kubernetes。因为那是不可能的,这是谷歌擅长的事情,那么我们就外包出去。我们就做最核心的业务,这是公司存在价值;你做的成本一定比别人低,这就是你存在的价值。

  UMC(统一运维中心),开源集成、借鉴自研相结合,提供统一的监控、预警、故障处理等能力,包括系统日志和业务日志的监控,产品的资源使用情况和运行情况监控,故障定位等。

这是某国内大型通讯公司公有云实验性发布的方案,在全球大概有二十多个数据中心,它最关键的实践是包管理。而,我们之前讲的都是在一个数据中心的内网发布一个软件。

  VCS(版本控制系统),开源集成 ,主要以GitLab为核心,不直接提供GitLab的原生界面,所有功能在统一的DevOps上提供;提供源代码库管理的能力,包括代码库的创建、维护,分支的管理和用户权限控制等;

在全球范围如何实现灰度发布?首先是策略,也许在不同的地域里面业务都是不一样的,那么软件包也是不一样的。这要有更高一个层次的考量,并不是做了灰度发布之后,就可以在一个数据中心或者在所有的数据中心上线。这是需要有一个统一的考量,也是全球化带来的改变。把业务差异从应用逻辑中分离到数据中去,就可以实现应用的全球灰度发布了。

  CI(持续集成),主要以Jenkins为核心,使之成为以API为主要使用方式的服务,提供持续集成任务调度和执行的能力,包括集成任务管理、编译、打包等;

(四)下一站智能运维

  BPR(二进制介质仓库)),开源集成,主要以nexus为核心;提供二进制包仓库的管理能力,包括二进制包、文档等编译产物的上传、下载和存储访问等;

最后,在本节让我们畅想一下智能运维的未来。当说到智能的时候,我们谈的到底是什么呢?在丹尼尔•卡内曼的著作《思考快与慢》中提到了一个概念,我们的大脑有快与慢两种作决定的方式。

  DPR(可部署介质仓库),自研,主要存储可部署的介质,其主要区别是注入了与环境相关的配置(这种部署模型是很适合没有上Docker或者容器,以虚机为主的IT基础设施或者物理机);

这两种思考系统:一个是不需要思考的;比如我和一个人交谈,很容易就可以感觉到对方的情感的变化——这是人情感的感知,不需要思考就知道。看电影不需要思考就知道这个电影是不是一个烂电影,这就是人的经验,不需要思考就能快速得出结论的思考系统。目前计算机并不擅长这样思考系统,因为计算机的计算力和成本很难满足这样的系统。

  PM(项目管理),自研,可以与常见的PM管理工具对接与集成,提供产品的开发过程的管理和协作的能力,主要包括:任务计划、人员分工和过程跟踪、看板等;

第二种是需要逻辑思考。比如:查看监控数据,找到故障记录,分析原因和关联性,最后解决问题。这个过程非常慢,但非常有效。它的正确率也很高,缺点是这样思考大脑会消耗大量能量。对于人工智能来说第二种思考系统正是计算机所擅长的。我们从第二种思考系统方式以及从数据的计算、数据关联分析、系统的相关性入手解决问题。

  MOC(API模拟),开源集成,为REST API调用提供模拟能力,以便产品或组件在开发调试期间可以脱离依赖、减少阻塞、单独运行,支持根据Swagger和Mock数据发布Mock Rest Service,支持用户私有的MOCK数据;

这里需要阐述一个问题:牛顿发现了三大定律,通过这三大定律推论得出物质运行的规律。但是,问题在于从科学研发到改变生活的周期和成本都是非常巨大的。就像沃尔玛要规划如何摆放货物就有一个很好的实践,啤酒和尿不湿只要放在一起就能卖得很好。还有像阴天时候甜品和蛋糕就卖得好。对于这些关联性不需要知道科学原理,只要按照这个结果去做就可以提高我们的销售额。那我为什么要知道原理呢?也许当了解了原理之后,就像那个啤酒和尿不湿的销售关联性在中国已经失效了,中国的父亲在买尿不湿的时候不会去购买啤酒。那么,一般情况下,掌握关联性并运用到实际的工作中就能获得收益。

  DOC(API文档),开源集成,提供REST API/SPI文档的自动生成能力;

4.1.软件研发流程的数据化和个体在线化

  TM(租户管理),自研,提供租户管理的能力,包括租户管理、邀请码管理和租户配额等功能;

软件在研发过程当中会产生很多的数据,比如需求实现的时长、发布频率、部署前置时间,稳定性,部署成功率、应用错误率等。上图是业务相关的数据,比如性能、用户体验、用户增长、用户满意度,转化率、流失率等。如果我们将上述这些串联起来,比如说有一个客户想花三千万获取新客户,如果性能不好的话,流失率就非常高;但是性能变化提高20%的转化率,那么价值就直接可见了。

  IM(即时沟通),开源集成,提供产品设计、开发、测试、运维等相关人员间的协作沟通能力,支持群组聊天、离线消息推送、聊天记录查询和导出;

4.2.人工智能的作用

  啰啰嗦嗦,罗列了18个核心的领域系统。

软件在开发过程中有三个特点:1.软件设计的不确定性。我们都知道拿到了软件设计文档并根据这份设计文档来生产的软件并不一定能有效果。因为,现实中进行交付软件时,如果客户说还可以,但是,要求加一个功能,才能通过验收。这不是加一个功能的问题,其实是委婉否定了你前面所有的软件的价值。

  图片 10

2.质量的不可见性。对于软件快速上线来说,如果你加班的话,短时间也能通过测试并上线;但是,短时间的测试没有办法能测到所有的问题。因为一个好的软件是写出来的,短期测试没有办法保证软件的质量。

  逻辑架构整个DevOps平台分为三层:

3.价值的不透明性。对于价值的理解,就要说到我们大脑如何理解做事情的意义,我们生活的改变速度远远超出大脑的进化速度。比如一个原始人,他们做一面镜子的意义就是用来打扮。但是,每天的软件研发工作却无法映射到最终上线上去,那么这就显得没有多少意义。长此以往会对工作失去不断改进的动力。

  基础设施层:包括IaaS,CaaS,我们分别是基于OpenStack和Kubernetes、Docker的,上层有一层不同环境的适配;

那么对于上述问题,我们能不能通过人工智能对以往同类项目的过程数据,制定出一条明确的研发过程。使得在研发,测试和发布的工作中,每个人都清楚的感觉到自己的工作对最终的产品起到的意义。那么,这种人工智能数据化的方式就会给我们生活赋予意义,这就是我能想到并且能做的事情。

  基础服务层:包括服务管理与调度的基础能力,如注册中心,编排,伸缩漂移;还有一堆具体的企业级或互联网式的云服务;

人工智能从研发和运维过程中收集的大量数据入手,寻找关联性使得工作的过程和结果直接产生联系,从而连接了研发与运维再到业务成功的链条,提升软件研发过程的可预见性,为业务成功打下坚实基础。

  DevOps层:更多的是工作流程(需求、设计、开发、测试、发布等)的串接,看板等文化的体现;

原文来自微信公众号:DevOps时代

  图片 11

  在整个平台研发过程中,采用了是自己开发自己的模式,即使用上一个发布的平台作为生产线,支撑下一个版本的产品研发工作。自己交付自己可以带来两点好处:

  平台交付客户前,自己先把可能的坑趟掉;

  当前生产线所有不能满足的功能,视作下一版本的需求(实际操作过程中,我们仅允许使用wiki作为辅助工具来支撑生产线未满足的需求);

  所以可以拿一些数字估算一下当前的规模。在研发过程中,把DevOps视为一套业务平台,目前规划的领域有18个,如果每个领域中再有多个以微服务架构落地的系统进行支撑,预计总共支撑DevOps的系统,就会超过50个。同时提供Mock、开发、测试、预发、生产5类环境(每类环境中可能还会有多套,比如集成测试、性能测试、全链路测试)。

  当前版本的DevOps,整体的部署规模将超过200个集群,部署的进程实例总数也会轻松超过500个。需要注意的是,500这个数字,还没包含技术平台中的一些分布式中间件,比如缓存、消息队列等等集群。

  不过,500映射到企业内IT人员自己用的平台,这个数字,对于不同的企业,可能是个天文数字,也可能只是九牛一毛。

  实施DevOps价值

  图片 12

  在部门实施DevOps之后,我们团队有显著改变:

  在团队组织上,每个团队小而自治且是全栈团队,沟通、技能互补,每个团队负责独立的领域系统,目标感非常明确,团队在走向使命型组织;

  项目的从原先线下协作、沟通,统一到统一的DevOps平台上协作、沟通;团队成员可以随时了解项目进展全貌,利用平台可以做到各种过程数据的实时收集(举例,比如需求变更、任务延期等);

  资源管理由原来专职人员,过渡到开发人员实现自助化服务,可以按需实现各类环境申请与开通,基础设施即服务提供来技术的支撑;

  从原来的邮件文化,到DevOps平台统一沟通,同时DevOps打通多个工具链路端,任务分发、沟通、提醒可以实时推送;

  最后给大家奉上DevOps成熟度评判指标,在践行DevOps时,可以从运营效率、IT服务水平、组织效能、客户价值、经营业绩五个维度进行评判,持续优化与改进。

  图片 13

本文由澳门威斯尼人平台登录发布于服务器&运维,转载请注明出处:到底该怎么领悟DevOps这几个词,你真正通晓呢

相关阅读