AICon 北京站 Keynote 亮点揭秘,想了解 Agent 智能体来就对了! 了解详情
写点什么

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

张健

  • 2019-09-16
  • 本文字数:2241 字

    阅读完需:约 7 分钟

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

在大家的印象中,运维人员更多的是从属业务的角色。在传统的企业 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 数量随着变更信用分的提高在稳步下降。考虑到同时期的变更数量也在一直增加,这种下降趋势就更加明显了。



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

四、未来展望

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


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


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


本文转载自公众号滴滴技术(ID:didi_tech)。


原文链接:


https://mp.weixin.qq.com/s/AYjpv2GSYDLl0pB9tHqkrg


2019-09-16 10:021387

评论

发布
暂无评论
发现更多内容

头脑风暴:目标和

HelloWorld杰少

数据结构 算法 LeetCode 8月月更

产品说明丨如何使用MobPush快速创建应用

MobTech袤博科技

ios android sdk mobpush 智能推送

数据产品经理那点事儿 一

松子(李博源)

数据产品经理

缺少比较器,运放来救场!(运放当做比较器电路记录)

矜辰所致

电路设计 8月月更 比较器 运放

mysql进阶(三十三)MySQL数据表添加字段

No Silver Bullet

MySQL 8月月更 添加字段

fastposter v2.9.1 程序员必备海报生成器

物有本末

海报生成器 海报编辑器 图片生成 二维码生成

容器化 | 在 S3 实现定时备份

RadonDB

MySQL 数据库 Kubernetes

2022年中国软饮料市场洞察

易观分析

软饮料 市场分析

兆骑科创高层次人才创业大赛平台,投融资对接,双创服务

兆骑科创凤阁

避免 10 大 NGINX 配置错误(上)

NGINX开源社区

nginx 架构 配置 配置分析 故障排除

智为链接,慧享生活,荣耀智慧服务,只为 “懂” 你

荣耀开发者服务平台

开发者 安卓 荣耀 honor

海外邮件发送指南(二)

极光GPTBots-极光推送

消息推送 邮件

易观分析联合中小银行联盟发布海南数字经济指数,敬请期待!

易观分析

金融 海南数字经济 易观分析

安克创新每一个“五星好评”背后,有怎样的流程管理?

科技热闻

易观千帆银行用户体验中心:聚焦银行APP用户体验

易观分析

金融 银行 用户体验

“低代码”编程或将是软件开发的未来

优秀

低代码

友邦人寿可观测体系设计与落地

阿里巴巴云原生

阿里云 云原生 可观测 合作案例 友邦人寿

万物互联,车联网数字化需要快速引入小程序生态

Speedoooo

小程序 车联网 IoT 小程序生态

等保2.0一个中心三重防护指的是什么?如何理解?

行云管家

等保 等级保护 等保2.0 安全等级保护

符合信创要求的堡垒机有哪些?支持哪些系统?

行云管家

信创 堡垒机 信创产业

在本地利用虚拟机快速搭建一个小型Hadoop大数据平台

Jack20

云计算 大数据

一文带你了解 HONOR Connect

荣耀开发者服务平台

开发者 教程 荣耀 honor

借数据智能,亚马逊云科技助力企业打造品牌内生增长力

Lily

用好 DIV 和 API,在前端系统中轻松嵌入数据分析模块

葡萄城技术团队

前端 嵌入式 BI 可视化数据

MySQL 原理与优化:Update 优化

老崔说架构

网络安全——XSS之被我们忽视的Cookie

Jack20

网络安全

leetcode 739. Daily Temperatures 每日温度(中等)

okokabcd

LeetCode 数据结构与算法 栈和队列

兆骑科创创业赛事活动发布平台,创业赛事,项目路演

兆骑科创凤阁

NFT数字藏品——数字藏品发行平台开发

开源直播系统源码

软件开发 数字藏品 数字藏品系统软件开发

社区动态——恭喜海豚调度中国区用户组新晋 9 枚“社群管理员”

白鲸开源

运维平台信用分——滴滴内部的数据驱动实践_软件工程_InfoQ精选文章