高校技术管理的思与变

彭小阳

作者：

徐奇琛，10年运维老兵，曾任职于腾讯、易迅、史泰博等公司，从事过网游、网媒门户、社交网络、电商等业务场景的运维及技术管理工作。致力于海量业务的技术运营保障工作，对架构规划、性能调优、用户体验提升等运维增值服务感兴趣。目前就职于京东，负责京东无线业务的运维和测试团队。

我们的部门更多是围绕前台的工程效率质量和技术运营去对产品研发做很好的一些知识服务支撑，但是也来看一下左边这张图，也是我监管的一些团队。

这个坐标轴都是以运维作为原点，我们先来看纵轴，纵轴更多是在CPO体系范围内的一些职能，运维测试产品研发；
再到横轴，我们经常把运维安全、数据、称之为技术运营部，然后在业务也有很多运营，今天有嘉宾其实也是提到了DevOps的涵盖业务很广，这里面把业务运营整个涵盖在运营线，最后业务运营就是COO的能力模型打造。
再来看对角轴，更多是附能和效率提升部门，包括一些工具团队，效率团队，以及项目管理团队。所以这里蓝色的圈圈都是我目前在负责的团队，以及间接监管过的团队，比较有意思的是我是京东偏向于前排的管理负责人，汇报的对象更多是业务层面的，思考的角度也会更多站在业务层面去思考。

今天我来干什么？今天的目标还是回到三年前，这张图也是萧田国老师三年前提出高效运维的概念，非常聚焦的把运维人员的服务意识和需要改变的困难和痛点总结的非常清晰。所以三四年过去了，我觉得三年前还是担心什么事就是云计算，运维会不会丢失自己的饭碗，当时的忧虑比较大。
但是三年过去了，云计算蓬勃发展其实我们在运维人才的深耕上面有更大的一些需求，然后DevOps也是兴起的，我们的就业方面有更多的选择面。在位的各位三年都发生了很多的变化，我自己在管理团队的拓展上面比较突出一点。
所以今天其实还是希望把整个链条的团队如何去高效跟大家做一个分享，简单的通过几点思索，带来一些思索的求变理解以及团队公司做的案例和数据分享，最后是一个展望总结。

一、左思右想

先来说一下左思右想，说了那么多还是回到到底什么是高效技术管理？

我来罗列一下都会有心里想的，里面有很多新的技术，比如说流水线，现在也是围绕在建设一个很好的生态，这个是当时产品交互的方式，打造持续交互的能力。这个换位到对于需求可能做的反向，对于需求和业务的预期是要做控制的，你的效率再高需求不良也会有很多的问题，达不到高效和有用价值的交互，尤其是顶层设计，包括KPI的建设可能都是老板建设的目标，这个是管理会去思考的问题。这里提到的我说都会，都让团队提到相应高效的层面或者附能，可能都不是完全的面面俱到。其实今天想讲很多的内容都体现在这样一个框架里面，包括服务的概念，这里面拆开讲都能讲一个下午，每一个点都能延伸很多，

1、用户、业务、核心价值

首先我们来看一下先从中心开始看，用户、业务、核心价值，其实刚才黄岛主说了很多的国企，包括传统运营商的思路，现在又把大家的频道拉回互联网，互联网企业更多的所创造价值更多围绕用户的痛点提供产品和服务创造价值。
所以目标导向是用户和业务价值为核心，所以你看很多的价值观就能看到，腾讯是以用户价值为依据，我到了京东之后就是用户为先要说的是同一个意思，说完用户之后来看质量，质量是一切的基础。

2、效率运营

再来看效率运营，来说目标，刚才说的目标在互联网企业还是有交互快速的价值作为目标；这里不单单是运维，所有的业务团队，你的目标会建立统一的输入输出，包括还是通过主动的使命感被动的绩效管理，统一做到1+1大于2。我们再看质量，有两个是内建质量，大家都有自己的团队质量意识都把一下关，才能做质量管理。
所以本质上提供一个基本的用户体验，相应的核心建立大量的准入和合规性建设测试的指标是比较枯燥的，所以也会通过度量，度量是测试最重要的手段，效率还有一个高效的管理，核心的思路发现流转去解决最核心的问题，优先解决哪些最大化的效益，这里面有很多的持续交互，对于研发产品运营测试都需要做到自动化，相应的一些研发管理要求后面都会展开来说。

