坐拥亿级用户--网易云音乐DevOps炼成之路

白凡

分享：于旭东
编辑：白凡

今天我给大家带来的分享叫坐拥亿级用户，网易云DevOps炼成之路，我最早接触敏捷也是在哥迪亚，这些业余时间我会和杭州的建设者，和其他的小伙伴一起组织杭州的活动，我想问一下这里有来自杭州的同学吗？
因为我在网易云最开始的和云音乐，云音乐是网易旗下专注发现与分享的音乐产品，定位主要在音乐社交和移动社区，2013年的4月份第一个版本上线，2015年达到用户一个亿，2016年2个亿，一直到2018年的11月份是6个亿，而且是非常典型的指数型增长，这种情况下我们怎么做我们的DevOps，我想问一下大家，在座的各位有用网易云音乐的举一下手，另外一半的同学可以下一个网易云看一下，因为你会喜欢上他的，这一块分几块。

第一个叫为什么要提升研发交付能力？
第二个如何衡量我们的研发交付能力
第三个如何提高交付能力，最后简单做一个总结。

1. 为什么提升我们的交付能力

先从第一个问题开始，就是我们为什么提升我们的交付能力，简单来说一句话叫“时代在变化”这个可能有点大，是最开始我们可以看到技术革新的速度越来越快，可以把整个人类大的变化回顾一下，从旧石器时代，至今的200万年，经过了200万年之后，经过了新石器时代，据今一万年，至今3000年进入了青铜&铁器时代，之后在1765年进入了蒸汽时代，1866年德国西门子的创始人发明的发电机，我们进入了一个电器时代，1946年第一个计算机的发明进入信息时代，这里面有一个明确的脉络，最开始进入信息时代之前，我们更关注的是一个叫以能量为核心驱动了一个社会进步，最开始靠人，人来手工，到了农业时代的话我们有一些工具比如青铜器或者一些家养的牲畜帮助我们，到后面的比如机器帮助我们，最后电力机器帮助我们，现在更多关注在如何从一个能量驱动的社会进入到了一个以信息+能量为核心的驱动社会。

现在有一篇文章叫软件正在吞噬这个时代,另外一篇文章叫敏捷正在吞噬软件世界，在这样一个信息时代，技术革新希望越来越快的时代，技术革新越来越快带来两个明显的结果就是产品的生命周期越来越短，第二个企业的生命周期越来越短，我们看一下产品的生命周期越来越短，比如美国的一个电话普及率从0-40%，39年的时间，今年电话用了6年的时间，智能手机使用只用了3年的时间，我从2006年一直在诺基亚网络工作，手机的品牌在2013年的时候卖给了微软，其实在发布会上说了一句话，我们没有做错任何事情，但是我们输了，为什么？

因为从传统社会来看更多的是连续性的假设，现在的话在技术革新越来越快的情况下，我们进入了一个非连续性的时代，比如说诺基亚为什么会起来最开始的时候，模拟数字的时候谁是龙头老大，摩托罗拉，进入了从模拟时代进入数字时代的时候，诺基亚取代了摩托罗拉，成为的手机界的NO.1，接着进入了智能手机时代，苹果就取代了诺基亚，包括现在的华为的时代。

另外一个后果企业的生存时间会越来越短，这个是从破坏型成长里面截了一个图，从1920年-1930年，在1920-1930年如果你普尔名单里的话，你会存在65年，但是过了70年之后，就是1998年到现在每一个标准普尔500里面企业存活淘汰率将近每年的都是10%，也就意味这你只有十年的时间在这个上面，企业的生存时间越来越短了，这是一切是源于技术核心的进步。

