朴素的 DevOps 价值观

前言

Nicole Forsgren博士在DOES上的演讲，对里面的一句话Architecture matters...Technology doesn’t，很有感触。

群里有同学也问到，初创公司，业务方向不明确的情况下，如何拆分微服务，我说“架构是服务于业务的，太过超前的架构是浪费”，由此想到架构与业务其实也有相似的关系。

参考Nicole的句式， 从DevOps涉及到的几个维度出发：业务、架构与技术；人、流程与工具；原则，方法与实践 ，于是便有了如下的几句话:

• Business matters...Architecture doesn’t

• Architecture matters...Technology doesn’t

• People matters...Process doesn’t

• Process matters...Tool doesn’t

• Principle matters...Method doesn’t

• Method matters...Practice doesn’t

我称之为朴素的DevOps价值观。之所以朴素，是因为这只是我的一个比较原始的想法，并未仔细推敲与提炼；称之为价值观是因为具有相当的普适性；同时我也希望，如果有幸真的可以逐渐形成价值观，它也应该是简单质朴的。

业务、架构与技术

业务Business，架构Architecture，技术Technology，缩写为BAT

• Business matters...Architecture doesn’t

架构是服务于业务的，关于初创公司，新型的业务，是否需要采纳微服务，回答当然是视情况而定的，但通常建议从单体应用开始。

微服务的价值与挑战一样明显，所以Martin Fowler有如下的一幅图。

初创公司，业务方向还在不断探索，服务的边界是模糊的，即使对微服务的技术储备足够，也不建议此时就搞微服务架构，用最简单直接的方法搞定快速变化的业务诉求。

用贷款买房来类比架构投入，自己出的首付款就像是前期在架构上的投入，贷款就好比是减少一定的架构投入，所需承担的技术债务：

• 贷款买房，预期的是未来的房产的增值，贷款的利息相较起来是可以接受的；创业期也是同样，此时承担一定的技术债务是明智合理的选择。

• 一味追求全款买房，就会错过买房的最佳时间窗口；业务的时间窗口更短，需要不断的快速试错，期望在架构层面一步就位是不现实的。

• 不能贷款过多，否则无法承担月供；架构可以一开始简单些，原始一些，但基本的质量和NFR还是需要满足的；而一旦找对业务方向，又需要快速展开，所以架构在初期具备一定的扩展能力还是需要的。

• 要定期清理债务，房贷车贷过多，即使是有力偿还，生活质量也会下降，脱离了原始购房改善生活质量的初衷；技术债务也需要定期偿还，定期清理，不能让因为技术债务产生的额外时间成本，大于承担技术债务所带来的机会成本。

• 这其实是一个经济杠杆，用短期或长期的负债，来换取时间成本和机会成本。

所以做架构也好，做DevOps也好，需要有经济的头脑。SAFe第一条原则Take an economic view，也有这层含义。

这是一个平衡，一场与时间的赛跑，但总而言之，业务诉求高于一切。

以上所说的都是因为业务战略需要，主动有意识的承担技术债务；如果是无意识的负债，那个叫做奢侈浪费，原本就应该消除。

• Architecture matters...Technology doesn’t

巴别塔：《圣经·旧约·创世记》第11章记载，当时人类语言相通，同心协力，联合起来兴建希望能通往天堂的高塔，“来吧，我们要建造一座城，和一座塔，塔顶通天，为要传扬我们的名，免得我们分散在全地上”。此举惊动了上帝，为了阻止人类的计划，于是他悄悄地离开天国来到人间，改变并区别开了人类的语言，使他们因为语言不通而分散在各处，那座塔于是半途而废了。

架构如此重要，所以一旦业务相对清晰一些，就要根据业务需要，考虑逐渐切换到微服务架构，才不至于堆积太多技术债务，对于可扩展性、可规模化、可部署性等也都至关重要。

优雅的良好的架构更加重要，不要让微服务成为另一座巴别塔。理论上微服务可以最大化利用各种语言的优势，但如果没有好的服务切分与架构设计，微服务只会变成更大的灾难，只会是碎片化而不是去中心化。微服务的目的是更灵活的协同，如果服务之间缺少沟通，就背离了微服务设计的初衷。

Google内部有开发三大语言 C/C++，Python， Java， 分别是官方编译语言，官方脚本语言，和官方UI语言。坚持三大语言意味着内部沟通的顺畅。没有使用最新的技术和语言，并不影响，反而有助于Google快速成为世界顶级的公司。

