惊心动魄一周记

1
 
一个人的职场江湖，第一篇
 
一个人的职场江湖，第二篇
 
2022年5月5号，晚上9点多，兰州。
 
项目专项会议室里，团队成员都挤在一张会议桌前，热火朝天地赶进度。
 
李松嬉皮笑脸地与同事插荦打科，同时还不忘操作键盘处理工作。
 
突然，喧闹声安静下来，他脸色煞白，凝固在那儿，像一尊石像。
 
旁边的同事拍拍他，问他怎么了。
 
他发抖着，如似自言自语，“我把数据库里的表全删了……”
 
我坐他对面，正在修改上线材料，距离系统上线只剩一周了。
 
我也注意到了他的异样，听到他说出“数据库”三个字，我心头一惊。
 
无论他的声音多小，我都能体会到，出大事了！
 
我经历过一起这样类似的大故障。
 
2011年3月份，半夜一串急促的电话声吵醒了沉睡的我。
 
刚拿起手机，就传来客户急切的声音，“快来机房，你们系统数据库的硬盘坏了！”
 
我打了个激灵，起床穿衣，打车狂奔而去。
 
我当时还是这个项目的项目经理。应用软件的开发和运维由我们负责，系统运行的服务器和数据库的运维由客户负责。
 
因为预算的问题，项目一直未能扩充硬件配置。由于数据库在共享存储上空间不足，客户的DBA（数据库管理员）就把服务器的硬盘空间划给了数据库临时使用。
 
为了保证4月初可以正式承接集团公司统一部署的新业务，当天晚上，DBA准备将服务器硬盘上的数据迁移到新扩容的共享存储上。
 
谁曾想，硬盘坏了，服务器挂了。机器已经运行了七八年，说罢工就罢工。
 
刚开始并不认为是什么问题，毕竟还有数据库备份，客户采购的商业备份软件会以“每周全量+每日增量”的方式备份数据。
 
我们只要把备份包恢复即可。
 
然而，检查备份包才发现，大小只有几百兆 — 备份的数据是无效的。
 
因为大家一直没有组织过应急演练，都想当然地认为每日备份没有问题。
 
作为客户的核心系统，系统每天运行着上千万张批量处理的业务。
 
同时，省分公司为了迎接集团公司的上半年检查，系统务必要赶在下月初上线。下周集团公司会提前派人进行一次专题检查。
 
关键时期，出现这种情况，犹如晴天霹雳。
 
机房里，省分公司的各级领导都已到达并部署各种应急安排。
 

• 客户服务部编写通稿，要求客服人员统一说法。
   
  
• 各地市公司的管理人员针对高优先级的业务优先手工处理。
   
  
• 客户集成部调配两台高性能机器重新搭建数据库。
   
  
• ……
  

 
此时已经是凌晨3点。
 
对了，我和同事2010年5月份在最后一个地市完成系统推广后，顺便研究了数据库的数据导入导出命令，随手把数据库中的静态数据做过一次导出备份。
 
赶紧将这个备份从服务器下载检查，竟然可用！
 
一年前导出的38张静态数据表完好无损。这类静态表数据一般变化不大，最核心的业务规则都已包含其中。
 
早晨8点，赶在正常营业前，系统已基本可以运行，不会再对业务运营产生较大影响。
 
当时还有个遗憾，用户相关的表没有备份。造成团队成员一直忙活到次日凌晨才算把用户权限补齐。
 
而后的几天就是一种煎熬，新一期的业务配置全在测试库，而测试库也在这个数据库上，也没有手工备份。
 
如果无法恢复，这意味着本期工作全要推倒重来。对项目组成员的士气将是一次极为沉重的打击。
 
忐忑了七天，客户告知，专业恢复公司已通过数据库逻辑层面将数据恢复，导入新库测试可以正常使用。故障正式消除。
 
总算长舒一口气。这次经历，刻骨铭心，心有余悸，终身难忘。
 
2
 
没想到啊，这次又碰上！
 
我立即招呼各位项目组成员，马上停止手头上的工作，并将数据库关停。
 
然后听李松做了什么。
 
他负责将测试环境的数据库数据同步到正式库，为下周的系统上线做准备。
 
正常的同步顺序应是：
 

• 在测试库上执行导出建表及数据的脚本；
   
  
• 在正式库上执行清除表和数据的脚本；
   
  
• 在正式库上执行从测试库导出的建表和插入数据的脚本。
  

 
当时他不知是聊天太嗨了，还是加班太久反应迟钝了，他先执行了步骤2。
 
而且，他是在测试库上执行的步骤2，即，在测试库上执行了清除表和数据的脚本。
 
