昨天，给大甲方做运维方面的安全检查，发现近半年多个重要系统发生故障停机，平均停机时间30多分钟。这些故障五花八门，看上去好像都是随机不可控“故障”，比如服务器中间件和数据库对接出问题了、异常增大的访问量把服务器压垮了、金蝶中间件出问题、装达梦数据库客户端占满服务器内存、应用服务器内存不够用、数据库密码过期、东方通中间件内存溢出等等。这些故障直接导致服务重启、系统反应变慢，甚至浏览器跳出 502、500 错误，好多业务操作都没法正常进行。所以，甲方大人也没有说啥，认为这个是不可控的技术故障。不过，咱们明白啊，这个明显是运维工作没做好，存在三大短板：类似应用服务器的内存使用率其实是要建立预警机制的，我做通保就经常会查这样一个条款——“应定义业务水平阈值，能够对业务及应用服务水平进行检测，并具备当服务水平降低到预先规定的阈值时进行告警的功能”这个业务水平就包括了CPU、内存、带宽，当使用量超过阈值发告警通知，现在云厂商都用云监控提供这类告警了。而这家大甲方的运维团队每次都是内存耗竭发生故障了才能发现，被动救火，分数只能打59分了。除此之外，数据库密码过期的问题其实也要预警的，实在不行写个脚本每天跑跑，把需要监控的参数都过一遍，也能避免因数据库密码过期而产生的停机。（真要是一些大电商平台、停机的成本多高啊，真要是数据库密码过期导致的，运维人员还能保住饭碗吗？）比如有的运维人员装达梦数据库客户端之前，连它会占用多少资源都没评估，也没预留足够的内存。装了完成任务了还不删除，结果时间一长就把资源占满了；另外，对那些非日常业务接口的访问量，也没做限流控制，导致访问太多把系统压过载。这些你说是经验问题还是技术问题，还是规范问题。分数也只能打59分了。数据库密码啥时候到期，没放进定期检查的清单里；中间件处理大文件时，内存释放的策略也没优化，结果故障反复出现，处理还总是滞后。那如果我们想把手里的工作做到60分以上，应该怎么做呢？其实就是对应这三个运维短板，各个击破之。首先，我们把监控预警体系要筑牢。诸如应用服务器内存使用率、数据库有效期、接口并发访问量这些指标要增加实时监控、设定阈值，如内存使用率超过85%就自动报警，这样一旦有异常就第一时间发现，不用等故障发生了再救火。其次，我们要把运维流程盯严实。要把需要定期检查的清单列全了，诸如数据库密码有效期、服务配置这些内容加进去，明确谁负责检查，多久检查一次，避免因为忘了检查导致故障。如果涉及占用大量资源的操作，必须先评估需要多少资源、预留多少冗余，报上去审批通过后才能执行，不能盲目变更。最后，当然是责任落到人头。得明确故障的责任归属，比如因为没检查到位导致密码过期，或者因为预警没做好导致内存溢出，这些情况都要能追溯到具体责任人。通过这种方式，让运维人员把规范操作记在心里，不敢懈怠。毕竟重要信息系统的稳定运行容不得半点马虎。
咱们运维工人，微小的工作，也有该承担的责任和该守的纪律。
THE END
我最近在研究网络安全运营平台（SOC）相关技术，写个人学术研究论文用，欢迎以下朋友加入我的交流群：
- 正在使用某款平台的运维/安全同仁
- 有开发过相关功能的工程师
- 想了解 SOC 架构/场景的研究者
🧩 请加我微信：catfishfighting（备注：SOC，不备注我就默认拉安全大群了）
📋 然后邀请大家填写一份SOC功能小问卷，调研完成后我会第一时间在群内分享分析结果。
一起学习，一起进步 🙌
或者直接点链接：https://www.wjx.cn/vm/rKrDnqL.aspx#
还没有评论，来说两句吧...