Bill 模式

4月5号将最近的一次版本发布到产品环境中，出了问题，所以最近10天都在通宵加班中度过。这个项目在6、7年内都没出过事！ 下面对事情经过做一个回顾和总结。Bill是把关每次发布到产品环境的经理，也是我们的Domain.

4月5号： 将新版本上线，发现有个30亿数据的表创建索引失败

4月6号:   DBA继续创建索引，并发现表空间不足，上线延时

4月7号： 继续创建失败，没有成功添加新的表空间，并锁住所有用户的登入账号

4月8号：抽取数据失败，数据累积量越来越大，索引仍然没有创建成功,支持组没人帮忙回复系统运行。干等。

4月9号：需要抽取的数据量更大，用户仍然被锁.索引创建成功。

4月10号： 高层接入，应该是用户过多，且太多人反应出问题，老板的老板直接接到老板的老板的老板的电话，出问题。事态直接上升3个级别。

4月11号：1号和2号大老板亲自作证，1号和用户沟通，2号亲自坐镇，将DBA组+支持组+开发组+Domain组一起，合力解决问题.第一次数据跑成功.期间Domain要随时给出估算时间和实时报告情况。开始统计各种数据。

4月12号:  第二次跑成功。估算时间在锁住用户的情况下很准确。继续24小时监视运行情况。

4月13号： 某个32亿的表搜集统计信息，直接使系统卡在那个表上。请来巨牛DBA创建临时执行计划，惊险过关

4月14号： 情况和13号相似

4月15号： 2号老板需要了解事情的整个经过，包括项目人员结构，资源运用，具体某个时间发生什么事。运行恢复正常，但耗时稍微有点比平时多

4月16号： Bill开始要求统计各种历史的数据，及为什么抽一次数据时间长了，对比各方给出的数据，有差异，把人问到死！！

4月17号： Bill继续他的方式，对比数据量，但是历史的数据量已经无法获取，差点被逼死。

4月18号: Bill转战数据库，调查数据库情况。无论如何要提高性能

4月19号： 继续.....

以上就是大概的过程。总结问题：

1. 组织协调太乱。每次开发找DBA 找支持组的人都他妈的求神拜佛一样。心情好就做。DBA和支持 都没有实时响应要求

2. 所有的测试都自己做了。 DBA有失职的嫌疑

3. 事情直接捅到1号BOSS那里。自己内部没有及时向上面反映情况。BOSS们心情很不好

4. BILL作为产品的把关经理，平时不出现。出问题了，对谁都怀疑，一堆人都出来，大搞特高，10天做半年的事，把人往死里逼！

最后的总结：

1. 团队协调是保证项目平稳的关键

2. 保存关键证据，才能活得下去

3. 自己兜不住的篓子 让boss来抗。等到Boss主动来抗，你就死了