至此，删库脚本开始瞬间执行，无法停止。测试库里一年的心血就在命令行的不断跳跃中化为灰烬。
 
历史总是惊人相似，这次的测试库没有手工备份。
 
国有企业实力雄厚，对安全要求很高，它们的系统并没有使用互联网公司的云资源服务，而是集采服务器运行在自己的机房。
 
具体服务器上应用的安装和部署都是由我们自己来负责。
 
因为是测试库，我们也没有将服务器开启硬盘自动备份模式。
 
批评抱怨已没有意义。下周系统要上线，时间非常紧迫，当前最紧急的事情是恢复数据。
 
经过商讨，考虑了三种方案：
 

• 请公司技术专家恢复数据。
   
  
• 请专业公司恢复数据。
   
  
• 手工重新补录数据。
  

 
第3种方案不到万不得已决不考虑。工作量实在太大了。最乐观估计，项目成员在24小时不休息的情况下，上线时间也要延迟一个月。
 
大半夜的，我已不顾及太多了，一个个电话把公司的技术大拿们喊起来，解决这个问题。
 
折腾了几个小时，天已大亮，毫无结果。
 
如何向客户答复？如实交待的话，客户刚对我们树立的信心，必将再次被摧毁。毕竟，出现这种低级操作失误，很不应该。
 
最终决定淡化处理，形成统一回复：“昨晚数据库存在一些小问题。正在加紧修复，预计明后天就可以处理完成。不影响上线。”
 
上午半天，一无所获。我们作为应用软件厂商，在硬件及中间件的知识和经验储备上还是不够充足。
 
我们决定启用方案2，联系外援。
 
专业恢复公司评估过后，给出意见，全部表大约78张，只要恢复40张表就要给全价，全价8万元。
 
真黑！
 
人在落难时，只能任人宰割。
 
这就像钥匙忘家里，需要开锁公司处理一样。开锁公司要多少，你只要能承受，就要支付。卡在这个关口上，你能怎么办？
 
我们决定只恢复其中的18张最最关键的表，这样价格可以再低一些。其它表可以快速手工来补。最终谈定，价格4万元，先交2万块钱押金。
 
成交！不能再犹豫。比对了其它一些专业公司，也就这个家技术靠谱。
 
如果不请专业恢复的话，全靠人工重做，这延迟一个月所带来的费用及损失会远远高于4万块。
 
专业恢复公司先将数据拷贝，中间花费了一天时间处理。
 
等待恢复结果的那几天，心急如焚，度日如年。
 
客户也明显感觉到氛围不对，强烈要求我们正式说明调查原因。
 
最终在故障发生后的第三天，恢复工作完成，但是18张核心表，只成功恢复出16张，另外2张虽然没能恢复，但数据量不大，可以手工处理。
 
而且，最最核心且工作量最大的5张表都已恢复出来。这将极大节省我们的修复时间。
 
因为2张核心表未能恢复，则我们支出的费用为 4万元/18张 * 16张 = 3.55万元。
 
血的教训！
 
而后大家24小时不停歇地全力加班修补。最终在5月11号恢复原状，不影响5月12号的正式割接。
 
事后的处罚不可避免。
 

• 直接操作人工作不认真，为公司带来较大损失，给予记过处分，扣减工资3000元；
   
  
• 项目经理负有管理责任，忽视数据备份的重要性，给予警告处分，扣减工资1000元。
  

 
3
 
有些朋友会质疑，公司那么大，一个恢复数据库的高手都没有吗？
 
公司有技术人员，但不能算为高手。就如三甲医院有很多，但不能说医院里各科室都是名医。
 
擅长数据库恢复这块的高手主要来自专业数据公司或运维集成公司。因为他们一直专注这块，干得多了，见得多了，自然熟能生巧。
 
公司也有安全规范，明确要求了任何重要操作要备份。然而，在实际工作中，参与人只有经历过这类事情才会深刻领会安全规范里的条例为什么会有这一条。
 
安全生产，警钟长鸣。这件事之后，我在公司层面组织了一次系统安全大排查。并加强了对项目经理的安全生产的宣贯力度。
 
同时修改了项目管理章程。引入定期抽查机制，将数据库的备份工作和应急预案的检查，纳入了抽查范围。
 
一个公司管理二三十个项目经理还比较轻松。但如果两百个三百个项目经理，而且项目经理分散在全国各地，又如何管理和宣贯？
 
所以，针对公司里的385位项目经理，安全生产如何宣贯到位？这就对项目管理委员会的工作提出了考验。
 
接下来，详见“一个人的职场江湖”第四篇，我在项目管理委员会干的那些事。
 
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！