TM夜战难眠

      8月13号晚上10:30启动我们自己的管理系统B1，在紧张的半个小时紧急配置中，复制关系已经OK。其实，在之前，上午已经启动了GEO的配置，只剩下最后启动一步的操作，不过在check的时候发现主备关系已经配置错误，于是决定删除PG的配置决定重做。值得说明的是，自己考虑得还算周到，不是那么冲动。在停止现网数据的GEO时是会导致现网数据断网的，但是原来认为复制关系为Error，也就是从现网运行的基础上去配置GEO，然后再停GEO是不会停止现网数据的。后来晚上的实践证明，只要你的GEO监控着资源，一旦停止GEO就会把资源给停止掉，导致现网业务中断。现在想来，做一件很有破坏性的事情的时候，如果存在风险，一定要考虑清楚。而在之前的备份数据库是必须的，就像打补丁必须备份系统一样。操作过程中务必专注，持续Check操作结果，高度警觉。

     12:00 U1,U2和U3启动AVS的安装和配置。凌晨2:30第一台U1的GEO和AVS配置OK。3点左右，由于数据复制方向错误，导致现网数据损坏，一线系统崩溃，与此同时U3的系统也由于同样的原因，系统也崩溃，而由于U2配置稍微延后，幸免于难。恰在之前，未在当天做全系统备份。8月13号这一天现网数据彻底丢失。由于数据损坏，绝大多数DB不能online。在经过快速的尝试之后，现网运行的Server上恢复数据无望，幸好LEE讨论后决定在备用服务器上进行恢复，但让人感觉很无奈的是，Backup的数据在另外一台机器上恢复后由于涉及到IP的原因（包括配置文件和数据库中的），启动失败。问题变得更加严峻，到客户要求正常恢复系统的时间6:00只剩下1个小时不到，而此时静悄悄的TM大厅上的会议室里面，气氛变得在异常沉闷，总部的老大们在焦急的等待着。时间在1分钟1分钟的过去，从产品到平台，再到产品，艰难的寻找着能求助的研发人员。。。而与此同时我和Yay只能使用手工方式在空的系统上恢复U3。终于在客户要求的最后通告时间10:00之前搞定了U1和U3。

   现在想来，这也算是一笔难得的经历。连续28个小时的工作已经是超过我工作的记录了。而反思起来，在这次事故中，造成最后爆发的结果，是一连串的失误导致的。其实在任何一个环节关注，是不会出现这种情况的。首先，使用的指导资料并不是适用给扩充安装系统用的，而是还是按照最初的全部彻底初始化来书写的，对于现网数据操作需要进行的相应改变，只字未提，不管是在总部的支撑人员，还是在一线的测试人员，都是有责任的。这个问题其实在我们B的安装指导书中也是一样的被忽略，这是一个值得吸取教训的部分。第二，一线测试人员不敏感，不警觉，除了纯粹按照操作指导书操作外，未对自己操作对现网数据可能带来的风险有足够的评估。第三，在进行晚上的搭建关系之前，一线根本就未考虑到对于可能出现的坏情况作任何的估计和应对措施。第四，作为一个很重要的组成部分，备份和恢复数据的工具功能相当的脆弱，或者根本就不知道该怎么去操作，假设数据库的恢复过程中不定位那么久，而是能有相应的操作指导，工具能支持跨服务器的一键式恢复，问题是根本也不会变这么恶劣的。而真正对于我们在正常的版本测试过程中，恐怕也是很难关注到这些。

  这些都是教训。谨记。