这个词是比较火的词叫乌卡时代，这个本来是军事上的用语，最开始是宝洁首席运营官他把他拿过来用在了描述当今世界新的商业时代做这样的东西，乌卡怎么解释呢？就是说，我们的不确定性，复杂性和模糊性，虽然是这么写的，但是从我个人来看，这里最核心的一点还是在于本质是一个负责的世界在这个世界上其实包含了各式各样的元素，各式各样的元素之间其实是会有非常复杂的因果关系，在这个过程中又会存在很多的反馈以及失言，大家听过“蝴蝶效应”，他描述的是一个混沌活动，开始一个微小的变化导致后面巨大不确定性，有一本书叫混沌边缘的繁荣，但是我们处在这样的世界里，那边有一点点的变化导致整个世界的增量的变化，所以说，正因为这样复杂，所以才会推出来一些异变模糊，以及这样结果带来的不确定性。

在这样不确定性的情况下，我们是否可以像以前一样，我们做一个大的进化，列了一堆的需求做这样的一个产品，把他们交给研发团队开发，如果我们想象一下，如果这个很多事情都是确定的，都是明确的，非常清楚的我们按照这种方式来做完全没有任何问题，但是在这样一个不确定的时代的话，我如何做这样的一个事情，现在产品已经不是像原来一样设计出来，而是不断的演化出来，正是开发，测量，学习，可验证的反馈循环，在这里面组强调的一点，我在有限的时间，有限的资源下，会以最大的速度加快我这样的一个认知循环，从而达到我的产品可以真正的活下来，无论是创业的所谓公司和小公司，如果不能加快这样一个循环的话是比较配悲摧的结果，我们简单一个小视频。

这是1953年的情形，大家可能觉得有点长，但是时间就是这样，这样的话整个竞赛花了一分20秒左右，我们再看一下2013年的情况，这样的话我们整个几秒钟完成了一个进站，如果我们和我们的竞争对手同在1950年，或者同在2013年，还是在竞争其他的一些东西，假设你的竞争对手是2013年，而你的公司还在1953年，这个就是很糟糕的情况，我不太相信会赢这样的一个比赛。

2. 如何衡量我们的研发交付能力

我们到底如何衡量我们的研发交付能力，这是一个很重要的问题，整个研发效能的数据体系包括了很多内容，如果从大方面来说可以保险质量，效率和成本，如果用一句话来说的话就是多快好省，我希望交付的越来越多，做的东西越来越快，质量越来越好，用的成本越来越小，当然大家也知道，如果在其他不变的情况下，可以把这个做下来是基本上不可能的，所以一定过程中有一些叫妥协，对于研发交付能力的话我们选的第三个指标，其他包括一些质量，一些成本的指标在因为今天时间有限没有讲，更多关注在我们研发交付能力三个指标。

我们先看一下这个叫研发交付周期，这有两个很重要的点，产品研发大方向来看，有两个部分，第一个产品的探索，一个是产品的交付，交付的周期也可以分为两种，从用户的需求开始，一直到整个的用户上线，这里通常存在一个问题，就是一个模糊的开始，什么是真正的用户需求的开始，另外一个更常见的是研发的交付周期，从我的研发接到需求开始，到整个我的研发交付上线，我们在这里用的是研发的交付周期，因为在不同产品阶段和公司有不同的关注点，当然从最终结果来看，我们希望在座的各位如果在公司里面做的话，如果有可能可以关注整个的需求的交付周期，从需求开始到需求上线，只要可以明确定义这样一个开始。

研发交付周期的话，我们基本上可以看到一个研发团队的能力，就是研发交付周期越短，交付能力越强，我们看一下第二个，这个叫需求交付频率，单位时间内，有效需求交付次数，这里为什么要说强调需求交付的频率，而不是常见的一些应用的，发布的频率，因为现在这种微服务的架构下，他和传统的那种单体的应用可能不一样，单体的应用在线上的部署就是我的一次交付，但是微服务的情况下，应用的部署可能未必代表用户需求的交付，这里更强调的是交付的结果，也就是用户需求的上线而不是我的输出，某一个微服务应用的交付上线，所以说这里是一个非常不一样的点，更关心的是结果而不是我们的输出，交付频率可以代表我们的交付的灵活性，我们交付的频率越快，在一定程度上来说，我们交付能力也是越强的。

