【DevOps】尝试一文读懂，什么是DevOps？

本文参考资料

参考资料：

• DevOps实战笔记 - 石雪峰，极客时间
• 文末引用的故事转载自公众号 码农翻身
• 什么是DevOps？ - 程序员小灰

一、DevOps怎么来的？要解决什么问题？

DevOps的英文全称（开发 Development 与运维 Operations 的组合词），因此我们需要弄清楚开发和运维两个角色之间究竟有过什么样的问题。

---

1、DevOps怎么来的

很久很久以前，大家都在用瀑布式开发模式，开发、测试、运维之间较为独立，开发之前就需要完全确立好项目目标、范围和实现方式。这样的坏处很明显，现在的市场环境变化快，如果是甲方需求，甲方想法也可能有变化，几乎不可能一开始就确定好所有的东西。

一旦有变化，就需要从头开始，上线计划就会延期，最后的结果就是投入了大量资源，但是达不到预期效果。

从业界巨头 IBM 的统计数字来看，有 34% 的新 IT 项目延期交付，将近一半的应用系统因为缺陷导致线上回滚

---

后来啊，敏捷开发模式应运而生。一句话概括，就是将大的项目进行拆解，既然无法一开始设定好所有的功能模块，那就拆分！就算是有变动，影响的也不会是全体。通过一次次迭代，一次次将新功能加进去，一点点将完整的项目做出来。

比如我们要做个微信朋友圈这样的，可以先做一个发朋友圈，再做朋友圈点赞，然后做朋友圈评论…

这也让测试同学能在最短时间内加入到开发活动中。测试同学保证了每一个独立的小模块的功能可用，交付的质量也有保障。因此，敏捷开发是更加灵活的研发模式。

问：敏捷开发会直接提升团队的开发速度吗？
答：当然不！用啥都不能加速研发编码速度。买个好电脑吧，也许有点用

敏捷之所以快，是因为节省了大量不必要的浪费和返工。

---

终于终于，DevOps要上场了。从最早的开发、测试、运维互相独立，到拉拢了测试，提高效率之后，接下来自然要拉拢运维团队。

也就是说，DevOps模式最早是想要打破开发和运维之间的隔阂。

为什么说存在隔阂？
答：因为在敏捷开发模式下，开发和运维的使命有些许冲突。

• 开发为了满足业务需求，不断堆砌新功能，很少有时间考虑可运维性、可测试性，只需要需求状态在开发，干就完事。
• 另一边运维的使命是系统的稳定性、可用性和安全性。

现在版本部署上线，大家都会如临大敌。

我在欧洲拜访 DevOps 之父 Patrick 的时候，曾经去过他的公司。那天风雪交加，比利时根特显得非常冷清。
我们停好车后，刚要推门进入他们公司，恰好碰到 Patrick 和他的一个同事下楼抽烟。简单寒暄之后，我们才知道，原来 Patrick 公司负责的一个系统要在 15 分钟后上线，他们趁这个间歇出来换换脑子，然后再回去大干一场。

听石雪峰文中所言，就连 DevOps 之父Patrick在面临上线的时候都十分正式对待。

“在无数次被开发不靠谱的功能缺陷蹂躏得体无完肤之后，运维团队意识到，变更才是影响他们绩效目标的最大敌人。于是，预先设立的上线窗口就成了运维团队的自留地，不断抬高的上线门槛也使得开发团队的交付变成了不可能完成的任务，最后，“互相伤害”就成了这个故事注定的结局。”

再后来大家意识到，开发也很无辜，有些不靠谱的需求其实在业务（运营或产品）提出阶段就已经存在了。

然后业务方也加入DevOps，有人叫做“BizDevOps”。不重要，目标也是为了多变的业务需求，及时作出业务层面的调整。

安全部门也积极的加入，不再是等待系统发布之后。在每个研发阶段注入安全反馈机制，保证团队可以在第一时间内应对安全风险。有人叫“DevSecOps”

后来就更多了，职能部门，战略部门等等等等，DevOps已经从最开始的一个点，拓展为了一个面。

---

总结：DevOps是什么，是要求产生一个产品的各个部门，根据敏捷开发的模型，全程参与产品的研发和变化讨论。

2、现场编故事，来感受DevOps

