前段时间接到右军的命题作文，要聊聊DevOps中开发的作用和主动性这个话题。
命题作文的好处就是，逼迫自己从不同的角度去思考同一个事物，这段时间以来也让我不断回顾和琢磨，对这个问题又有了很多新的认识。
我们讲现在的DevOps和运维，之所以越来越受到重视，跟分布式架构在业界的广泛实施这个背景是紧密相关的。
也就是，DevOps是分布式架构场景下的DevOps，运维是分布式架构场景下的运维，会更加的准确，后面我们介绍的案例基本都会以此为背景。
回到开发的作用和主动性的命题上，其实我的理解，应该是在这种背景下：
系统复杂度远远超出人力掌控范围，超出人脑认知范围，开发和运维必然要紧密协作，共同面对新挑战和新场景的问题。
也就是，除了合作，别无选择，如果有任何一方不主动，就会造成效率的极大下降，以及稳定性的极大损害。
面对这样的场景，多少有些“被动”意味，所以所谓的“主动性”更多的是被现实场景，被业务场景倒逼出来的。
这里，我根据不同公司的做法，总结了三种典型的模式来参考，以便于后面更深入的分析：
第一种，文化使然，开发主导模式。
最典型的就是Netflix的“Freedom and Responsibility”，Netflix号称是没有运维岗位的，连SRE角色也只有极少数，与此类似的还有Amzon，他们的运维工作基本都是由开发自助完成。
无论极致的Netflix，还是大名鼎鼎的Google，还是老牌的Amzon，正是在这种自由和责任共存的文化驱动下，无论开发还是架构师，天然地对自己的系统、平台甚至是应用端到端负责，从而逐步构建起了能够支撑海量业务的基础设施和服务平台。这样到了后期，很多繁杂和重复的工作，开发都可以基于平台自助完成，而不是依赖运维的人来完成。
所以，我们仔细观察，你会发现，国外的大厂其实极少提DevOps这个概念，因为他们天然就是这么干的，是理所当然的一种研发模式。
这种模式对于组织来讲是最为高效的，但是文化导向之所以能够发挥这么大的作用，也有一个极为重要的前提就是技术团队和人才的能力问题，只有当团队能力足够强的时候，才能够支撑起如此完善的体系建设，再加上国外强烈的工程师文化，让他们能够耐住性子，沉下心来，稳扎稳打。
反观国内，一个是技术人才的能力还达不到这个程度，再就是，国内的公司和产品往往追求业务增速和发展，往往会牺牲一些非功能性的能力。
单纯从技术角度来看，国内公司在这方面很明显是落后很多的。
第二种，自上而下的决策，开发和运维“被动”执行模式。
最典型的就是阿里的DevOps转型，阿里应该是在2015年左右，甚至更早，就启动了DevOps转型。
体现在组织架构上，最明显的就是取消了PE应用运维这个岗位。
这个转型有两个必要因素：
第一个，多年技术积累，基础设施和平台非常完善。
原来基础能力不够的时候，很多运维工作也是要依赖PE这样的角色人肉去完成，但随着平台不断完善，有很多事情，开发完全可以基于平台自助完成，而不再需要多一个PE这样的环节去做。
所以，从技术角度，阿里已经完全具备了DevOps的基础条件，从组织效率角度，提升研发整体的交付效率也势在必行。
第二个，也是最关键的一点，自上而下的决策执行。
虽然基础条件具备了，这时无论是开发还是运维，都不具备能力去做组织层面的调整和融合。
但是，从研发高层的角度，当意识到DevOps转型时机成熟，且经过论证和实践是可以带来效率极大提升的时候（国外大厂的模式已经证明），组织上的职责和岗位调整，就势在必行了。
我在几个大会上听到的分享，以及线下与经历DevOps转型的工程师交流，可以看到，上面的决策一下达，研发团队就制定了非常详细的交接和培训计划，原PE团队职责逐步交接到开发团队，经过多轮培训和交接后，历时两年左右，完成了整个DevOps的转型。
讲到这里，我们可以看到，对于两个团队来说，都有一些被动的意味。但是，这个结果的达成，是离不开前期这么多年，技术能力不断积累完善这个前提条件的。
所以，准确一点讲，应该是结果达成的阶段相对被动，但是前期的准备和积累阶段，都是主动的。
稍微总结一下，以上两种模式的案例，我们可以看到都是大厂的案例，他们有一个共同的规律，就是基础设施和基础平台完善且强大到一定程度后，DevOps转型和落地更多的是水到渠成的结果。
但是，上面的案例已经是结果，但是对于一般企业，DevOps的演进过程应该什么样的，这个过程中，开发应该怎么做？运维应该怎么做？
下面我就结合蘑菇街的案例讲一些更细节的部分。
第三种，技术战略项目切入，开发和运维合作共建
所谓技术战略项目，可以理解为当业务发展到一定程度或某个阶段时，技术层面为了更好的适应业务趋势和场景，而做出的一些整体技术架构调整，这里可能包括软件架构、研发组织架构、基础设施建设等等。
我回顾了下，蘑菇街整个DevOps体系的逐步形成，基本就是在这些技术战略项目的执行中，不断形成和完善的。
第一个，Java服务化体系的建设
2015年初，蘑菇街研发部启动业务架构的服务化项目，对原来的PHP单体架构改造。
当时，这个项目是为了能够快速响应业务变化而做出的改变，并不是单纯为了DevOps的目的。
不过，后来项目进行过程中，我们遇到了分布式架构体系下的一系列效率问题，比如应用发布、资源申请，快速扩容、问题定位以及故障响应等，统统跟不上节奏了。
到了这个阶段，我们发现效率上不去，工具跟不上，最关键的问题就在于各种标准缺失。
所以，我们花了大量时间和精力做了标准制定，从机型选择、OS版本、系统参数、到应用命名、部署目录、依赖管理，配置管理再到后面分布式组件和框架的标准约束等等。
再往后，我们开始基于标准又配套提供了很多解决棘手问题的工具平台，一开始这些平台很简陋，但是能解决问题，再往后慢慢完善和重构，能力就越来越强大了，比如持续交付系统。
开发在这个阶段，最主要的作用就是与开发共同制定标准，并在后续的架构设计和研发过程中，严格遵从标准，否则，接入不了工具平台，效率和稳定也就谈不上了。
一开始强制约束，不按标准来，不给资源、不给发布，开发感觉非常不灵活，被限制了创造力，但是随着后来效率的提升，大家都慢慢认可了这种模式，而且会主动执行。
这个过程下来，我们所理解的DevOps，其实是被现实场景倒逼出来的，开发和运维必须更紧密的合作，一步步尝试和探索，才能让团队运转下去，其它别无选择。
第二个，电商大促的常态化
电商企业的大促越来越频繁，已经呈现出日常化的形态。
蘑菇街也不例外，为了保证业务峰值状态下的稳定，技术手段上，对线上压测、故障模拟、预案演练以及容量评估等，提出了更高的要求，从这个维度，又在驱动着整个稳定系体系的不断完善。
这里要做的非常关键的一点，稳定性的标准化，并且在开发阶段严格执行。举个例子，我们要做限流，在开发的代码中，哪些API、函数需要限流？限流的阈值多少？限流对外部的影响是什么？
这就需要对业务和代码都非常熟悉才可以，不然限流的点的方式不对，稳定性就无从谈起。
对于容量评估、全链路压测等等也是一样，只懂技术，不了解业务场景和模型，就没法有效实施。
所以，在这种场景下，开发是要发挥核心作用的，运维可以通过指标和模拟等手段去推到，但是始终是黑盒，作用终究有限。
第一和第二个项目中涉及的平台建设细节，我就不再赘述了，大家如果感兴趣可以看我公众号的文章或者极客时间专栏文章。
第三个项目，业务上云
到了2018年，我们决定业务整体上云，依托于腾讯云完善的基础设施体系，将更多的精力专注在业务研发领域。
这里带来的一个变化就是，很多服务都是现成的，如云主机、缓存、消息、数据库等等，申请即用，大大提升了我们资源和服务交付的效率，但是面临的问题，就是大量的服务实例成本如何管理的问题。
最简单的方式，就是将能力暴露出来，由开发自助使用，而不是再通过运维审核或控制，最终通过成本分摊来控制合理使用。
之前，自建IDC模式，服务器一旦采购，成本就已经形成，用与不用，成本并不会有差别。
但是上云之后，按需付费，开发就要开始形成成本意识，必须要对自己所做事情，对自己的设计和写的代码的的ROI，有明确的分析。
场景不同，要求也就完全不一样了。
限于篇幅原因，这部分内容，包括我们在云上的双活站点建设，我会再开新文章来介绍我们的经验。
三个部分做个总结，我们可以看到运维更像是技术运营，在驱动一些事情，但是真正的落地和执行，仍然在开发。同时，我们可以感受到，双方合作是否顺畅和紧密，心态和意愿，也是关键的要素。
最后，总结
上述的过程，如果倒过来看，其实就是一个公司随着业务发展和增长，技术体系演进的一个缩影。
也就是，业务场景驱动，组织手段推进，文化导向覆盖。
蘑菇街从无到有的建设，随着体系完善，终究会走向阿里DevOps转型后的模式，而阿里随着转型的完成，更深入的发展，必然会朝着Netflix的文化导向的趋势发展，让团队中每一个技术人员都能够具备端到端意识。
所以，DevOps的实施和落地，不是某个点的改变，它必然一个体系的要求，比如业务上，体量和场景达到一定规模，技术层面必须达到一定高度，组织层面必须具备足够的力度和决心，同时文化宣导上覆盖要足够广，足够彻底。
而开发在这个过程中的落地执行，无疑又有着决定性的作用。
作者介绍：赵成（谦益），美丽联合集团运维经理，负责美丽联合集团（原蘑菇街、美丽说）运维团队的管理及运维体系建设工作。拥有近10年研发和运维经验，见证和参与了多个电信级和互联网产品从无到有的创造、从微量到海量的成长过程，也经过多轮炼狱般的磨练和蜕变积累了非常丰富的电信级和互联网业务研发和运维经验。
