本文转载自公众号  码农翻身

开发和运维的战争

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

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

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

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

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

 ......  

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

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

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

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

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

张大胖的回忆

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...... 

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

开发和运维的鸿沟

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

（图片来源：http://www.agilenutshell.com/scrum） 

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

（码农翻身注，参见《白话敏捷软件开发》）

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

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

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

 (开发要求变化，运维要求稳定，图片创意来自 http://dev2ops.org，老刘做了重画) 

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

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

Dev + Operations = DevOps

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

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

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

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

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

“没错。” 

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

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

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

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

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

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

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

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

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

 “那具体该怎么做？” 

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

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

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

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

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

 张大胖和老李再次点头。 

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

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

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