南昌易动力网站建设公司,网站建设技术的实现,最简单的企业网站,自助建站系统哪个好用这是一个创建于 375 天前的主题#xff0c;其中的信息可能已经有所发展或是发生改变。由数人云、优维科技、中生代社区联合发起的 系列 Meetup 《 DevOpsSRE 超越传统运维之道》 先后在深圳、北京举行过两场 7 月 15 日上海站#xff0c;敬请期待 ▼ 王一男老师在《 Dev…这是一个创建于 375 天前的主题其中的信息可能已经有所发展或是发生改变。 由数人云、优维科技、中生代社区联合发起的 系列 Meetup 《 DevOpsSRE 超越传统运维之道》 先后在深圳、北京举行过两场 7 月 15 日上海站敬请期待 ▼ 王一男老师在《 DevOpsSRE 超越传统运维之道·北京站》活动中结合百度的实践讲述落地 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、1.1、2、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 部门都提供很好的数据支撑。当把这些数据给团队看的时候他们就会比较客观的了解自己的工程能力从而根据自身的需要主动改进。 所以有了这些方法和实践加上工具的支撑百度在最近这几年有了一定的工程效率提升以上都是一些项目的实践希望对大家能有帮助。 转载于:https://www.cnblogs.com/hofmann/p/9259968.html
