一个真实的devops演进过程是啥样的? -买球官网平台

4顶
0踩

前几天听老王分享,提到关于devops在国内外的发展问题,其中就说到早期腾讯做运维时,那个时候也没什么意识是devops,其实就是在变态的业务体量下面一步步做出来的,后来国内devops的概念火起来了,才发现原来这个叫做devops。

挺有意思的一个话题,听老王讲完,也很有感触,所以分享下我们自己的运维(devops)演进过程,有点长,但是会比较完整,看完或许有收获奥:)

第一阶段,只有dev,没有ops,dev是全栈工程师

如何理解?最初的时候,产品和业务形态都处于摸索期,业务复杂度不高,访问量不大,软件能够尽快跑起来推向市场是最重要的,所以架构上不设计的很复杂,单体或分层架构足矣。如下面典型的lnmp架构:

服务器和网络设备数量也就是两位数规模,最最一开始个位数也有可能。所以几个开发同学在简单架构下,维护几十台服务器还是没问题的所以,这个时期确实不需要运维工程师(但是并不意味着没有运维的事情),这个逻辑同样适用于测试。

现在很多startup公司,直接在云上使用docker部署模式,对于基础设施就更不用投入太多精力去维护,所以这些公司都会讲我们的研发团队比较单一,只有开发,没有运维和测试,所有的事情开发都可以搞定。

第二个阶段,dev ops,但不是devops

一个业务发展良好的公司,第一个阶段肯定不会停留太久,毕竟业务在发展,甚至是高速发展,不然公司肯定就没什么前途了。

伴随着业务发展,业务复杂度升高,开发需要将更多的精力放到更多更快地需求实现上,也就是集中精力写代码;同时业务访问量增加,后端设备数量也增加起来(一定时期内堆机器还是可以解决不少问题的),达到几百上千这样的规模,维护的工作量也就上来了。

所以很自然的,这个时候就需要ops这样的角色来管理和维护设备,同时对于db、缓存、web服务器、存储以及cdn这样的通用基础服务也适用这个逻辑。概括一点说,除了写代码,运维最好能把所有之前开发干的事情都干了。

这时ops的主要职责:硬件维护、网络设备维护、dba、基础服务维护等。

我也是在这样一个阶段进入到现在的公司,我觉得在这个阶段上,我们的意识还是比较好的,比我当时的意识要超前很多,运维团队已经具备工具开发能力,并有了类似机器资源管理、php发布系统、监控等一些工具平台,以及一些非常高效的自动化脚本工具。所以,这个团队从一开始就崇尚能用技术解决问题就绝对不靠人的理念。

但是运维的注意力仍然聚焦在上面提到的基础设施和服务层面,而且运维开发在做的事情更多的是自给自足,也就是满足运维团队内部的工具需求,当然也有一部分原因是受限于当时的技术架构,规模和复杂度有限,运维能做的事情也有限。

所以这个时候是dev是dev,ops是ops,还没有做到dev和ops的融合

第三个阶段,仍然是dev ops,但是ops开始组建运维开发团队

这里有个技术架构演进的背景,就是从单体 分层的架构,向服务化架构演进。随着业务复杂度的提升,所有代码和逻辑都放到一个工程里的结果就是下图:

这时耦合严重,牵一发而动全身,开发效率日渐低下,所以要做的事情就是一个字,拆(专业说法:服务化拆分),如下图所示:

这时,大量的应用被拆分出来,对运维自动化、持续发布、稳定性的要求就随之而来,所以ops开始正式组建运维开发团队来做有规划的、系统性的提升效率和稳定性方面的事情,这个时候的运维开发团队支撑的需求方有两个,一个是运维内部,一个是开发,因为运维会配合支持开发做很多事情,所以很多情况下运维的需求一定程度上就代表了开发的需求,但不是完全代表。

