运维平台信用分——滴滴内部的数据驱动实践

栏目: 服务器 · 发布时间: 5年前

内容简介:【编者的话】在大家的印象中,运维人员更多的是从属业务的角色。在传统的企业IT中,没有快速的产品迭代,没有每天成百上千次的服务发布和伸缩容,这样的角色看似没有问题。但在如今的 DevOps 时代,日常的运维工作中每天要应对成百上千次的服务发布与线上操作。如果运维人员(即SRE)仍然只是被动的去应对这种变化,所造成的结果,必然是疲于应付,最终会对全平台的业务稳定性造成很大隐患。那么,在这种量变引起质变的挑战中,运维人员应该发挥怎样的作用,才能适应新业务的挑战呢?笔者之前曾就职于IBM Cloud部门,现在就职于

【编者的话】在大家的印象中,运维人员更多的是从属业务的角色。在传统的企业IT中,没有快速的产品迭代,没有每天成百上千次的服务发布和伸缩容,这样的角色看似没有问题。但在如今的 DevOps 时代,日常的运维工作中每天要应对成百上千次的服务发布与线上操作。如果运维人员(即SRE)仍然只是被动的去应对这种变化,所造成的结果,必然是疲于应付,最终会对全平台的业务稳定性造成很大隐患。

那么,在这种量变引起质变的挑战中,运维人员应该发挥怎样的作用,才能适应新业务的挑战呢?笔者之前曾就职于IBM Cloud部门,现在就职于滴滴运维部,长期从事自动化运维方面的工作,下面就结合自己之前的经验和目前的工作,谈谈自己的一些见解。 如果你想和更多运维技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

来自业务的挑战

无论是在滴滴还是在之前的部门,在业务发展的初期阶段,都不可避免的经历了粗犷型的扩张阶段,比如业务量指数级上升,用户量急剧增加,每时每刻都有服务模块的迭代。

在业务优先的前提下,运维人员承担着巨大的运维压力。以监控为例,用户添加监控不规范,会造成报警频发,报警有效性不足,导致的后果就是容易让真正有价值的报警湮没在海量数据中,同时,也会造成对报警资源的浪费,比如,研发同学不区分测试、线上环境,随意的添加报警采集指标,会对监控系统的存储,查询带来极大的挑战。再比如部署系统,不按照规范,在高峰期更新服务,一旦出问题,会造成整个应用的服务不可用。这样的例子有很多。

如何应对

如果上述的问题一直延续下去,运维工作必然带来巨大的挑战,并且会严重影响线上服务的稳定性。面对这些问题,滴滴运维团队的同学也在一起思考,运维应该不仅仅去被动的适应业务,而是要从平台稳定性出发,去指导研发同学,如何规范的执行变更,如何合理的使用监控资源以及其它公司IT基础设施。

我们想到的解决方法就是“数据说话”,尽可能的去量化监控、部署及基础组件(MySQL、Codis、ZooKeeper)的使用。然后用数字去指导研发的同学,尽可能的去匹配我们给出的“最佳实践”,从而减少造成线上业务不稳定的隐患。

所以,滴滴运维部推出了“风险量化平台”,包含“变更信用分”(用来度量服务的变更操作,比如服务部署上线,配置变更等)、“监控健康分”(用来度量用户对报警监控的使用),从而打造一个“看得见的手”,驱动业务同学来一起提高线上稳定性。

数据驱动的难点有三个方面

首先是如何获取数据?这是“风险量化平台”的基础。使用监控系统,部署一个服务,执行一次配置变更,都是一个个用户操作,很难用数字去表达。为此我们结合运维经验,基于对操作每个步骤的详尽输出,近可能的去用数字维度来衡量用户操作。比如以部署为例,会以灰度发布中间的暂停时间是否满足一定时长,是否有在上线高峰期操作记录,部署过程中是否执行了double-check,在哪个阶段执行了回滚等等,来形成一个个的打分项。