下一个是故障恢复时间，从我们发生故障一直到故障结果，这是一个故障恢复的时间，从故障两个连续故障之间叫故障间隔之间，传统一点叫故障间隔之间，因为交付上之后不能有一些故障，我们来看一下通常来说怎么处理这个故障，简单说两种，第一个叫质量前置，花了很多的时间成本交给客户之前没有故障，这样是需要非常多的时间在里面，尤其对于互联网的产品，如果我们不能避免故障的话就是第二个问题，就是可以在多长时间故障恢复回来，这里涉及到几个问题，第一个我们什么时候可以感知到这个故障，也就是说在用户和客户发现之前，就感知到这个故障还是说等到客户有投诉的时候才可以感知到这个，我们当然希望在客户发现之前，我们可以发现这个故障，并且解决这个问题，第二个问题实际到当我们发现这个故障，感知到这个故障，大概多长时间可以定位这个问题，定位之后我们再来看一下多长时间可以修复代码，发布上线，整个这样的过程。

这是三个部分，就是如何感知我们的故障，定位我们的问题，和解决我们的问题，故障的话，其实是我们一种对于外界的一种非常明确变化的能力，我们从企业内部来看有两类需求，一是产品经理提的需求，另一类就是客户的故障，对于研发的业务类的需求，用研发周期和需求交付频率衡量我们对于需求的一个交付能力，对于这个叫故障恢复时间衡量对故障的这种响应能力，大家有没有学过一些系统思考，这是系统思考里面的一个图，其实在这个里面我会把我们的交付周期发布频率和我们的故障恢复时间和我们产品的一个响应能力关联在一起，如果我们的交付周期越长，也就意味着我们从客户那边得到反馈的时间就越长，这是一个正向的循环，如果从客户的反馈时间越长的话，意味着产品学习的速度是变慢的，其实就是产品对于市场上的变化的响应能力其实是变慢的，这样的话就意味这产品有很大的调整压力。

当然从另外一方面来看我们有一些外部环境的变化，速度和外部环境的变化量，也会增加我们产品的调整压力，这样就可以看到我们的交付周期，发布频率，以及我们的故障恢复时间都会影响到我们产品相应能力，并且增加产品调整能力，这是整个的循环，当然返回来之后变成一个叫平衡的回路，有一些调整。

这种三个情况下，这是在音乐的时候做的结果，也就是需求交付频率提升了20倍，那个时候每天发布一次，下午的时候基本上都很忙，现在把他改变成另外一种方式，就是谁开发，谁发布，我们每天发布大约20个版本，所谓的需求版本大概有20个，研发的一个交付周期五天，故障的恢复时间一个小时之内，我们前面讲的位什么提供研发交付能力，以及我们如何衡量我们的交付能力，现在看一下如何提高我们的一个交付能力。

3. 如何提高交付能力

这里面涉及到很多的内容，今天的时间也比较有限，所以我就挑几个非常关键的点给大家讲一下，当然对于不同的公式来说有不同的实现落地。

3.1 第一个叫搭建基础，可以按需创建环境

对于一些单体的应用，测试环境似乎不是一个太大的问题，只要可以把单体的服务集中起来，我只要启动起来，就意味着可用的环境，可以进行一些测试等等这样的事情，但是对于微服务的架构的话，这里存在一个比较大的挑战，对于像音乐这样的产品，大概有将近不到1000个，后面一些微服务的应用，如何定义这样的一个测试环境，比如说我有一个需求，我需要做一些开发，但是我的开发商来说只改到某几个应用的代码，这里存在一个问题，我怎么样搭建我的环境，怎么样和别人链条，怎么样做一些据测，通常的解决方案有一个基准的环境，这个环境里面有所有的基础的服务，都会在这个环境里面，同时还有一个叫测试的环境，测试环境就涉及到一个问题，不可能包含所有的服务，意味着这个测试环境里面所以来的服务可能会回调到我们的这种基准的环境，这里会涉及到一个问题，如果回到一个基准环境的话，我们如何从基准环境回到测试环境.