运维内部的需求主要是资源分配、扩缩容、应用管理、域名、vip等的管理需求,开发主要是持续交付的需求,两者共同的需求就是监控、容量管理、性能管理、链路跟踪等等。这些具体内容,之前有部分文章分享过,这里就不细说了。

还是说说这个阶段devops存在的一些问题:

第一个问题,也是我们遇到的最大的问题就是,运维开发是脱离实际运维工作的,这个团队的定位还是要从运维这里承接需求,然后开发实现,并不实际参与运维工作,再加上运维开发自身也会有一些独立的想法或者带着之前的经验在设计开发,所以对于现状下的运维工作理解是不够深入的。同时,运维同学自身也不是产品出身,一开始也很难按照产品化的思维模式表达清楚自己的需求,往往就是现实工作场景的口述,所以表达的更像是一个个功能点的堆砌,而不是系统化的建设思路。

所以这里始终就会有个gap。结果上,最直接的体现就是运维开发做出来的工具和平台没法很好的满足运维的需求,甚至过程中也会出现一些矛盾,比如运维抱怨运维开发没能很好地实现需求,做出来的东西不好用,甚至是没法用,运维开发也会抱怨运维需求没提清楚,或者说辛辛苦苦做出来的东西运维不用,辛苦都是白费。

所以你看,一个团队并不是有了运维开发和运维自动化就万事大吉了,还会涉及到一些团队管理和运作模式上的问题。

而且现实中,有很多公司的运维开发团队是独立的,运维和运维开发不是同一个主管,甚至不在同一个组织架构下,这样就很容易出现上面说的这个问题。

这里根本原因还是目标不一致,运维是需要一个平台能把自己的事都干了,但是运维开发更多的是考虑你给我提什么需求我做什么需求,目标是做完需求,而至于好不好用,不是最重要的事情。

稍好一点的运作模式,运维和运维开发在某个具体的项目上形成虚拟团队,这个团队的目标和考核方式一致,如果运维和开发的效率得不到提升,团队的整体绩效就会受到影响,至于考核方式和一些细节就不详细说了。记住一点,就是目标一致的情况下,大家才会朝一个方向使劲,事情做地才会更好。

最好的方式,吃自己的狗食,eat your own dog food.

ops去做运维开发,运维开发去做ops,这样也就不存在需求传递的过程和gap了,自己做出来的东西自己用,运维开发可以更深刻地理解运维工作,而不是天马行空地凭空yy。

这样可以让彼此能够站在对方的角度去考虑问题,也就不会有什么抱怨和指责了。

我们当前模式是虚拟项目组模式,好在运维和运维开发团队都在统一团队中,这样可以省去大量沟通成本,目标也可以相对容易达成一致。同时,我在做的一个尝试就是上面说的,ops有一部分员工要去做运维开发的事情,运维开发要去做运维的事情,后续应该会把两个团队逐步融合。

总结下第一个问题,我们可以看到不光dev和ops之间会有协作问题,哪怕是运维团队内部的开发,在配合上也会存在问题,这是个细节问题,需要团队管理和项目运作上做一些优化。

第二个问题,就是运维开发和业务开发团队的协作问题,第一个问题可以通过内部沟通和协作的方式去改进,但是对外,只能强调服务意识,这里就一个判断原则,如果你做出来的东西,开发都不用或者意见很大,那只能说你的工作完成不到位,或者在合作协作上是有很大问题的。

第四个阶段,真正的devops,dev和ops融合

当ops的能力沉淀到一个个产品平台之后,原来开发依赖运维的人去干的事情,就可以自助地依赖运维平台去做了,也就是日常运维由开发自己做,而不再依赖运维这个环节,真正实现devops。

典型案例就是持续交付做好之后,开发完全可以自助发布,全程无需运维介入。

所以,判断一个团队是不是devops模式,有一个很简单的原则,上面也提到了,如果运维做出来的东西开发用不上,那就不要叫devops,或许你做的只是运维自动化而已。