团队效率高于个人效率，统一技术栈带来的收益，往往大于使用最新技术栈带来额外的维护和沟通成本。

Etsy在2010年，决定大量减少生产环境中的技术，统一标准化到LAMP栈，“与其说这是一个技术决策，不如说是一个哲学决策”，这让所有人，包括开发和运维，都能理解整个技术栈。

另一个例子，Etsy在2010年引入MongoDB，结果是“无模式数据库的所有优势都被它们引发的运维问题抵消了”，最终Etsy还是选择放弃了MongoDB，迁移到MySQL。

DevOps也并非只有Web应用、SaaS或是开放平台才适用，我们听到太多传统银行的转型案例，主机开发的案例，技术并非DevOps的绝对先决条件，虽然开放平台可供选择的工具会多一些，后面我们还会就工具进行讨论。

技术圈总是喜欢追逐潮流，总是存在各种鄙视链。就像前一段看到的PHP与其他各种语言的互喷群；还有类似于容器编排技术，大家一窝蜂的从Swarm、Mesos向K8s迁移。 技术永远不是第一位的，最新的未必是最合适的，永远追逐最新的技术，往往丧失了自我的思考和技术的积累。

人、流程与工具

人People, 流程Process, 工具Tool，传说中的PPT模型

• People matters...Process doesn’t

最近敏捷微信群里沸沸扬扬的CMMI之争，不去论述谁是谁非。我早先也参加过公司的CMMI 2/3级评估，CMMI应该是团队做到一定程度，拿来对自身进行现状评估，用以指导下一步改进的参照。CMMI模型的初衷是好的，设置也还算合理，模型事实上也是在演进的，只是被不合理的使用了。

所以模型也好，流程也好，使用它们的人，以及用法，才是最重要的。

这就好比聚贤庄一站，乔峰用一套太祖长拳，打败天下英雄。太祖长拳，号称三岁孩童都会的拳法，为何可以在乔峰手里发挥如此巨大的威力？

具体的武功招式，方法流程，并不重要，重要的是看谁来用，如何用。

关于流程的另一个问题：如果流程是最重要的，那么到底是流程要求的多好，还是流程要求的少好？

正如上图， Henrik Kniberg在《Kanban vs/with Scrum》里，对 RUP、SCRUM、KANBAN等方法的约束给出了最直观的感觉：RUP有120多个要求，XP有13个，SCRUM是9个，而KANBAN只有3个。RUP是最重视流程和方法的，而KANBAN是最不重视的，孰优孰劣？很难讲，我并不觉得RUP就一定不如KANBAN，RUP在实际采纳时需要裁剪，只是因为裁剪的过程对人的能力要求太高； Henrik说，“Scrum和RUP的主要区别在于，RUP给你的东西太多了，你得自己把不需要的东西去掉；而Scrum给你的东西太少了，你得自己把需要的东西加进来。 看板的约束比Scrum少，这样一来，你就得要考虑更多因素”。

一边是需要裁剪，另一边是需要增加，所以执行到最后，成熟的团队的研发流程，大抵都能找到很多相似之处。

• Process matters...Tool doesn’t

现在一提到DevOps，大家谈的比较多的，是如何用工具搭建流水线，如何用工具搭建容器化开发平台，持续集成应该用什么工具，自动化测试应该用什么工具，诸如此类。

我们常见的持续交付工具图谱，里面有太多是5年前、10年前甚至更早就推出的工具。如果工具是实施DevOps的关键，那么十年前就有这些工具，理论上当时我们就应该成功实施了DevOps，实际上我们又做的如何呢？

http://www.jamesbowman.me/post/continuous-delivery-tool-landscape/

工具当然是重要的，没有工具是万万不能的。

但工具不是万能的，比工具更重要的是使用工具的方法和流程，当然比流程更重要的，是执行流程和使用工具的人。

简单如SVN，复杂如Clearcase，我都看到过在此基础上，实施持续集成非常成功的企业。

Martin Fowler对CI的定义和建议，从2006年至今，居然未曾修改过:

https://martinfowler.com/articles/continuousIntegration.html

即使到现在，又有几个人敢拍着胸脯说，真正能把CI这些实践做到的？

所以流程也好，工具也罢，最重要的是执行的人，而对人而言，关键的是思维模式Mindset，用今年的热词，我称之为原则Principle。

原则、方法与实践

原则Principle，方法Method，实践Practice，缩写为PMP

• Principle matters...Method doesn’t

