新足迹

 找回密码
 注册

精华好帖回顾

· Q&A各类问题大汇总,解答你绝大部分困惑! (2005-1-7) horseanddragon · 国内和日本的美食报道(现场实录)——604 美丽的回味,唐朝未来店。 (2010-3-29) 老陶
· 上海夏天 (2010-5-15) xblues · 终于通过Customs Broker National Exam (2006-11-19) fighting010605
Advertisement
Advertisement
查看: 40068|回复: 228

[IT] 浅谈DevOps,文化、技术和职业发展 [复制链接]

2021年度勋章获得者

发表于 2016-8-13 09:58 |显示全部楼层
此文章由 heroxk 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 heroxk 所有!转贴必须注明作者、出处和本声明,并保持内容完整
本帖最后由 heroxk 于 2021-3-14 13:49 编辑

身边和论坛里的不少朋友都向我咨询什么是DevOps?DevOps是做什么的?成为一名DevOps需要什么背景和技术知识?我觉得是时候开个贴了,在这里系统谈谈自己个人的理解和看法,希望对有志成为DevOps的朋友一些帮助。


1. DevOps是什么?

DevOps是一种文化,定义随著可见,Wiki上的定义还是非常经典的:
“DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.[1][2] It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.”

过去的很多大型软件开发项目,Dev(开发)和Op(运维)基本上是完全分离的。Developer在一些相对封闭的开发环境里完成了开发(比如自己的电脑),所有的代码都编译打包好,写好部署文档,交给Ops,之后Devs的任务就完成了。然后Ops按照这些步骤把app在企业的服务器环境中部署好。

当Ops尝试着把App部署到服务器上,这时,问题出现了,App起不来。这时,

Ops说:我们按照你们提供的步骤丝毫不差的进行部署,环境也没变,东西起不来,我管不了也不想管。我们只负责环境的运行维护和部署,功能方面的东西不是我的职责范围。Devs,肯定是你们的程序有问题,不够robust。

Devs说:我们的code在本机和测试环境上全部编译通过,各种也没有问题。Ops,肯定是你们搭的production环境有问题,或者部署上面漏掉什么,没完全按照我们的部署说明来。我们只管APP功能上的实现,prod环境起不来不是我们的责任,对不起我们不管。

皮球踢上了。。。。



好家伙,一个都不愿意管,但头头们可不干了。所以,一种常见的场景就是在大半夜,Devs和Ops肩并肩,红着眼,怒气冲冲地坐在一起解决问题,搞不定觉不要睡了,家也不用回了。。。。

这种情况,应该不少参与过大型企业级开发项目同学应该都经历过。如果放到15年前,那时候一个项目几个月才release一次,可能还不是太大的问题。但是到了今天,系统越来越复杂,项目release的频率越来越高,有的甚至是每天都在做release,环境、部署、运行不够迅速往往会对公司的主营业务造成很大的影响。


2. 再谈谈Agile

既然谈到DevOps,就不能不谈到Agile。有Dev背景的同学应该多少都晓得Agile。什么是Agile,简单的说就是将一个庞大的需求变成特别小颗粒的需求,在非常短的开发周期(一般是2周左右的sprint)里完成。

颗粒化的任务有助于快速的完成,更短的反馈周期、更频繁的反馈,使得在implementation偏离requirement/business value时候能够快速的修正。在10年前的瀑布模式SDLC中,经常出现项目的严重delay,或者一个三个月的开发周期开发完了后,突然发现开发出的东西并不是stakeholder所需要的。而Agile,主要解决的就是这方面的问题。



3. 回到DevOps的问题


Agile项目意味着什么,意味着可能每天Dev team都有开发任务完成。也许这个task很小,但是无论task多么小,都需要做完整的test和deploy,至少是在Dev/Test环境中。如果Devs和Ops还是处于一个严重分离的状态,各自为阵,各顾各,出了问题互相踢皮球,项目就无法Agile化。

这时,DevOps的文化和理念就诞生了。DevOps意味着什么,四个词概括的很好,CAMS- Culture, Automation, Measurement, Sharing。

----------------------------------------------------------------------------------------------------------------------------------------------

一转眼,2021年了,离第一次发这个帖子都快5年了。

DevOps的理念已经渗透到很多领域,比如DevSecOps,DataOps,MLOps

这几年,看到越来越多的华人同胞都陆续转行到DevOps和Cloud领域,而且薪资也是芝麻开花节节高,甚是欣慰,大家加油。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?注册

x

评分

参与人数 27积分 +142 收起 理由
风行者止水 + 4 感谢分享
hzsunnybay + 2 感谢分享
osrookie + 2 感谢分享

查看全部评分

Advertisement
Advertisement

2021年度勋章获得者