问一下在座的各位公司里面用微服务架构的可以举一下手吗？如果单体的话听起来没有太多的感觉，OK，这里就会涉及到一个问题，当我的服务2调用服务3，服务3接着调用服务4，到底是调哪里面的服务4，尤其当我存在多个测试环境，我有多个服务4，到底调谁的，或者我有多个服务3调谁呢？这里面有一个很大的挑战，这里面就用到一个环境隔离的方案，当我们的下游服务测试环境就是存在于这个测试环境的时候我们服务3优先调用服务4，简单来说涉及到两块，比如如何从一个服务这是一个简单的同步服务的路游，服务3调到服务4，还有一块涉及到调用，就是消息如何收费，比如我这个服务2上的消息，服务3发的消息到底是服务4调配还是其他，就是测试环境里面的服务4还是基本环境里面的服务4调配，这里是很重要的一点，这边是我们和云音乐这边一起配合做这样的修改，做到整个环境的合理。

我们看一下怎么做的，这个之前的时候，比如第一方面我的环境的隔离的方案，第二个时候我即使有这样的环境隔离方案，如何搭建这样的环境，原来的时候有PE和机器，在CMDB上进行集群，切换一些应用的分支，应用的配置做一些调整，在部署发布上做一些配置.

当然这个可能是在网易内部用到的工具和平台，但是最开始的时候，我们整个这样做一套，这里会存在几个问题，第一个不是所有人搭建一条环境，他需要对于整个环境了解的开发和PE的认识，随着应用的不断扩张，到700-800-1000应用的时候，基本上没有任何人可以很完整的搭建一条环境，另外一个非常的耗时，搭建环境的话需要3-8个小时，最夸张的搭一个需要40个小时，也就是一周的时间搭建这样一个环境，并且每一个环境机器消耗比较多，由于环境比较少话就会存在一个问题叫环境竞争，开发有些时候不是我不想撤，但是没有环境的话也很难搞，但是还是要和别人做一个集成和链条，如果存在环境这种比较耗时，可能做一些环境的竞争，切不同的测试分支，这是非常常见的问题，切设计分支的情况下，导致整个测试环境不稳定，某一个同学测了半天发现环境上部署的内容其实是部队的，有一个分支做错了，这样的话就导致整个测试结果不可靠，甚至还有一些人，一些开发者说你报了一个问题，我先打一个断点，这里造成了很多的结果不可靠，并且造成很多的沟通浪费，而且很重要的问题是整个环境不透明的，到底用了多少机器，什么分支，机器的利用率情况到底怎么样，没有人说得清，如果内部没有一些人的内部结算还好，当你发现内部结算的时候发现，我线下的机器超过线上的机器。

这里的话我们做几件事情，现在搭建的这样一个平台，只要很简单一次性添加应用分支进来，点我们的创建环境，一键部署，原来需要花3-8个小时，现在只要一分钟就可以把这样的环境搭建起来，在这样的基础之上做了测试环境，继承环境，我们为什么做性能环境，很多团队和产品里面都是性能测试的同学来做，音乐的话我们更推荐把性能测试的能力可以赋能给到开发，而不仅仅是这个能力由测试的来做，对于赋能到开发过程当中存在一个很重要的问题就是性能完毕，因为对应的脚本有一个共用的平台支撑但是环境是一个很大的问题，这样的话我们就可以通过一个平台把这些能力赋给相应的人，做更多更容易的一些事情。

原来的时候音乐有100个研发同学的时候几个研发项目，现在高峰的时候有300套相应的东西，这个环境也是做一个非常动态的释放添加，这个需求方完成以后，这个环境会自动你释放出来，所以无论是效率上也好，还是从我的搭建的效率，包括环境的数量，整个有一个非常大的提升。

