摘要：所以，滴滴运维部推出了风险量化平台，包含变更信用分用来度量服务的变更操作，比如服务部署上线，配置变更等监控健康分用来度量用户对报警监控的使用，从而打造一个看得见的手，驱动业务同学来一起提高线上稳定性。
出品 | 滴滴技术
作者 | 张健
在大家的印象中，运维人员更多的是从属业务的角色。在传统的企业IT中，没有快速的产品迭代，没有每天成百上千次的服务发布和伸缩容，这样的角色看似没有问题。但在如今的 DevOps 时代，日常的运维工作中每天要应对成百上千次的服务发布与线上操作。如果运维人员（即SRE）仍然只是被动的去应对这种变化，所造成的结果，必然是疲于应付，最终会对全平台的业务稳定性造成很大隐患。
那么，在这种量变引起质变的挑战中，运维人员应该发挥怎样的作用，才能适应新业务的挑战呢？笔者之前曾就职于IBM Cloud部门，现在就职于滴滴运维部，长期从事自动化运维方面的工作，下面就结合自己之前的经验和目前的工作，谈谈自己的一些见解。
一. 来自业务的挑战
无论是在滴滴还是在之前的部门，在业务发展的初期阶段，都不可避免的经历了粗犷型的扩张阶段，比如业务量指数级上升，用户量急剧增加，每时每刻都有服务模块的迭代。
在业务优先的前提下，运维人员承担着巨大的运维压力。以监控为例，用户添加监控不规范，会造成报警频发，报警有效性不足，导致的后果就是容易让真正有价值的报警湮没在海量数据中，同时，也会造成对报警资源的浪费，比如，研发同学不区分测试、线上环境，随意的添加报警采集指标，会对监控系统的存储，查询带来极大的挑战。再比如部署系统，不按照规范，在高峰期更新服务，一旦出问题，会造成整个应用的服务不可用。这样的例子有很多。
二. 如何应对
如果上述的问题一直延续下去，运维工作必然带来巨大的挑战，并且会严重影响线上服务的稳定性。面对这些问题，滴滴运维团队的同学也在一起思考，运维应该不仅仅去被动的适应业务，而是要从平台稳定性出发，去指导研发同学，如何规范的执行变更，如何合理的使用监控资源以及其它公司IT基础设施。
我们想到的解决方法就是“数据说话”，尽可能的去量化监控、部署及基础组件（MySQL, Codis, ZK）的使用。然后用数字去指导研发的同学，尽可能的去匹配我们给出的“最佳实践”，从而减少造成线上业务不稳定的隐患。
所以，滴滴运维部推出了“风险量化平台”，包含“变更信用分”（用来度量服务的变更操作，比如服务部署上线，配置变更等）、“监控健康分”（用来度量用户对报警监控的使用），从而打造一个“看得见的手”，驱动业务同学来一起提高线上稳定性。
| 数据驱动的难点有三个方面
首先是如何获取数据？这是“风险量化平台”的基础。使用监控系统，部署一个服务，执行一次配置变更，都是一个个用户操作，很难用数字去表达。为此我们结合运维经验，基于对操作每个步骤的详尽输出，近可能的去用数字维度来衡量用户操作。比如以部署为例，会以灰度发布中间的暂停时间是否满足一定时长，是否有在上线高峰期操作记录，部署过程中是否执行了double-check，在哪个阶段执行了回滚等等，来形成一个个的打分项。
其次是如何去制定风险量化的标准，也就是如何用各个指标去构造一个最佳实践。这更像是一个数学建模，里面涉及到大量的运维经验积累，以我们新推出的监控健康分为例，我们遵循着“有服务必有监控，有报警必须处理”的原则，对于每个服务，要求衡量的标准包括，是否有存活指标监控（进程、端口等）；是否有基础指标监控（如cpu.idle，mem.used, disk.used）；是否添加了上下游监控，报警是否有效，即报警接收人是否过多（因为大家都收到报警，最终的结果，往往意味着大家都不会处理报警），报警是否被及时处理（运维领域也有MTTA， MTTR，即报警平均响应时间，和报警及时处理时间这样的概念）；是否配置了监控大盘，方便我们日常巡检。
各个量化项目占据不同的权重（如下方的监控健康分剖析图）， 比如我们根据滴滴目前的服务特点，存活指标占比40%， 报警有效性占比30%，推动业务去收敛报警，和完善监控。监控健康分以80分为及格线，寻找出监控漏洞，并指导用户加以改进。 用这样的方法，可以让研发同学尽可能的减少漏配监控的事情发生，提高线上服务的稳定性。
最后的难点是如何驱动？这是我们现在着力想的一个点。风险量化实际上就是总结前人踩过的坑，趟过的雷，去告诉后面的同学，提前来规避风险，这是运维部门对公司业务稳定性的一大贡献。
现在已有的做法是如下图（各部门变更信用分排名图）所示，通过计算、打分、全公司各个业务线排名，将风险量化数据和反应出的问题推送给各个业务线的leader。以竞赛方式去推动各个业务线重视风险量化。我们还计划以监控健康分去驱动报警有效性的建设，完善报警值班制度，避免群发报警又无人处理，报警配置不合理这种现象的发生。
三. 效果如何
目前的风险量化体系包含“变更信用分”，“监控健康分”，其中变更信用分已经上线一年多了，在2018年，从下图能明显看到信用分在稳步上升。
带来结果是什么呢？ 下面是本年度故障case统计图，能明显的看到这种趋势，故障case数量随着变更信用分的提高在稳步下降。考虑到同时期的变更数量也在一直增加，这种下降趋势就更加明显了。
我们期望其它的信用分机制，也能给业务稳定性带来这样积极的结果。
四、未来展望
对于未来的展望，首先希望能对尽可能多的涉及线上操作的内容进行风险量化，比如业务使用的中间件／基础组件，业务中涉及安全的服务是否遵循了相应的规范，是否有密码／数据泄漏风险。
其次，我们仍然需要对已有的运维经验进行总结，结合经验，利用量化分数去构建“最佳实践”，指导大家去遵守。
最后是如何去驱动，将总结的数据价值，最大化的发挥出来。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/8103.html
摘要：北京时间月日月日，由和中国国际人才交流基金会联合主办的第七届全球软件案例研究峰会简称在北京国家会议中心圆满落幕。本届峰会，来自阿里美团百度平安银行等企业的讲师分别从企业转型及研发效能方面分享敏捷和的实践细节和操作经验。 北京时间11月30日-12月3日，由msup和中国国际人才交流基金会联合主办的第七届全球软件案例研究峰会（简称：TOP100summit）在北京国家会议中心圆满落幕。T...
摘要：北京时间月日月日，由和中国国际人才交流基金会联合主办的第七届全球软件案例研究峰会简称在北京国家会议中心圆满落幕。本届峰会，来自阿里美团百度平安银行等企业的讲师分别从企业转型及研发效能方面分享敏捷和的实践细节和操作经验。 北京时间11月30日-12月3日，由msup和中国国际人才交流基金会联合主办的第七届全球软件案例研究峰会（简称：TOP100summit）在北京国家会议中心圆满落幕。T...
摘要：滴滴机器学习平台的治理思路主要是减少重复提高效率。本文将对滴滴的机器学习平台进行全面解读，重点分享机器学习平台不同阶段所要解决的问题，以及解决问题的思路和技术方案。综合和各自的利弊，滴滴机器学习平台开始由架构向建构迁移。 前言：现在很多互联网公司都有自己的机器学习平台，冠以之名虽然形形色色，但就平台所要解决的问题和技术选型基本还是大同小异。所谓大同是指大家所要处理的问题都相似，技术架构...
摘要：摩拜每天产生的骑行数据超过，在全球拥有最为全面的骑行大数据，飞速增长的业务使摩拜面临数据库扩展与运维的巨大挑战。目前，摩拜主要上线了两套在线业务，分别是摩豆信用分业务和摩豆商城业务。 作者：Mobike / 技术研发部 / 基础平台中心 丁宬杰 胡明 背景 摩拜单车于 2015 年 1 月成立，2016 年 4 月 22 日地球日当天正式推出智能共享单车服务，截至 2017 年 11 ...
摘要：摩拜每天产生的骑行数据超过，在全球拥有最为全面的骑行大数据，飞速增长的业务使摩拜面临数据库扩展与运维的巨大挑战。目前，摩拜主要上线了两套在线业务，分别是摩豆信用分业务和摩豆商城业务。 作者：Mobike / 技术研发部 / 基础平台中心 丁宬杰 胡明 背景 摩拜单车于 2015 年 1 月成立，2016 年 4 月 22 日地球日当天正式推出智能共享单车服务，截至 2017 年 11 ...
阅读 2574·2021-09-26 09:55
阅读 2601·2021-09-10 10:51
阅读 2027·2021-09-02 15:21
阅读 3081·2019-08-30 15:44
阅读 697·2019-08-29 18:34
阅读 1545·2019-08-29 13:15
阅读 2338·2019-08-27 14:27
阅读 3179·2019-08-26 11:37
