DevOpsDays有感 - DevOps概谈

  有幸参与了3月18号在北京举办的DevOpsDays活动，这也是DevOpsDays这个全球性的DevOps聚会第一次落地中国。官方给出的数据是，大会吸引了将近1200名参会者。在此期间，也有机会见到了被业界称为“DevOps之父”的Patrick，以及《持续交付》的中文译者乔梁。从火热程度、嘉宾阵容以及票价上来说，这样的技术活动可算是较为盛大了，但是从一个开发者的角度来说说，会议中的“干货”才是我最期望看到的内容。本文将会从个人角度来回顾这个会议中的一些内容，并针对其中DevOps相关内容给出一些自己的认识，如有不正之处，还望各位读者指正。

<!--more-->

会议整体流程与内容

  首先，活动的国际化程度还是很值得认可的，除了像Patrick、John Wills这样的国外演讲嘉宾出席之外，还是可以看到不少国外的参会者，并且还配备了专业的同声传译团队和设备。参与的企业也都是与DevOps强关联的技术企业，虽然在会议内外难免会有不少相关企业的软硬广，但是除了个别以自家工具为主题缺乏实质内容的演讲之外，总体感觉也不算过分。

  上午的前两个简短演讲来自活动的两位联合创始人。各十分钟的演讲除了讲述DevOpsDays来到中国的历程，感觉不出来太多DevOps真正技术相关的内容，中间还自带了些小广告，让人不得不对本次活动产生一些怀疑的想法。还好接下来的几个演讲还算有货，Patrick的slide内容足够吸引人；乔梁的内容让我略感失望（真的是冷饭，且没找到重点，PPT也是不够惊艳，也可能期望比较大吧）；李俊提到的几个新的概念，可以看出他们的重点在于数据分析；John的内容主要集中在DevOps文化上。下午的三个分会场以及两个讨论会场的设置按主题区分同时进行，虽然节省了很多时间开支，但选择过多，让很多人不得不做出舍弃。另外，不知道组织方自己会不会针对活动做Retrospective，反正作为参与者，我是没有看到任何关于本次活动反馈的问卷调查(不知道是巧合还是什么原因，该文发布后一天，活动官方在微信群内发出了反馈问卷)，虽然几乎每个演讲都提到了反馈文化的重要性。

  而关于内容，个人觉得DevOps领域高屋建瓴的总结多于切实有效的实际案例，作为一个在TW工作两年多的家伙，DevOps是我进入TW的第一天就已经被“灌输”了的概念❶，敏捷也可谓深入每天的工作，所以会议中提到的诸多概念、原则、结构等内容个人感觉不够惊艳，反而就像乔梁在演讲中说的那样 - 有种炒冷饭的感觉。不过，这不可谓大会中的内容没有价值，相反，这些内容都应该是各位结合实际提炼出来的精华，所以我还是打算用以下几个方面来再炒一碗“冷饭”，希望可以帮助大家进一步理解、或者作为简单的参考。而于我个人而言，自知这些内容不一定完全保证正确，毕竟一切方法论都需要因地制宜，但希望能够起到总结和督促的作用吧。

  在参加DevOpsDays之前，我阅读了伍斌伍道长 实例化DevOps原则 一文，深以为然，如果你还对DevOps知之甚少，推荐你阅读一下这篇文章。里面提到了两个相对主流的DevOps框架/原则：CALMS 和 The Three Way，之后在这次活动中的多个演讲中，都看到这两大框架的影子。本文我将不会围绕着这两个框架展开，而是以我自己的思路在4个维度叙述，当然，不可避免地，你会发现所有这些还是逃脱不了这两个框架/原则。

1. 人 - 组织 - 文化

  CALMS原则第一字母C表示Culture（文化），它其实算是DevOps中的基本和核心，但对于很多企业和组织来说，也经常是最难实现的一部分。而文化的载体可以说是一个组织/团队，它的实现需要靠人，所以最基本的还是人。如何消除组织间的壁垒，促进人与人之间的沟通合作，是DevOps运动需要考虑的一大课题（当然，这往往也算是敏捷组织转型的企业需要考虑的）。DevOps强调合作，强调沟通，强调在组织/团队内建立信任，这其实也是敏捷所倡导的。这让我想到，曾经很多次，我们在公司内部关于敏捷的讨论中，我们都会提到一点“没有信任，就别谈啥敏捷”，是的，自组织、高效的合作和沟通 肯定不是建立在充满怀疑和问责的环境中。

  然而，“如何构建信任，如何高效合作”这不是一个简单的问题，也不会有一个普适的答案，因为这涉及企业文化类型、管理学等等相关内容。但是理想情况下，我们会追求建立全功能团队（实际真正的敏捷组织内几乎都是全功能团队），实现组织解耦。这里，我个人很赞同张乐在演讲中提到的，全功能团队应该具备的三个特点：