在2018年这一年原来只有十个环境，这种情况下做了六千套的环境，意味着不是没有这样的需求，而是说这些需求被压抑住的，开发不是不想做这个测试，而是说“臣妾做不到”
这里面有一个非常重要的点，叫if it hurts，do it more often，原来没有交付周期压力的情况下，把周期拉长一点，所以敏捷里面有一个非常重要的概念，就是时间核，在一定的时间核内较教会一定需要的东西，就是把这个水位不断的拉低，就会把这样的一些问题充分的暴露出来，如果这个是我们的目标，并且需要经常做的话，一定会想一些办法把这个问题解决，所以在我们企业落地的时候，更多有我们的目标，并且把这些问题可以暴露出来，针对我们的非常痛点的问题核心的解决，我们不要说到一个企业里面讲一大堆的概念做他，而是是不是可以在整个落地的过程中解决我们的研发团队和研发组织上成立的问题。

3.2 一站式服务平台

第一个自然暴露的问题，如果你只是做了一个东西推到研发团队是非常痛苦的一件事实，第二个的话有一个叫一站式服务平台的支撑，最开始的时候，其实我们整个会有很多的工具平台，但是这些工具平台实际上就是占一个问题，就是彼此割裂的，比如我作为一个开发，写了一堆代码，但是他给哪个需求写了不知道写完之后交给测试，明确告诉他们我这块写的是什么需求，最后上线的时候也是一样，题了一个工单，不包含任何需求的东西，只要告诉你我这个应用的上线，从需求到开发到最后的发布上线，虽然有各式各样平台开发，但是可以把真正的形成合理我们内部叫OVERMIND的平台，我们会把他分成效能引擎，从几个大方面包含，比如项目的协作力，就是需求，迭代，我们版本的管理，研发支撑就是研发上有哪些应用，持续的集成等等这样一些事情，有一个质量赋能，就是整个的程序的集成，产品持续的回归线上的验证，这样一些东西，最后是我是不是可以做到这个交付，在这样之外产生最终效能的数据，因为最终回落到效能数据，从效能数据来看到底是不是真正的做一点改进，做了半年老板说我做了这么多的事情，老板说结果呢？效果呢？把他尽量的数据化，说明一下。

这下面其实有服务的组件，这里面涉及到很多的测试组件的支撑，大家如果做自己的工具平台开发的时候也会存在这样一个问题，原来的时候有很多的工具，如何在这个工具的基础之上，可以分装出来我自己的整个的工具链，这里以一个选择问题在现有的基础之上把他统一到品台上来，我们内部做的时候选择一条路径我们分装我们现有的能力，对于没有一些能力的话把他加进来，这样的话从整个研发来看，我面向的只是这样一个平台，可以成从我的需求，开发，测试，发布到运维整个的全过程，并且很重要的一点这个过程对于大家所有的人都是清晰可见的，是有了非常明确的一个链路在里面。

这是我们整个目前现在接的一些产品，就是网易内部的产品都在我们这个平台上，包括教育，支付，包括考拉等等都在我们这样的内部来做。

3.3 建立快速反馈

第三点我们要在这个过程，有了整个的从需求一直到发布的链，我们在这个链的过程中有非常重要的一点，就是如何可以快速的持续做一些反馈，所以很重要的一点建立快速的反馈，其实分几个层面，前面更多是说代码的反馈，也就是说一个开发的同学做一个代码，这个代码可能触发一系列的事情，比如扫描一些检测等等类似这样的事情，是一个代码层面的反馈，代码层面的反馈是不是可以一定代表需求层面的反馈，尤其在微服务架构下，通常来说有多个应用代码反馈放在一起才会做成需求的反馈，这就涉及到一个问题就是第一个解决的问题，就是环境的问题，把ABC这样的三个应用放在一个环境里面，从需求的维度做一些集成的测试，比如整个版本问题的话，还会涉及到一个问题，就是我有影响到其他人吗？或者有影响产品的其他部分吗？所以最后还是要建立产品的反馈，这样的话从我们的代码的第一次的提交，一直到我和其他人的一个合作，包括在我整个大的生态里面对其他人的影响，我们把这样一个分层快速反馈渠道建立起来，这是我们做的。

