如何通过数据运营驱动技术升级
讲师 | 王培安 编辑 | 白凡
王培安，上海找钢网高级经理。目前在找钢网负责两部分，一部分是测试，对质量负责，一部分是对工程教育，属于保障中心。负责的还有研发管理平台、质量度量平台，还有持续交付到最后发布上线。曾就职于思科、HP。
本文给大家分享《如何通过数据运营驱动技术升级》，怎么理解这个题目呢？这个是比较官方的话，更多的是像我们基础架构，系统运维、运维平台更多是做背锅侠，需要通过这个转身，怎么拿运营数据推动研发在架构上进行升级，对他们进行考核。
1、端到端数据的实现
首先按照传统的讲一下DevOps模型。这是理论上的DevOps模型，计划、需求、设计、开发、部署。现实的情况下，目前没有全部打通的，这是由于各种原因导致各个系统之间是很难集成的。什么原因呢？就是组织架构决定了是否能够打通。
找钢网也会有各种平台，像计划需求、研发管理平台，这块有质量、集成交互平台、运维平台、应用治理，应用治理主要是一些中间件，像SOA、配置中心，监控平台是全链路的监控。我们不仅仅有这些平台，更为关键的是能够全部打通，形成一个端到端的数据，然后拿这些研发数据衡量运维的水平。
为什么能形成端到端的数据呢？这取决于组织架构：
- 保障中心：中间件开发，像SOA、监控平台等等
- 运维中心：运维平台有系统运维，CMDB、需求管理、质量pingt 等等
同时我本人既属于保障中心，又属于研发中心，研发中心带着测试，我就对质量负责，质量上我是有话语权的。所以我能拿到这些数据，虽然我们属于两个中心，但工资只有一份，很辛苦。
什么数据是领导比较关心的呢？
1.1 效率
为什么讲效率呢？所有的领导关心的都是钱，时间就是钱，通过研发管理平台，把需求、把每个人的工值和每个任务的拆分全部统计出来，绝对挖掘、分析形成报表，每周推送给研发总监，研发负责人，他们能够实时看到我们团队的饱和度情况，能够进行人员的调整。
这里有两张图，这是几个大的研发中心需求的分布情况，绿色的就是已经开发完成的，红色是代开发的，通过这些数据领导能清楚地知道到底这个团队需求饱不饱和。去年的10月份，我们发现有一个团队，就是这个红色的特别多，绿色的特别小。这个团队之前是正常的，突然之间就出现了这个问题。HR进入访谈以后发现了一个问题，后来研发老大就走掉了，其实他已经想走了，基本上那个团队已经处于放羊的状态了。这些对我们管理层是非常关键的数据。
1.2 价值
领导怕大家偷懒，也怕大家做无用功。研发也经常抱怨，业务提的很多需求，提了很多需求要求很急最后可能没有用。
这个我们就提供度量，首先价值度量，是不是所有的价值都能够数据化呢？这个是值得商榷的一件事情，因为像有些技术改造或者说短期内是看不到价值的，我们尽量会数据化，主要包括产生的交易量和系统的访问量，用来达到两个目的：
- 由于公司发展很快，找钢网成立五年，做了很多系统，每年都开发很多系统。其实有很多系统是没有访问量没有人用的，需要进行下线，这样减少维护成本，研发、测试人员就可以转到新的系统上去，同时能够节省物理资源。
- 避免盲目开发。团队一大，如果只管理一百个人无所谓，但到了几百人、上千人的时候就有这个问题。大家都想做东西，都和老板说我做的东西好，其实最后做的东西可能60%都是用不上的系统。我们期望的是通过这个数据，让大家谨慎开发，对自己做的系统要负责任。
2、集成交付平台
2.1 功能
持续交付平台有四个功能：
- 持续集成，主要是通过13个指标通过数据化的度量系统质量。
- 持续交付，就是发布、回滚的功能，包括定时发布的功能。
- 数据度量。
- 多纬度功能，每个研发人员看的东西是不一样。
2.2 架构
- 统一的策略和分值环境，保证统一管理统一出数据
- 持续集成，持续交付的关键，这个是很难进行统一的，因为你的优先级不是我的优先级，找钢网这一点已经实现统一了。
上面可以做很多东西，包括代码评审、代码质量代码合并我们没有做，因为风险比较大，另外也不是优先级的事情。
- 最后是界面和平台。
前面讲了领导比较关心的是效率、价值、质量。质量这里有13个纬度的数据，不同的研发水平不一样，所做的系统也是不一样的，对他也是提出不同的要求，要不然有的研发组是很LOW的。我们为什么把安全和性能放的低一点，是to B的，没有那么大的访问量，所以对于性能和安全没有要求那么高，to B也很难薅羊毛的进行攻击。因为我们大部分是在内网。
2.3 研发平台界面
这是研发平台界面，全流程如下：
- 代码的检测
- 进行部署
- 测试，代码检测是因为我们有统一的分支策略，前面第一个分支，到最后测试、上线，其中任何一环达不到标准的话，是不能进行的。
- 这里的上线有很多，如果真正点开的话会有选择的，怎么验证，这里没有展开截屏。
通过这些数据就提供一些标准，这个就是质量度量的界面，大家可以看的很清晰。大家可以清晰的看到每个部门到底有多少应用，应用系统到底是合格还是不合格。质量情况到底怎么样，想度量别人，一定是两个纬度。
第一个纬度是管理者，第二个纬度是底层程序员的研发，刚才提到的十三个纬度，如果我把13个指标直接放到领导桌子上，估计领导看花眼了。如果通过一个算法，直接提供一个数据或者指标就可以了，到底合格还是不合格，领导拿这个直接招人就可以了。
2.4 代码质量指标细化
主要包含代码的可读性、单元测试安全问题。为什么一定要细化出来呢？如果你对一个程序员说，你这个程序写的不好，全是问题，你对每一个程序员这么说，估计电视剧里活不过两集。既使是不行指标是什么样，是越来越好，还是越来越差。从领导层来看，管理一个员工是变得越来越好还是越来越差，反应了你工作态度和工作能力的问题。
这是2016年4月份的数据，之后就推行代码质量的检查，蓝色是已修复的，红色是未修复的。举这个例子给大家看一下，红色是很少，是一些老的系统，已经要下线的了，我们不会清，但会放在这里。基本上所有新增问题都修掉了。第二个，这个曲线是比较陡的，越来越缓，这是为什么？这是我们研发水平提高了。这是真正研发水平提高了，通过这些数据就可以知道到底是提高了还是降低了。
另外每周会统计新增代码问题的统计，展示最近修复率怎么样，新增了多少问题。为什么我能推动这个问题呢？因为我们产生了两次事故，我刚去的时候，由于数据库资源没有关闭，大家做技术应该知道，如果连接数据库，最后程序忘记关闭了，一般测试员测不出来，只有当量达到一定程度的时候会爆掉，我们产生了两次线上事故。我们每天交易额3到4亿，耽误5分钟是多少钱？耽误1小时是多少钱？后来加强这个问题以后，后来在扫码是直接扫出来了，我们已经修复了5个这样的问题，但从来没有在线上遇到过。自从推出这个标准之后，线上再没有出现这个问题。
这个是我们每个月会做的事情，基于这一个月的代码质量进行分析，我们每个团队到底哪些问题是比较常见的，大家可以看一下，这是我们5月份的一份数据，首先变量生命没有使用1600多个，控制针576个，空的判断依据，这个是比较低级的，通过这个就可以知道他需要什么样的培训，可能不需要太高级的，但是需要基础的严格的要求，把这些问题解决掉，这样的培训才会有的放矢。这也是为什么刚才我们的曲线越来越缓，因为是有针对性的解决这些问题。
2.5 质量测试覆盖情况
这个会统一管理自动化手工测试包括智能测试，这样能清晰地体现一个功能上线到底覆盖了什么东西。之前有一个痛点，自动化跟手工是分离的。自动化跑完了不知道功能覆盖了多少，后来经过这个平台就有一个非常统一的度量，功能点覆盖了多少。有数据就一定有排名，这是为什么能够驱动研发改进他架构跟技术。这个研发经理会不会紧张？这个研发管理一定出了问题，是研发不够重视，是资源不够还是测试出了问题，这是需要注意的。
3、全链路监控
我们也有全链路监控，日志系统是ELK，所有日志都读到ELK里面再进行分级。诊断中心就是看到底是不是问题，不断升级去报警。一开始邮件短信后面就直接自动打电话，告诉你有这个问题。
这个大盘，前面是技术，大盘更多是展示。驱动的一定是两方面，领导层和程序员，大盘给他们的视角是不一样的。
3.1 监控大盘
这个是实时报警的大盘，是针对各个研发组工程师的，可以看到这是每分钟报错日志的情况。
上面是30分钟概况，当系统出现问题的时候一定要在业务之前发生问题。如果业务之后发现问题，IT会越来越被动。为什么是叫趋势图？因为事故发生的时候，一定要看前面到底经过了什么，出现了什么事情。是网络流量问题，还是突然有大的交易量。
这个是给研发总监的，包括每个系统，各个研发部门，不同颜色标识着各个研发部门。通过技术的考量，通过数据去驱动技术升级，可以看到日志的趋势是明显变缓的，系统是越来越稳定的。
3.2 慢调用
前面是基于日志，这个是属于APM级别的，要清楚地知道系统出现的问题，慢在哪里，如果只告诉他慢，想定位是非常难的事情，如果有这些东西就知道每个接口。
这里做一个统计，让大家知道有没有出事情。例如一天只有一两个没关系，突然之间爆增到一百个以上是要出问题的。我们公司每个研发部门挂了两个大屏专门投这两个东西。这个跟前面一样，慢日志的趋势图。当出现事故的时候，绝对不是突然之间出现，而是有趋向的。我们ELK跟万能钥匙是一样的，后来觉得不够直观，又做了这些东西全部投到大屏上。这是某一月我的汇报数据。这个是我们的调用次数，一个月调用了21次的API到底设计合不合理，耦合度到底强不强。这些数据其实都是很有参考价值的，经过我们的推动，我们整体架构有了质的升级。
3.3 物理资源监控
这是物理资源的监控，原来一个及其是一百虚以上，大家知道这个节约到什么程度了，这台物理机挂掉了，这个业务基本上就要挂掉了，通过这个不断驱动系统运维，我们研究是一虚20到30。这些对于领导来说两眼一抹黑，出现事故只能单点的解决事故，不能全局的考虑应该怎么做这件事情。
4、团队综合战斗力评估
有了这么多数据，有了价值、效率、质量，怎么对团队做出评估呢？这个是非常难的事情，实际情况可能就是拍脑袋，年底表现好的话可能更好一点，年初表现不如年底，估计做过领导都有这个感觉，到底这个东西怎么评价，尤其是我们跨部门之间调用资源的时候，怎么协调这个资源。这是都个很难的一件事情，我们做了什么呢？
团队战斗力评估，这个是我们通过综合算法，把团队的能力数据化了，这不是一个性能，是一个参考值，每个研发部门怎么样。这个包括需求的质量，包括业务方提的需求有没有价值，还有产品做的PRD是否合理，是否符合的规范。
4.1 效率的度量
包含三方面评估：
- 需求值是否充分，如果产品和研发部在一个部门的话，产品和研发永远是天地，总是相互打架。这个需求值就是说整个研发团队，收到的需求到底充不充分。能够度量团队到底饱不饱和，是否需要加人，不饱和是否给他多做一些培训。或者说长期不饱和的话，有的资源是否要调出，这仅是一个参考值。
- 需求效率，需求效率是什么意思？因为业务方比较强势，他们是赚钱的，技术和产品是成本部门，如果业务方提了需求，多久能够产生PRD。这个过程也是产品需要调研的，非常考量产品经理水平。而现在产品到底做的怎么样，看指标就可以了。需求完成的速度，是说产品决定做了PRD研发认可了，从产品PRD产生到最后上线到底花了多久。业务部经常问，提了一个需求怎么这么长时间没反馈，进程是什么样，这里就可以看到。
- 研发效率是从一个需求的计算，测试效率就是SRT，到最后系统上线到底花了多久，包括一些质量，就是我上线的日志、综合的考核。这个迭代管理是考核KA的，到底哪些流程落地了，哪些没有落地，符合率是多少。
4.2 质量度量
- 需求质量。业务部门经常提很多需求，实际上迭代之后马上又变掉不用了。哪些业务提的需求真正是转化为产品了，哪些业务部门提的需求质量是比较低，以后就要对他进行考核。需求质量是考核产品的，什么意思呢？产品写的PRD到底清不清晰，研发到底理不理解，不理解就打回。
- 代码质量。这个是考核研发的。研发写的代码，也不用争不用吵，成员相互鄙视，你说我烂我说你烂。
- 测试标准和发布质量。研发部门本周上了多少次线，做了多少次回滚，产生多少次事故，多少次故障、多少时间。
- 过程符合度，所有人是否符合流程，是否遵守流程，这些都是通过管理角度做的。
通过这些数据，包括前面反应的数据综合产出了这个团队战斗力的评估。物流的业务方、产品方、研发方到底运作的怎么样，如果是分数比较低的话，领导就要关注到底产生了什么问题。能够量化的东西就在这里，可以通过这些数据度量。
5、PaaS平台
这些数据怎么来的呢？其实还是paas平台里面研发、管理、设计、需求、开发、部署、运营，同时我是研发测试的负责人，对这个质量有话语权，这个事情能推动起来，我们形成端到端的数据，推动技术上的升级。要想度量别人，首先做好你的向上管理，其次让下属接受。让领导你接受你的价值，而且不要都反对。能够落地生根起到作用才是我们做事的目的。
这是找钢网的PaaS平台，这里还有一个研发管理没有列进来。虽然数据讲起来很简单，实际上推动起来很难。想统一别人是非常难的事情。可能做一个系统只需要一个月，统一规范别人可能要一年。找钢网一年多的时间把平台搭建起来，并且形成统一的规范，出数据度量别人，其实成绩已经非常不错了。
