救火队员的那些事(2)

　　这次救的火救的时间有点长，持续一年多，总共4次，每次去厦门大概1个月左右，每次去救火都是顶着巨大的压力，还好每一次我都不错的活着回来了。

　　这个项目与很多要救火的项目一样，项目交付第一，质量被抛在后面，几十人的团队不断往上堆需求，没有人做架构看护，没有人真正关注能否持久，只要功能实现了，暂时不出问题了，没有人care你的代码写的怎么样，可维护性怎么样。

　　在这四次救火中，举2个印象最深的例子，有一天晚上9点多，领导给我打电话说厦门某项目的系统今天下午系统挂了一次，他们在那边搞不定，希望我能出差支持一下，我说好的那我明天去，领导说能否今天晚上就去，没办法，订了10点多的机票，匆匆忙忙的赶到机场，由于飞机晚点，到厦门已经是凌晨2点了。到了以后，我还没找到地方住下，厦门这边的PM就给我打电话，直接去他们的办公场所解决问题，于是直接去了厦门软件园，到了以后，当时心里是很感动的，因为还有一波人在那里等着我一起和他们解决问题，想想大家都挺不容易的。

　　于是开启了我连续2天2夜没有睡觉的先河，接下来在11天的时间里每天凌晨2到3点回酒店。先不说这些苦逼的加班了，再多的加班，如果不能解决问题，都是徒劳的。我们先是把之前发现的一些问题做了梳理，然后我开始阅读他们写的代码，开始优化，测试，但是在头2天里，仍然抵挡不住用户访问的洪流，系统在连接2天上午高峰期间挂了，下午挂了，甲方的在当地最大的领导就站在我们的背后看着我们的系统挂了，重启。当时的心理压力是巨大的，但是我心里有底的，因为在前面几年磨练中，我已经遇到过绝大多数的问题，我对linux操作系统有足够的了解，我对java有足够的了解。

　　但是一开始开出的药方，似乎总是命不中要害。这时已经临近春节还有十多天的时间了，领导发话，如果此问题不解决，除了扣分以外(影响收入），所有的人春节都不允许回家。虽然外部不断的施压，但是当时我还是有信心解决的，我仍然在不断的在现网patch代码，分析日志，直到第3天，我给出一个当时绝大多数同事都不太认可的方案，将合并部署的数据库单独迁移到单独的数据库服务器上。他们认为这个方案的成本太高，从服务器的下单、到货、安装在短短十天的时间很难完成，如果迁移到新的数据库上仍没有解决问题，我们就一点退路就没有了。大部分人都不同意这个方案，而我相信自己的分析，一遍遍的拿出充分的数据做图表分析，当时幸亏自己熟练的写perl脚本，做了很多分析的工作。为什么要迁数据库到新的数据库?

　　我们的系统的数据库是和另外一个系统的数据库是合并部署在一台小型机上，这台小型机号称是IBM性能最猛的服务器，内存好像是128G,处理器是64核，因为我发现我们的系统的sql的执行时间不稳定，从单个sql来看，执行时间最高的时候会比正常的时间高于30%左右，这样看来问题不明显，但是不要忘了，我们为什么挂的功能是一个非常复杂的功能，一个流程有大量的sql执行，如果这些sql执行时间都很慢，那么整个流程就会慢很多。这也是为什么他们怀疑的地方，就是因为单个sql性能差异不那么明显，但是他们没有想到整个流程中会执行很多次sql. 另外我发现另外一个系统会不定时执行的非常耗资源的sql会拖累这个最猛的服务器，一旦服务器性能影响，在这台服务器上所有的进程都会受到影响。

　　其它人也没有更好的办法，最后只能采用我的方案，后来想办法调借一套ATAE双机，操作系统安装，安装Oracle数据库双机，这中间有一个小插曲，那天晚上甲方技术负责人都在帮我们一起来装解决数据库双机的问题，搞过数据库的同学可能知道，这些大型的软件在安装的时候因为补丁之类的问题，有时会出现一些难缠的问题。累了，大家就拿了硬纸板找个角落睡一会儿，在放假前3天的凌晨，我们完成了数据库的迁移。

　　我还记得迁移完成以后大概是凌晨6点左右，等待着早上9点左右的业务高峰期，大家都很紧张，总共有近20台服务器，把top命令开着一直盯着，一上午服务器的CPU都没有超过30%。接下来的3天也再没出现过之前的服务挂的情况，CPU和数据库的连接一直都稳定在安全范围线内。

　　在放假前的最后一天，我和PM一起回了南京，在从南京机场回市区的路上他对我说，如果没有你，我真的不知道该怎么办，那一刻感觉自己做的事情还是挺有意义的。回到南京的时候，南京已经下了白皑皑的雪，回到公司的时候，大部分同事已经回家了，路上人很少，心情很好