原文链接：奢侈的 DevOps 价值观_软件开发生产线 CodeArts_实践实际_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“拍照神图”》， 许峰