ES索引误删的名场面

慌了3秒,果断发个邮件;


01


最近,在版本发布时;

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

对于新手来说,妥妥的社死名场面;

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

当时的情况也不复杂;

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

为了严谨;

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

万事皆因忙中错;

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

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

这一幕,属实有点似曾相识;


02


人祸横跳出来的时候;

慌没用,自责没用,甩锅更没用;

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

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

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

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

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

【纵观】全程,主打一手:若无其事,一本正经;

此处,细思极恐;

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

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


03


客观来说,项目本身「规格」很低;

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

在实际情况中;

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

结果就是,和手搓的BUG正面对线;

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

必须要郑重提醒;

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

这样整体可控,也有利于测试验收;


04


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

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

不怕一万,就怕下一次的一万;

至于哪里能值得借鉴,这得看实际情况;

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

ES索引误删的名场面_第1张图片

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

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

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

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

可惜,没给他兜底表演的机会;


05


最后总结两句;

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

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

你可能感兴趣的:(互联网微观角度,elasticsearch,数据库,大数据)