广东十一选五开奖 > 计算机网络 > DevOps定义编年史:通过DevOps定义看DevOps发展

原标题:DevOps定义编年史:通过DevOps定义看DevOps发展

浏览次数:165 时间:2020-04-05

作者简介

2017年10月【DevOps Handbook】

胥峰《Linux运维最佳实践》作者、《DevOps:软件架构师行动指南》译者2006年毕业于南京大学,2011年加入盛大游戏,十年运维经验,曾参与盛大游戏多款大型端游和手游的上线运维,主导统一运维平台的产品功能设计和实施,拥有工信部认证高级信息系统项目管理师资格。《Linux运维最佳实践》作者、《DevOps:软件架构师行动指南》译者。

DevOps是一个软件工程实践。通过开发、质量、IT运营和信息安全人员的协作,朝着一个共同的目标努力,使技术价值流通过计划工作快速投产用于满足业务和组织的成功,实现每天多次部署、达到世界级的稳定性、可靠性、可用性和安全性。

前言

图片 1

本文来自于 GOPS 2017 深圳站的演讲“在复杂业务体系中 DevOps 理论及方法的实践”。分享分为 4 个方面:

DevOps

初识 DevOps;建构组织文化;架构技术体系;案例研究;1、初识 DevOps

发展一:DevSecOps:它 的作用是扩展了DevOps的思想,通过建立每个人都对安全负责的理念,实现在不影响业务需求的情况下,敏捷地执行安全决策,并保证交付的快速可达,即每天多次交付与部署。

对 DevOps 有这样一个解释:“ DevOps 是一套实践方法,在保证高质量的前提下,缩短从提交对系统的变更到部署到生产环境的时间”,这是引用了我翻译的这本书里的概念。我们看一下这个概念里有哪些值得注意的关键点:

DevOps Handbook包括DevSecOps最新思想

我们在部署系统的时候,质量是非常重要的。我们部署的系统,你不能因为变更的问题导致业务中断,这是不可接受的问题。要求交付机制也是高质量的,就是你的交付过程。比如说你交付到测试环境,交付到生产环境里面,也应该是一个高质量的。在里面规划了两个时间周期:一是开发完成的时间;第二是把代码开发完成到部署到线上的时间。在这个定义里面强调了 DevOps 是一种以目标作为导向的,它并没有强调我们采取什么样的形式的实践,或者使用什么样的工具。目标并不限于 DevOps 用于测试和部署的实践,它其实是把整个流程都包含在里面。

北京老李讲DevSecOps,我们惠州见:)

我们看到在 DevOps 的定义里面,最主要的一点还是讲到从代码开发完成到上线的过程。这也是行业内对 DevOps 理解比较多的一点。

DevSecOps新一代IT管理方法

这个图来自企业 DevOps 白皮书,这是对 DevOps 理解的一个扩展。相对于前面说的那个概念,它讲到从开发到部署的过程,但是在这个图里我们可以看到,它其实是把流程进行了前置和延伸。

发展二:AIOps:也就是基于算法的IT管理,是由Gartner定义的新类别,使用数据科学和算法正在被用于自动化传统的IT运维任务和流程。算法被集成到IT管理工具,帮助企业进一步简化工作,把人类从耗时又容易出错的流程中解放出来。AI发展从已知到未来,这条路刚刚开始,还有很远的路要走。

比如说计划、需求、设计,以及后面的运维过程,它都把它纳入到 DevOps 流程里面去了。这其实是讲一个什么东西呢?一个产品或者一个业务有了想法之后,它就会进行下面这样的流程,从这个图里面我们看到,它强调的是价值交付的过程。

AIOPS刚刚开始,这也是未来

从产品和业务来讲,它开始有些想法在里面,怎么通过技术手段、流程,快速的把这个想法变成一个产品,变成在实际场景中投放给客户的产品,这是一个价值流的过程。

2017年09月

只有当你的想法真正投入到里面去的时候,它才产生价值,你做的计划也好,你做的开发代码也好,在没有投放到生产之前,其实对用户来讲是没有任何意义的。

DevOps是一个软件工程实践,旨在统一软件开发(Dev)和软件操作(Ops)。DevOps运动的主要特点是在软件构建、集成、测试、发布到部署和基础设施管理中大力提倡自动化和监控。DevOps的目标是缩短开发周期,增加部署频率,更可靠的发布,与业务目标紧密结合。

