在一个阳光明媚的周一上午，当我们正准备开始一周工作的时候，运维组的突然跑过来告诉我，
十万火急的问题出现了，销售，采购，库存这几个核心模块都无法使用了，早上9点前还好好的，现
在运维组的电话都已经爆线了，所有人都手忙脚乱的向用户道歉。
我马上找组里的开发和配置人员进行确认，有没有人动过数据库脚本并让配置人员进行了发布，
因为公司现在有权限的直接操作PRD数据库和PRD环境的人比较有限，一般都需要通过配置人员来
完成操作，其他人是不会有权限直接执行的。
配置组的同事告诉我，刚才的确是执行了一个脚本，但是这个脚本是在QAS环境执行通过了的
而且只花费了几秒钟时间，刚才他在PRD环境执行时，却执行很慢，而且他终止了执行。
一查才知道，上周有个任务让他优化数据库的查询，他考虑将客户表的索引改变下，由于是周
一，用户量比较大，而且执行的脚本是先将原索引去掉，然后再建，但是新索引没有建好就失败了。
所以进销存模块进入时都超时了，系统业务无法完成了。
原因找到了，那就要马上采取相应的对策了，我们和运营组的协商后，在运维老大的许可下决定
马上将所有在线用户从服务器上踢掉，然后关闭服务端，立即执行脚本，再开启所有的服务端，所有
操作需要在10分钟内完成。
很幸运，我们用5分钟的时间完成了所有操作，总算解决了燃眉之急，松了一口气。不过接下来
我们要做的是对这次的事故总结，因为有人不小心，没有按照操作流程做了一件自认为很简单的事
情，在晚间执行或者在测试环境，当然没有什么影响，但是PRD环境就不一样了。所以我们在发布
系统或者执行脚本及其他操作时，一定要考虑PRD环境的特殊情况。而且执行这些任务一定要在规
定的时间进行，当然有特事特办的情况，但是也要酌情考虑。