Q公司想开发一个聊天app。主要有单聊、群聊、动态相关和个人信息展示。很自然划分了前后端团队，前端有客户端，后台管理网站研发；后端是服务端。

DevOps模式，划分小模块和周期，人员拆分成小组（组内包含业务方、开发、测试和运维），聊天模块分一组，个人信息相关拆分为一组。

拆分为多小呢？一般一个需求两周一个迭代，有一周的开发时间，一周的测试时间，两周一交付。

每个组的大方向都有了，就是进行组内业务的一期二期拆分，比如用户管理模块，不能上来就做一些用户之间的关注吧，得先把个人资料页做好；聊天模块，不能上来先做群聊吧，得先做单聊，单聊又需要一些用户那边的业务进行支持。因为根据业务之间的关联关系，决定一期都要做“基础能力”，用户需要把登录注册等基础能力做出来，不耽误聊天模块或动态相关的进度。

当一个小功能做开发出来之后，就直接提测，交给组内测试人员，测试人员完成后，提交需求单流转，运维方可利用一些自动化工具，如Jenkins和Gitlab做Hook，自动化部署。

如果！中间业务方有一些需求改动，比如，不想要动态相关了，或者想多做一个功能，这个时候对整体项目的影响会降到最低。

当其中一个小组的小模块在短期内搞定，一个软件的雏形也就有了，接下来进行二期、三期功能完善。一个聊天软件就做出来了。

二、引入DevOps前后的效能指标

• 部署频率：指应用和服务向生产环境部署代码的频率。
• 变更前置时间：指代码从提交到成功运行在生产环境的时长。
• 服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
• 变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。

每年，这个报告都会基于这 4 个核心指标统计行业内高效能团队和低效能团队之间的差距。从去年的数据来看，与低效能团队相比，高效能团队的部署频率高了 46 倍，变更前置时间快了 2500 多倍，服务恢复时间也快了 2600 多倍，失败率低了 7 倍。

三、DevOps是思想？还是工具？

常见的DevOps工具包含：Chef、Docker、Ansible、Packer、Troposphere、Consul、Jenkins、SonarQube、AWS…

DevOps 的 3 个支柱

对工具和文化的体系化认知，可以归纳到 DevOps 的 3 个支柱之中，即人（People）、流程（Process）和平台（Platform）。3 个支柱之间两两组合，构成了我们实施 DevOps 的“正确姿势”，只强调其中一个维度的重要性，明显是很片面的。

• 人 + 流程 = 文化
• 流程 + 平台 = 工具
• 平台 + 人 = 培训赋能

业界的很多开源工具已经相当成熟，以 Netflix、Amazon、Etsy 等为代表的优秀公司也在不断将内部的工具平台进行对外开放，各方面的参考资料和使用案例比比皆是。无论是单纯使用，还是基于这些工具进行二次开发，成本都已经没那么高了，一个稍微成熟点的小团队可以在很短的时间内完成一款工具的开发。

机制就是人们愿意做，而且做了有好处的事情。

DevOps是一种思想，也可以是一种平台化工具，让研发过程中的所有相关人员加入进行协同办公，

四、类比CMMI、ITIL

两者都是基于瀑布模型进行的细化和完善，还需要一部分管理层面的参与。

ITIL是一套标准和规范，ITIL即IT基础架构库(Information Technology Infrastructure Library, ITIL，信息技术基础架构库)由英国政府部门CCTA(Central Computing and Telecommunications Agency)在20世纪80年代末制订，现由英国商务部OGC(Office of Government Commerce)负责管理，主要适用于IT服务管理（ITSM）。

---

与DevOps相比没有好与坏，需要看公司的运作模式，以及当前项目的类型，更适合选用什么样的模式。

五、自己编的故事太难听了，听这个

1、开发和运维的战争

五天前，张大胖负责的开发团队向运维部门交付了一批新代码，这是一次用户期待已久的重要升级，部署进行得非常顺利，大家都很高兴。

可是今天生产环境的CPU持续接近100%，有好几台服务器都down机了， 运维老大勃然大怒：“已经是第三次了！ 张大胖，你们开发团队怎么搞的？ 新代码一上线CPU就100%！”