3、运营

最后一个其实是运营，最后不是说运营不重要，互联网企业最核心的就是动态运营，不断的去和同行去做对比，不断的收集用户的体验这是一个小步开跑，找到一些真正的价值，所以这里面洞察创新改造，相应的方法论也很多，朋友说到的MVP的方式，都是运营的重要手段。
所以有一句话来概括高效技术管理的概念其实就是以业务用户价值为核心，以技术能力为驱动，快速交互给客户最有用的价值，前面加一个括号在互联网企业纬度，我差不多15年的工作经验全在互联网企业思维也固化了。

二、三思后行

再来说三思后行，这个三思大家觉得什么意思？“三”指的你我它，不同角色的思考。

这是一张众生相，我们先来看运维，运维非常伟岸，运维对其他部门的想法是为什么有这么多的变更，为什么大半夜还要变更？会有不理解的，为什么每天互联网企业有上千次的上限，为什么要这么多的创新，不变企业就没有关系，我们看第一副图就是一把破枪，永远需求都排不进来。
大家看看研发这是在社会顶层的研发，产品经理管他，所以研发确实很痛苦地我现在也管很多的业务研发团队，基本上需求做不完的，在座的有很多研发，研发真的去质疑抵触我做这么多哪些需求才是有价值的，所有的问题都是测试的问题，测试的压力还真的是非常大的，最后其实更多是不明墙。
从老板的视角看我团队这么大，每年的成本投入这么大效率很质量很低，大家的沟通效率协同都很差，所以这是绝大多数企业非常现实的众生相。

还是回到解决问题的方法，我一句话来说从局部的补强到协同附能到量身定制的全链条交付，我想说的规范和定级只是给大家一个很好的指引，在不同的阶段不同的层次大家还是要选择自己相对来说适合自己的方式，那个规范可以给到大家很多指引和参考，所以我大概拆了5种能力，达到高效的捷径。

1、工程能力

首先就是工程能力，直接部署流水线上午和下午都有很多嘉宾去说，其实每一个企业都会围绕建设自己量身定性的产品去做定制，后面有图也会做相应的解释，其实有了工具层面的附能，才会完全打造，其实你靠那个流程是绝对达不到高效的，可视化还是要把所有的团队放到一起。

我们经常说需求相应的一些交付能力，好像很少听到和产品有相关的，我们更多需要去思考，我们做那么多的需求，产品的数据是什么？
所以一定要有一个可视化的平台，能从产品研发测试运维都能看到他们各自的数据。所以现在很多的数据都会提供他们的数据，研发管理你不同的阶段的选择的研发也是不一样的，包括需不需要去写相应的用力。
我相信互联网企业90%都不做，这是很垂直的一些业务才会去做，这个按软件设计都会去做，还是为了效率删掉一些东西，敏捷的东西不再多提了，所以我们更多把敏捷支撑到工具的能力里面去，这个还是在工程能力里面的要求。
这个端到端的流水线，从需求早运维层面都包括了，持续在做一些补充，以前需求这边也很乱，相应的缺失也挺多的。

这几年下来，京东前台的研发体系首先是补全了，在过程当中做了很多的减法，最终形成的统一流水线，来了之后要对所有需求拆分，包括需求价值的供养，包括共享的一些机制代码，代码也是统一的托管和开放的扫描能力，集成部署发布从服务端都是统一的品牌，再到产线上做一些优化，持续的收集用户反馈，持续的做进一步发布和用户上限，就是比较闭环的流水线。

2、研发能力

再说研发能力，还是把它从工程里面拆分出来，研发拆分还是比较多的，我们先说代码方面，里面提的代码规范和要求还是有很多的分析需要传递，同时还有效率方面的标准化考虑，也会考虑到一些交叉开发，其实很多团队互联网企业都是成都、上海、深圳都会考虑到交叉开发的场景，也会尽量的考虑代码共用的机制，测试就不说了不是强要求地可能选择适度的系统去做单一测试。
组建化还是说把相应的一些伦理去做公共建设避免重复的开发，大家基于SOA的方式对于结果负责，架构能力不单单是系统架构能力，还有转变架构能力平台化的架构能力，后面其实也会简单的提到，配置化经常有的时候不多，很多方式通过配置化的方式发布，比如说电商都是通过配置化后台就可以做，有额外的发布方式这里就不说了。
这个研发首先没有及时的去做相应的代码优化或者代码的整理，“干干净净”要求你的代码或者是做定期技术债的偿还，所以研发的能力真的涵盖非常多。

