朴素的 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）这个维度：

点击放大

• Business matters...Architecture doesn't.

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

  微服务的价值与挑战一样明显。

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

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

  贷款买房，预期的是未来的房产的增值，贷款的利息相较起来是可以接受的。

  创业期也是同样，此时承担一定的技术债务是明智合理的选择。

  一味追求全款买房，就会错过买房的最好时间窗口。

  业务的时间窗口更短，需要不断的快速试错，期望在架构层面一步就位是不现实的。

  不能贷款过多，否则无法承担月供。

  架构可以一开始简单些，原始一些，但基本的质量和 NFR 还是需要满足的；而一旦找对业务方向，又需要快速展开，所以架构在初期具备一定的扩展能力还是需要的。

  要定期清理债务，房贷车贷过多，即使是有力偿还，生活质量也会下降，脱离了原始购房改善生活质量的初衷。

  技术债务也需要定期偿还，定期清理，不能让因为技术债务产生的额外时间成本，大于承担技术债务所带来的机会成本。

  这其实是一个经济杠杆，用短期或长期的负债，来换取时间成本和机会成本。所以做架构也好，做 DevOps 也好，需要有经济的头脑。SAFe 第一条原则 Take an economic view，也有这层含义。这是一个平衡，一场与时间的赛跑，但总而言之，业务诉求高于一切。

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

• Architecture matters...Technology doesn't.

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

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

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

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

  团队效率高于个人效率，统一技术栈带来的收益，往往大于使用最新技术栈带来额外的维护和沟通成本。Etsy 在 2010 年，决定大量减少生产环境中的技术，统一标准化到 LAMP 栈。“与其说这是一个技术决策，不如说是一个哲学决策”。这让所有人，包括开发和运维，都能理解整个技术栈。另一个例子，Etsy 在 2010 年引入 MongoDB，结果是“无模式数据库的所有优势都被它们引发的运维问题抵消了”，最终 Etsy 还是选择放弃了 MongoDB，迁移到 MySQL。

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

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

人、流程与工具

接下来，再让我们看看人（People）、流程（Process）和工具（Tool）这个维度：

点击放大

• People matters...Process doesn't.

  最近敏捷微信群里沸沸扬扬的 CMMI 之争，我们不去论述谁是谁非。早先很多公司也进行过 CMMI 级别的评估，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，实际上我们又做的如何呢？

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

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

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

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

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

  由于工具本身对于 DevOps 的也扮演着不可或缺的角色，因此在结束这个维度的内容之前，让我们来看看针对 DevOps 在工具链上的要求：自动化、标准化，那么有什么样的工具能帮我们提供落地实践的基础。

• 华为云 CodeArts 服务

  CodeArts 提供软件开发全生命周期的云端 DevOps 工具链，帮助团队真正实现自动化，标准化，配置化。

  CodeArts 提供基于 Git 的版本控制系统，不只将代码版本化，而是版本化管理一切与环境有关的配置。

  CodeArts 可自定义的自动化部署流水线，提交代码自动触发，帮助团队实现持续交付，为团队带来自动化，标准化。

原则、方法与实践

最后让我们来看看原则（Principle）、方法（Method）和实践（Practice）这个维度：

点击放大

• 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，这里的所谓朴素的价值观，只是一种解读方式。只希望能为各位开发者，在读后带去更多的思考，找出更适合自己的道路。

本文参考资料：

• 《一文收录 16 张 DevOps “拍照神图”》，许峰