SQL Server DBA实战手册：自动化运维宝典

　　我原以为那只是个普通巡检日志里飘过的“登录失败”——第七行，第十三列，连IP都懒得标红。结果盯着看了半分钟，手没动，心先往下沉了一截：失败时间间隔太齐了，齐得像拿尺子量过，每三十七秒一次，不多不少。防火墙日志一直在刷，但刷的不是攻击流量，是心跳包，密密麻麻叠着盖章，根本分不清哪一行底下压着真实请求。

　　去年六月，凌晨两点十四分。运维老张电话打进来时我正啃第三包泡面，汤已经凉透，浮着层油膜。他说“库表锁住不释放”，我回“查谁在跑长事务”，他顿了两秒，“没人跑……所有会话都是 sleeping，但阻塞链绕成了麻花”。我没接话，点开监控面板的手有点抖。CPU没爆，内存没涨，IO平得像湖面——可数据库就是不动，像被焊死在某个毫秒级的时间切片里。

　　其实那本《SQL Server DBA实战手册：自动化运维宝典》，我书架上躺了两年，扉页还写着“待精读”。真翻开来，是上个月——就在我把主从切换脚本改到第四版、又因为业务方硬塞进来的“实时报表定时任务”崩掉三回之后。书里第三章讲“不可中断操作的幂等回滚”，不是教你怎么写SQL，是教你怎么在凌晨三点四十七分、DB已失联、备份校验脚本刚报错的情况下，靠一行带判断的PowerShell命令，把七台实例里五台的状态拉回“疑似存活”。我当时边抄边骂：这哪是手册，这是续命指南。

　　我不信命，但我信淘汰率。你见过多少人靠手动杀spid撑过连续四十八小时？你见过多少人一边拖着SSIS包重跑一边听业务方在钉钉语音里吼“就差这一单数据！”？我们那个群，年初一百二十三人，现在七十六个头像灰着。不是离职，是悄没声儿地退了——有人去干云迁移了，有人说“算了，考PMP吧”，还有人直接转去写Python爬虫，说“至少能看见响应码”。优胜劣汰？它不挑你多懂死锁图谱，只看你熬不熬得住第七次应急复盘会前，突然发现昨晚的自动巡检邮件压根没发出去。

　　窗外天亮了，灰白的那种，灯还亮着。手机一直在震，是同事小林问“恢复脚本里的-Force参数到底要不要加”。我没回。盯住那段报错日志：Login failed for user ‘app_readonly’… 然后下一秒变成 Login failed for user ‘sa’… 再下一行，又跳回 ‘app_readonly’。不是爆破顺序乱，是有人故意在混淆溯源路径。可我查不出源头在哪——代理？中间件？还是某台三年没重启过、管理员密码写在Post-it上贴在显示器边框的旧服务器？没查清，也不敢说清。

　　反正那天最后收尾，不是靠书里的方案。是老张在机房拔了网线，我又让小林在SQL Agent里删掉一个名字叫“Data_Refresh_Sync_v2_2023”的作业——这玩意儿半年前上线，业务方说是“为BI平台准备的”，但从来没人看过它的T-SQL。删完不到十秒，阻塞链断了。DB活了。没人庆祝，我灌了半杯冷咖啡，手还在抖。后来翻手册第47页，才发现有一行极小的批注：“警惕带‘v2’‘_new’‘sync’字样的Agent作业——它们常伪装成必要任务，实则为兜底通道。” 我原以为是作者臆测，结果……呵。

　　对了，中午跟业务方吵了一架。起因是他非要在凌晨一点零三分手动执行“清理历史订单”的存储过程，理由是“系统提醒我今天要清理”。我吼他“你点确定的时候看没看上面写的‘建议由运维调度’？”，他反手把截图甩过来：提醒框右下角，确实印着一行灰色小字：“此任务已绑定自动化策略，当前触发条件失效”。我哑火了。后来才知道，是他们自己上周把策略调度服务停了，理由是“测试环境要腾资源”。我说你早说啊。他说，“我以为你们有告警”。

文章配图，仅供参考

　　我其实记得更早的事。八年前，也是六月，一个客户库半夜暴涨到98%磁盘占用，查出来是审计日志没关，每天自动生成两百G二进制流。我蹲机房用xp_cmdshell手动删，删到手抽筋，回来写了个bat扔进计划任务。第二天一上班，运维老大拍我肩：“小伙子，别干体力活了，来学写自动化”。那时我觉得“自动化”仨字金光闪闪。现在才懂，它不是省事，是让你在同一个坑里，踩得更快、更深、更不引人注目。

　　泡面盒还在桌上，结了一圈奶皮。我伸手按灭屏幕，黑下去之前最后一帧，是手册目录页里用荧光笔标出的“第八章：故障自愈闭环设计——基于事件流驱动的响应式模型”。没细看，但知道下面一页是“实战案例：模拟跨可用性组脑裂场景下的仲裁决策逻辑”。我知道得补——得把那个逻辑改成支持异构集群，下周上线新环境用。也知道补完也没用。这类问题，防不住。顶多，让它晚来两小时，够你扒完最后一口凉面。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!