发表于 2016-8-13 09:59 |显示全部楼层
此文章由 heroxk 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 heroxk 所有!转贴必须注明作者、出处和本声明,并保持内容完整
本帖最后由 heroxk 于 2016-8-14 22:32 编辑

CAMS

Culture: 重中之重,这是一种文化上的转变,强调是多方的有效沟通和紧密的合作。主要是Dev/Op/Test/QA几大部门。共同的应对app的开发和系统环境改变所带来的一些问题。

Automation: 无论是Dev, Op, 还是Test,怎么能更有效的去完成任务,让所有的工作变得可重复,更高效,同时避免人为错误。Automate, automate, automate,重要的事说三遍。这里面就需要熟悉不少tool,比如git,configuration management tool,CD tool等。

Measurement: 怎样去衡量一个项目是不是Agile了。简单的例子,一个项目,deploy time需是多长,这里面手动和自动部署的比例是多少? Dev新开发一个feature,从开发开始,多久可以push到production?

Sharing: 也是一种文化上的转变,不但是knowledge上面的share,更多的是share responsibility。当出现问题时,Devs和Ops需要同时承担责任,共同去解决问题。

评分

参与人数 2积分 +8 收起 理由
财神爷 + 4 感谢分享
Jenny_2000 + 4 感谢分享

查看全部评分

2021年度勋章获得者

发表于 2016-8-13 09:59 |显示全部楼层
此文章由 heroxk 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 heroxk 所有!转贴必须注明作者、出处和本声明,并保持内容完整
本帖最后由 heroxk 于 2016-8-13 15:40 编辑

不少朋友问,掌握了一些tool,比如Git, Puppet/Ansible,会用一些vm, docker,AWS是不是就具备了DevOps相关工作所需要的技能。在我看来,这些是基础。换句话说,一个DevOps person,一般都需要会这些工具,但是会了这些工具,并不意味着具备DevOps所需要的其他素质。

为什么呢,工具只是一种解决问题的手段,也就是How,更关键的是Why和What。比如说docker,看到不少人谈,包括身边的朋友同事,会几个命令就认为掌握了,其实这只是解决了How的问题。

Docker究竟是什么?和VM比有什么不同?Docker究竟解决了什么问题?使用Docker会不会带来什么问题,比如安全方面的,怎么避免?Docker网络层是什么样子?一个企业的Infrastructure全面containerize了以后是什么样子的?Docker的引入对一个开发项目甚至开发流程究竟有什么影响?

如果只是拿docker当一种轻量级的VM来用,其实对docker精髓的理解可以说是有限的。

所以学习各种工具是个好的开始,有时间的话不妨多了解技术之上的东西,多从问题的根源出发。

评分

参与人数 4积分 +14 收起 理由
fangqiangqiang + 3 我很赞同
somewhat + 2 感谢分享
Jenny_2000 + 4 感谢分享

查看全部评分

2021年度勋章获得者

发表于 2016-8-13 10:06 |显示全部楼层
此文章由 heroxk 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 heroxk 所有!转贴必须注明作者、出处和本声明,并保持内容完整
本帖最后由 heroxk 于 2016-12-26 09:47 编辑

DevOps工作

- DevOps=Dev+Ops , 错!
首先必须要说,市场上面很多打着DevOps的工作,其实和DevOps半毛钱关系都没有。有招sysadmin说自己的DevOps,有招IT Support的也说自己是DevOps。同样的,很多标榜自己是DevOps的人其实也不是DevOps,看过一些人懂点编程,懂点点系统,就说自己是DevOps。不少人认为DevOps就是一个比较杂的工作,做些编程,再搞几下环境,



- 真正的DevOps

DevOps有两种:

1) OpsDev/ System DevOps/ SRE(Site Reliability Engineer)
偏重基础Infrastructure/Environment,强调Infracoding。CloudOps就是这类的典型。

如果是system或者support背景,职业发展路线一般是:
第一阶段,sysadmin,主要就是BAU,面对设备,维护不宕机。监控,运维。又叫NOC,一线运维。
第二阶段,system engineer,需要开始有一定的engineering任务,这时候需要一定的scripting能力,处理的任务开始变得复杂起来。处理一些一线运维无法处理的问题。
第三阶段,OpsDev/SRE/System DevOps,新一代的system engineer,需要对DevOps文化和Agile的理解,懂Software Defined XX,比如SDN。需要懂modern infra,比如vm,cloud, docker。如果需要达到比较高的高度,Dev技能很重要,比如API,REST。用软件开发的方式去管理Infra。比如Google的SRE,就是一群精通系统,同时软件开发能力也很强的人。


2) DevOps (CI/CD)
偏重software build和release。更多的是application layer,也就是Infrastructure的上端。如果job description里面很多CI/CD,SDLC等关键字出现的多,那基本就是这种类型的DevOps。

