救火队员的那些事(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一块儿回了南京，在从南京机场回市区的路上他对我说，若是没有你，我真的不知道该怎么办，那一刻感受本身作的事情仍是挺有意义的。回到南京的时候，南京已经下了白皑皑的雪，回到公司的时候，大部分同事已经回家了，路上人不多，心情很好