Pick一下，工具上线前运维必备原则

作者：周小军。资深运维专家，拥有十几年的IT运维经验，擅长互联网网站架构、云计算平台及运维、自动化运维开发等领域，具有十万台级规模的基础设施规划及运营能力，腾讯学院讲师。 目前在腾讯社交网络运营中心负责数据运维和接入运维工作。

突袭而来的告警

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

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

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

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

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

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

DLP 告警是运维最关切的告警。

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

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

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

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

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

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

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

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

谁变更了路由？

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

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

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

小 D 和小 Y 电话联系上开发测试机的负责人，运维开发小 E。

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

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

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

故障后的优化和改进措施

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

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

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

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

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

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

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

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

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

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

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

11、……

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

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