写点什么

被变更逼疯的我,是如何成功自救的?

  • 2019-10-19
  • 本文字数:3022 字

    阅读完需:约 10 分钟

被变更逼疯的我,是如何成功自救的?

干货概览

作为一个合格的码农,我们每时每刻都在为开发新功能、修复 Bug、提升系统性能挥洒汗水。变更发布是产品迭代的必经之路,但是变化总伴随着风险,互联网公司轰动一时发生的大故障,往往跟变更有关。一半以上的故障是由变更引入的,毫无疑问,减少变更引入的故障能够显著提升服务的稳定性。


减少变更引入故障的基本方法是规范开发流程、提升开发质量、加强 QA 测试环节,从而避免将有问题的版本发布到线上,防患于未然。但是,由于线上环境与测试环境往往存在差异,一些变更在测试环境中工作正常,但是在线上环境会暴露出故障。这些变更成为了薛定谔的猫,只有在上线后才能揭晓是否存在故障。因此,在发布过程中对服务健康情况进行跟踪检查、及早发现变更引入的故障成为发布过程不可或缺的环节,这样才能避免系统卷入重大故障的血案中。本文将介绍百度是如何对变更发布进行分级、检查来控制变更故障影响范围的。

分级发布,让故障影响范围可控

在百度,我们采用分级发布机制来发布变更到线上环境。分级发布将变更发布过程拆分成多个阶段,每个阶段只将变更应用到部分机器上,并在相邻的两个阶段之间对服务的健康情况进行检查。如果发现服务的健康度显著下降,则可以中止甚至回滚变更。在这个过程当中,大部分故障都能够在最后一个阶段之前被发现,因此故障通常只影响已经应用了变更的部分机器,从而有效地控制了故障的影响范围。


分级发布拆分的阶段越多,越能够在变更全面应用之前发现问题。但是,阶段的数量也并非越多越好,因为每个阶段都需要花费一定的时间来应用变更和检查健康度,阶段的数量大必然导致发布的时间变长,从而降低发布的效率。图 1 给出了百度内部分级发布的最佳实践方案。方案包含 5 个阶段,依次为沙盒环境、单机房少量机器、单机房全量机器、其他所有机房少量机器、以及其他所有机房全量机器。这种划分方法平衡了故障风险和变更发布效率,在每个阶段制定了对应的故障止损预案,在实践中取得了很好的效果。



图 1


将变更发布过程拆分成多个阶段是基础,相邻的两个阶段之间服务健康度检查是核心。如果在各阶段发布后未进行服务健康度检查或者检查方法无效,即使将变更发布划分成了多个阶段,故障最终将扩展到所有机器。因此,分级发布检查是否有效直接决定了故障引发的损失量。下面将重点介绍如何进行分级发布检查。

更快、更准发现变更潜在隐患

1 人工检查,变更发布效率无法保证

人工检查是最容易想到的检查方法,当一个阶段变更发布结束后,运维工程师会去监控平台对核心指标的波动情况进行逐一检查。如发现有波动异常的指标,则认为本次变更存在问题,中止甚至回滚变更。


在百度,运维工程师会检查 CPU 等系统指标以及请求量等业务指标,需要检查的核心指标个数一般在 300 个以上。为了保证变更发布效率,一次变更发布除去机器重启的时间,留给人工检查的时间通常只有 10 分钟左右。根据上述的分级发布流程,一共存在 4 个检查点,这就意味着要保证变更发布效率,运维工程师需要在 0.5(10*60/4/300)秒内完成一个指标的检查。我们知道,在对指标检查的时候,不单要看当前的波动,还要参考指标在历史上的波动情况,0.5 秒完成一个指标的检查人工是无法做到的。

2 基于人工规则检查,阈值选择、更新是难题

每次变更发布后人工检查核心指标耗时耗力,能否将人工检查的经验转化成规则,变更发布时基于规则进行自动检查?这就是基于人工规则自动检查。首先,人工根据指标的波动情况,给指标设定不同的阈值。当服务变更发布后,会自动启动服务健康状态检查脚本,脚本会将当时的指标采集值与人工设置的阈值进行比较,若存在指标采集值未落入人工配置的阈值范围内,则判断本次变更可能引入了故障,中止变更并通知运维同学进行处理。


