阅读更多

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 楼 xiesw3 2017-10-22 20:22
当成入门了解,可以。

发表评论

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

相关推荐

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

    .NET23种设计模式【完整】

  • .net 有哪些主流的设计模式_「设计模式」组合模式详解

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

  • .net 设计模式

    http://terrylee.cnblogs.com/archive/2006/06/01/334911.html 

  • .Net 设计模式(二) 策略模式

    定义 策略模式(Strategy):它定义了算法家族,分别封装起来,让它们之间可以互相替换 结构图 结构组成 策略控制(Context):控制了具体的算法使用,以及负责客户端与算法之间的数据交互 抽象策略(Strategy):定义了一个公共接口,各种不同的算法以不同的方式实现这个接口,Context使用这个接口调用不同的算法,一般使用接口或抽象类实现。 具体策略:实现Strategy的具体算法 代码实现 生活中有很多例子,每个人做菜的方式不同做出来的菜口味口感都会不同。 /// <summa

  • ASP.NET 23种设计模式简单实例代码

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

  • .NET 23种常用设计模式

    23种常用设计模式,包括单例模式、工厂模式、桥接模式、适配器模式、亨元模式、抽象工厂模式等。

  • 23个设计模式C#代码.学习.NET设计模式

    23个设计模式C#代码.学习.NET设计模式

  • C#23种设计模式【完整】

    C#23种设计模式【完整】

  • [源代码] .NET学架构之用户体验层 常用设计模式

    ☆☆ 资源说明:☆☆ ☆ 设计模式 ☆ Periodic Refresh and Timeout Pattern; Client-side data binding with jTemplate; Unique URL Pattern; Predictive Fetch Pattern;

  • .net之设计模式

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

  • 设计模式 之 单例模式(MSDN)

    在 C# 中实现 Singleton 发布日期 : 4/1/2004 | 更新日期 : 4/19/2004 使用 Microsoft .NET 的企业解决方案模式 > 分布式系统模式 > 在 C# 中实现 Singleton 版本: 1.0.1 本页内容 上下文 实现策略 结果上下文 致谢 上下文 您要在 C# 中构建应用程序。您需要只有一个实例的类,并且需要提供一个用于访问实例的全局访问点。您希望确保您的解决方案高效,并且能够利用 Microsoft? .NET

  • 设计模式讲解与代码实践(十五)——命令

    本文讲解了命令(Command)设计模式的使用目的、基本形态及各参与者,并结合示例代码,讲解了该设计模式在具体业务场景下的使用。

  • [导入].NET设计模式系列文章

    摘要: .NET设计模式系列,共分为30章,本部分内容不断更新中。阅读全文文章来源:http://www.cnblogs.com/Terrylee/archive/2006/07/17/334911.html 转载于:https://www.cnblogs.com/tufeng/archive/2008/10/29/1322338.html...

  • 设计模式

    耐着性子花了一个小时看了下MSDN WebCast讲设计模式的几个录像,实在是受不了了。讲的太慢。很小的东西要讲好久好久。于是于是决定不再看录像,直接上网搜索文章,收藏了讲设计模式的一个链接了事。设计模式的作者们把23种设计模式分为3类1 创建型模式(Creational Pattern):为你创建对象,而不必有你直接实例化对象。2 结构型模式(Structural Pattern

  • 设计模式讲解与代码实践(十)——装饰

    本文讲解了装饰(Decorator)设计模式的使用目的、基本形态及各参与者,并结合示例代码,讲解了该设计模式在具体业务场景下的使用。

  • C#设计模式总结

    一、引言   经过这段时间对设计模式的学习,自己的感触还是很多的,因为我现在在写代码的时候,经常会想想这里能不能用什么设计模式来进行重构。所以,学完设计模式之后,感觉它会慢慢地影响到你写代码的思维方式。这里对设计模式做一个总结,一来可以对所有设计模式进行一个梳理,二来可以做一个索引来帮助大家收藏。   PS: 其实,很早之前我就看过所有的设计模式了,但是并没有写博客,但是不久就很快忘记

  • 设计模式讲解与代码实践(十三)——代理

    本文讲解了代理(Proxy)设计模式的使用目的、基本形态及各参与者,并结合示例代码,讲解了该设计模式在具体业务场景下的使用。

Global site tag (gtag.js) - Google Analytics