朴素的devops价值观-九游平台

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《圣经·旧约·创世记》第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迁移。但对于企业而言技术永远不是第一位的，最新的未必是最合适的，永远追逐最新的技术，往往丧失了自我的思考和技术的积累。

最近敏捷微信群里沸沸扬扬的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少，这样一来，你就得要考虑更多因素”。一边是需要裁剪，另一边是需要增加，所以执行到最后，成熟的团队的研发流程，大抵都能找到很多相似之处。

现在一提到devops，大家谈的比较多的，是如何用工具搭建流水线、如何用工具搭建容器化开发平台、持续集成应该用什么工具、自动化测试应该用什么工具，诸如此类。

我们常见的持续交付工具有太多是5年前、10年前甚至更早就推出的工具。如果工具是实施devops的关键，那么十年前就有这些工具，理论上当时我们就应该成功实施了devops，实际上我们又做的如何呢？

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

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

martin fowler对ci的定义和建议，从2006年至今，居然未曾修改过。

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

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

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

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

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

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

敏捷的方法有很多，讲了很多年也还任重道远。

丰田tps被各大车企学习了30年，没有哪家能学到真经的。有人说，丰田生产模式，最重要的是背后的kata，即丰田套路，如何使得改善和提高适应性成为组织日常工作的一部分，而kata的书出版到现在也快10年了，好像依然没有多大改观。

敏捷的方法有很多，scrum、精益看板等，safe是大规模的敏捷，devops也有很多种模型。比模型更重要的是背后的原则，虽然这些模型从表象上相差甚远，但其背后的原则却十分相似，比如敏捷宣言的十二条原则、safe的九大原则、以及devops的calms原则。

方法论的表现形式有很多，具体落地执行又根据不同企业千变万化，但不变的、相通的，是背后的原则。好比张三丰教张无忌自己新创的太极剑，张三丰教的快，每次的招式还都不同，张无忌学的快，忘的更快，“不坏，不坏！忘的真快”，武功招式始终是下乘的，心法精髓才是上乘，守住了心法，招式就可以随时创新，不必拘泥。

《雷神3》里的桥段，奥丁的女儿海拉轻易的就捏爆了雷神之锤，索尔灵魂出窍，一时仿佛看到他已故的父亲奥丁。他向他的父亲求助。奥丁：索尔，你是锤子之神吗？那锤子，是为了让你控制你的力量，让你更专注，它不是你的力量的来源，你才是。

devops原本就是偏实践层面的，有很多实践归纳，比如下图的gartner的devops模式和实践图，还有devops地铁图。但这些实践都只见树木不见森林，缺少彼此之间的关联和依赖，需要方法将其串起来。这也是为什么一套辟邪剑法的剑招，缺了葵花宝典的心法，就稀疏平常沦为三流一样。

从practice，到method，到principle；也就是是从doing，到thinking，到being的过程。being devops并非一蹴而就的事情，需要从实践做起，心里要有方法论，过程中始终严守原则。但又不能固守着那把实体的锤子，方法也好，实践也好，都只是达成目标的途径，而原则才是指南针。