如图 2 所示的两个指标,人工给请求量指标设置的阈值上界为 2.2k、下界为 1.5k;对于请求失败数指标,用户只关心指标上涨,因此给指标设置了 20 的上界。变更发布后,请求量指标在 1.5k ~ 2.2k 之间波动,判断该指标正常;请求错误数超过了人工配置的上界 20,判断该指标异常,需要中止变更。



图 2


基于人工规则检查将检查过程自动化,大幅提升了变更发布效率的同时也节省了人力成本。但是人工规则检查面临两大难题:阈值选择、阈值更新。首先,应该设置什么样的阈值是一个很难回答的问题,图 3(a)为某服务的错误日志数指标,人工根据经验将阈值上界设为 15,在一次变更发布后错误数发生了明显的上涨,但未达到人工设置的阈值,因此基于人工规则无法发现这次变更引入的故障,导致故障扩散到所有机房,影响了服务的稳定性。另外,人工配置阈值也并非一劳永逸,当指标水位发生变化后,需要对阈值进行更新。如图(b)是某服务的请求量指标,历史请求量经常维持在 1.3k,人工将阈值设置在 1.2 ~ 1.4k。随着业务的发展,服务的请求量有了突增达到了 1.6k,需要人工对阈值进行调整。



图 3(a) 图 3(b)

3 智能检查,安心躺着做变更

鉴于人工规则检查存在阈值选择、更新困难的问题,迫切需要有更智能的检查方法。我们对一些引入故障的变更进行分析发现,大部分的故障会导致指标突变,运维工程师往往对发生突变的指标格外关注。同时,我们也发现,在变更场景下,指标突变不一定代表变更引入了故障。比如,当在流量上涨期间进行变更发布时,流量相关的指标必然会发生突增。再比如,在变更发布过程中伴随着进程重启,像内存、文件句柄等指标可能会因为资源释放而发生突降。因此,智能检查算法由两部分组成:度量指标是否发生突变、对突变是否合理进行判断。若指标在变更发布前后发生了无法解释的突变,则认为指标异常


指标突变是否合理可以从以下两个角度进行解释:突变是否由时间因素、重启导致。由于时间因素的影响会同时施加在应用变更的机器(实验组)和未应用变更的机器(对照组),可以根据对照组来排除时间因素的影响;进程重启对指标的影响可以通过历史变更来建模。当对照组与历史变更均无法解释指标突变时,则认为指标异常,需要中止变更。智能检查无需人工配置参数,可以自动、智能地识别异常突变的指标。


图 4 给出了一个具体的例子,每一行代表一个指标,对于每个指标都展示了在某次变更发布前后的波动情况、对照组在对应时间的波动情况以及指标在历史一次正常的变更发布前后的波动情况。对于指标①,指标在本次变更发布后出现了上涨,但是对照组也出现了类似程度的上涨,因此判断上涨是由时间因素导致,指标变化正常;对于指标②,变更发布后指标出现突降,历史正常变更发布后指标都会发生突降,因此判断突降是由进程重启导致的,指标变化正常;对于指标③,变更发布后发生了突增,而对照组跟历史变更发布后均未发生明显变化,即指标突变无法被对照组、历史变更解释,指标异常,需要中止甚至回滚变更。



图 4

总结

以上就是我们使变更发布更加安全高效的方法,智能检查算法是减少故障损失的核心。算法基于历史变更和对照组进行,不需要人工配置参数,具有普适性。希望能够对大家有所帮助,如有任何想法和疑问,欢迎一起交流。


作者介绍


陈云 百度资深研发工程师


负责百度智能运维产品(Noah)的算法设计研发工作,在服务变更及网络故障发现、定位等方向有大量实践经验。


本文转载自公众号 AIOps 智能运维(ID:AI_Ops)


原文链接


https://mp.weixin.qq.com/s?__biz=MzUyMzA3MTY1NA==&mid=2247485233&idx=1&sn=6c4be595d677e98df69c29a6cc853e4c&chksm=f9c37ef8ceb4f7eedb95d6991c021b1578393402a7b46f5b7ae0f591bca5e4dc99cde11985e9&scene=27#wechat_redirect


