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

作者简介：

周小军
腾讯资深运维专家，拥有十几年的互联网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 三十六计之数据库运维：

标签：小卫,运维,业务,变更,生死,告警,路由
来源： https://blog.51cto.com/15127563/2665773