和1)的区别:
- 需要更多的软件开发背景,尤其是大项目中的。
- 需要有一定的系统的背景。但是没有1)要求那么强。
- 需要会用configuration tool,更多的是部署application
- 对CI/CD的理解比1)要求高
- 需要Infra的经验比如cloud的经验,但更多的是使用而不是管理。因为应用层并不care下面的infra层。无论是Datacentre还是Cloud,都不是上层care的项目。


相比之下, 1)和2):
- 哪个对系统知识要求更高?1)
- 哪个对软件开发的知识要求更高? 2)
- 哪个需要熟练掌握configuration tool? 1), 2)
- 哪个市场上面目前更抢手?2)
- 哪个适合完全没有IT背景的人?N/A
- 哪个对troubleshooting的技能要求更高?1)=2)
- 哪个的成长曲线更短,更容易速成?1)=2)
- 哪个对communication的要求更高?2)



评分

参与人数 1积分 +4 收起 理由
ywolf + 4 感谢分享

查看全部评分

2021年度勋章获得者

发表于 2016-8-13 10:06 |显示全部楼层
此文章由 heroxk 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 heroxk 所有!转贴必须注明作者、出处和本声明,并保持内容完整
本帖最后由 heroxk 于 2016-12-26 09:51 编辑

举例谈谈这两种不同的DevOps Job。

因为一些机会,这两种DevOps工作我本人都从事过,先说说第一种:

OpsDev/ System DevOps/ SRE(Site Reliability Engineer)

OpsDev,字面意思就是去Develop the process of operation,字面意思就是‘开发运维(的管理流程)’。

举个特别简单的运维情景,用户忘记了密码,打电话过来,让sysadmin进行重设。当一天只有一个用户电话过来的时候,sysadmin手动操作,重设密码,通知用户,没有问题。

好,现在情况变成一个小时50个用户打电话过来,忘记了密码,需要重设。。。这时候,单独一名sysadmin已经没有办法handle了。而有OpsDev sense的人,立刻应该想到,有没有方法让用户自己进行密码重设?哦,没有现成的API,那好,OpsDev自己去写API,整合到当前系统当中。

一个人管理20台server/vm可能并不难,那管理200台呢?管理2000台,20000台呢?Amazon和Google的SRE,平均人均管理的系统数量都是过千的。如果用管理20台server的方法去管理20000台,光各种监控报警的email,就能把mail server搞瘫。而true alarm可能被淹没在几千上万份false alarm的邮件里面了。这时,除了一些tool以外,软件开发的手段能极大的解决问题。

再举一个我工作中的例子,创建环境,Infrastructure provisioning,里面需要控制Vsphere,DNS server,Load balancer等各个模块。创建VM,查询空闲的IP地址,给VM分配IP后,加入DNS中,将VM加入Load Balancer Pool。当然,GUI界面是有的,每个模块也有自己的management tool。但部署不同environment的流程是不一样的,不同的team所给的部署的权限也不同。比如,不能给Dev team destroy production environment的权限。作为OpsDev,我们需要把所有的流程用Web的方式进行wrap,对外界,无论是Devs(人)还是CD server(自动部署)都只能通过REST API接口进行访问。同时在web层进行身份验证(authentication)和授权(authorization)。这些Web API/REST interface的开发,都是我们OpsDev自己搞的。

以上说的,就是OpsDev/ System DevOps/ SRE和传统的Sysadmin的不同之处。


当然,还有一些是理念上的转变。

例如,Cattle, not Pets

以前的一台台server就像一个个宠物,需要特别的照顾。而现在的server就像是牲口,不需要单独进行特殊照顾。

宠物生病了,怎么办?送宠物医院。牲口生病了怎么办?杀掉,再养一群。

具体这面的意思,就自己慢慢去体会吧。

评分

参与人数 4积分 +14 收起 理由
在澳洲 + 2 哈哈 AWS同道中人
fly_cat + 5 感谢分享
epoxboy + 3 感谢分享

查看全部评分

发表于 2016-8-13 10:07 来自手机 |显示全部楼层
此文章由 stacknotoverflo 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 stacknotoverflo 所有!转贴必须注明作者、出处和本声明,并保持内容完整
留坑5
Advertisement
Advertisement

2021年度勋章获得者

发表于 2016-8-13 10:07 |显示全部楼层
此文章由 heroxk 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 heroxk 所有!转贴必须注明作者、出处和本声明,并保持内容完整
本帖最后由 heroxk 于 2016-8-14 12:08 编辑

再谈谈

2) DevOps (CI/CD)


举个我在CI/CD DevOps工作中遇到的例子,希望通过这个例子,让大家了解一下这个工作:

我曾今在一个multi-million的大项目工作过一段时间,当时有C公司,software vendor,主要提供基本的产品平台。I公司,国际知名consultancy,主要对C公司产品进行customization,也就是二次开发。而我们公司,主要是过去监督和提高I公司的DevOps水准。

一天下午快下班了,C公司的delivery manager怒气冲冲的跑过来对我说,“你是不是搞坏了CD server,我的手下刚刚做了一个重要的bug fix,change都push上去了,编译测试显示全部通过,部署显示成功。怎么网页开了后,上面那个错误还在?”

因为那个时候我刚对CD server进行了重新配置。所以他第一时间找我我也不觉得奇怪。我说,应该不会的,你让我查一下,我仔细分析了编译测试和部署记录,完全没有问题。于是我对他说,部署的东西branch,version都是对的。Ansible也没有报错,应该不是CD server的问题,也意味着不是我搞的。

这时C公司的delivery manager还是一脸怒气,拉了两个I公司的小弟,说,我的人打了patch,为什么到你们手上做完了customization后,那个patch就没了??“,I公司小弟也说不出个所以然,也就唯唯诺诺站在那不知怎么解释。C经理说:”我不管,你们赶快找出来改过来,改不过来到时耽误了项目,都是你们I公司的责任!!“,两个小弟说,好好,我们再重新部署两遍试试,看看会不会好一点。。。。

这时候,我说,等等,要不我来看看吧。我登录到目标server,到了glassfish的部署点一查,那个文件根本就是老版本的,没有patch。然后我对C经理说,来,我从repo里面把包sync过来手动部署一遍。

-> 部署完了,一看,还是个没有patch的。

-> 查看repo,确定部署的包 - 版本都是对的 (也就是说,印度小弟再重新部署一万遍,都不会看到那个patch)

难道是compile有问题,选了错误版本的source code?

-> Git里面的branch和source code的版本都是对的。再一看source code,的确有一个patch过的文件,为什么编译、打包过就消失了?

-> 立刻开docker,git pull那个commit过来进行本地编译打包测试,以确定不是CD server犯怪。果然,只要打成包那个patch过的文件就消失了,留了个没patch的文件在里面。

这怎么回事,还带变魔术的。

-> 这时焦点集中在这个Java的Maven project上面,仔细分析了项目里的结构,突然发现了两个同样文件名的文件!一个是patch过的,一个是没patch过的!问题终于找到了,C公司的Dev将patch过的文件鬼使神差地放到了一个错误的位置,Maven编译后打包时压根就没有将那个patch过的文件打过去,永远指向那个没patch的文件!!!如果这个问题不发现,编译永远都是成功,但是文件打就是包不进去。

下面的故事就简单了,C经理一声FXXX后走了,估计是找手下去算账了。I的两个小弟终于松了口气,连声谢谢。我也可以回家了。

评分

参与人数 3积分 +8 收起 理由
fangqiangqiang + 3 你太有才了
wyllyw + 2 我很赞同
epoxboy + 3 你太有才了

查看全部评分

2021年度勋章获得者

发表于 2016-8-13 10:07 |显示全部楼层
此文章由 heroxk 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 heroxk 所有!转贴必须注明作者、出处和本声明,并保持内容完整
本帖最后由 heroxk 于 2016-8-15 20:13 编辑

最后谈谈DevOps的community。

在澳洲,DevOps做的比较好恰恰不是那些大型的跨国Consulting。这里面有多方面原因。

四大的DevOps是不错的,因为他们财大气粗,Fintect,也有需求。IT公司,比如REA,Seek这种也是DevOps文化的引入者,曾今也是极客的天堂,要玩技术,这些都是首选。再次就是本地的consultancy,比如Odecee这种。

而且也很流派化,基本上一出手,就知道是哪个派系出来的。比如Odecee,比如REA/Thoughtworks,比如NAB。做东西都有自己独特的pattern,用的tool,看两眼就能晓得。

而身边的同事也是,绕了一圈发现好多都是认识的,同事的前同事的前同事之类

怎么才能获得更多了解,参加meetup吧。

发表于 2016-8-14 09:12 |显示全部楼层
此文章由 summerlover 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 summerlover 所有!转贴必须注明作者、出处和本声明,并保持内容完整
heroxk 发表于 2016-8-13 09:07
最后谈谈DevOps的community。

在澳洲,DevOps做的比较好恰恰不是那些大型的跨国Consulting。这里面有多方 ...

我完全不懂你上面说的那些, 但是我想问问, 为何每次我们系统更新后,那个难用啊?客户也不喜欢, 每次都要被客户喷我们的系统难用。我们单位就是你上面提到的那些单位的其中之一。

发表于 2016-8-14 11:29 |显示全部楼层
此文章由 anklos 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 anklos 所有!转贴必须注明作者、出处和本声明,并保持内容完整
写的很好