上面这部分主要是讲这个流程,在下面我们可以看到,其实它核心的理论支撑是精益和丰田生产系统。我们在整个流程中需要非常关注的一点就是持续改进的过程,不管我们现在的流程是什么样的,或者说你已经做到什么地步了,其实都是有一些可以改进的方向,包括这个精益也是告诉我们要持续不断地做一些改进。

2017年07月

2、建构组织文化

DevOps是一个软件开发和交付过程,它强调在整个价值流中产品管理、软件开发和运营专业人员之间的沟通和协作的方式,它在整环境中建立一种管理文化和环境。包括集成、测试、部署和基础设施变更等方面实现自动化和测量,通过构建、测试和发布实现软件的快速、频繁且更可靠地交付。

在这里面我想强调一点,不管 DevOps 的定义是什么,它都是一个价值流的交付。从产品或者是业务的想法开始,把它快速地、高质量的交付给用户。但是在实现 DevOps 的过程中,很重要的一点是文化。不管组织的类型是什么,大部分组织都是惧怕变化的,所以采用 DevOps 这个新方法论可能是极具挑战的。

2017年06月

在构建组织文化的过程中,需要关注三个主要的原则:沟通、协作、集成。在这里面要强调一点,我们现在各个部门在协作过程中,可能还存在一些部门利益冲突的问题,这也是一个很现实的问题。

DevOps是一种开发和软件交付过程,它强调在整个价值流中应从概念到业务,包括产品管理、软件开发和运营等方面,建立沟通和协作的方法。在自动化的过程中实现软件集成,测试,部署和基础设施的改变。它的目标是建立一种文化和环境,通过构建、测试和发布等方法,可以更快速、频繁地、更可靠地发布软件。

另外一个就是我们要倡导一种免责文化,大家都说运维背黑锅,这个其实是不对的,关键的一点是我们是以价值流交付作为一个整体的目标,倡导一种对事不对人的工作态度。

2016年11月

我们在构建组织文化过程中要注意四个方面:

DevOps是一组实践,用于强调软件开发人员和其他信息技术人员的协作和沟通,同时自动化软件交付和基础设施变更的过程。它的目标是建立一种文化和环境,通过构建、测试和发布等方法,可以更快速、频繁地、更可靠地发布软件。

第一是团队内的协作;

2016年09年【EXIN DevOps Master课程体系】

第二是团队之间的亲和性;

DevOps的目标是建立流水线式的准时制(JIT)的业务流程。DevOps旨在通过合适的准时制业务流程来最大化业务成果,例如增加销售和利润率,提高业务速度,或尽量减少运营成本。

第三是要使用一定的工具来加速流程的落地;

EXIN DevOps全体系课程

第四是伸缩性,随着组织规模的扩大, DevOps 流程也要做相应的变化,

2015年11月

大家想想在我们的组织内部,是不是有这样的一些问题,我们在传统的开发、测试、运维过程中是什么样的情况?开发把代码丢给测试去测,测试测好之后,又把这个包丢给运维部署到现场,中间可能有相关的文档,这本身就是一种筒仓思维的表现。

DevOps是一种文化、运动或实践,它强调软件开发人员和其他信息技术人员的协作和沟通,同时强调自动化软件交付和基础设施变更的过程。它的目标是建立一种文化和环境,通过构建、测试和发布软件等方法,可以快速、频繁地、更可靠地发布软件。

筒仓思维的英文叫 Silo,它就像是在沙漠里面,或者是大型的场地里面有这样一个个存储物品的仓库,每一个都是独立、封闭的个体,它们之间是没有沟通的,它们的利益也都是有冲突的。

2015年09月

这里讲一个小故事,我们原来有一个同事是来自国企的,他是做财务的。有一天他跟他的领导说,我们现在很多的工作还是手动的,我们是不是可以引入一些自动化的计算机系统来做这些事情?领导就问他,这样做有什么好处呢?他说,我们可以节省很多人力。

DevOps是一种软件开发方法,它强调软件开发人员和其他信息技术人员的角色。

领导说,节省人力不行,你节省人力了,我这事就没有人管了。大家有没有理解这个意思?就是说在体制内,领导比较关注他的权力的分配,而不是说从整体角度提高工作效率。

