一条测试路由引起的业务生死告警

作者简介:

图片

周小军
腾讯资深运维专家,拥有十几年的互联网IT运维经验,擅长互联网架构、云计算平台、运维自动化等领域。对跨行业的DevOps、云计算、技术架构和团队管理等均具有深厚兴趣。腾讯学院讲师,高效运维社区金牌讲师。在腾讯SNG社交网络运营中心负责社交业务运维管理,目前专注于运维AI、运维大数据和海量运维自动化的实践。

突袭而来的告警

一场突袭而来的大雨猛烈冲刷着DBA 小卫身侧宽大的玻璃窗。窗外原蓝天白云映照下的深南大道转眼陷入一片阴暗。

图片

小卫抬起手看看手表,已经差不多11点50分,他起身对DBA 小王喊,小王,好了没,走吧吃饭去。12点后的腾讯12楼食堂通常人山人海,出餐的队伍一直排到电梯口,DBA们早去早食,节约时间。

小王立起身来说,刚搞定一个工单,走吧。

二个人刚要走出卡位,突然小卫手机响起iPhone的经典铃声,屏幕上闪出“腾讯自动语音告警”,拇指点击接听,人工合成的生硬女声从麦克风里跳出来:“你有一个语音告警,业务ID 394521模调成功率下跌到0%,请及时处理,确认请按1,转接备份负责人请按2……”

几乎与此同时,同楼层的业务运维小吴向小王大喊,小王,开放接口业务有DLP告警,ROOT显示是数据层有问题,赶紧看下。

图片

DLP是业务生死告警,每个业务将核心指标接入DLP,如图片上传成功率、用户登录成功率等,当核心指标下滑到阈值时触发DLP告警。DLP告警是运维最关切的告警。

ROOT是根源智能分析,它基于业务架构,结合数据流关系,通过时间相关性、面积权重等算法,将监控告警进行筛选分类,发掘有业务价值的告警,并直接分析给出告警根源。

小卫马上扑到电脑前,钢琴师般的手指娴熟输入十多位锁屏密码,他打开监控视图,只见开放接口业务ID的模调成功率从99.98%高空跳水跌到0%,触发了模调失败率告警。

小卫滑动鼠标点开业务视图,输入告警的业务ID,跳转到业务ID所属的数据仓库视图。数据仓库监控一切正常,接入服务器、数据服务器等没故障告警,网络正常,唯一异常的是接入和数据流量都严重下跌。

小卫马上对小王说,你查下A仓库到业务逻辑的链路是否OK。稍候小王回,PING包正常,网管值班反馈交换机无异常。

与此同时,几个RTX群已开始在屏幕右下角闪烁个不停,不消说,产品、开发、QA和运维已经在拉群询问故障原因。

小卫脑海里闪出清晰的业务架构逻辑,仓库正常,业务逻辑模块正常,流量跌零,网络正常,大机率是路由出了问题,他切到路由系统,果然,仓库路由流量跌到零,路由里的接入服务器IP列表都不是正确的接入服务器IP。

小卫马上联系路由系统运维回滚路由版本,同时让小王排查是谁在这个时间点变更仓库路由。

10分钟后,路由版本回切到正确版本,数据仓库流量回升,模调成功率重回到三个九。

谁变更了路由?

业务恢复正常后,此时已经是中午12点30分,幸亏是长尾业务数据仓库,影响用户范围不大。

图片

顾不上吃饭,小卫和小王继续排查问题根源。小王反馈,从系统上查不到故障时间点的路由变更记录。看来是非正常途径的路由变更操作,只能查看路由变更接口的记录。

路由系统运维在接口变更记录里看到在11点46分,有一个IP做变更,将该业务ID的所有接入服务器变更为一台测试接入服务器。在CMDB(配置中心)里查到此IP是开发测试机。

小卫和小王电话联系上开发测试机的负责人,运维开发小李。

原来小李负责开发跨仓库的数据搬迁工具,今天上午他刚完成某个版本的迭代。在测试环境开发完成后,经过简单的功能调试,小李在现网验证工具的功能。

数据搬迁工具有个步骤,将新仓库的路由批量变更接入机IP。小李在现网的测试仓库创建了测试业务ID 394521,但杯具的是,他在调试代码里把测试仓库ID误写成现网仓库ID,没经过认真核查,小李在上午11点多匆匆手工跑了下流程。看到流程运行正常,没有异常日志,恰好是饭点,小李于是便起身去了食堂。

正常仓库的现网业务路由被误覆盖后,模调告警、DLP告警等接连触发,但此刻的小李正在食堂里边排队边刷手机,丝毫没意识到自己的工具BUG引发了严重的线上故障。

故障后的优化和改进措施

故障解决后,QA 小黄拉起现场会复盘故障的整个流程。告警触发、响应速度、根源追查、故障恢复等都在预期之内。但故障反映出运维开发工具的不规范:运维开发对运维环境不了解,工具在生产环境随意测试,测试时未知会运维人员,核心代码无审核等。

小黄根据大家的意见,制定了运维工具开发规范,规范包括以下几条核心原则:

1、严格遵循团队编码开发规范

2、技术架构和核心产品规划都需经过团队评审

4、模块间松耦合,使用API进行交互,API必须具备标准协议、鉴权、日志和限流能力

5、网站有严格的权限鉴权

6、核心逻辑代码双人审核,特别是规模性、集群性的变更工具代码必须要过T3工程师审核。核心构架代码经过严格的单元测试,并且灰度逐渐使用

7、所有操作记录都要存入操作日志

8、规模性变更工具具备变更版本差异记录、变更回滚能力

9、测试环境和生产环境严格剥离,禁止在生产环境使用各种测试用例

10、变更工具必须向中心变更接口提交变更日志

11、……

运维人员掌握着生产环境的生死大权,相对产品功能BUG,运维的脚本BUG,或者操作疏漏,造成的危害都是极大的,甚至会导致现网全网故障。

因此,“工具上线前要严格测试和灰度验证”,不把BUG引入生产环境,不仅是DBA,也是全体运维必须把握的原则。

DevOps 三十六计之数据库运维:

图片

图片

图片


猜你喜欢

转载自blog.51cto.com/15127563/2665773