我听说，牛x的人，都关注整体，不关注细节，因为他们觉得没必要;我也听说，管理的哲学，就是协调资源，让人俯首甘为孺子牛，不达目的不罢休。

在这种环境下耳濡目染很多年，人生就有一股若有若无的错觉：管理可以解决一切问题。如果管理解决不了，那一定是流程的问题。

但看了PDD这种企业的管理方式以后，信仰再次转折，我又觉得这是错误的。PDD的管理模式，打脸了所有高校的《管理学》课程，让所有从事管理工作的人，颜面扫地。

只要钱给够，不需要什么管理!只有没钱的穷B公司才在哪里文邹邹的搞管理。要说高能的、正统的管理学，那非传销莫属。

话说的有点远，已经进入了跑题的路上，我们需要用一个故障把它拉回来。

1. 出故障了

没办法，干it这一行，就得天天面对故障，大家就是传说中的消防员，到处救火。不过，这次的故障范围有点大，宿主机都打不开了。

好在监控系统留下了一些证据。

证据发现，机器的CPU、内存、文件句柄，随着业务的增长，持续的上升…上升….，直到监控也无法将信息收集上来。

要命的是，这些宿主机上，部署了非常多的Java进程。没别的原因，就是为了节省成本，混部了应用。当宿主机表现出整体性的异常时，就难以找到罪魁祸首。

因为远程登录也Over，暴躁的运维只能重启机器，重启机器之后开始重启应用。经过漫长的等待，所有的进程都活了，但是，仅仅过了片刻，宿主机又立即死去。

业务一直处于死翘翘的状态，真是让人恼火啊。也让人心急。尝试过几次之后，运维崩溃了，启动了紧急预案：回滚!

最近的上线记录有点多，而且有开发人员私自上线部署的行为，运维蒙圈了：回滚哪些呢?还好有人脑瓜一亮，想起了还有find这个命令，那就找到最近更新的所有jar包，都给它来次回滚吧。

1. find /apps/deploy -mtime +3 | grep jar$ 

如果你不知道find这个命令，那可还真的是一场灾难。还好有人知道。

把十来个jar包回滚，还好没有碰到数据库的schema变更，系统终于正常运行了。

2. 找原因

没别的办法，查日志，进行代码审查。

代码审查要追溯到最近1周或者2周之内的代码改动，因为有些功能代码要沉淀一段时间，才能到线上风光一把。

看着满屏的提交记录“OK”，技术经理的脸都绿了。

“xjjdog说过，《80%的程序员，不会写commit记录》，我看你们是100%都不会写”。

大家都静悄悄的，忍着痛翻查历史变更。经过大家的不懈努力，终于在屎山之间，找到了一些问题代码。CxO亲自建了个群，大家一股脑的把可能会出问题的代码，扔到了群里面。

"系统服务中断了接近一个小时，影响非常恶劣"，CxO说，“务必把问题彻底解决掉，这个问题投资人非常关注”!