前言

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