这次救的火救的时间有点长，持续一年多，总共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执行时间都很慢，那么整个流程就会慢很多。这也是为什么他们怀疑的
延伸阅读
- ssh框架 2016-09-30
- 阿里移动安全 [无线安全]玩转无线电——不安全的蓝牙锁 2017-07-26
- 消息队列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 论文笔记【图片目标分割】 2017-07-26
- 词向量-LRWE模型-更好地识别反义词同义词 2017-07-26
- 从栈不平衡问题 理解 calling convention 2017-07-26
- php imagemagick 处理 图片剪切、压缩、合并、插入文本、背景色透明 2017-07-26
- Swift实现JSON转Model - HandyJSON使用讲解 2017-07-26
- 阿里移动安全 Android端恶意锁屏勒索应用分析 2017-07-26
- 集合结合数据结构来看看(二) 2017-07-26
学习是年轻人改变自己的最好方式