2015年05月

还有一个与之类似的例子,在上海有一家基金公司,我有个同事去那里应聘,当然级别也比较高,他发现他们在部署的时候还是手工去部署的,有几个同事专门做部署的工作。

DevOps是一种软件开发方法,它强调沟通、协作、集成、自动化、测量,以及软件开发人员和其他信息技术人员之间的协作。DevOps承认软件开发、质量保证和IT运维之间应相互依赖,旨在帮助组织快速生产软件产品和服务,并提高操作性能。

他就想去推动这些自动化部署的工具,但是他的领导说,我们还是要手工去布,这样的话领导才会重视我这一块,你全自动化了,把我隐藏起来了,我这个经理就没用了,这就是很明显的筒仓思维。

2015年03月

包括我们在运营一些产品或者业务的时候会发现,开发和运维之间互相踢皮球的事情,这也是一种筒仓思维。比如说开发肯定是要求快速上线,而运维要求稳定,大家的利益产生了冲突,这必然会对我们的价值流产生负面的作用。大家可以想想我们生活中或者是在工作里面是否也有这样的筒仓思维的表现。

DevOps是一种软件开发方法,它强调沟通、协作、集成、自动化,以及软件开发人员和其他IT专业人员之间的合作度量。

我们在构建 DevOps 的过程中,必须要打破这种筒仓,形成合力,让大家围绕价值流一致的目的共同努力。

2015年01月

3、架构技术体系

DevOps是一种软件开发方法,它强调软件开发人员和其他IT专业人员之间的沟通、协作(信息共享和web服务)、集成、自动化和测量的方法。DevOps认为软件开发和IT运维之间应相互依赖。它的目的是帮助组织快速生产软件产品和服务,并提高操作性能和质量保证。

在构建组织文化过程中有三点:沟通、协作、集成。集成肯定是一种自动化集成,而不是说手工对接的过程。这就要求我们在开发、测试和运维整个链条里面,在每个环节上要能实现一定程度的自动化,不能说没有对应的运维自动化系统来对接前面的需求,完全是通过公开的形式去做发布、部署,其实是不符合快速交付这样一个理念的。

2014年12月

关于自动化运维这一块,我可以简单说一下我们盛大游戏是怎么做的。大家知道盛大游戏目前是国内比较领先的游戏发行公司,它创立的时间比较早,在1999年这个公司就成立了,到目前已经有18年的历史。

DevOps是一种软件开发方法,它强调软件开发人员和信息技术人员之间的沟通、协作和集成。DevOps是对软件开发和IT运维相互依赖的集成。它旨在帮助一个组织快速生产软件产品和服务。

它现在面临的问题,在运营方面主要表现为几个:一是服务器操作系统异构;另外一个是我们的服务器数量特别多,在高峰期的时候,我们的服务器达到2万台的规模。

2014年9月

因为每一个游戏代理过来的时候,游戏的开发商(比如说美国、韩国、日本)服务器的偏好不一样,面对这样的挑战,我们在实现自动化集成的过程中,我们是怎么构建自动化运维平台的呢?

DevOps是“开发”和“运维”的合成词,包括软件开发、运维和服务。它强调软件开发人员操作人员、信息技术之间的沟通、协作和集成。DevOps是对软件开发和IT运维相互依赖的集成。它旨在帮助一个组织快速生产软件产品和服务。

从这个图可以看到,我们有一台中央控制机器,它从 CMDB 里面读写数据,根据不同的服务器的类型和操作内容,把这个命令分发到对应的服务器上面去。

2012年5月

我们可以看一下这里面的几个特点:

“DevOps”是一种多用途的开发和操作的方法,用于针对软件开发方法。强调沟通、协作和集成软件开发(应用程序/软件工程)和操作(系统管理/基础设施)的专业人士。它是为了快速响应业务和客户的需求,改善IT部门间的沟通,加快IT组织交付生产软件和服务的目标

第一,我们这个平台是采用 BS 架构的,不需要在电脑上装软件,现在在家里都可以操作,完成这个运维任务;

2011年3月

第二,我们使用的是通用的协议来管理着所有的异构系统,比如说我们在 windows 下面,大家知道以前管理 windows 是比较困难的,现在有很多公司在这一块也是依靠手工去操作的,这样会很麻烦,也有可能造成一些遗漏或者是错误的过程。

