由数人云、优维科技、中生代社区联合发起的markdown
系列 Meetup 《 DevOps&SRE 超越传统运维之道》框架
前后在深圳、北京举行过两场运维
7 月 15 日上海站，敬请期待微服务
▼工具
王一男老师在《 DevOps&SRE 超越传统运维之道·北京站》活动中，结合百度的实践，讲述落地 DevOps 时，首先要拆掉业务→开发→测试→运维中间的这三面墙，一块儿来看一下吧！性能
数人云友情提示：前方全文约 9000 字，且不含标点符号~建议先收藏~单元测试
效率=工具+方法+实践的结合
最近有一篇比较火的文章大概说 DevOps 不是工具的堆砌。如今出现一种概念：将研发流程自动化就是 DevOps，我的不敢苟同。在百度内，研发效率的提高除了工具以外，更可能是这些工具与方法以及一些实践的结合，来共同支撑研发效率的提高。学习
再往前一步，在一个大版本开发的闭环中，产品如何更好地管理、需求如何更好的肯定，百度也总结了一些比较好的实践。这些实践通常都方法和工具的集合，同时在实际项目中，将其落地实践，最后概括总结并分享出来。因此并非仅有工具就能把全部事情都作好，但没有工具也很难作到。测试
任何事情想要达成，都依赖于人、方法和工具的结合。编码
任发科老师也提到：最好不要作一个大而全的工具。以前百度的工具也曾是 All in one 的，那时候发现虽然一个工具能解决全部问题，但一线同窗感受工具特别重，不灵活。
当公司的规模或者团队逐渐扩大之后，就会发现工具适用于全部团队，让工具去适应团队的需求也不方便，因此在几年前百度就把 All in one 的工具拆分红了三个更专一的工具：
项目管理或需求平台 iCafe，它主要作需求管理和项目管理，目标用户是项目管理的角色：产品经理以及一些研发团队的 Leads。
代码管理工具 iCode，全公司全部工程师都在使用 Git 的时候会遇到 Git 规模化的问题，一万多名工程师天天频繁的向这个 Git server 中提交代码，此时会遇到一些性能问题，因此 iCode 工具首先要解决的就是 Git 规模化的问题。同时还要保证万人研发的“快”和“有序”。
持续交付平台 iPipe，它负责把从把从代码到发布到部署的过程经过可视化流水线串联起来。
软件交付过程当中的三面墙
当 DevOps 的概念逐渐被了解后，你们就一直在致力于实现持续交付，怎样能让业务的想法、或产品经理的想法、抑或是客户的需求能快速经过开发和测试，并能快速发布上线，真正作到持续交付？
其实交付的不只仅是产品功能，更是交付客户的价值，怎样能作到这一点呢？要想达到持续交付的这个过程，团队之间的“墙”要拆掉。
DevOps 在拆墙，敏捷研发实践也要拆墙，到底有几面墙呢？将它画了出来，在一个团队里面，不管团队规模或大或小，即使角色分开后，这个墙可能也还存在。
主要能感到这三面墙（上图）的存在，业务和开发之间有一面墙，开发同窗可能会有很是深入的认识。开发和测试之间是有一面墙的，有一些团队可能开发测试间合做比较紧密。但在一些大的产品线上，开发和测试的墙仍是存在的。
最后的是测试和运维的墙或叫开发测试团队和运维的墙。今天谈的 DevOps 是要重点拆除的墙。但前面的墙是怎么被拆掉的呢？前面两位老师讲到：用精益的方法、敏捷的方法去打通前面的墙。
现在你们都在学习 DevOps，但是实践 DevOps 真正解决了最重要的问题吗？我的表示怀疑。
都在说 DevOps 有一个好处是能让运维自动化、可视化，使得工做更高效，可是 DevOps 只是为了解决运维的问题吗？
让价值能快速地流动到客户那里。若是想让价值从前至后快速流动，必需要把前面的墙打掉，若业务和开发那面墙、开发和测试那面墙仍旧存在，即使打通了测试和运维这堵墙也没太大意义。如下有一组数据来证实观点，其实关于 DevOps，国内可能还没有准备好。
真的只剩最后一面墙了？
这是 CSDN 在 2016 年对国内敏捷方法覆盖的一个调查。假设精益、敏捷方法可以把前面的两堵墙打掉，在 2016 年的国内，用 Scrum、用看板、用 RUP 这种方法和实践的企业及团队加起来不到 30%，更多的国内企业或团队一方面是在本身定制的流程，用瀑布的在 20%左右，因此一个结论——去年国内敏捷方法、实践的覆盖率也就 30%左右。
你们会看到企业里面有一部分团队是在尝试使用敏捷方法，但整个企业还处在所谓“敏捷转型”的过程当中。
再对比一下欧美 2016 年相似的一个统计——
-
首先统计显示 8%的企业或者是团队所有使用了敏捷的方法，则里面全部敏捷的方法涵盖的实践比较多，可能只要有一些敏捷实践的都算。
-
其次 32%的企业和团队超过了一半的团队在用敏捷的方法和实践。
-
最后 58%的是什么呢？就是这些企业内部有少于二分之一的团队在使用敏捷实践。只有 2%的没有用敏捷的方法。 因此我的感受如今国外为何都在讲 DevOps，多是由于他们的敏捷已经作到了必定程度，前面两堵墙已经拆的差很少了，只差最后那堵墙了。
实现持续交付的道路上，是否先 DevOps，应该看前面两堵墙有没有打通。
以上是我的观点，可是咱们一块儿学习 DevOps 包括去实践，这是没有问题的，由于它确实能提升组织的效率，而且能提升交付的能力。是否要先去作 DevOps 实践，要从整个价值交付的角度来看，在百度不会强调用敏捷的方法、用 DevOps 的实践来改进业务团队，而是要从价值角度出发，须要依次把这几面墙打掉，因此总结的方法和工具实践只要能把墙拆掉，就是管用的。
打通业务到开发的墙
下面简单介绍下有哪些比较好的实践帮助拆墙，第一个比较好的实践是需求管理。
当产品经理决定要作一个功能，首先要写一篇需求文档，而后把文档交给开发同窗。写需求文档有各类各样的方法，如写个 Word 文档、或者用 Excel 来管理多个需求点，或者在系统中录入一个个需求卡片，其实这都是经常使用的方法。
写 MRD 的过程很是痛苦，由于研发同窗基本不看，他们更但愿你当面讲清楚。写得越长，他们越不肯意看，写得越短的话，他们以为你干脆给我讲讲就行了，因此总在自问，为何要写个文档？ 一直在想怎样能更好地把需求管理起来，其实写文档目的是让产品经理的想法快速进入到开发同窗的脑海里面，让你们把产品的想法对齐了之后快速进入开发，因此怎样能让这个过程更高效？
下图是沟通成效和沟通方式的关系，左下角是沟通方式最“冷”，沟通成效最低的，就是 Paper，文档。说明用文档的形式来传递思想、传递需求的沟通效率是最低的。
什么样的沟通方式效果最好？右上角是 Face To Face At Whiteboard，你们面对面的在一个白板面前沟通，这种效果是最好的。这也就是为何如今不少的研发优秀实践大可能是把这些流程、方法可视化出来，在看板上面对面沟通。
既然用文档来进行需求传递效率最低，那么，用什么样的方式能更好地管理和传递需求呢？一种比较好的方式就是——用户故事地图。这种方法把需求拆成一个一个用户故事，而且让全部的用户故事在一个看板上能所有看获得。用户故事地图的方法介绍有一本书，书名就是《用户故事地图》。
不少时候，习惯用一个 Story 的列表排列需求优先级，我作产品经理时，感受这种排列需求优先级的方法不太灵，会发现排出的需求分散在产品的各个板块上，没有连成一个完整的用户体验，用户看到每次产品更新的功能，殊不知道产品到底升级了什么。
用户故事地图可以很好地解决这个问题，它通常分为三层结构，上面两层从左到右用来把产品的骨架梳理出来，如产品的一级模块、二级模块。产品经理在写需求文档时会写 一、1.一、二、2.1。有一个比较好的实践：若是这个产品是一个用户类的产品，好比一个手机 App，那能够从左到右把用户的体验进行排序，而后能够把详细需求点拆到更细的颗粒度。
需求在用户故事地图上拆分之后——
-
首先，最下面层级的需求颗粒度基本上是一个 Story 的大小。这样，研发同窗比较愿意接受大小颗粒度的需求。
-
其次就是把需求平铺在看板上，可以可视化整个产品的全貌。
-
第三点对产品经理的帮助，能够方便地排列需求的优先级。
-
最后是排开发计划，不管是从精益的角度仍是敏捷的方法，你们都认为最小、可用的产品需求集合是最优先要开发且验证的，在用户故事地图上作一个横向分组，分组内的需求最终连成一个完整的用户场景，而且能够快速的开发出来，这就是 MVP。
以上就是用户故事地图在需求管理方面的实践。
如今，用户故事地图作成了工具，放在百度效率云，愈来愈多的团队产品经理再也不用 MRD 文档来管理需求，使用故事地图和研发团队沟通，能更高效地把需求快速传递给研发，工具的好处就在于不受物理条件限制。过去作用户故事地图的时间，让你们在墙上贴便签，最后发现便签不够用或场地不够大，因此这个实践用工具作比较好。工具内能记录下产品每个版本的演进，不用考虑卡片数量和场地限制。
打通测试到开发的墙
第二个实践是快速地作计划。严格的 Scrum 流程，要求必须一个一个迭代去作。现实中有许多团队作敏捷开发其实都有本身的开发节奏，除了作迭代，上层还有版本计划，版本上层可能还有里程碑计划。因此工具并无限制必须采用哪一种计划的组织方式，而是你们能够很灵活计划的层级结构，方便把计划作的卡片拖拽到计划中，而且能很方便看到每个计划里面每人的工做量以及计划整体的工做量。有了这些功能的配合，就能让这个计划作的更快速以及更合理一些。
计划完成后要作进一步追踪，以前提到，好的沟通实践是你们共享一个看板把项目中的工做呈现出来。百度公司如今基本上都使用百度效率云 iCafe 工具中提供的电子看板方式，开站会时打开这样（上图）一个板子，就能知道进度和风险。
邱戈川老师提到燃尽图挺难画的，由于在线下用卡片的形式作看板，确实很难。但用工具就能很方便计算并画出燃尽图，它能帮助咱们看到不少项目中的风险和问题。
当实践时首先要有这样的意识：怎样把质量提升？你们都认为质量不该该由测试来保证，而是应该由开发同窗本身搞定。其实在许多外企，如谷歌、亚马逊等，测试角色更多的是提升自动化测试能力，基本的质量保证大可能是由开发同窗来完成的。百度也是这样学习和实践的。
怎样让产品的质量作的更好？比较深入的一点是开发同窗本身保证质量，可是仅仅说这句话去告诉每个开发同窗，请你本身来保证质量。这仍不够，还得须要有工具保证这个流程或者保证这个思想的实践和落地，因此在百度效率云中 iCode 的这个产品上作了一些比较严格代码质量保证的功能。
首先是代码提交前的检查。研发同窗不能直接把代码提交到一个分支或者一个主干中。在提交代码之后，代码工具先自动生成这样一个评审单，上面首先要作的是自动检查编码规范，若是此次提交的代码没有知足公司的编码规范，那是不容许继续提交的。
构建流水线被愈来愈多的 DevOps 提倡，其实它也是保证质量一个很是好的实践。从前提交前构建流水线多是在云端编辑一下便可。如今愈来愈多的研发团队，提交前的构建流水线作的愈来愈丰满，除了编译，还有自动化测试，包括单元测试，功能测试，甚至说集成测试，都得在提交前先跑一遍，保证这个代码提交前把完整的自动化测试运行完。
一些优秀的实践已经可以作到 Review App，就是说真正能发布出来，研发同窗本身在这个 Review 环境上去看运行获得底怎样，直至没有问题。
此时再作提交前的最后一步：人工代码评审。
每次代码提交后，仅运行自动代码规范检车和自动流水线还不能根本上保证代码质量，需进行人工评审，必须由同行来给出此次代码提交的评审结果。由嗲马裤的 Owner 总和分析这段代码实现了哪一个需求，解决了哪一个 BUG 之后，以为没问题了，打出评审经过，最后此次代码提交才真正进入到公司的代码库内。
这些代码开发实践，可以有效保证代码及整个产品的质量。而且因为有了研发工具的支撑，如今百度每位工程师每次提交代码，都能严格遵照整个规则。
一次代码提交的质量保证是单人的视角，可是若是团队扩大，如何保证不一样类型的产品、团队可以快速有序的开发？像一些业务的核心团队可能有两三百人，他们天天都要提交代码，此时如何能更好的协做，怎样更好去保证质量，确实是一个问题，因此说就须要代码研发的工做流。
其实代码的工做流对于你们来讲应该都很是熟悉，如主干开发的工做流，分支开发的工做流。可是仅在团队内部口头约定有这些工做流，效果不会太好，由于这是团队内部的约定，一旦新人进入不知道工做流的事情，可能就把重要的代码分支冲掉了。因此团队执行代码工做流时更好的方式还得须要工具来保障。
iCode 有这样的功能——在代码库管理配置里面，能够开启此代码库的工做流，开启后就强制要求代码库按照工做流去提交，如此设置之后，不管团队有新人进入后者团队有人忘记工做流的事情，研发同窗都只要提代码便可，由于入托提交方式不知足工做流的要求，代码是没法正常提交的，同时 iCode 会提醒该如何正确提交。
作代码提交前的严格检查，加上团队代码协做工做流，基本上能保证让开发同窗提交的每一行代码都是通过比较严格的质量保证。如此，测试同窗就能更好的去专一于一些自动化测试工做。
前两面墙基本上都打掉了，咱们终于到了 DevOps 要打掉的这么墙。
打通测试到运维的墙
DevOps 要打掉的这面墙，从前面日后看，就是前面这些团队看运维同窗：运维要求是稳定的，并且不能随便变化，这样就不能知足快速开发的要求。若从后往前看，就是运维团队往前看，会如此想：测试测的不太好，上线之后总出现问题，质量没法保证，让运维如何上线？
另外运维排期紧张、上线存在等待，好多工做须要手工部署，比较容易出现人为错误，故而这都是如今 DevOps 要解决的问题。
首先用流水线的方式把整个软件开发流程串起来、从代码编译一直到发布上线 iPipe 这个工具的特色在于流水线能够分红多个阶段，阶段里面能够设置多个任务，任务既能够并行执行，也能够串行执行，如此，流水线配置也就很是灵活。有了这样一个端到端持续交付工具框架之后，测试就能把自动化测试挂接到流水线上，用自动化的方法来保证整个产品的质量。
为了更好的指导自动化测试工做，QA 同窗们作了自动化的测试分级。
测试会把自动化测试分红多个级别，根据不一样的测试框架、方法、脚本可以对应不一样的测试级别，再把不一样级别的测试脚本挂载到 iPipe 流水线上，此时你们看到的流线以下图：
在流水线上，代码编译后，通过单元测试、系统测试、性能测试，就会到一个检查点，如以前任发科老师所说，这条流水线不彻底自动化，会有一个或多个检查点。并非每一次提交都要自动上线，而是说可能挑选一次或者几回，最后认为此次功能已经比较完整，而后手动验收测试执行，完成后再去执行后面的任务。
iPipe 让流水线可视化，它能把从开发到测试、发布、再到最后的部署均可视化，可使团队中的多个角色的信息共享。经过这样一种“半自动”流水线及可视化的方法就可以有效打掉运维和开发和测试之间这堵墙，由于流水线可视化把这些信息串联起来了。
iPipe 工具的思路，就是把各类各样公司内部的、为外部的优秀工具能力都集成上来。测试过程当中能够接入多种测试工具、环境资源管理工具，发布时能够对接公司运维部门的多种部署和监控系统。
现在都在学习 Docker 技术，这是百度在 iPipe 上的一个用 Docker 发布和部署流水线例子，编译完成之后就自动部署镜像，能够去走准入测试、镜像转推、发布。其实把更多通用的功能挂到流水线后，就看每一个团队须要什么，灵活地配置流水线，帮助团队更高效地持续交付。
DevOps 带来了另一个技术概念是微服务化，目前百度不少产品项目都开始实践微服务化，那么流水线及 DevOps 的工具怎么可以帮助团队去作多模块发布或者微服务的发布和部署？
iPipe 采用了这样一种可视化的方法，左边都是每个代码库微服务模块的版本，而后流水线自动将它集合在一块儿，去测试、发布、部署。集成的流水线确实是 DevOps 工具的一个重要功能。
度量与改进实践
刚才讲的是如何拆墙。但墙是否存在、改进后有没有被拆掉，须要你们的一个评判。若是没有一些数据的支持或没有一些可视化展示，就很难了解墙是否存在，更不知是否被打掉。因此在整个研发工具的角度，除了作这些工具意外，还要作一个事情就是数据的积累和度量展示。
百度效率云中，需求管理平台 icafe、代码管理平台 iCode 和持续交付平台 iPipe，它们的数据是彻底打通的，打通后能够看到一个需求产生了多少代码，作了几回评审，评审市场，以及需求最后发布到哪一个版本上、发布到哪一个环境上。这些信息都是可追溯、可视化的。
有了这些研发数据后，在后台作了一个研发数据中心，把全部研发数据所有汇总到一块儿，作一些研发数据的分析。
目前主要分析一些有助于团队持续改进的基础数据，作一些对比数据，好比如今看到的就是一个团队完成一个需求的平均周期，用散点图、累积流图看。
举例子，这是咱们的项目团队从开发到上线的交付周期的数据，每个点表示一个 Story，纵坐标表示此 Story 停留的市场，横坐标表示它在什么时间完成的。这个绿色线显示 Story 的交付周期在缩短，说明团队交付 Story 的速度是愈来愈快的。具体为何会快呢？哪儿变快了呢？或者说过去哪儿慢呢？经过数据分析咱们发现有一个测试等待状态的时间，原来是很是长的，大概是 10 天，有了这个数据才能知道——开发和测试的这面墙是存在的。这面墙经过咱们不断的努力打没打掉呢？最后发现打掉了，测试状态等待时常降到了四五天左右，总体交付率有明显提高。
总结
因此说怎样去拆墙？有没有数据来证实墙的存在以及墙被拆掉？这是工具能带来的便利，若是手中工具是第三方开源工具搭建出来的，也要思考怎样把这些研发的数据聚集到一块儿作数据的分析。
此外，以前提到分级测试在公司各个产品线作的如何？若是想真正 DevOps 起来，就得先把自动化测试、分级测试作了。作了之后还会问作得如何？谁作得好？谁作得很差？百度也有这些数据帮助团队了解它们的自动化测试完备程度。每个团队或者每个大的部门的测试能力数据，像红灯修复时长，测试完备度等，QA 部门都提供很好的数据支撑。当把这些数据给团队看的时候，他们就会比较客观的了解本身的工程能力，从而根据自身的须要主动改进。
因此有了这些方法和实践加上工具的支撑，百度在最近这几年有了必定的工程效率提高，以上都是一些项目的实践，但愿对你们能有帮助。