18年原生开发亲测：全栈建站必备运维资源清单

　　三个月前那台机器挂了的时候，我正盯着屏上并排开的三个终端——左边是日志，中间是监控，右边在敲回滚命令。冷风机在头顶嗡嗡响，外卖袋子上的水汽把桌角弄湿了一片，老张在旁边嗦泡面，吸溜声混着告警灯的闪烁，突然就懂了什么叫「运维的夜晚」。

　　我原以为全栈建站最坑的是开发环节，结果这十八年踩的坑，八成都在运维上。那天挂的是主库，磁盘inode满了，备份脚本卡在僵尸进程里，新写入的数据全堆在swap分区——等发现的时候，业务已经瘫了半小时。老板在群里@所有人，开发在工位上骂监控阈值设得太低，而我盯着跳板机密码过期提示，突然想起上个月删掉的「运维资源清单」文档。

文章配图，仅供参考

　　所以我现在特别信「优胜劣汰」这四个字。运维资源清单不是越全越好，是得经过血泪验证的。比如我们之前用某云厂商的负载均衡，文档里写着「支持百万级并发」，结果实际压测到十万就丢包——后来换了另一家，文档里只写了「经过生产环境验证」，反而稳得一批。再比如监控告警，有人喜欢把所有指标都加上，结果半夜被「磁盘使用率85%」的告警吵醒，爬起来一看，是临时文件占的，删了就没事。现在我清单里只留关键指标：主库连接数、API响应时间、核心业务日志错误率——其他的，爱闪闪去。

　　但最坑的还是那些「看起来没问题」的细节。比如证书续期，之前有个项目用的Let's Encrypt，自动续期脚本写得挺漂亮，结果有次域名解析被污染，证书没续上，业务直接挂了。后来我在清单里加了条「证书续期前需检查DNS解析」，还把测试环境的证书故意设成过期，逼着开发自己手动续一次——现在他们比我还怕证书过期。还有备份，有人觉得「每天全量备份」就够，结果有次误删数据，恢复的时候发现备份文件被覆盖了——现在清单里明确写着「全量备份保留7天，增量备份保留30天」，还加了条「恢复测试需在测试环境验证数据完整性」。

　　说到测试环境，我想起上个月迁移那档子事。老板为了省钱，非要把测试环境从云主机迁到物理机，说「物理机便宜，性能还好」。结果迁移那天，开发小李在工位上骂了半小时——物理机的磁盘是SAS的，IOPS比云主机低一半，数据库查询直接慢了30%。更搞笑的是，物理机的网卡是千兆的，内网传输速度还没云主机的万兆快。最后老板妥协了，说「还是用云主机吧，至少稳定」——我默默把清单里的「迁移前需测试硬件性能」那行加粗了。

　　不过清单也不是万能的。比如有次主库挂了，按清单里的步骤先切备库，结果备库的同步延迟了5分钟，切过去后发现丢了最近5分钟的数据。后来我们改了策略，主备库之间加了个中间件，实时同步数据，还写了个脚本监控同步延迟——现在清单里多了条「主备同步延迟超过10秒需告警」。还有次DNS解析被劫持，业务全跳到了钓鱼网站，按清单里的步骤改了DNS记录，结果缓存没清干净，部分用户还是访问到旧地址。后来我们在清单里加了条「修改DNS后需在各大CDN厂商后台手动刷新缓存」，还把测试环境的DNS解析故意改错，逼着开发自己清缓存——现在他们比我还怕DNS问题。

　　现在回头看，那十八年踩的坑，最后都变成了清单里的一行字。有人觉得运维是「救火队员」，可我觉得，好的运维应该是「防火员」——把能想到的坑都填上，把能预防的故障都挡住。至于那些想不到的坑？那就等踩了再说——反正清单会越写越长，运维也会越做越稳。

　　不过话说回来，这清单也不是一成不变的。比如上个月云厂商出了个新功能，支持自动扩容，我就把清单里的「扩容需手动操作」改成了「优先使用自动扩容，手动扩容作为备选」。还有次开发用了个新框架，监控指标和之前不一样，我又在清单里加了条「新框架需单独配置监控指标」。所以这清单啊，得跟着业务变，跟着技术变，跟着坑变——不然，迟早会被淘汰。

　　最后说句实话，这清单我从来没给老板看过——他只看业务有没有瘫，用户有没有骂。但开发们知道它的好，每次故障复盘，他们都会翻出清单，说「这行没写」或者「那步没做」。有时候我觉得，运维资源清单不是给老板看的，是给开发们看的——是让他们知道，运维不是「背锅侠」，是「兜底的人」。

　　至于明天会不会有新的坑？谁知道呢。反正我的清单已经更新了，这次加了条「值班时别吃泡面，容易呛到键盘」。

（编辑：草根网）

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