DevOps是一种新兴IT管理的原则、方法和实践,开创了新一代IT管理运行方式的变革,通过增加部门间的交流、协作和集成,使得软件开发(应用程序/软件工程)和操作(系统管理/基础设施)的专业人士可以,快速响应业务和客户的需求,通过行为科学的改善IT各部门之间的沟通,以加快IT组织交付满足快速生产软件产品和服务的目标。

对于 windows 管理,我们也是采用了 SSH 的方法去做,这样就可以让所有服务器以相同的方式管理起来,比如说它们的安全策略,公钥和私钥的管理,另外还有一些审计,都可以内置在这个操作平台里面。

2010年9月

关于自动化运维平台这一块,还要注意做一些并发的设置,以及超时和重试的机制,都需要考虑到里面去,不能因为一些顺序的执行,某台服务器的故障,或者是连接服务器的问题,导致它无法连接,导致整个任务延迟。

DevOps是一组流程、方法和沟通系统的统称,用于开发(应用程序/软件工程)、技术操作和质量保证(QA)之间的部门集成协作。它涉及新兴的管理思想的发展和业务相互依赖的关系,以满足企业及时生产软件产品和服务的目标。

现在我们在做另外一个系统是作业编排系统,如果知道 Ansible playbooks 的话,可以看一下它的方式和方法。我们知道 playbooks 是通过声明一些配置项,然后把它编排起来,把所有的人工分类的步骤做进一个配置里面,让它顺序执行。

2010年5月

比如说我们做游戏维护的时候:

DevOps是一个新的术语,用来描述对IT组织开发和运营的相互依赖的关系,用于满足企业及时高效性地交付软件产品的目村。

第一步,是先把服务器上的游戏服停掉;

DevOps是一个重要的理论,它通过敏捷、精益等新在方法在一个传统的组织中,把独立的部门例如:开发人员、IT运营和QA部门等人员协同在一起实现跨部门集成,而不像以前一样,开发、部署、QA是完全的分离管理,建立更加紧密的多部门协作。DevOps不仅仅关注软件部署这一技术问题,它是考虑部门与部门之间沟通和协作的管理方法。

第二步,停数据库;

2009年10月【Patrick Debois】

第三步,更新程序;

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

第四步,还要更新数据库的一些表结构;

來源:简书

第五步,把前面的游戏服务器启动起来,或者数据库启动起来;

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

通过一些作业编排,就能更大地减少这个运维的重复劳动的过程,它的理念其实是基于场景的自动化运维。我们可以想想在运维过程中有哪些工作可以串联起来,这样你就不需要对着一个文本的东西去做,因为你在对着它做的过程中很容易造成遗漏。

比如说你做游戏维护的时候,没有把前面的关闭,你就直接维护数据库了,这时候可能会导致玩家数据丢失的情况。通过 playbook 编排系统,就可以避免这个事情,它是固化的,没有办法绕过前面的步骤去进行后面的操作。

4、案例研究

刚刚说过,大家在不同的行业里面,在不同的业务里面,它对应的发布方式还不一样,我相信目前我们在座的,系统里面也有一些人是用手工发布的方法上线。我知道一个比较大的公司,它的部署也是很落后的方式,因为它前面有负载均衡,它布的时候还是要登一些脚本,把负载均衡上的东西剔除,然后再更新,它需要更新多个脚本,这是很浪费时间和精力的过程。

看看我们以前面临的问题。这是我们的某个平台,主要是支付相关的。大家知道我们除了游戏服务器之外,还有相关的登录、认证和计费的平台。我们第一个选取的案例是在支付平台这边做的一些 DevOps 实践。

随着公司业务的发展,日积月累,你这个模块可能会越来越多,部署了之后会有测试,测试了之后交给运维,但是测试的模块名和运维的模块名可能是不一样的,这里面存在一个协调的问题。因为有人工协调的过程,不然导致这个部署需要排期,原来部署和测试系统是割裂的,它们之间没有对应的关系。

我们是怎么改进的呢?现在已经做的工作是:

