前言

记录下过去几天的事情来平复下心情,再想想如何预防和应对已经出现和可能发生的问题。最近的线上环境问题接连不断,快到每天晚上都会做噩梦的地步。目前暂时不用出差施工,只是一边对接硬件设备写后台,一边跟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盛行的现在,对于一个公司来说,最重要的事情之一,应该就是做好应对运维开发跑路后的服务崩溃处理了。