张大胖自然也不甘示弱：“我们在测试环境测试得非常充分，用户压力比生产环境大多了，代码坚如磐石，肯定是你们配置错了什么东西！”

“不可能，我们是严格按照你们要求的步骤来部署的，肯定是你们代码的问题！”

“那测试环境怎么就没有问题？”

…

两位主管吵了好久，也没有什么好的解决方案，大家又熬了一个通宵，把代码回滚到上个版本，烧香拜佛，希望不要再出问题。

经过这一番折腾，今年年底的奖金估计是悬了！

张大胖觉得极为郁闷， 心绪难平，黑着脸来到茶水间倒了一杯咖啡，坐在那里一边喝一遍感慨这运维部门简直是太难合作了！

看看他们新招的这些人，完全不懂业务，他们为了要“逃避责任”，经常说：“我不懂业务，这次上线的内容，你要把每一步都写得清清楚楚，我只管执行，不问为什么，出了问题可不是我的责任。”你说气人不气人！ 难道他就想当个机器人吗？

还有，他们运维团队每个人侧重不同，有人负责数据库脚本执行，有人负责Web服务器，有人负责SSO ， 我的天，每次上线前都得把一堆人拉过来开好几次会，让他们熟悉操作步骤。 这个人部署了一次，好不容易熟悉了，下一次又换了一个人，还美其名曰这是人力资源池，能提高效率，但是新人又需要从头儿学习，这怎么可能不出错？！ 唉…

2、张大胖的回忆

喝了两杯咖啡以后，张大胖稍微平静了一下，仔细想想，本质原因还是软件本身太复杂了，不但开发复杂，部署也超级复杂，每次部署就把人扒掉一层皮。

张大胖不由地想起来这些年来自己经历过的软件开发和部署流程。

大学时候，跟着老师做一些小项目，开发、测试都是一个人搞定，部署到用户那里也是自己做，几乎没出过岔子。

毕业后进入一个小公司，做的是C/S架构的系统，有了开发团队、测试团队之分，开发团队把代码写完，交给测试团队测试，通过以后就可以到客户那里部署了。

通常来说实施人员也都是开发或者测试的兄弟们兼任，自己也兼职干过，拿着部署文档和光盘，到客户那里严格按照步骤把系统安装到客户的机器上，基本上没啥大问题，即使有了问题，现场调试一下也都能解决，大不了把开发的兄弟们叫过来一起熬夜。

再后来互联网浪潮来临，自己也跳槽到这家互联网公司，专门做一个网上约车的系统，给用户提供约车服务，根本不用到客户那里去安装软件，公司独立地运行、维护好这个系统就万事大吉。

但是这个网上约车的系统可比原来的单机软件、C/S软件要复杂得多，尤其是要面对海量用户的高并发访问，需要解决各种各样的技术难题，挑战巨大。 系统不但复杂，还需要以24*7的方式运行， 靠开发或测试的兼职人员已经无法维护了。

公司专门设立了运维（Operations）部门，负责系统的部署、日常维护、监控。运维人员的地位空前提高，当然，对他们的技能的要求也空前提高。

张大胖看过一个招聘的运维的邮件:

熟练使用Linux, unix, windows操作系统；

精通各种常用服务器软件（tomcat, apache, nginx,redis,mysql…)的配置及优化

了解负载均衡和高可用的原理，如LVS,Keepalived等

熟悉网络原理，TCP/IP协议，掌握至少一种脚本语言。

会使用各种配置管理和部署管理的工具。

…

总之，运维的重要性已经和开发差不多了。

3、开发和运维的鸿沟

为了加快交付速度，前两年，自己带领着开发团队实施了敏捷转型，成功地把原来的瀑布开发方式转换成了小步快跑，经常交付的敏捷模式。

通过敏捷软件开发，把需求人员，开发人员，测试人员拉到了一起，形成所谓“特性团队”，把需求拆分成一个个独立的，对用户有价值的故事，按优先级排序以后再开发、测试，甚至可以达到每两周就能交付几个独立需求的程度。（码农翻身注，参见《白话敏捷软件开发》）

成功的敏捷转型获得了公司的极大认可，还对外输出了不少培训。

虽然能频繁地交付，但是却不能频繁地上线，原因很简单：搞运维的家伙们总是希望系统稳定、稳定、再稳定， 稳定压倒一切。所以他们从骨子里不想频繁地上线，那不是给自己找麻烦吗？