• Overall Goal
• T-shaped
• Co-located

  这三点，第一次看到可能还不是特别容易弄明白。但是如果你一直工作在敏捷团队内，这三点便不难理解。Overall Goal 表明所有团队成员都有同一个目标 - 往往是保证某个软件/更改按质按量的准时交付。T-shaped 表示团队成员的技能应该呈现T字型，稍微形象点解释的话，就是你在专注某项技术或者某个内容的开发时（T字的那一横），也要关注团队整体技术或者产品整体业务（T字那一竖）。Co-located 是说团队成员的位置是随时变动的，这其实是期望团队成员多和团队内外不同的人交流，加深合作沟通的一种表现（就像在结对编程中，我们也经常switch pair）。这三个特点，其实可以实现资源效率到流动效率的转换❷，关注的点在于产品交付完成，而不只是开发关注开发结果，运维关注运维内容，两者互相不满互相指责（其实全功能团队里没有绝对的Dev和Ops之分）。

  不过在这次活动的私下交流中，还是能感觉到很多人仍然觉得开发就是开发，运维就是运维，DevOps只是运维工程师，顿感路漫漫其修远兮。

2. 代码 - 工具 - 基础设施

  说到代码，其实是一个软件产品的根本，如果把一个产品比较一栋建筑，代码就是它中间的砖块、钢筋、混泥土等建材。而保证建筑能够被顺利且高质量的建成，其实并不是把这些建材简单堆砌就可以实现的，需要设计，需要选材，需要度量。软件也是这样，需要考虑设计❸，考虑技术选型，考虑度量。

  精益开发（CALMS中的L，lean）中内建质量的说法其实就是要求我们能够在开发的同时考虑，越早发现缺陷，修复它们的成本就越低，这其实也契合The Three Way原则中系统思考、不断试错的思想。其实敏捷开发中各个流派中的很多方法和理论都可以算是内建质量的一种体现 --- TDD、测试金字塔，甚至结对编程。

  为了更好的开发编写代码，也为了让代码更好的工作，并了解、探析其运行状态，我们往往需要借助各种各样工具。大量的工具也伴随着DevOps运动的发展，顺势而来。版本化、测试、软件度量、可视化、监控、部署等等相关的工具❹，让代码的编写、测试、维护、度量过程变得更加简单，也更加复杂。而这些工具，随着技术的发展，也走在了自动化的路上，以自动化配置管理工具为例，不管你是Ansible还是Chef、Puppet、SaltStack甚至是Shell脚本、PowerShell脚本，基本都是去除非自动化情况下的痛点，解决不同场景、不同平台下的基础设施管理问题。不过，我个人也赞成不能过分关注工具本身，毕竟所有这些都是为了解决特定的问题或者优化某些具体的过程，再好的工具也不能脱离软件本身而论。

  几乎所有的代码运行都需要一定的环境基础，用更加专业的词汇，那就是软件的基础设施。刚刚提到的自动化配置管理工具，其实也就是针对基础设施的管理，它们大多也是“基础设施即代码”这一概念的实现手段。基础设施即代码，让我们用代码的形式管理和维护软件环境/基础设施，这不仅仅是针对现实机器上的基础设施，现在主流的工具/技术也让云平台❺的基础设施管理变得简单。当然近年来，另一种“简化”基础设施管理的方式也越来越流行，那就是容器，让代码运行和基础设施配置都在容器中进行，环境的纯净性、隔离性得到巨大提升。而云平台、容器化的兴起，也衍生了很多其他工具，如容器的集群管理工具、服务注册与发现等等。