2019-10-19 08:002188

评论

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

查询速度最高提升50倍!火山引擎ByteHouse在广告投放领域实践分享

字节跳动数据平台

数据库 大数据 云原生 数仓 企业号 8 月 PK 榜

2023中国算力大会,和鲸科技携手生态伙伴共同推动算力创新发展与应用

ModelWhale

AI 算力 云算力 2023中国算力大会

Audition 2021 mac完整版 音频编辑软件audition新功能

mac

苹果mac 音频编辑软件 Windows软件 audition 2021 audition

蓝易云:shell简单命令大全。

百度搜索:蓝易云

云计算 Linux 运维 Shell 云服务器

数字化转型与架构-架构设计篇|建模之“静态”模型

数字随行

数字化转型

数字化转型与架构-架构设计篇|建模之“动态”模型

数字随行

数字化转型

WIFI6E moudle-QCN9074+WiFi6 MT7915-support 2.4GHz and 5GHz-M.2-MINI PCIE how to choose?

wifi6-yiyi

wifi6 WIFI6E

峰会回顾第7期 | 视窗绘制技术演进和新趋势

OpenHarmony开发者

OpenHarmony

26. NumPy

茶桁

Python Numpy

华为云classroom赋能--Toolkit系列插件DevSecOps助力开发者提速

华为云PaaS服务小智

DevOps 开发工具 华为云

【代码实践】使用FastAPI+Supabase+LangChain开发AI应用

张文平

FastApi 应用开发 Supabase #人工智能 #LangChain

SRE 与开发的自动化协同 -- 生产环境出现 bug 自动生成异常追踪

观测云

异常追踪 智能巡检

How IPQ9574, IPQ9554, QCN9274, and QCN6274 Qualcomm Chipsets Harness the Full Potential of WiFi7 Features

wallyslilly

WiFi7 ipq9554 qcn9274 qcn6274 ipq9574

《操作系统实战 45 讲》笔记2——内存管理

袁世超

操作系统 Cosmos LMOS

illustrator2023最新版 矢量图形编辑软件ai2023简体中文版下载

mac

Illustrator ai2023 苹果mac 矢量图形编辑软件 illustrator2023

百度工程师浅析解码策略

百度Geek说

解码 企业号 8 月 PK 榜 生成模型

实时云渲染的关键技术是什么?

Finovy Cloud

云计算 3D 云渲染 实时云渲染

蓝易云:JAVA使用HTTP代理教程。

百度搜索:蓝易云

Java 云计算 Linux 运维 HTTP

使用 FastGPT 构建高质量 AI 知识库

米开朗基杨

人工智能 云计算 AI ChatGPT FastGPT

最好用的Java开发工具:IDEA 2023激活中文+安装教程

胖墩儿不胖y

Mac 软件 Java 开发 java开发工具

Apache Paimon 实时数据湖 Streaming Lakehouse 的存储底座

Apache Flink

大数据 flink 实时计算

火山引擎DataWind产品可视化能力揭秘

白露为霜

数据可视化 商业智能 BI 分析工具 图表库 BI 报表

小灯塔系列-中小企业数字化转型系列研究——CRM测评报告

向量智库

Databend 开源周报第 107 期

Databend

打造基于AI的一站式节能减碳方案,南洋万邦助力工业园区实现“双碳”目标

飞桨PaddlePaddle

人工智能 paddle 百度飞桨

学习微服务必推荐的天花板级别微服务架构笔记

小小怪下士

Java 程序员 微服务 springboot

iStat Menus for Mac中文下载附激活码

mac大玩家j

Mac软件 系统检测工具

高性能网络 SIG 月度动态:ANCK 首次支持 SMCv2.1,virtio 规范支持隧道报文内头部哈希

OpenAnolis小助手

高性能网络 龙蜥社区 anck 龙蜥sig smc

被变更逼疯的我,是如何成功自救的?_文化 & 方法_Geek_cc9ec7_InfoQ精选文章