我们都可以用这个标准去对照下,答案不言而喻,不信可以试试:)

当然,我们自己也还有很多地方做的不够完善,只能算是这个阶段的过程中,还没有完全达到。后面我们会争取把所有目前运维在做的事情全部沉淀到平台上,让开发自助完成,甚至做到让开发做到开发-发布-再开发的模式,完全不用考虑后端的事情,当然路还很长,必然也会很曲折。

像阿里,做的就更极致,目前就已经不存在pe(应用运维)团队了,原来的pe要么转型去做devops产品设计或开发,要么就面临一个很残酷的现实,被淘汰。可以预见,阿里未来应该也不再会招纯运维岗位,未来只有开发,可以提升研发效能的开发人才。

国外像netflix和amazon是压根就没有运维这样的角色,运维的事情都是由开发工程师来完成,所以他们也戏称sde是someone do everything。

所以,运维转型不是一句吓唬人的话,真的已经在我们身边发生了。

最后,说一下我们真实的经历

在上面这些过程中,现在总结下来是一个devops演进过程,说实话,我们当时并没有devops、持续交付或者sre等等这些概念的意识,摆在我们面前的就是一个个很现实很实际的问题,当时的状态也是一脸懵逼,比如我们采用了java的技术栈,做了服务化拆分之后,非常现实的问题就是你怎么做发布,开发整天盯在运维屁股后面,你们怎么能把发布效率提升上去,你们能不能快点,业务在后面催着上线呢,你们怎么解决我的分批发布不停服问题,你们怎么管理好我们的分支合并和版本管理问题,你们怎么管理好我们的二方包和三方包等等,再比如,出了故障,一群人堆到一起一点点排查,而且有时候找不到问题在哪儿,业务都恢复不了,压力山大到要崩溃,所以到底怎么能提升稳定性、提升排障的效率也是都是一个个非常非常现实的问题。

我们能做的就是从实际问题和业务场景出发,优先解决紧急的、棘手的问题,然后不断地通过业界的图书、社区文章、会议和大牛学习、交流和探讨,不断的完善,再就是招聘到有经验的人,这样可以少走很多弯路,最后也就这样一步步做成现在这个样子了,后来才发现,原来我们这个差不多也可以叫做devops了,虽然还有很多可以改进和提升的地方。

所以为什么一开始提到说听老王的分享很有感触,说完上面这些实际情况,我们会发现其实过程和经历都是相似的。

虽然这篇文章蹭了devops的热点,但是我通篇都没有讲或说devops理念或方法论的东西,所以最后,还是表达一下观点,技术发展和积累都是被业务给逼出来的,实实在在解决问题才是正道,从本质上说,我们没有什么特别之处,只是比较幸运,正在经历这样一个过程而已。
  • 大小: 136.5 kb
  • 大小: 82.7 kb
  • 大小: 115.6 kb
  • 大小: 111.4 kb
  • 大小: 104.4 kb