这恰恰和自己的敏捷软件开发相反，敏捷就是要拥抱变化啊 ！

想通了这个本质矛盾，张大胖就明白自己是搞不定这个问题了，必须上层出面解决。

张大胖立刻去找CTO Bill，希望他能出点好主意。

4、Dev + Operations = DevOps

让张大胖没想到的是， 运维主管老李已经在Bill办公室里了，张大胖心说不好，这小子也许恶人先告状了。

Bill 一看到愁眉哭脸的张大胖，让他先坐下，听老李把开发和运维之间的“矛盾”和“战争”讲完。

老李唠唠叨叨，说的问题和自己思考的也差不多。

Bill笑着说：“大胖，软件的开发流程基本上就是需求->开发->测试->部署， 现在你的团队已经把需求、开发、测试给‘团结’到一起了， 看来你又要‘团结’一个新的小伙伴了！”

“难道是老李的运维部门？”

“没错。”

“那是不可能的， 我们的目标都完全不同，一个要变化，一个要稳定，怎么可能在一起玩？” 大胖非常诧异。

“不，以后我们要强调业务目标，以用户的价值为唯一的评判标准，团队的考核评价机制也要改变，个体和团队的成功都要放在整个开发-运维生命周期内来进行评价，开发完成了很多用户需求不一定是成功，运维保障系统不down机也不一定是成功！只有用户想要的功能被及时实现了，被成功部署了，被稳定使用了才算成功。 ” CTO总是很擅长用MBA的词汇来讲话。

“就是说要求我们运维和开发紧密合作喽？” 老李接着问道。

“是啊，现在有个热词叫做DevOps，就是把敏捷开发部门和运维部门之间的围墙打通，形成闭环。”

“难道我们要再增加一个部门，叫DevOps部门？ 招聘DevOps工程师？”

“不不，如果再增加一个这样的部门，岂不是又增加了一堵墙？ 我们本来是要打破开发和运维团队之间的隔阂啊。其实运维部门的工作目标不仅仅是让我们的网上约车系统更加稳定和高效，更需要支持业务的快速演化——这一点是和你们敏捷软件开发的目标是一致的啊。”

"但我们也不能频繁部署啊？快速和稳定的矛盾还是解决不了。"老李叹了口气。

“我知道张大胖的团队正在实施微服务的改造，将来再部署的话就不是以一个巨无霸应用为单位了，而是以一个个微服务为单位，那样就简单得多，频繁部署是有可能的，并且出了错回滚也便捷得多，肯地不用你们熬夜了！”

张大胖和老李都点头认同。

“那具体该怎么做？”

“首先是观念的改变，以后你们不能互相推卸责任，互相指责，而要共同担责了！一个项目的开发、部署、维护，是你们双方的事情，双方都要对业务负责，出了什么问题，你们要通力合作，共同解决。这一点你们回去后要给组员多洗洗脑。”

张大胖心想，我们刚刚通力合作回滚了代码。

“还有，”，Bill看了一眼老李， “运维人员也要了解业务，Code变化带来的影响要告知运维人员。你们开发人员工作的开发/测试环境要尽可能地和生产环境一致。”

“运维部门所要求的详细安装步骤实在是太烦人了！” 张大胖抱怨。

Bill说道：“我们先设定一个短期目标，把部署工作完全自动化起来。部署的脚本由老李的运维部门主导，有问题大胖来辅助， 将来这个部署脚本要在所有的环境都用起来！”

张大胖和老李再次点头。

Bill又说道：“最后一点就是度量，例如失败部署的百分比，用户开的ticket数目，故障恢复的平均时间等等，这些老李应该比我清楚。我们会用这些度量指标去衡量DevOps做得到底怎么样， 最重要的是我们无论用了什么工具、方法，如果最后没有减少需求从提出到上线，交付给用户使用的时间，那都是失败。我要求你们两个想尽一切办法，去减少这个时间，不是一次、两次，而是持续、稳定地交付给用户。”

张大胖说：“这DevOps听起来不错，但实施起来估计难度不小啊！”

Bill说道：“我们先选定一个产品作为试点，然后再扩大推广吧！”