第一个我们先做的是产品层次的反馈，我们没有先做一定要从开发的代码开始，因为一样的问题，大家在企业里面落地的时候总是找到一个切入点，如果有很多人的挺你，你想怎么做，就怎么做可以，如果没有很多人挺你你就找到一个比较容易切入的点，我们先从线上验证，任何的应用发布都会去自动化的运行线上的测试用力，而且这些是非常核心的测试用力，如果这个失败的话，基本上代表P0和P1的故障，而且这里要求时间非常短，大概1-2分钟，现在这个情况下我们基本上实际的效果大概每个月都会拦截到2-3个问题。

我们还会做一个需求层次，前面是我的相关的微服务的应用，对应的分支，分支上做相关的分置，做版本的测试，这个版本一些相关的新的功能，这样的话我们OK你整个的分支，包括到我们整个环幕，整个环境的一些需求上的层次，最下面这一块就是我们代码的层次，就是先从产品的层面到产品需求的层面到代码的层面，也就是产品发布后，发现一些问题，严格来说是可以在前一个阶段把他发现的，我们就要把这样的一些能力，或者是不足把他补到前面，接着补到最下面的层面，这样才能第一时间发现这样的问题。

4. 总结

简单做一个小总结，因为这里面涉及到很多的内容，并且是说，还有很多其他的实践，时间也不够，所以我就主要讲这三点，第一个，我们可以搭基础，可以按需的创建一个环境，这是我们整个的持续交付的一个基础，我们带这样的话也一个一站式的服务平台支撑，最后做一些分层的反馈，在这个链路的过程中，不断的去做一些质量的反馈，可以让我们的问题更及时的发现，这样的一些实践的话，增强交付能力，在这样一个交付能力情况下，促进我们整个开发测量，学习，这样的一个产品，学习的一个循环，从而让我们在乌卡的世界里可以活得更好，产品真正可以活得更好。

有一个题外话，刚才一直在说是效率，还有一个词叫效能，不知道大家怎么理解效率和效能两个词。

因为一些公司叫效率部门，还有一些叫效能部门，有没有叫工程效能部门的吗？因为效率和效能，我是这么理解的，我们很辛苦的做了很多事情，是没有解决的，我不知道大家在实际研发过程当中有没有这种问题我上线的很多功能都要区分一点，无论是产品也好，或者产品上的功能也好，他只是我们的一个OUT PUT输出，他能不能真正的解决客户的问题，这些解决是不是能够影响，叫IMPACT，比如那我们的平台做一些东西叫环境，环境我们一键搭建环境，这个是产品输出的功能，他带来的结果就是说，研发同学可以非常便捷快速的去大家他的测试环境，对客户整个影响他提高了他的研发的效率，增强了他的研发交付的能力，这是我们的输出结果和客户的影响，通常希望尽量用较小的输出最大化我们的结果和影响，这是非常重要的一点，因为你做的越简单，越聚焦，通常带来越大的价值，因为把产品做的复杂，大，非常重要，但是你把他做的少，做的小，并且做的最大的价值，这是很大的挑战，所以这里我们希望最大化我们的可输出，这里可能就会发现我们其实无论是我们的需求的交付周期或者频率，我们的故障恢复时间，影响了只是我们的这一块的交付，所以大家在做的过程一定要区分这一点，我们这里只是影响了交付，但是是否可以一定在这一块的影响不确定，而且根据多年的工作经验来看，很多时候我们做了很多的无用功。

最后补充一点，叫没有NO Silver Bullet，其实整个的软件开发的复杂性，不在于代码的编写，测试，而在于我们逻辑上的验证和测试，就是产品上的测试和验证，所以我们无论是交付的能力，我们的交付的频率，他当然帮助我们更快的把我们的产品交付到客户，从而和客户那边受到一些反馈，加入我们学习的过程，但是本质的复杂性，在于产品逻辑上的验证，而不仅仅是我们的代码和测试，所以更多做的时候还是要关注我们的一些价值，就是价值的交付，而不仅仅是我们功能，或者产品的交付。