上篇写了个《DevOps都是被逼出来的。。。》，有很多读者问是怎么个过程逼出来的，就看这篇吧。
这篇当时是右军给我的命题作文，要聊聊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的实施和落地，不是某个点的改变，它必然一个体系的要求，比如业务上，体量和场景达到一定规模，技术层面必须达到一定高度，组织层面必须具备足够的力度和决心，同时文化宣导上覆盖要足够广，足够彻底。
而开发在这个过程中的落地执行，无疑又有着决定性的作用。
开了个星球（当前免费），专门聊聊SRE，云计算、运维这些事，星球里互动性更强一些，有很多想法和内容，我会随时写到里面，慢慢会沉淀很多内容，当然如果内容积累足够多了，就要提高进入星球的门槛了。
大家有兴趣可以加入下，记得一定写上备注，真实姓名+公司+职位，否则不会通过奥。
本文分享自微信公众号 - 成哥的世界（forrest_thinking）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
