慌了3秒，果断发个邮件；
最近，在版本发布时；
ES线上未备份的索引，被当场「误删」了；
对于新手来说，妥妥的社死名场面；
对于老手来说，慌它3秒表示一下态度；
当时的情况也不复杂；
某「个别」队友在处理动态索引的字段问题时，反复重新构建结构和数据；
为了严谨；
还在自个本地环境不断的测试；
万事皆因忙中错；
忙着忙着，本地环境和线上环境就混了，手一抖，生产环境的数据跟着就没了；
当场傻楞了3秒，接着就是一句国粹脱口而出；
这一幕，属实有点似曾相识；
人祸横跳出来的时候；
慌没用，自责没用，甩锅更没用；
有用的操作就是团队静心找补，快速把问题解决好，不然都得跟着耗时间；
【首先】客观的说明一下项目情况；
体量很小的项目，几个「资深」的码农在三心二意应付着，然后就有老六不按常理出牌，事后还狡辩说锻炼了团队的应急能力；
【再来】聊聊当时每个人的应对；
- 项目经理：邮件通知相关人员，版本发布+结构模型和数据升级，并且禁用了相关模块；
- 当事人甲：平复情绪，稳住完成索引上线；
- 围观人甲：拖出线程池脚本，快速完成几千条索引条数据的重建；
- 运维同学：完成服务的最终升级，备份相关索引；
【纵观】全程，主打一手：若无其事，一本正经；
此处，细思极恐；
如果不是项目不值一提，这些个参与者弄不好还值得开会表扬一下；
职场上的队友要都是这般梦幻，一定要珍惜；
客观来说，项目本身「规格」很低；
但是，这种有开发介入，发布还在临时调试的情况本身就不常见；
在实际情况中；
虽然版本发布，有严谨的执行步骤，依然避不开个别老六灵光乍现的骚操作；
结果就是，和手搓的BUG正面对线；
这种要是出现在公司系统级的项目中，必然是得祭出点什么，取决于业务模块和影响面；
必须要郑重提醒；
不能轻易用手动的方式执行删除动作，可以用流程管理的方式实现；
这样整体可控，也有利于测试验收；
虽然索引删除的场面比较尴尬；
但是经过实践考验的应对流程，值得反思和总结；
不怕一万，就怕下一次的一万；
至于哪里能值得借鉴，这得看实际情况；
关于索引删除和重建的问题，在以前的文章中有提过，这里更多是记录一下处理思路；「参考文尾」
- 【1】快速下线相关功能模块，问题影响面广会增加复杂度，当时绝对在5分钟内下线；
- 【2】索引数据是基于消息队列调度的，并且可以暂停流程执行，方便处理索引结构；
- 【3】基于线程池高效的实现索引数据恢复，（没实际对比过，经常倒腾数据用顺手的工具脚本）；
- 【4】运维进行索引备份，增强数据安全；
BUG对线过程，半个小时内就处理完毕了；
这里对于团队的人来说，每个人都迅速找准解决问题的切入点，顺畅的合作，准确并高效的解决；
项目负责人说，他那会去给客户道歉的话都想好了；
可惜，没给他兜底表演的机会；
最后总结两句；
虽然发布故障有点出其不意，但是团队在处理上还算体面妥当；
所以，魔幻的职场不重要，重要的是有魔幻的队友。
网友评论