最近的几次生产环境事故
文章目录
前言
记录下过去几天的事情来平复下心情,再想想如何预防和应对已经出现和可能发生的问题。最近的线上环境问题接连不断,快到每天晚上都会做噩梦的地步。目前暂时不用出差施工,只是一边对接硬件设备写后台,一边跟App需求写应用,全盘接手运维,离手忙脚乱只差一点。如果下个月能够专心处理好运维的事情的话,要把麻烦的问题全部自动化处理。
正文
这几天出的三个事故:
第一次A厂家删除数据导致磁盘爆满,牵连B厂商服务挂掉,接着查出B厂家在线下的设备已经烧掉四个;
第二次升级一个没有依赖的独立服务,结果导致线上服务连续挂掉,没有预警,直到线下人员反映;
第三次还是A厂家ActiveMQ配置问题,导致服务器被入侵挖矿,又一次牵连B厂家服务挂掉。
第一个和第三个问题和当前的服务器配置有关,因为A、B两个厂家的服务都部署在一个服务器上,对比硬件采购费用,服务器的每年开支只占了很小很小的一部分,而直到发生事故才觉得这是一件很不理智的事情,但如果做好防火墙配置,也不会发生第三个问题,因为之前对接人员没有继续跟进关闭不需要对外开放的端口。
第二个问题则与代码有关,一个服务没有做好异常处理,相互依赖的服务接连故障,在问程序员为什么的时候,他回答需要做的异常处理太多了,没办法一一解决。
oracle undo表导致磁盘爆满
事故回顾
最初是A厂单独用来存放oracle数据的磁盘快满了,于是联系对方技术支持清理数据库;
对方技术支持并没有在约定时间清理,第二天磁盘已满,于是再次联系;
对方清理数据库,采用delete的方式,undo表空间直接爆满。
最终A厂的全套服务挂了,B厂服务因为存放在同一个磁盘上的MySQL数据库也无法写入,也一起挂了,而待B厂的服务恢复后,又发现一些路段接收器无法正常工作,排查原因后才发现因为下雨进水,设备烧了。
当天紧急清理了数据盘,腾出了大约2GB的空间,让两个服务恢复工作,然后从上午开始到夜间10点都间断地盯着磁盘空间,随后又清理出3GB的空间。到了夜间关闭服务,直接删除了全部数据后,重建数据库,并约定以后定期清理数据库,采取直接删除,避免undo表空间爆满。B厂的设备则只能联系厂家更换。
小结
一开始沟通时A厂技术人员提出拓展硬盘空间,而目前阿里云不论系统盘或者数据盘,扩容后都需要重新格式化;
于是讨论新增一个硬盘,拷贝数据后重新挂载,300GB的空间可以使用一年左右,只是无法避免到时删除数据又导致磁盘爆满;
最后确认直接清空数据库,不保留恢复操作,因为旧数据在推送后就不会去使用了。
事故持续了漫长的时间,幸好主要在夜间和清晨,早上赶到公司后,整整一天都在处理问题。很多时候,当第一个问题出现时就应该警觉,很多被隐藏的问题可能会一起出现,另外鸡蛋最好不要放在同一个篮子里。
微服务带来的麻烦
事故回顾
那天下午升级了一个没有其他依赖的独立服务,一个用于管理app发布的服务。升级后发现MongoDB和NFS配置出错,于是回退,紧接着发现接入层facade服务异常,线下人员反映App无法使用,于是重启facade服务,到了晚上快回家时,线下反映新路段的硬件设备全部无法工作。经过排查,还有一个向facade转发数据的服务在facade重启后,并没有正常工作,重启该服务后恢复正常。
小结
微服务增加了运维的难度,特别是在原运维离职的情况下。我们的后台将各种服务拆分,使得各自之间可以独立开发升级,然后在k8s内部使用命名空间和EndPoint联系服务,同时也使用了zookeeper。这样的状况就是,运维必须懂后台开发,理解服务之间的依赖,更直白的说,需要懂Java后台开发。
又被挖矿了
事故回顾
在那天晚上19点过后,线下反映设备又无法工作了。赶紧上到接入A、B厂的网关查看,发现有几个进程一直占用100%的CPU时间,反复杀死也无效,由于该程序占用了一些本地端口,导致B厂的程序一起挂掉。最后联系A厂的运维人员清理服务器并重新配置了MQ,也是从他那里得知挖矿程序是从MQ进来的。
小结
A厂的运维人员在登录服务器后 ,就立刻反应过来被挖矿,而且应该是透过MQ服务进来的,很显然对方遇到过类似的情况......在对接第三方服务时,应该做好全面的工作,只开放需要开放的端口,而对于开放的端口,仔细检查好权限。
总结
几次事故下来,每次的反应都变得更快,在微服务和k8s盛行的现在,对于一个公司来说,最重要的事情之一,应该就是做好应对运维开发跑路后的服务崩溃处理了。