2019 年 12 月 31 日晚，我正在公司门口准备打车回家，因为想跟家里人一起过个跨年夜。
望着灯光四射的广州塔，脑海里突然出现了 2012 年跨年夜的场景。
那时候也是 12 月 31 日晚， 也有出租车， 也有广州塔，还有一个跨年的故障。
我记得当晚，我们一帮同学四人，约好了去广州塔倒数，毕竟还年轻，对跨年倒数这个事情还蛮热衷的。
说好了，他们三个搭出租车，到我楼下的路口来接我。
那晚天气稍冷，需要穿两到三件衣服的样子，时不时有微风吹过。
路上行人络绎不绝，大家三三两两的，都朝广州塔方向走去。
路边绿化树上，各高楼外墙，广州塔上，灯光闪闪。
一片喜庆热闹的图景。
搭载着我同学的出租车到了，我赶忙上了车，一上车，大家就七嘴八舌地寒暄起来，虽然同在广州，但一年见面相聚的次数也不多，每次相聚，都像认识了几十年的老友。
大家聊得正酣的时候，我的手机突然响了。
我打开手机一看 ， 公司的电话，“完了，麻烦来了！
” 我的潜意识犹如条件反射般 ，立马想到了故障。
我接听了电话，是值班机器人的报警，提示说我有一个5星报警，需要我关注。
我立马打开了微信，报警机器人给我推送了一条 机器磁盘占用率超过 80% 的报警。
我点进那条 h5 消息，看了具体的细节。
是 朋友圈集群 的一组机器，看曲线，机器的磁盘占用率已经达到 80%了， 而且还有继续上涨的趋势。
2012 年，年中的时候，我们已经将自研存储系统推广到了微信的账号，联系人等模块，朋友圈模块是一个月前刚接入的。
因为朋友圈的写入量相比其它业务要大很多，所以确实存在一些待优化的地方，但因为人力紧张，还没给排上期。
当初存储系统的设计，为了追求更高的性能，采用的是追加写的模式，所以会引入数据膨胀的问题。
不过，我们设计了一套数据回收机制，可以让机器在夜晚低峰期的时候，做数据回收。
不过遇到写入量巨大的时候，会出现回收速度赶不上写入速度，导致爆磁盘的隐患。
那晚的故障，便是这个原因带来的。
）
我一看，磁盘占用率已经80%了，心里一紧，想着回家 vpn 处理，但刚上出租车，而且大家伙已经大半年没聚了，真不想扫大家的兴。
后来我静下心来仔细想了想，想到了处理的办法。
我赶紧联系了一个开发同事A， 但A刚好也在外面，然后又联系了运维同学B， B在家里，可以帮忙 vpn 处理。
处理方式不难，就是提前打开磁盘回收进程，回收磁盘空间，但过程中需要时刻监控机器的负载，保证服务质量不受影响，所以需要有人一直盯着。
我电话跟 B 说明了整个过程，他表示没问题，可以处理。
于是，我心稍微安定了下来。
10 分钟后，出租车到达了广州塔周边的一个露天酒吧，我们准备在那个露天酒吧喝点啤酒，然后看着广州塔的上的倒计时跨年倒数。
一下车，我靠路边站定，立马电话运维同学B， 询问处理的情况。
他说一切操作完毕，回收进程已经开启，目前磁盘占用率由 80% 下降到了 75% 。
我心更安定了些。
我们走进酒吧，找地方坐定，我同学点了些酒。
喝着啤酒，就着些小吃，看着珠江上的游船和对岸珠江新城绚丽的灯光，着实惬意，不过忽得想起那个故障来，心里又隐隐升起一丝担忧。
23：
59：
50 秒，广州塔上出现了倒数的计时器， 我们仰头对着计时器，跟着全酒吧的人一起倒数 “10 ， 9 ， 8 ， 7 ， 6， 5， 4，3，2，1 ”， “耶， 新年快乐！
！
！
” 我们举杯同庆。
大家沉浸在一片欢乐中，我看有人开始认真拿着手机，在编辑什么。
我也打开了手机，习惯性的打开朋友圈，一看， “麻烦又来了”。
就在刚刚一分钟不到的时间里，已经多了十几条的新动态，我想朋友圈的那组机器可能要撑不住了！
我赶紧电话了运维同学 B， 确实如我所料，磁盘占用率飞速上涨，目前已经到 85% 了，而且上涨势头不减。
我跟 B 说，再调大回收的速度吧，也暂时想不到更好的处理办法了。
B 立马着手了操作。
调大了速度后，磁盘的回收速度是加快了，但机器的负载也上去了，感觉是游走在崩溃的边缘呀！
我心里紧张极了，但也只能期待老天爷保佑了！
后来，我每5分钟一个电话，询问最新的情况，所幸，到了 00 ：
20 分后，朋友圈的写入量降了下来，总算得救了。
我们几个同学喝了些啤酒后，觉得肚子有点饿，提议去吃夜宵。
打车走了 10 公里左右，去到了一个港式茶餐厅。
下了车，我们进入餐厅里面坐定，我又拿起手机，跟运维同学 B 详细核对了各个数据和机器的表现，才最终安定下来。
准备开吃的时候，我同学说，“你从出来到现在，打了快十个电话了，有那么忙吗？
今晚是跨年夜呀！
” “唉，没办法呀，遇到故障，总要处理的！
不过现在已经搞定了，来，以茶代酒，我们干一杯吧！
新年快乐！
！
！
”
那晚，虽然一路都在处理故障，不过最后总也算是跨年了。
这种苦逼的事情，在后面还时有发生，不过随着系统建设的完善，发生的次数也越来越少了。
后来，我们总结了那次的故障：
1. 系统可以不完善，但需要有完备的故障处理预案
我们当时的系统确实还不够完善，因为建设时间不够。
不过当时也存在故障处理预案不够完备的问题，导致最后要赌运气。
后来，就这块，我们也制定了更完备的处理预案。
2. 一定要安排好备份负责人