敏捷的方法有很多，讲了很多年也还任重道远；丰田TPS被各大车企学习了30年，没有哪家能学到真经的；

有人说，丰田生产模式，最重要的是背后的KATA，即丰田套路，如何使得改善和提高适应性成为组织日常工作的一部分，而KATA的书出版到现在也快10年了，好像依然没有多大改观。

敏捷的方法有很多，SCRUM，精益看板等，SAFe是大规模的敏捷，DevOps也有很多种模型。

比模型更重要的是背后的原则，虽然这些模型从表象上相差甚远，但其背后的原则却十分相似，比如敏捷宣言的十二条原则，SAFe的九大原则，以及DevOps的CALMS原则。

方法论的表现形式有很多，具体落地执行又根据不同企业千变万化，但不变的，相通的，是背后的原则。

好比张三丰教张无忌自己新创的太极剑，张三丰教的快，每次的招式还都不同，张无忌学的快，忘的更快，“不坏，不坏！忘的真快”，武功招式始终是下乘的，心法精髓才是上乘，守住了心法，招式就可以随时创新，不必拘泥。

• Method matters...Practice doesn’t

《雷神3》里的桥段，奥丁的女儿海拉轻易的就捏爆了雷神之锤，索尔灵魂出窍，一时仿佛看到他已故的父亲奥丁。他向他的父亲求助。奥丁：索尔，你是锤子之神吗？那锤子，是为了让你控制你的力量，让你更专注，它不是你的力量的来源，你才是。

我们经常会得到锤子，锤子很重要，它是个开始。锤子又不重要，当你能够控制你的力量的时候。

（部分截取自欧兰辉朋友圈的一段话）

DevOps原本就是偏实践层面的，有很多实践归纳，比如下图的 Gartner的DevOps模式和实践图，还有DevOps地铁图。

但这些实践都只见树木不见森林，缺少彼此之间的关联和依赖，需要方法将其串起来。

这也是为什么一套辟邪剑法的剑招，缺了葵花宝典的心法，就稀疏平常沦为三流一样。

从Practice，到Method，到Principle；也是从Doing，到Thinking，到Being的过程。

Being DevOps并非一蹴而就的事情，需要从实践做起，心里要有方法论，过程中始终严守原则。

又不能固守着那把实体的锤子，方法也好，实践也好，都只是达成目标的途径，而原则才是指南针。

小结

我的朴素的DevOps价值观

• 首先， 业务、架构、技术，人、流程、工具，原则、方法、实践， 这九大元素不能孤立的来看，原本就是相辅相成，密切相关的。

Principle背后，其实是人的Mindset思维模式，而一堆人遵循同样的Principle，就演化成了文化Culture。

方法Method也好，流程Process也好，最终都由实践Practice通过工具Tool落地。

DevOps、微服务和容器的三剑客，也是方法、架构与技术与工具的极佳结合。

• 其次，所有这些元素都重要，缺一不可； 但不要舍本逐末 ，需要了解什么是根因，什么是手段。

技术、工具、实践，都是服务于方法和流程的，需要遵循核心的原则，最终的目的是为了商业的诉求，为了快速的价值交付。

方法、实践、工具，都是形；原则、Mindset、人，才是根。

• 最后，我的DevOps朴素价值观

殊途同归，不管是CALM/CALMS，还是SAFe的CALMR，或者是Nicole Forsgren/Jez Humble/Gene Kim的新书Accelerate中的能力成长模型，都只是对同样问题的不同解读。

本文是我原始的对于DevOps思想的解读；DevOps是什么，DevOps有很多面，每个人心中都有自己的DevOps， 我的所谓朴素的价值观，只是个人的一种解读。如果你也认同，十分感谢；如果你不认同，也欢迎一起探讨。

参考：

https://mp.weixin.qq.com/s/wCFM6Ln-iG_G-Um8cad0aA   许峰  “一文收录16张DevOps ”拍照神图””

关于作者

姚冬 资深 DevOps与精益/敏捷 专 家，软件工程专家 ；中国DevOpsDays社区核心组织者之一；Exin DevOps Professional认证讲师；SAFe SPC规模化敏捷咨询师 ；认证Scrum Master, SAFe Agilist ；曾任IBM DevOps产品线大中华区技术总监，金融行业Technical Leader；现任华为云资深解决方案架构师。

扫描二维码，关注个人公众号AgileRunner，获取更多他的原创内容。

路漫漫其修远兮，吾将上下而求索。Don't Fight Stupid, Make More Awesome。定一个小目标，参加上海DevOpsDays~