更多相关文章阅读
其他
乐神：如何更好的理解 DevOps 革命的潜能
个人简介：
张乐
DevOps时代联合创始人，高效运维社区合伙人，DevOpsDays大会、GOPS全球运维大会金牌讲师。国内首批DevOps Master，前百度资深敏捷教练、架构师。超过十四年敏捷转型、工程效能提升和大型项目管理实践经验，曾主导数百人团队实施DevOps转型，在保证质量的前提下发布频率提高数倍。
前言：
本文将介绍《DevOps Handbook》全书的重要部分：Dev 和 Ops 如何能够组成 DevOps，也就是我们目前碰到的这些问题的根本原因是什么，哪些因素导致了我们的效率、质量无法跟上业务的发展速度，DevOps 方法和实践是怎样解决这些问题的。
一、Dev and Ops Become DevOps
理想的世界
首先描述一个理想的世界，业务、开发、测试、运维一起协同工作，保证组织成功，他们朝共同的目标努力，达到世界级的稳定性、安全性、可靠性。
跨职能团队严格测试业务的假设，哪些功能能够满足用户和企业的需求。整个工作过程是安全的，每个小的团队都可以独立快速做开发、测试、部署。
现实的世界
而我们真实世界里的现实情况是，工作的系统是破碎的，开发和运维通常是对手，测试和信息安全只在项目结尾进行，大多数关键活动需要手工交接，大量工作都要等待下游去完成，经常排队，经常有些问题解决不了，需要上升到管理层做介入和决策。系统部署时间非常长，客户和业务影响非常消极。
这是现实生活的场景，就像Gene Kim讲的，我们一定会有一个更好的方式，我认为DevOps就是这个更好的方式。
二、更好的理解 DevOps 革命的潜能
DevOps是不是真正能够帮助我们成功，它的潜能在哪里？
书中做了一个对比，在1980年代的制造业革命，精益从那时发展起来，很多公司开始采用精益的原则和实践，帮助他们提升生产效率，缩短客户前置时间，提升质量和满意度。
数据表明，在精益运动之前，平均制造的前置周期是6周，70%可以按时交付。2005年普遍应用精益实践后，产品前置周期少于3周，缩短50%以上，95%是按时交付的。
但是没有采用精益实践的组织正在逐步消亡、退出市场，这是制造业的革命。
于此对应的IT革命是在软件交付过程中技术和产品的革命，在1970到1980年代，大多数的新需求需要1-5年时间才能开发完成，成本消耗数千万美元。
2000年由于技术发展，互联网的爆发，敏捷应用慢慢扩大规模，让开发周期缩短到数月到数周，部署生产环境时间也大大缩短。
2010年DevOps已经提出，随着DevOps引入以及云和软件的PaaS化、SaaS化，很多功能的开发都非常快，甚至很多互联网公司可以做到按周做迭代，部署时间非常短，数分钟到数小时之间。
这些组织可以通过快速的实验去验证商业的想法，尤其在互联网时代讲究”唯快不破”的背景下，如果企业能更快的开发系统、更快的试错、更快找到方向，企业的竞争能力和优势是不言而喻的。
DevOps在今天已经在很多公司里取得成功，DevOps的实践已经让他们可以实现每天成百上千次安全的变更，这就是对企业竞争优势最明显的体现。
三、找到问题所在（核心、长期的冲突）
我们逐步往下深入分析，刚才说DevOps很好，但这些传统的组织里为什么不能达到这么好的效果，这里有一些问题是需要解决的，我们把它叫做核心、长期的冲突。
开发和运维之间内在的冲突导致了下行螺旋。
开发和运维有相互冲突的目标，比如开发强调快速响应变更，运维强调稳定、可靠和安全性。
他们之间有不同的激励机制、不同的仓筒间度量和激励会阻碍整个组织目标的达成。
精益里面有很多精华的思路，比如我们要同时关注资源效率和流动效率，保证流动效率很高的情况下，我们再去提升资源效率。不要仅仅关注资源效率的优化，过度的局部优化会导致全局过程的劣化。
下行螺旋的产生具体来讲有三个步骤。
首先，应用和基础设施复杂、缺乏记录，导致很多问题产生。我们常常承诺解决一些技术债务，但是这些技术债务一直被新的需求、新的计划压制，从来没有解决技术债务的那一天，解决技术债务更多变成一种无法兑现的承诺。因为系统的复杂性，产生了技术债务，这是下行螺旋的第一步。
下行螺旋的第二步会让问题更加严重，因为我们有的产品经理、有的业务部门，为了给客户呈现更多超预期的功能，他会承诺一个可能比实际能力更大的目标，而不太注意技术可行性。
这导致了一个不正常的状态，项目只要提到IT部门就是紧急项目，所有问题都是紧急问题。为了支撑这种紧急项目，IT的应对办法只有”走捷径”。
我之前在做程序员的时候深有体会，如果给我一天时间让我开发一个应用逻辑或实现一个类，和给我一个礼拜去实现同样的逻辑，做法是完全不一样的。为了压缩周期，为了更快实现，无形之中就会注入更多的技术债务。
下行螺旋第三步，因为以上情况工作会变得更困难，大家更忙，工作时间更长，沟通更慢，队列更长，整个工作更紧耦合，小问题会导致更大的失败。
这就导致部署时间更长，更多的救火，不停的恶性循环，会进一步剥夺解决技术债的能力。整个IT交付过程可能不断会有新的问题产生，会导致永远无法解决技术债，永远无法做改进。
这些下行螺旋最终导致的结果，就是按月甚至按季度发布。我原来在传统IT公司做顾问的时候，发现这种例子很多，业务可能发布的时候经常需要中断，习惯性的救火和英雄主义的行为，这种下行螺旋的危害非常大。但是有句话很有意思，说其实每个公司都是技术公司，银行只是拥有银行营业许可的IT公司，那么只要IT做得不好，整个公司就不会好，这是说问题的严重性。
四、DevOps：There is a better way
谈了这么多问题，我们也要抬头看看是不是会有更美好事情发生。很多转型比较成功的公司都认为DevOps实际上是帮助他们取得成功的关键因素，比如小团队可以独立开发功能，在类生产环境做验证，代码可以更快、更可靠的发布到生产环境里，代码的部署更有节奏感。
运维人员在这十年里终于可以跟别人一样有正常工作时间了，因为他们不用周五午夜熬夜进行发布，然后整个周末都在解决问题。部署是在工作日进行，客户是无感知的，使用灰度发布、蓝绿部署、金丝雀发布的模式。
变更只要提交到代码库，会自动做很多测试验证，反复确认代码是符合预期设计，并且是安全、可部署的。自动化测试做得很快，可以分钟级反馈。
生产上即使有问题也不可怕，因为我们有很好的监控措施，可以快速发现生产环境的问题，快速解决这些问题。
重要的产品都使用灰度发布的技术，比如马上到双十一了，双十一的这些功能和代码相信提前就会部署到生产环境了，进行不断调整和优化，直到特定时间点通过功能开关开启，这些新的功能才会对用户可见。这是一种很典型的灰度发布技术，通过灰度去控制风险。
还有很多DevOps组织有良好的学习文化，高度信任、相互协作，每个人保证他自己工作的质量。如果出现问题会采用免责的事后故障分析，后面讲DevOps的组织文化里专门有一个章节讲免责文化，通过免责文化促进组织学习。
以上这些描绘大家可能会觉得有些遥远，以我在大型互联网公司工作的经验来看，有很多产品已经完全做到了上面这些效果，所以通过我们的努力这些都是可以实现的。
五、DevOps 的业务价值
关于DevOps的业务价值，前几个月我做过一次分享，解读《2017年DevOps现状调查报告》，这个报告每年都会有一个新的版本，今年已经是第六年。
报告里面提到DevOps有很多优势，比如代码变更能快30倍，代码从提交到运行到生产环境快200倍，采用DevOps的公司他们的市场占有率逐步上升，他们花费更少的时间去补救安全性的问题。
六、DevOps 帮助规模化开发者生产率
实施DevOps还有一些额外的好处。我遇到过很多传统企业，当团队很小的时候，一切都还比较正常，但是当企业变大之后，很多问题就出来了。比如当开发人员增多的时候，整体的效率并没有随着人数的增加而提升，而是人多了但效率却下降了。
很多大公司都有所谓的”大公司病”，部门之间的沟壑和过多的交接导致了更多的跨部门协作的开销，就像《人月神话》里讲的，当项目延迟的时候仅增加更多的开发人无法提升整体生产效率，而且随着每个人的生产效率下降，整体的生产效率也会下降。
反过来，为什么我们说DevOps能破除这个问题，当我们有正确的架构，在正确的技术实践道路上，做正确的文化转型，小团队可以快速、安全的进行开发、测试、部署，如果我们能做到这样，大型组织依然会有非常高的生产效率，我们可以看到很多像谷歌、亚马逊这种公司，公司规模已经非常大了，但是他们的生产效率就跟我们初创公司是一样的。
虽然有数千人的开发人员，但是他们的架构和实践允许他们像小团队一样有极高的生产效率。通过图中的曲线可以看到，传统公司人数提升了，但公司整体的生产效率没有提升，但是对于采用DevOps的公司来讲，随着开发人员数量增长，生产效率也会同步提升。这也是DevOps能够帮助我们很关键的因素，实现开发者生产效率的规模化。
END