《DevOps的价值观解析》由会员分享，可在线阅读，更多相关《DevOps的价值观解析（18页珍藏版）》请在金锄头文库上搜索。
1、DevOps的价值观解析目 录1.前言32.业务、架构与技术43.原则、方法与实践144.小结171. 前言初创公司，业务方向不明确的情况下，如何拆分微服务，其实：“架构是服务于业务的，太过超前的架构是浪费”，由此想到架构与业务其实也有相似的关系。参考Nicole的句式，从DevOps涉及到的几个维度出发：业务、架构与技术；人、流程与工具；原则，方法与实践，于是便有了如下的几句话: Business mattersArchitecture doesnt Architecture mattersTechnology doesnt People mattersProcess doesnt Proc
2、ess mattersTool doesnt Principle mattersMethod doesnt Method mattersPractice doesnt称之为朴素的DevOps价值观。之所以朴素，是因为这只是我的一个比较原始的想法，并未仔细推敲与提炼；称之为价值观是因为具有相当的普适性；同时我也希望，如果有幸真的可以逐渐形成价值观，它也应该是简单质朴的。2. 业务、架构与技术业务Business，架构Architecture，技术Technology，缩写为BAT ? Business mattersArchitecture doesnt架构是服务于业务的，关于初创公司，新型的业
3、务，是否需要采纳微服务，回答当然是视情况而定的，但通常建议从单体应用开始。微服务的价值与挑战一样明显，所以Martin Fowler有如下的一幅图。初创公司，业务方向还在不断探索，服务的边界是模糊的，即使对微服务的技术储备足够，也不建议此时就搞微服务架构，用最简单直接的方法搞定快速变化的业务诉求。用贷款买房来类比架构投入，自己出的首付款就像是前期在架构上的投入，贷款就好比是减少一定的架构投入，所需承担的技术债务： 贷款买房，预期的是未来的房产的增值，贷款的利息相较起来是可以接受的；创业期也是同样，此时承担一定的技术债务是明智合理的选择。 一味追求全款买房，就会错过买房的最佳时间窗口；业务的时间
4、窗口更短，需要不断的快速试错，期望在架构层面一步就位是不现实的。 不能贷款过多，否则无法承担月供；架构可以一开始简单些，原始一些，但基本的质量和NFR还是需要满足的；而一旦找对业务方向，又需要快速展开，所以架构在初期具备一定的扩展能力还是需要的。 要定期清理债务，房贷车贷过多，即使是有力偿还，生活质量也会下降，脱离了原始购房改善生活质量的初衷；技术债务也需要定期偿还，定期清理，不能让因为技术债务产生的额外时间成本，大于承担技术债务所带来的机会成本。 这其实是一个经济杠杆，用短期或长期的负债，来换取时间成本和机会成本。所以做架构也好，做DevOps也好，需要有经济的头脑。SAFe第一条原则Tak
5、e an economic view，也有这层含义。这是一个平衡，一场与时间的赛跑，但总而言之，业务诉求高于一切。以上所说的都是因为业务战略需要，主动有意识的承担技术债务；如果是无意识的负债，那个叫做奢侈浪费，原本就应该消除。 Architecture mattersTechnology doesnt巴别塔：圣经旧约创世记第11章记载，当时人类语言相通，同心协力，联合起来兴建希望能通往天堂的高塔，“来吧，我们要建造一座城，和一座塔，塔顶通天，为要传扬我们的名，免得我们分散在全地上”。此举惊动了上帝，为了阻止人类的计划，于是他悄悄地离开天国来到人间，改变并区别开了人类的语言，使他们因为语言不通而
6、分散在各处，那座塔于是半途而废了。架构如此重要，所以一旦业务相对清晰一些，就要根据业务需要，考虑逐渐切换到微服务架构，才不至于堆积太多技术债务，对于可扩展性、可规模化、可部署性等也都至关重要。优雅的良好的架构更加重要，不要让微服务成为另一座巴别塔。理论上微服务可以最大化利用各种语言的优势，但如果没有好的服务切分与架构设计，微服务只会变成更大的灾难，只会是碎片化而不是去中心化。微服务的目的是更灵活的协同，如果服务之间缺少沟通，就背离了微服务设计的初衷。Google内部有开发三大语言C/C+，Python，Java，分别是官方编译语言，官方脚本语言，和官方UI语言。坚持三大语言意味着内部沟通的顺畅
7、。没有使用最新的技术和语言，并不影响，反而有助于Google快速成为世界顶级的公司。团队效率高于个人效率，统一技术栈带来的收益，往往大于使用最新技术栈带来额外的维护和沟通成本。Etsy在2010年，决定大量减少生产环境中的技术，统一标准化到LAMP栈，“与其说这是一个技术决策，不如说是一个哲学决策”，这让所有人，包括开发和韵味，都能理解整个技术栈。另一个例子，Etsy在2010年引入MongoDB，结果是“无模式数据库的所有优势都被它们引发的运维问题抵消了”，最终Etsy还是选择放弃了MongoDB，迁移到MySQL。DevOps也并非只有Web应用、SaaS或是开放平台才适用，我们听到太多传
8、统银行的转型案例，主机开发的案例，技术并非DevOps的绝对先决条件，虽然开放平台可供选择的工具会多一些，后面我们还会就工具进行讨论。技术圈总是喜欢追逐潮流，总是存在各种鄙视链。就像前一段看到的PHP与其他各种语言的互喷群；还有类似于容器编排技术，大家一窝蜂的从Swarm、Mesos向K8s迁移。技术永远不是第一位的，最新的未必是最合适的，永远追逐最新的技术，往往丧失了自我的思考和技术的积累。人、流程与工具人People, 流程Process, 工具Tool，传说中的PPT模型 ? People mattersProcess doesnt最近敏捷微信群里沸沸扬扬的CMMI之争，不去论述谁是谁非
9、。我早先也参加过公司的CMMI 2/3级评估，CMMI应该是团队做到一定程度，拿来对自身进行现状评估，用以指导下一步改进的参照。CMMI模型的初衷是好的，设置也还算合理，模型事实上也是在演进的，只是被不合理的使用了。所以模型也好，流程也好，使用它们的人，以及用法，才是最重要的。这就好比聚贤庄一站，乔峰用一套太祖长拳，打败天下英雄。太祖长拳，号称三岁孩童都会的拳法，为何可以在乔峰手里发挥如此巨大的威力？具体的武功招式，方法流程，并不重要，重要的是看谁来用，如何用。关于流程的另一个问题：如果流程是最重要的，那么到底是流程要求的多好，还是流程要求的少好？正如上图，Henrik Kniberg在Kan
10、ban 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少，这样一来，你就得要考虑更多因素”。一边是需要裁剪
11、，另一边是需要增加，所以执行到最后，成熟的团队的研发流程，大抵都能找到很多相似之处。 Process mattersTool doesnt现在一提到DevOps，大家谈的比较多的，是如何用工具搭建流水线，如何用工具搭建容器化开发平台，持续集成应该用什么工具，自动化测试应该用什么工具，诸如此类。我们常见的持续交付工具图谱，里面有太多是5年前、10年前甚至更早就推出的工具。如果工具是实施DevOps的关键，那么十年前就有这些工具，理论上当时我们就应该成功实施了DevOps，实际上我们又做的如何呢？http:/www.jamesbowman.me/post/continuous-delivery-t
12、ool-landscape/工具当然是重要的，没有工具是万万不能的。但工具不是万能的，比工具更重要的是使用工具的方法和流程，当然比流程更重要的，是执行流程和使用工具的人。简单如SVN，复杂如Clearcase，我都看到过在此基础上，实施持续集成非常成功的企业。Martin Fowler对CI的定义和建议，从2006年至今，居然未曾修改过:https:/ 原则、方法与实践原则Principle，方法Method，实践Practice，缩写为PMP ? Principle mattersMethod doesnt敏捷的方法有很多，讲了很多年也还任重道远；丰田TPS被各大车企学习了30年，没有哪家能
13、学到真经的；有人说，丰田生产模式，最重要的是背后的KATA，即丰田套路，如何使得改善和提高适应性成为组织日常工作的一部分，而KATA的书出版到现在也快10年了，好像依然没有多大改观。敏捷的方法有很多，SCRUM，精益看板等，SAFe是大规模的敏捷，DevOps也有很多种模型。比模型更重要的是背后的原则，虽然这些模型从表象上相差甚远，但其背后的原则却十分相似，比如敏捷宣言的十二条原则，SAFe的九大原则，以及DevOps的CALMS原则。方法论的表现形式有很多，具体落地执行又根据不同企业千变万化，但不变的，相通的，是背后的原则。好比张三丰教张无忌自己新创的太极剑，张三丰教的快，每次的招式还都不同
14、，张无忌学的快，忘的更快，“不坏，不坏！忘的真快”，武功招式始终是下乘的，心法精髓才是上乘，守住了心法，招式就可以随时创新，不必拘泥。 Method mattersPractice doesnt雷神3里的桥段，奥丁的女儿海拉轻易的就捏爆了雷神之锤，索尔灵魂出窍，一时仿佛看到他已故的父亲奥丁。他向他的父亲求助。奥丁：索尔，你是锤子之神吗？那锤子，是为了让你控制你的力量，让你更专注，它不是你的力量的来源，你才是。我们经常会得到锤子，锤子很重要，它是个开始。锤子又不重要，当你能够控制你的力量的时候。（部分截取自欧兰辉朋友圈的一段话）DevOps原本就是偏实践层面的，有很多实践归纳，比如下图的Gart
15、ner的DevOps模式和实践图，还有DevOps地铁图。但这些实践都只见树木不见森林，缺少彼此之间的关联和依赖，需要方法将其串起来。这也是为什么一套辟邪剑法的剑招，缺了葵花宝典的心法，就稀疏平常沦为三流一样。从Practice，到Method，到Principle；也是从Doing，到Thinking，到Being的过程。Being DevOps并非一蹴而就的事情，需要从实践做起，心里要有方法论，过程中始终严守原则。又不能固守着那把实体的锤子，方法也好，实践也好，都只是达成目标的途径，而原则才是指南针。4. 小结我的朴素的DevOps价值观 首先，业务、架构、技术，人、流程、工具，原则、方法、实践，这九大元素不能孤立的来看，原本就是相辅相成，密切相关的。Principle背后，其实是人的Mindse
