管理服务器，到底该“套”什么清单？一个老运维的私藏干货
干服务器运维这行久了，你会发现一个特别有意思的现象：新手总爱研究怎么装系统、配RAID、调内核参数，觉得那才叫技术；而真正干了三五年的老油条，下班前干的第一件事往往是——打开一个Excel表格，或者翻一翻Trello、Notion上的某个清单，挨个打勾，为什么？因为服务器这玩意儿，平时不出事岁月静好，一出事就是连环爆，没有清单在手，脑子里那点“以为记住了”的东西，在半夜两点被报警短信炸醒时，根本顶不住。
所以今天这篇东西，我就把自己压箱底的那几套“清单”掏出来跟你聊聊，别小看这些清单，它们不是从网上下载的通用模板，而是我一次次宕机、一次次丢数据、一次次被老板吼之后，用血泪换来的“保命符”，你问我“管理服务器套什么清单”，我给你的答案不是一张单子，而是一套组合拳——硬件清单、软件清单、监控告警清单、变更操作清单、灾备恢复清单、安全合规清单，六个方向，缺一不可，你要是能把它们串起来，别说自己管三五台机器，就算是上百台的集群，心里也不带慌的。
一、硬件清单——别等机器冒烟了才想起看型号
先聊最基础的硬件清单，很多人觉得这玩意儿有啥好列的，服务器型号、CPU、内存、硬盘序列号，装好系统的时候看一眼就完了，错，硬件清单真正的作用，是在你出故障之后帮你快速判断“换什么、去哪换、怎么换”，比如说你一台戴尔R740，某天硬盘亮黄灯，你打开清单一看，嘿，这台机器硬盘位装的是三星PM983 3.84T，接口是U.2，那你是直接买同型号，还是可以用Intel P5510代替？如果没有清单，你就得拆机、看标签、再上网查兼容列表，半小时过去了，有清单的话，两分钟搞定下单。
更关键的是，硬件清单要包含“保修状态”和“备件位置”，我见过太多公司，机器都过保了还在死扛，结果硬盘坏了买不到原厂盘，被迫换整机，所以你的清单里必须有三列：SN码、购买日期、保修到期日，每月看一眼，快过保的提前走续保流程，建议把备件库里的硬盘、内存、电源、风扇也列进去，标清楚“可用数量”和“存放位置”，别等到换的时候到处翻箱倒柜。
二、软件清单——谁装了什么东西，心里得有数
软件清单比硬件更头疼，因为硬件是物理存在的，少根内存你一眼就能看出来；软件可不一样，很多人入职第一件事就是往服务器上装各种包，离职了也没人知道装过什么，结果系统跑着跑着，某个服务突然报依赖库冲突，一查发现是三个月前有人装了个Python包改了系统库路径。
我的做法是：每台服务器必须维护一份“已安装软件清单”，包括操作系统版本、内核版本、主要应用（Nginx、MySQL、Redis、Docker等）及其版本号、依赖库列表（比如OpenSSL、zlib、libxml2），每次升级或者安装新软件，都要在清单里记录变更时间和操作人，别偷懒，这玩意儿可以用ansible批量采，也可以用脚本每天自动生成一个快照，然后git管理差异，不要相信人的记忆力，只相信记录。
许可证和密钥也属于软件清单的一部分，Windows Server的激活码、数据库的商业授权、SSL证书的到期日，全都要列出来，我见过最惨的一次，是某公司用的Web应用依赖一个商业字库，证书到期后前端模板直接报错，整个网站字体乱码三天，最后挨个排查才发现是字体授权过期，你说冤不冤？但有了清单，提前一个月设个提醒，一分钟就能解决。
三、监控告警清单——不要报警了才想怎么配
监控告警这块，很多人的误区是“装了Zabbix/Prometheus就算完事了”，然后每天看到几十条告警消息全当没看见，这不是监控，这是噪音，你需要的是监控清单——不是工具配置，而是“到底哪些指标必须告警？告警阈值是多少？告警升级规则是怎样？”
我建议你从四个维度列清单：可用性（ping通吗？端口活着吗？）、性能（CPU、内存、磁盘IO、网络带宽的使用率）、资源历史趋势（比如磁盘空间90%以上就要告警，而不是到99%才报，因为SQL慢查询可能早就开始拖库了）、业务指标（接口响应时间、错误率、QPS），每个指标都要写清楚：谁来检查、检查周期是什么、告警级别是P1还是P3、通知渠道是短信还是钉钉群、谁是第一负责人、多长时间没响应要升维。
举个例子：磁盘可用空间低于20%时发警告给值班群；低于10%时直接电话打给系统负责人；低于5%时自动触发运维经理介入，没有这个清单，你永远不知道哪个告警该先处理，有次我带的一个新人，半夜三点收到磁盘满的告警，他看了一眼“好像还有10%”就继续睡了，结果凌晨五点业务全挂，后来发现那个磁盘是数据库的redo日志专用区，10%空间只够写五分钟，有了清单，这种事就不会再发生。
四、变更操作清单——改什么、怎么改、改完怎么回滚
服务器最怕的就是“手贱”，多少人因为没打变更规范，直接在线上执行了rm -rf？又有多少人升级内核之前没做备份，结果系统起不来？变更操作清单就是为了管住这双手。
每个变更操作前必须走一个流程清单：变更目的、影响范围、操作步骤（含每一步的预期结果）、回滚方案、执行窗口、审批人、测试确认人，注意，回滚方案不是“重装系统”这么笼统，而是要写清楚：如果第3步执行失败，第4步应该怎么恢复；如果整个变更失败，能否切回上一个快照或备份，每一步都要能验证，比如你要升级MySQL 5.7到8.0，清单里就应该包括：先克隆一台测试环境升级验证，再在主库做备份，然后从库灰度升级，观察半小时确认无报错后再切主库，最后备机也升级——每一步都要打勾。
我自己的经验是，把这种清单做成一个模板，像做手术前的核对表一样，每次变更前，必须两个人同时确认，一个人读操作，一个人核对清单，别觉得啰嗦，这花费的十分钟，可能省下你通宵三天恢复数据的时间。
五、灾备恢复清单——别等火烧眉毛了才翻文档
灾备这件事，大多数公司都有备份策略，但很少有人真的“定期恢复演练”，结果真出事了，才发现备份文件是坏的、恢复步骤文档和实际环境对不上、或者数据库恢复到一半发现日志断链，所以灾备恢复清单的核心不是“怎么备份”，而是“怎么恢复”。
清单上要写清楚：全量备份文件的位置、最近一次备份的时间、增量备份的日志链完整性校验结果、恢复步骤（注意数据库要选时间点恢复）、恢复后如何验证业务正常（比如跑一个测试查询、检查某条关键记录是否存在）、联系人电话（包括机房断电后值班人员的手机号），更重要的是，这张清单必须每季度做一次“桌面演练”——不用真跑，但至少要打开文档，跟着步骤在脑子里过一遍，看看有没有“这里写的不对”或“这个IP地址已经变了”的情况。
我见过最离谱的一次：一家创业公司的灾备文档里，恢复步骤写的是“登录Azure portal，找到blob容器，下载最新的dump.sql，然后导入”，但他们的数据库后来从MySQL换成了PostgreSQL，文档却没人更新，真出事那天，折腾了一整天，最后发现他们根本没PG的导出工具，清单不能写了就完事，要像消防演习一样，定期检查、更新、跑通。
六、安全合规清单——别等被黑了才补漏洞
最后说安全清单，很多运维觉得安全是安全部门的事，错，服务器在你手里，你是防线第一人，你需要一张安全检查清单：哪些端口开放了？对应哪些服务？这些服务有没有已知高危漏洞（CVE）？SSH是否开启了密钥登录并禁用了密码？管理员账号有没有定期轮换？系统级别的安全加固做了哪些（SELinux、AppArmor、内核参数调整）？日志有没有集中收集并保留180天？
合规方面，如果你们公司要过等保或者ISO 27001，那清单就更细了：系统日志审计策略、用户权限最小化原则、数据库加密、传输层加密（TLS版本不能低于1.2）、第三方依赖库的漏洞扫描频率、甚至机房的物理访问记录，不要想着全记住了，老老实实列张表，每季度对着检查一遍，打勾或打叉，叉多了就知道哪里要补。
我特别建议把“补丁升级清单”也放进来，很多安全事件就是因为一个已知的RCE漏洞没有打补丁，你可以在清单里记录每台服务器的补丁更新日期、重启次数、已知未修复漏洞数量，推荐用CVE评分大于7的漏洞作为强制修复项，低于7的可以随版本升级一起处理，但不能永远不修。
—清单不是为了限制你，而是为了解放你
写了这么多，你可能会觉得：“妈呀，管理服务器要搞这么多清单，也太累了吧？”其实恰恰相反，当你把所有该记的东西都写进了清单，你的大脑就可以从“记细节”中解放出来，去思考架构优化、自动化运维、性能调优这些更有价值的事情，我身边那些运维大神，没有一个靠的是记忆力，全是靠一套打好的“清单体系”在支撑——遇到问题先查清单，按步骤走，出错了也有回滚方案托底，心态稳得很。
所以回到最初的问题：“管理服务器套什么清单？”我的答案是：硬件、软件、监控、变更、灾备、安全，这六大清单一个都不能少，它们就像你工具箱里的一套内六角扳手，每个尺寸都对应一颗螺丝，少一把，关键时刻就干瞪眼。
最后送你一句话：清单是运维的肌肉记忆，写下来，用起来，你就能和服务器好好过日子了。
文章摘自：https://idc.huochengrm.cn/js/27611.html
评论