其次是如何去制定风险量化的标准,也就是如何用各个指标去构造一个最佳实践。这更像是一个数学建模,里面涉及到大量的运维经验积累,以我们新推出的监控健康分为例,我们遵循着“有服务必有监控,有报警必须处理”的原则,对于每个服务,要求衡量的标准包括,是否有存活指标监控(进程、端口等);是否有基础指标监控(如cpu.idle,mem.used,disk.used);是否添加了上下游监控,报警是否有效,即报警接收人是否过多(因为大家都收到报警,最终的结果,往往意味着大家都不会处理报警),报警是否被及时处理(运维领域也有MTTA, MTTR,即报警平均响应时间,和报警及时处理时间这样的概念);是否配置了监控大盘,方便我们日常巡检。

各个量化项目占据不同的权重(如下方的监控健康分剖析图), 比如我们根据滴滴目前的服务特点,存活指标占比40%, 报警有效性占比30%,推动业务去收敛报警,和完善监控。监控健康分以80分为及格线,寻找出监控漏洞,并指导用户加以改进。 用这样的方法,可以让研发同学尽可能的减少漏配监控的事情发生,提高线上服务的稳定性。

运维平台信用分——滴滴内部的数据驱动实践

最后的难点是如何驱动?这是我们现在着力想的一个点。风险量化实际上就是总结前人踩过的坑,趟过的雷,去告诉后面的同学,提前来规避风险,这是运维部门对公司业务稳定性的一大贡献。

现在已有的做法是如下图(各部门变更信用分排名图)所示,通过计算、打分、全公司各个业务线排名,将风险量化数据和反应出的问题推送给各个业务线的leader。以竞赛方式去推动各个业务线重视风险量化。我们还计划以监控健康分去驱动报警有效性的建设,完善报警值班制度,避免群发报警又无人处理,报警配置不合理这种现象的发生。

运维平台信用分——滴滴内部的数据驱动实践

效果如何

目前的风险量化体系包含“变更信用分”,“监控健康分”,其中变更信用分已经上线一年多了,在2018年,从下图能明显看到信用分在稳步上升。

运维平台信用分——滴滴内部的数据驱动实践

带来结果是什么呢? 下面是本年度故障case统计图,能明显的看到这种趋势,故障case数量随着变更信用分的提高在稳步下降。考虑到同时期的变更数量也在一直增加,这种下降趋势就更加明显了。

运维平台信用分——滴滴内部的数据驱动实践

我们期望其它的信用分机制,也能给业务稳定性带来这样积极的结果。

未来展望

对于未来的展望,首先希望能对尽可能多的涉及线上操作的内容进行风险量化,比如业务使用的中间件/基础组件,业务中涉及安全的服务是否遵循了相应的规范,是否有密码/数据泄漏风险。

其次,我们仍然需要对已有的运维经验进行总结,结合经验,利用量化分数去构建“最佳实践”,指导大家去遵守。

最后是如何去驱动,将总结的数据价值,最大化的发挥出来。

原文链接: https://mp.weixin.qq.com/s/AYjpv2GSYDLl0pB9tHqkrg


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Head First EJB(中文版)

Head First EJB(中文版)

KathySierra,Ber / 中国电力出版社 / 2006-9 / 79.00元

有些人只是想通过认证来取悦挑剔的老板,但相信你不是这种人。确实,你也想通过Su n认证业务组件开发人员(SCBCD)考试,但不仅如此,你还需要真正把EJB用到实处。你要构建应用,要对付最后期限,如果通过考试之后第二天早上就把你学过的EJB知识忘得一干二净,你肯定会受不了。 我们会看着你稳稳当当地通过考试,而且会帮你在实际中使用EJB。你会深入地了解EJB体系结构、会话、实体和消息驱动......一起来看看 《Head First EJB(中文版)》 这本书的介绍吧!

随机密码生成器
随机密码生成器

多种字符组合密码

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具