AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

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

张健

  • 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:021394

评论

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

亮相亚太 CDN 峰会,火山引擎 CDN 与加速助力数字化业务加速发展

火山引擎边缘云

CDN 火山引擎 全球加速 火山引擎边缘云

LangChain 联合创始人下场揭秘:如何用 LangChain 和向量数据库搞定语义搜索

Zilliz

Milvus Zilliz #LangChain

牛刀专业低代码开发实战—招聘管理

牛刀专业低代码

低代码 低代码开发平台 起步牛刀低代码 牛刀低代码 牛刀专业低代码

牛刀低代码开发实战—需求评审

牛刀专业低代码

低代码 低代码开发平台 牛刀低代码 低代码paas平台 java低代码

HDC.Cloud 2023|邂逅AI,华为云CodeArts铸就研发效能10倍提升

华为 华为云 华为开发者大会2023

平衡业务合作,推动企业全面预算管理取得成功

智达方通

数据分析 全面预算管理 业务合作

用友BIP时间轴——回溯历史 预置未来

用友BIP

人力资源

牛刀低代码开发实战—物联网车载大气监测

牛刀专业低代码

低代码 低代码开发平台 起步牛刀低代码 牛刀低代码 低代码paas平台

Flask快速开发Web应用:入门到精通必备知识

互联网工科生

Python flask

大型企业全面预算管理数智化转型路径

用友BIP

全面预算

白鲸开源WhaleScheduler完成阿里云PolarDB数据库产品生态集成认证

阿里云数据库开源

开源数据库 国产数据库 polarDB PolarDB-X PolarDB for PostgreSQL

解读 6 月 NFT 行业:市场停滞,Azuki 崩跌

Footprint Analytics

区块链游戏 NFT NFT链游

用友:数智技术核心驱动  服务企业数智化与商业创新

用友BIP

国产替代

蚂蚁集团积极参与《金融业分布式信息系统运维技术研究报告》的编写

TRaaS

可观测性 Trace 全量存储之性能优化

乘云数字DataBuff

APM 可观测性 k8s监控 全链路追踪 Dynatrace

牛刀专业低代码开发实战—奖酬金预分配

牛刀专业低代码

低代码 牛刀低代码 低代码paas平台 java低代码 私有化低代码

龙蜥白皮书精选:面向 HTTP 3.0 时代的高性能网络协议栈

OpenAnolis小助手

开源 HTTP 标准化 QUIC 龙蜥白皮书

官宣!Databend Cloud 和青云科技达成合作

Databend

财务共享,驱动企业持续升级的动力引擎

用友BIP

财务共享

银行机构数据治理案例解读,构建全行数据资产体系

袋鼠云数栈

数字化转型 金融

微博评论的高可用计算架构

sandywrh

火山引擎徐广治:边缘云,下一代云计算

火山引擎边缘云

云计算 边缘云 火山引擎边缘云

免费试用商业智能工具,帮助您轻松选择BI工具

夜雨微澜

苹果iOS App Store上架操作流程详解:从开发者账号到应用发布

2023年iOS App Store上架流程详解(上)

Sentieon | 每周文献-Population Sequencing-第一期

INSVAST

基因数据分析 生信服务 群体基因

CQ 社区版 2.2.0 发布 | 配置要求降为 4 核 16G!!!

BinTools图尔兹

数据库 数据安全 数据库管控工具 数据库管控

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