文档首页 > > 理论实践> 概览> 朴素的DevOps价值观

朴素的DevOps价值观

分享
更新时间: 2020/05/26 GMT+08:00

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在工具链上的要求:自动化、标准化,那么有什么样的工具能帮我们提供落地实践的基础。

  • 华为云DevCloud服务

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

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

      

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

      

原则、方法与实践

最后让我们来看看原则(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 “拍照神图”》,许峰

  

分享:

    相关文档

    相关产品

文档是否有解决您的问题?

提交成功!

非常感谢您的反馈,我们会继续努力做到更好!

反馈提交失败,请稍后再试!

*必选

请至少选择或填写一项反馈信息

字符长度不能超过200

提交反馈 取消

如您有其它疑问,您也可以通过华为云社区问答频道来与我们联系探讨

智能客服提问云社区提问