3. 分支 - 流水线 - 持续交付

  现代的开发团队，基本上都是多人的分布式团队，借助于版本控制工具，很多时候我们首先需要考虑的是如何设计项目的分支模型。我个人觉得，分支策略其实也是工作合作模式的一种代码层级体现。关于这方面，现阶段有很多成熟的模型体系可供参考，但不管你是用git flow、github flow、trunk based还是自定义的分支模型❻，一个大部分人应该达成的共识是：除了主分支，我们应当尽量避免存活过长的其他分支的出现（这一点似乎在git flow里面经常被打破）。按照The Three Ways原则，我们应当尽早的试错，持续做试验，应用在分支模型上，就是需要大家及早地合并那些衍生分支，及早地发现可能存在问题（运行各层级的自动化测试），免去长时间积累下的合并之苦，这也就可以继续谈到持续集成、持续交付❻了。另外，Pull Request也可以算是分支模型里面的一个高频词汇了，它在分支合并前加了一道步骤，可以看做成一种Code Review❼，是一种更加安全和相对有益的合并举措。

  持续集成、持续交付恐怕是大家听到次数最多的关于DevOps的词汇了。不过每次在提到这些的时候，很多人包括这个DevOpsDays的嘉宾在内，都应该会说到一个词 -- 构建流水线，也就是我们所说的pipeline。其实，流水线是自动化的多方体现，测试、构建、部署都应该在一个健全的CD流水线上自动实现。一次提交，只要顺利通过流水线的各个步骤，就是一个可以发布的版本。它提高的不只是发布的效率，更是利用机器实现对代码的频繁验证，当然，也不只是代码，同时还是对部署过程的验证（在发布之前会在多个环境中部署验证软件）。近年来，随着CI/CD工具的逐渐流行，人们也逐渐发现在维护和使用它们的过程中还是暗藏一些痛点，所以又多了一种实践/概念 --- 流水线即代码。这其实和基础设施即代码的思想类似，就是用代码来表示我的流水线结构和配置，并且放到版本控制中，这里我就不再赘述，感兴趣的读者以读读这篇文章 流水线即代码。

  其实说到分支合并、流水线、CI、CD，概括出一个核心词汇的话，那就肯定是反馈。Pull Request可以获取代码层级的反馈。及早合并分支、持续集成，就是希望及早地获取代码集成后的反馈。而持续交付涉及整个交付过程的反馈环，代码集成的反馈，部署到各个环境后的反馈，客户验收的反馈等等。

4. 容器 - 微服务 - 新概念

  刚刚提到的全功能团队，其实是为了实现组织解耦，代码上的设计和模式使用往往是为了代码解耦，而容器的出现，又导致另一种层级的解耦，那就是服务解耦。它让变化的环境变得可控，可随时创建销毁的特点让“一次构建，多次运行”、“配置一次，运行在多个环境”成为可能。服务的解耦很多时候似乎也可以让多团队之间解耦。微服务的架构似乎也应运而生，其实对于微服务的架构，大部分人都应该了解到它也不一定是完全完美的，也不一定全部适合所有场景❽。但是随着组件化趋势的不断发展以及容器的大火，它势必为今后的一个重大课题。而关于容器的开发模式，DevOpsDays里面徐磊提到的一点：用容器开发容器，颇有道理。说简单点，就是利用容器的可以远程调试的特点，实现在真实的容器环境里面开发调试。

  当然，DevOpsDays上面还是接触到几个不是很主流的，相对“新”的概念。如Patrick和多个嘉宾都提到的ChatOps，它就是一种强调团队沟通协作的理念，通过协作缩短反馈环节。而刘俊提到的SRE(Site Reliability Engineering)其实最早是由Google提出的一套运维理念❾，另一个概念AIOps偏重智能算法，也可能是未来的一种趋势。由于在这两个概念上未做过多研究，在这里就不做太多叙述啦。

  另外，本次大会中似乎没有提及（当然，也有可能是提及了但我错过了），一个比较不错也可能成为未来趋势的新概念：Serverless无服务器架构。它其实是依托类似AWS这样的云服务，尤其是在像Lambda这样的东西出来之后，它似乎让大家进一步忘记软件服务开发的过程中基础设施管理的成本了，这里我也不会赘述啦，感兴趣的读者依然可以阅读Martin Fowler的Serverless一文。

最后，如果用一句话...

  说了这么多。最后，思索一二，如果让我用一句话总结下来，DevOps说到底，可以是：

  为了更快、更有质量的交付可用软件，我们使用一些工具（容器、自动化工具、版本化工具、可视化工具等），遵循一些原则（基础设施即代码、流水线即代码等），打破职责间的壁垒，不断地验证软件的正确性（包括但不仅限于测试、构建和部署过程），且乐意并更快地收获反馈。

注释

1：虽然当时不一定真的理解，详情可以参考我14年底的文章 初涉ThoughtWorks。 2：传统的组织结构更加关注各个团队角色所占有、产出的资源，多少会存在利益冲突，而全功能性的团队关注的是如何让产品生产线流动，享有一个共同的目标。 3：如代码的解耦，职责分离，其间，我们可能会用到一些解决经典问题的设计模式。 4：其中，就拿最基本的版本化工具来说，不管你是说git、svn甚至更老的CVS，其实从某种意义上说也是为了协作和沟通；度量工具，其实也为了能够获得各种层次的反馈。 5：如AWS、Azure、阿里云等等。 6：关于分支模型和CI/CD，不得不说两者之间还是存在着微妙的关系，这里不做过多延伸。不过，可以关注之前我之前写的一篇文章 关于两种CI/CD策略以及git分支模型的思考 7：实际上，我们心目中一场好的Code Review应该像这样：Code Review: 超越“审、查、评”的代码回顾。而不是PR中的review。 8：可以参考本文：微服务的优缺点 9：可以参考本文：SRE系列教程