浅谈DevOps，文化、技术和职业发展

heroxk

身边和论坛里的不少朋友都向我咨询什么是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领域，而且薪资也是芝麻开花节节高，甚是欣慰，大家加油。

heroxk

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需要同时承担责任，共同去解决问题。

heroxk

不少朋友问，掌握了一些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精髓的理解可以说是有限的。

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

heroxk

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）

heroxk

举例谈谈这两种不同的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就像是牲口，不需要单独进行特殊照顾。

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

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

stacknotoverflo

留坑5

heroxk

再谈谈

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的两个小弟终于松了口气，连声谢谢。我也可以回家了。

heroxk

最后谈谈DevOps的community。

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

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

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

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

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

summerlover

heroxk 发表于 2016-8-13 09:07
最后谈谈DevOps的community。

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

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

anklos

写的很好

求知

外行看热闹。不过知道个框架。楼主继续好贴

tasl

好文章，虽然我不干这个。澳洲比较流行和崇尚这些啊

blacksheep

说白了，在网络公司里面 就是一群干杂活的人为了凸显自己的地位重新定义了个名字 就是系统集成工程师干的，区别就是devops要有很强的编程技能，但没用一种专长，不像网工，是以网络为主其他技能为辅的。

nkwd

只有专长，无助于消除silo

飞飞鱼

heroxk 发表于 2016-8-13 09:06
DevOps工作

- DevOps=Dev+Ops ， 错！

这个的思路好像是主要针对软件开发环境的，楼主有没有Enterprise层面运行系统的案例？

还是或者说Devops的主要适用对象并不是Enterprise运维应用，比如说Restful API等等这些，只需用Openstack或者Redhat，Ubunta的Customised包实施。

因为企业级别应用的运维求稳怕多变以避免出错，这个和Devops好像天然有冲突。不过在现实案例里看到很多Devops思路对传统运维的影响。

Helen_hah

楼主真牛人

heroxk

summerlover 发表于 2016-8-14 08:12
我完全不懂你上面说的那些， 但是我想问问， 为何每次我们系统更新后，那个难用啊？客户也不喜欢， 每次 ...

你所说的系统是什么？操作系统？应用程序？最好举个例子说一下

heroxk

blacksheep 发表于 2016-8-15 00:13
说白了，在网络公司里面 就是一群干杂活的人为了凸显自己的地位重新定义了个名字 就是系统集成工程师干的， ...

顶着DevOps名头而不明白其中含义的不少。

lubber

super

czy1024

感觉国内对这个 没那么高需求

系统就是系统, 很难懂编程的一些事情,   

summerlover

heroxk 发表于 2016-8-15 20:08
你所说的系统是什么？操作系统？应用程序？最好举个例子说一下

说白了online banking， 应该是应用程序吧

heroxk

飞飞鱼 发表于 2016-8-15 13:57
这个的思路好像是主要针对软件开发环境的，楼主有没有Enterprise层面运行系统的案例？

还是或者说Devops ...

我说的就是Enterprise级别的应用项目。绝大多数的企业级项目都不是起几个Server，然后静态地运行3-5年。上层的开发是在一直进行的，而且进化速度越来越快。一般的企业网站，比如CBA，Realestate这种，基本都是这样，几十个开发团队在不停的开发，release一个接着一个。

一个大型企业系统一般可以拆成设备层，包括bare metal , network, storage，再上面是Infra层，主要将这些资源进行虚拟化，主要就是虚拟层的管理。Infra层再往上是System层，system层就是将虚拟化过的资源按application需要进行各式各样的组合，比如一个CMS系统，这时的系统会又Web,App,DB,Cache等一堆server组成。system再往上就是COTS(commercial off the shelf)层，比如具体的DB，Apache，Tomcat这种基础的component，可以理解成基本的容器层。最上面就是APP层，一般APP都是功能和feature的实现，APP层是有非常重的开发任务的，CI/CD尤为重要。

APP(Dev/Customization)
|
COTS
|
System
|
Infra(Hypervisor)
|
Baremetal/Network/Storage

再上面的架构中，
  OpsDev会涉及一部分的Infra层，全部的System层，一部分COTS层
  DevOps CI/CD会涉及一部分的System层，全部的COTS层，全部的APP层

Restful API只是一个例子，一种典型的Infracoding手段。因为只有这样，才容易实现自动化，才容易实现持续部署。而AWS的Cloudformation，和Openstack的Heat，也都是实现了这种思想。与之相对的，是使用AWS，Openstack的Web UI，手动一通click创建出的infrastructure。

随着APP层的Agile化，需求可能会变化的非常快，System层可能经常遇到来自Dev层这样的要求：“哥们，我在开发系统。给我创建3个Dev环境，非HA的，系统不必完整，我不要DB server因为弄几个测试的dummy data就行了。再来一份Integration Test的环境，需要全部模块。最后再来一个Pre-Prod环境，不但要全部的系统模块，Web, App全部要HA的。下午就要哦。。。”

因为上层的应用层需要持续集成，导致下面的System层，也随之需要持续集成，意味着频繁的创建/销毁/修改系统。而这些CI/CD的问题，就需要用DevOps的思路去解决。

tuxiaobao

说个大白话吧， DevOps对一直搞开源的从来不是新玩意，就是可以的话呢，一个人从搞定客户需求到搭建环境到编程到交付到维护一手一脚全都包了。。。。。。。。。

heroxk

tuxiaobao 发表于 2016-8-15 21:11
说个大白话吧， DevOps对一直搞开源的从来不是新玩意，就是可以的话呢，一个人从搞定客户需求到搭建环境到 ...

的确，DevOps需要Dev的技能和Ops的技能，但是DevOps的工作不完全是Devs+Ops

DevOps的需求一般都来自于大型的项目。大的系统和项目必然是团队作战，每个人开发一个项目不同的feature，每天可能都有新的feature开发出来，code commit可能几十上百次。同时还有可能bug在运行中被发现，需要修复。有些关键的service，在频繁部署的同时，还要保证Zero Downtime。这些都是值得思索的。

YugaYuga

感谢楼主分享

terryandtaotao

（四五年前） DevOps 概念刚炒起来时（感觉现在已经被玩坏了）为了拓展技能树，学了半年觉得不对劲，工具迭代太快，忙成狗任务都完不成也不可能学到太多东西（除非真的开发和那些工具有兴趣）坑爹且没前途，赶紧转方向。结果害了圈子里一些喜欢偷偷跟风的人跳进了这个大坑，感觉挺不好意思的，害了他们...

说穿了 DevOps 就是一种文化、方法学和人。现在 Puppet Camp 也不去了...

至少上一个公司，和现在公司的 DevOps 是真苦逼，一般人不想做

还是感谢楼主分享。

大家记得订阅 DevOps Weekly 这货我现在还在看。

jessieweiyi

过来支持下同行 楼主平时参加什么meetup 有机会聊聊

boatstar

楼主写的太好了

菜花土匪

两个人的活变成一个人的活，垂直开发变成水平开发，换汤不换药。就是为了提高效率，减少人员。

tuxiaobao

heroxk 发表于 2016-8-15 22:08
的确，DevOps需要Dev的技能和Ops的技能，但是DevOps的工作不完全是Devs+Ops

DevOps的需求一般都来自于大 ...

往深了谈，没底了，包括microservice， 现在不像以前，coding用框架和现成的包比较多，machine code 写的少，很多programmer呢，对底层硬件的理解不深，所以DevOps的人才也缺。。。。。。。。。。