3、质控能力

来说一下质控能力，偏执型的东西还得用动画，先把自己解放出来能让自己真正测试有价值的东西，内建质量的输出把你的用力提前给到产品经理，把你的自动化能力和平台给到工艺研发，这个也是要提注册报告，这种能力是带来整个能量的提升，真正关心最有价值的是什么？
就是金字塔塔尖，你应该做比较专项的一些测试，这些是研发或者是产品真正做不了的，比如说一些探索型测试，或者是移动端的测试，这些都是研发没有进一步做到的，所以对质量控制的要求是这三点。

4、组织协同

再来说一下组织协同，我们在写规范标准的时候，也是考虑到组织能力这样一个KPI，我们看到大量组织方面KPI帮助团队提升效率，京东也是叫做前中排，大家的职责分工和需要的目标都是完全不一样的。
首先大家都把团队做了相应的拆分，也会有一些决策委员会一，在协同的过程当中有大量的决策需要技术人员做决策，做管理的已经没有需求去做，我们建立一个委员会，比如说APP瘦身委员会比如说塔河会有大量同行的借鉴，大家都有很多的专题去做技术层的决策，一般都是高层去担任里面的职责。
KPI导向说一下最真实的例子，我在京东5年其实我是一个技术人员，但是我每半年的绩效合同三分之一都是用户的增长指标，这个就把技术人员跟产品业务都放在同一条线上了所以是刚才说的统一目标，不要强调业务的技术性都要为业务发展负责。

5、运营

再来说运营，好的产品不是设计出来的是通过不断的运营改良用户体验运营出来的，这里简单的说三点，一个是动态运营，要有最小化交互的能力，包括部署能力快速的看用户的反馈，有一些需求是没有必要从头做到尾的，因为反馈已经决定了它没有价值的，所以我们经常说要交付有用的价值还有一个不断的看数据，边工作边生活这也是定期的要去做结构改造。

三、实践与案例分享

这是一些简单的案例，还是言简意赅说一下，当时考虑的是大家所围绕的方向都不一样，运维关注的是标准化监控，还有一个协同平台的建设，大家的观点可以看到，运维和质量相关都可以合作共赢可用性和用户的体验，可视化自动化，运维还是和环境的供应点，这是整个团队的供应点，这是建立服务团队的协同。

1、案例一、京东项目

说一下质量保证体系，这里面质量保证更多偏向在质量团队为主或者是平台化团队为辅的支撑，刚才也说过了不同阶段策略的选择和不同业务其实是可以根据自己的量身定制，没有一个统一的规范，还是为了每一个业务有更好的交互能力，真正的单一测试我们确实也没有办法再要求了。

但是确实在一些特定的垂直系统上面确实会有要求，然后相应的过程改进，真正的研发团队会看到很多的问题，所以后面会说每一个阶段只会选取真正能够提升最大化的一些东西，量化管理质量平台的细分，管理类的质量平台，监控类的质量平台。

刚才说到的过程改进，接受的技术团队发现的最大问题是整个研发的发布成功率非常差，我记得差不多只有86%的成功率，差不多每天有很多上线失败，当时觉得这里面的瓶颈是最大的，所以里面有很多的过程，当时做的更多是在变更管理这一块，差不多花了一年的时间，把所有的变更管理流程做相应的约束。
这个是现在的成功率是非常理想的状态，这是测试重要的不良，合规性审批，还有场景化的品牌和业务结合还是要推进和场景结合，大家经常说AI，我对AI的评价是和场景结合，包括一些用户体验用AI体验和产品结合，我们现在通过一个产品化平台，可以节省大的运营能力和流量的转化率，如果点开不可用这个流量真的很浪费。

还有通过平台化演进减少开发，沟通开会也是成本质量方面的一些数据，差不多是1：7，整体的研发是10%，UI的覆盖率核心流程接近70%—80%的互动整体性能在40%左右，崩溃率今年上十一控制在万分之十五左右，成功率99.7%，这个数据都真实。
所以这是一种协同质量的体系，还有一个案例中间插了平台化附能。