来自:
4
0
评论 共 1 条 请登录后发表评论
1 楼 2017-10-22 20:22
当成入门了解,可以。

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • .net23种设计模式【完整】

  • 在上一篇文章里我通过具体场景总结了“.net面向对象的设计原则”,其中也多次提到一些设计模式方面的技术,可想而知,设计模式在我们的开发过程中也是必不可少的。今天我们就来简单交流下设计模式。对于设计模式的介绍呢,网上流行这么一句话“想要搞好对象,必须要熟知套路”,所以百度中说设计模式简介时“设计模式一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结”一点也没错,在开发过程中通过渗入一些设计模式,我们的设计效果又会怎么样呢?话不多说,直接进入正题吧! 一、设计模式的分类 ...

  • 前言《设计模式自习室》系列,顾名思义,本系列文章带你温习常见的设计模式。主要内容有:该模式的介绍,包括: 引子、意图(大白话解释) 类图、时序图(理论规范)该模式的代码示例:熟悉该模式的代码长什么样子该模式的优缺点:模式不是万金油,不可以滥用模式该模式的应用案例:了解它在哪些重要的源码中被使用该系列会逐步更新于我的博客和公众号(博客见文章底部),也希望各位观众老爷能够关注我的个人公众号:后端技术漫...

  • 设计模式(design pattern)是代码设计经验的总结。设计模式主要分三个类型:创建型、结构型和行为型。创建型是对象实例化的模式,创建型模式用于解耦对象的实例化过程,主要用于创建对象。结构型是把类或对象结合在一起形成一个更大的结构,主要用于优化不同类、对象、接口之间的结构关系。行为型是类和对象如何交互,及划分责任和算法。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。本文主要介绍.net(c#) 设计模式 状态模式。 原文地址:.net(c#) 设计模式 状态模式 ...

  • http://dev.csdn.net/develop/article/14/14365.shtm 设计模式(design patterns)笔记 如果你有一定的面向对象编程经验,你会发现其中某些设计模式你已经无意识的使用过了;如果你是一个新手,那么从开始就培养自己良好的编程习惯(让你的的程序使用通用的模式,便于他人理解;让你自己减少重复性的编程工作),这无疑是成为一个优秀程序员的必备条件. 整

  • 引言: 建造者的特点是过程,需要建造对象的过程是一样的,如:软件项目,过程都是,poc、投标、立项、软件过程、收款,那么标准的软件项目都是这个过程,只是不同的项目在做这个过程的内容不一样。所以需要有一个过程,这个过程需要被抽象出来(接口化),不同的项目实现不同的过程。 上面的过程,是有顺序的,poc、投标、立项、软件过程、收款,这个过程不能乱,所以需要有一个指挥官来固定建造的顺序。 结合上述两点,就是一个建造的的模式了,理论的说法是:是将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不

  • ——适合有一定设计模式基础和.net基础的人阅读。 写在前面 “设计模式”我一向是敬而远之的态度,不会去写这方面的文章,原因有二:第一,要想写好设计模式的文章太难,需要笔者丰富的经验;第二,没有深厚的功底写出的设计模式文章容易误导他人。自认没有深厚的功底,但我不会为了设计模式而设计模式。我想大部分人对设计模式的理解是不够深刻的,不然应用自如,特别是初学者!所有研究高质量的源码或框架是我们学习实...

  •   longronglin之设计模式:christopher alexander 说过:“每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的买球软件推荐的解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复劳动”。模式描述为:在一定环境中解决某一问题的方案,包括三个基本元素--问题,买球软件推荐的解决方案和环境。阅读类图和对象图请先学习uml创建模式 结构模式 行为模式创建模式:对类

  • 最初写探索设计模式系列的时候,我只是想把它作为自己学习设计模式的读书笔记来写,可是写到今天,设计模式带给我的震撼,以及许多初学者朋友的热心支持,让我下定决心要把这个系列写完写好,那怕花上再多的时间也无所谓。本部分内容不断更新中。 目录计划: 第ⅰ部分 开篇 开篇 第ⅱ部分 创建型模式篇 第1章 单件模式(single pattern) 第2章 抽象工厂模式(abs...

  • 1、框架的通用作用及层面: 软件开发要满足用户的功能性需求,只有在满足了功能性需求的前提下,非功能性需求才算有价值的。可以归纳出软件开发的两大需求:功能性需求,非功能性需求。前者优先级高。 功能性需求可以用各种方式实现,在满足功能性需求后,需要完成非功能性需求,非功能性需求形态各异:安全、性能、稳定性、易维护、易伸缩。在满足了功能性需求后,这些将变成重点考虑的范围。 框架的...

  • 最近在学设计模式,其实不是第一次学了,才工作的时候就看过,不过那时候看设计模式就是天方夜谭,不明白为什么要用这些模式,觉得反而更麻烦了,工作两年后再看有些感觉了,但是陷入无穷无尽的场景假想中,设想自己处于一种场景,然后有各种需求,然后要用哪个模式就可以实现,三分之二的时间在围绕这这些假想转悠。偶然在msdn上看到篇文章 discover the design patterns you're alr...

  • 外观模式(façade pattern) ——.net设计模式系列之十二 terrylee,2006年3月 概述 在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?这就是要说的façade 模式。 意图 为子系统中的一组接口提供一个一致...

  • c#的设计模式代码实现—创建型模式 包含单例模式、工厂模式(普通工厂、工厂方法、抽象工厂)、建造者模式、原型模式。

  • 模式是一种对现实世界的概念抽象,建筑模式,设计模式,营销模式,商业运作模式各行各业都有自己的模式。这里说的设计模式是软件设计里的模式,主要是指面向对象的软件设计。遵照设计模式,可以有效的提高软件的可维护性和可复用性,提高开发软件的效率,避免过多的出现再造轮子的现象。我学习模式是从知道大名顶顶的四人帮的力作《设计模式》,真正感觉到了设计模式给软件设计所带来的诸多好处。《设计模式》内容精练,实

  • 我假设看这篇文章的朋友对装饰者模式都能有各自的、深入的理解。因为这篇文章是讨论装饰者模式的性能问题。 在本人的“.net简谈设计模式之(装饰者模式)”一文中比较详细的讲解了装饰者模式的一般应用,但是我总是感觉装饰者模式隐隐约约之中有点不完美。经过我昨天一整天的思考、推敲终于找到了它隐隐约约中的那点不完美是什么,为了行为去继承带来的无辜的性能开销。所以本人想把它写出来,跟大家讨论下装饰者...

  • 设计模式(design pattern)是代码设计经验的总结。设计模式主要分三个类型:创建型、结构型和行为型。创建型是对象实例化的模式,创建型模式用于解耦对象的实例化过程,主要用于创建对象。结构型是把类或对象结合在一起形成一个更大的结构,主要用于优化不同类、对象、接口之间的结构关系。行为型是类和对象如何交互,及划分责任和算法。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。本文主要介绍.net(c#) 设计模式 策略模式。 原文地址:.net(c#) 设计模式 策略模式 ...

  • 我们继续学习设计模式系列文章。 今天我们要学习的是设计模式中的适配器模式,适配器模式其实也比较好理解,光从它的名字我们都能理解个所以然了。 适配器模式定义:将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 上面的这段话可能对初学者来说有点抽象,短短的一段话提到了几个关键的技术点。都是一些基本语法,如果我们还没有掌握这些...

  • >> singleton(单例模式) 1. 意图 保证一个类仅有一个实例,并提供一个访问它的全局访问点 2. 动机 对于一些类来说,只有一个实例是非常重要的。虽然系统中可以有许多打印机,但却只应该有一个打印假脱机,只应该有一个文件系统和一个窗口管理器。一个会计系统只能应用于一个公司 怎样才能保证一个类只有一个实例,并且这个实例易于被访问呢?一个全局变量使得一个对象可以被访问,但它不能防止

  • 题记:     《.net中的设计模式》系列随笔停下有一段时间了,一则总结个东西不容易,另一则,不想写相同的内容(如果朋友们没有在我的随笔中看到新东西,我认为是浪费大家的时间,也是一种失败)。     今天开题之前先让大家见一个老朋友,相信没有一个人会不认识它:-)大家是不是觉得很眼熟啊。程序中产生一个错误的原因很简单,解决方法也很简单,我也相信写过两年代码的人只要稍微细心一点就很少遇到这个...

  • 学习asp.net 23种设计模式时,编写的实例代码,代码虽然比较简单,但是都是根据实际的应用场景编写的,该用到的技术点都有了,也加了相应的注释,适合初学者学习。我这里只有20中,其他3种感觉平时几乎用不到。

global site tag (gtag.js) - google analytics