最近，在版本发布时；

ES线上未备份的索引，被当场「误删」了；

对于新手来说，妥妥的社死名场面；

对于老手来说，慌它3秒表示一下态度；

当时的情况也不复杂；

某「个别」队友在处理动态索引的字段问题时，反复重新构建结构和数据；

为了严谨；

还在自个本地环境不断的测试；

万事皆因忙中错；

忙着忙着，本地环境和线上环境就混了，手一抖，生产环境的数据跟着就没了；

当场傻楞了3秒，接着就是一句国粹脱口而出；

这一幕，属实有点似曾相识；

人祸横跳出来的时候；

慌没用，自责没用，甩锅更没用；

有用的操作就是团队静心找补，快速把问题解决好，不然都得跟着耗时间；

【首先】客观的说明一下项目情况；

体量很小的项目，几个「资深」的码农在三心二意应付着，然后就有老六不按常理出牌，事后还狡辩说锻炼了团队的应急能力；

【再来】聊聊当时每个人的应对；

• 项目经理：邮件通知相关人员，版本发布+结构模型和数据升级，并且禁用了相关模块；
• 当事人甲：平复情绪，稳住完成索引上线；
• 围观人甲：拖出线程池脚本，快速完成几千条索引条数据的重建；
• 运维同学：完成服务的最终升级，备份相关索引；

【纵观】全程，主打一手：若无其事，一本正经；

此处，细思极恐；

如果不是项目不值一提，这些个参与者弄不好还值得开会表扬一下；

职场上的队友要都是这般梦幻，一定要珍惜；

客观来说，项目本身「规格」很低；

但是，这种有开发介入，发布还在临时调试的情况本身就不常见；

在实际情况中；

虽然版本发布，有严谨的执行步骤，依然避不开个别老六灵光乍现的骚操作；

结果就是，和手搓的BUG正面对线；

这种要是出现在公司系统级的项目中，必然是得祭出点什么，取决于业务模块和影响面；

必须要郑重提醒；

不能轻易用手动的方式执行删除动作，可以用流程管理的方式实现；

这样整体可控，也有利于测试验收；

虽然索引删除的场面比较尴尬；

但是经过实践考验的应对流程，值得反思和总结；

不怕一万，就怕下一次的一万；

至于哪里能值得借鉴，这得看实际情况；

关于索引删除和重建的问题，在以前的文章中有提过，这里更多是记录一下处理思路；「参考文尾」

图片

• 【1】快速下线相关功能模块，问题影响面广会增加复杂度，当时绝对在5分钟内下线；
• 【2】索引数据是基于消息队列调度的，并且可以暂停流程执行，方便处理索引结构；
• 【3】基于线程池高效的实现索引数据恢复，（没实际对比过，经常倒腾数据用顺手的工具脚本）；
• 【4】运维进行索引备份，增强数据安全；

BUG对线过程，半个小时内就处理完毕了；

这里对于团队的人来说，每个人都迅速找准解决问题的切入点，顺畅的合作，准确并高效的解决；

项目负责人说，他那会去给客户道歉的话都想好了；

可惜，没给他兜底表演的机会；

最后总结两句；

虽然发布故障有点出其不意，但是团队在处理上还算体面妥当；

所以，魔幻的职场不重要，重要的是有魔幻的队友。