首先还是说去建立相应的分层，京东讲平台化都会去讲另外一个词叫“积木化”你做一个平台能被另外一个平台做借鉴，无论是最顶层的包括自动化或者度量或者是一个流程类的，再到OPI再到平台化，再到最终的业务形态，一层层可以作为一个原则的投入拼装，可以作为一个最基础的积木原理，最终到产品会去做同一个收口，监控是雷神统一户覆盖，都会有类似打标签的一些平台去做相应的可能。

2、案例二、磐石项目

第二个案例也简单的说一下经历了两年的时间去做的事情，这个是我参与的一半开头是我做的叫“磐石项目”。
简单来说京东交付能力是两个月一个版本，差不多那个时候的投诉是相当大的，一个是大家的需求，两个月过程当中需求都会变，真的一个业务需求插进来等两个月业务风险是有的，实在没有办法去等待.

所以还是在领导的指示下，还是做了一个大规模的缩短，第一个从两个月减少到一个月，第二个从一个月缩短到两周，并且具备随时可以上线的能力，所以是三个要求首先是几千人的团队，需求只能增不能减，版本的质量不能下降还是有挑战的一件事情，如果你是50人的团队我觉得还是有信心的，千人的团队压力还是比较大。
这就回到了一些方式，可以用Safe方式做一些拆分，你要建立一些文化上的认可，并且还要去建立很多的考核顾虑，还会有大量不合规的打入进来。
其实可以看到双方在这个之前还是有很多的条件，比如说相应的架构，你的团队比如说原来的苹果分布率很低，五次审核都过不了，配置的管理团队，独立的回归测试团队，把测试组织结构做一些拆分，对整个版本的一些发布结果负责，大家是责任共担的，相应的分支审核流程合规的不良CI层面的升级自动化。

还有一些借力输出，最终结果还是好的，通过相应的一些全流程改进，版本交付周期应该是75%，每一次提升50%，它努力提升了20%，这个赶不上就赶不上了，你没有什么成本，因为也就是两周一个版本，你还有很多其他的能力，还能帮助你上线额外的需求，包括有效的提升。
有一个效率说50%可以配合，不要去沟通发布解决问题，到需求的拆分以前的需求很大，现在三天马上就能做，这个都是敏捷化开展得到的一些真实数据反馈，最周结果还是非常好的，也是在人员没有任何增加的前提下达到了产能和效率的提升。

四、总结展望

最后总结一下，首先统一目标理解相应的背景，去利用技术驱动业务价值最大化的交互在各自的领域做到合格这是我自己非常深的感受，以前大家觉得我是超人我的团队什么都能做，但是在整个链条团队里面都不重要，整个链条关心真正的流转在哪里，比如说运维超人也对业务没有价值。

坚守质量的底线，始终去保持一个同理心互相去理解。运营和学习，以用户业务为中心小步快跑，把握好业务价值的平衡保持尊重和敬畏不断的保持学习，你会发现做互联网的各个角色都不容易产品的压力也很大，所以我们真的应该多一些互相理解，有一个展望在工程效率的方向还是要持续的投入，大家还是持续的去做减法精细化，去更多的能力支撑到现实的业务里面去。
更多是产品细分做更多的扩展，现在真的很多业务平台化对我们的帮助很大，我们现在所有的活动都不需要搭进来所有的文案都是机器人写的，你要投钱去写文案现在都是机器人，写出来比人还要好，包括持续的优化，架构这一块都能理解，智能这一块稍微的扩展一下。

上午也是有学术界很多企业都分享了自己的算法和AI方面的能力，现在京东的AI是彻底的改造，基本上所有的业务全在做AI方面的演进，打开那些文案全是机器人写的，无非还是那些算法，研发中心差不多有200个科学家不断的帮我们做算法的优化，所以这投入和业务还是有很多的产值，包括物流都是基于算法路径去做相应的决策，包括很多的业务平台流量切换。
大概两年前我觉得在运维做无人化还是很恐怖的事情，但是在一年前绝大多数京东操作都是无人化，所以我觉得在今后结合场景的一些AI化趋势会非常密切，并且会很快去改变很多的行业。
最后一句话相应的一些效率建设工作，其实真的没有那么容易，其实也是很多同事默默的付出也靠大家协同能力认可和建设，也希望这个平台对大家有一些借鉴，大家在各自的部门寻找到效率的方式，谢谢大家。