第一,我们建立在部署流水线上不同环节的模块对应关系,首先把它映射好。比如说测试和运维这边的部署系统,它们之间的对应关系要映射到数据库里面去,这样就可以实现从前端出发的部署动作。第二,后端的部署系统,它需要提供对应的功能接口。比如说它需要上游的系统提供一个模块对应哪些服务器的接口,当上游需要部署某个模块的时候,它就知道在测试环境里面需要部署哪些服务器,在正式环境,灰度发布的时候需要先部署哪些,再部署哪些。第三,建立对应的授权机制,我们可以把部分模块的授权前置给开发上线,或者是由运维从内部平台直接部署上线,取得的效果是非常明显的。在2016年12月份的时候我们做了一个统计,当时有900多次的部署,其中50%以上通过新平台自动部署,大约10%的模块可以由开发自主上线,不涉及到核心功能的,开发简单测试一下就直接上去了。非核心模块的部署,我们可以在5分钟内完成,不再需要一些配置管理员进行上线的排期和编排。

这是我们部署的系统的界面,它会选择对应的版本,选择你是灰度发布,还是部署到生产环节里面,这个动作很多情况下已经不需要运维去做了,直接测试完成之后就可以上线了,这时候就把运维的工作解放出来了。

这是我们的部署过程,对于自动部署,银行和金融机构有要求,开发和运维要分离,我们现在做的是让开发和测试都可以上线。

我们的底层部署是通过配置一些项目,比如说模块对应的目录、配置文件、执行脚本,对应的用户,这个用户主要是指启动程序时的用户,以及对应的某个模块在不同的服务器上的IP列表,这些都会在系统里面进行相关的配置,这样配置之后就可以对前面的系统进行相关调用。

这个案例也告诉我们一点,我们在进行部署设计的时候,暗含了对架构的要求。

这里简单介绍三点:

第一,模块化,可独立部署,微服务有一个类似的概念。如果你是一个大一统的体系,你很难集中发布这个东西,你还要协调很多资源,如果你做成模块化,你自己上线,不影响他人,通过接口去调用,对自动部署是非常有好处的;第二,重试机制。作为一些后端的服务,它在部署的时候,不应该影响前端的调用服务,前端的调用服务必须有一些重试机制,失败的时候要能够重连,这应该集成在调用方的架构设计里面,如果没有重试机制,肯定是会影响业务的,这也没办法达到高质量交付的目的;第三,负载均衡与多实例的应用。这里也讲到,如果你的某一个功能只有一个模块,你在部署的时候,不管它的时间窗口是什么,你必然会影响业务,有些请求会丢掉或者是失败。通过负载均衡和多实例的方法,就可以包括你在部署部分服务器的时候不影响前面调用的结果。总结

DevOps 的目的是打造持续增量的价值流并杜绝浪费。我曾经有一句话「任何不以消除浪费为目的的 DevOps 实践都是假的 DevOps」,我们实践 DevOps 的目的,是实现从一个想法到真正把这个想法形成产品、形成服务,提供给用户去用的流程。

缩短这个过程的时间,提高这个过程的效率是 DevOps 实践的一个最重要的目的。我们要让每一个步骤,每一个过程的价值都是递增的,而不是说产生等待,或者说产生依赖,比如对配置管理的依赖,对人员的依赖,这都是有悖于这个目的的。

所以我把这句话送给大家:DevOps 的目的,最重要的一点就是加速高质量的交付,提升用户价值。但是在实践过程中,我们可以从各个子环节的自动化流程作为一个起点,很多时候你可能没办法一次性把整个部署流水线构建那么完美,我们就可以分析是不是在每个子环节里面已经实现了足够程度的自动化。

比如说自动化发布,现在是不是还是要靠人工去操作,这些是最基本的动作,做好这些之后,你才有能力或者有条件和上下游进行对接。只有完成的每个环节的自动化之后,我们才有可能去构建整个部署流水线。

也就是说我们在落地的时候可以想想整个业务流程里面的痛点,比如说你是部署没有完成自动化,还是测试没有完成自动化,导致了这个流水线没有办法流传下去。然后以每个环节的自动化作为一个开始,然后把它们集成起来,就可以实现整个价值流的快速交付。

文章来自微信公众号:高效运维

本文由广东十一选五开奖发布于计算机网络,转载请注明出处:DevOps定义编年史:通过DevOps定义看DevOps发展

关键词:

上一篇:我们都被骗了,所有的跨平台迁移都可以通过X

下一篇:没有了