共计 5490 个字符，预计需要花费 14 分钟才能阅读完成。
原文链接：奢侈的 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“拍照神图”》， 许峰
