最近，在版本發布時；

ES線上未備份的索引，被當場「誤刪」了；

對于新手來說，妥妥的社死名場面；

對于老手來說，慌它3秒表示一下態度；

當時的情況也不復雜；

某「個別」隊友在處理動態索引的字段問題時，反復重新構建結構和數據；

為了嚴謹；

還在自個本地環境不斷的測試；

萬事皆因忙中錯；

忙著忙著，本地環境和線上環境就混了，手一抖，生產環境的數據跟著就沒了；

當場傻楞了3秒，接著就是一句國粹脫口而出；

這一幕，屬實有點似曾相識；

人禍橫跳出來的時候；

慌沒用，自責沒用，甩鍋更沒用；

有用的操作就是團隊靜心找補，快速把問題解決好，不然都得跟著耗時間；

【首先】客觀的說明一下項目情況；

體量很小的項目，幾個「資深」的碼農在三心二意應付著，然后就有老六不按常理出牌，事后還狡辯說鍛煉了團隊的應急能力；

【再來】聊聊當時每個人的應對；

• 項目經理：郵件通知相關人員，版本發布+結構模型和數據升級，并且禁用了相關模塊；
• 當事人甲：平復情緒，穩住完成索引上線；
• 圍觀人甲：拖出線程池腳本，快速完成幾千條索引條數據的重建；
• 運維同學：完成服務的最終升級，備份相關索引；

【縱觀】全程，主打一手：若無其事，一本正經；

此處，細思極恐；

如果不是項目不值一提，這些個參與者弄不好還值得開會表揚一下；

職場上的隊友要都是這般夢幻，一定要珍惜；

客觀來說，項目本身「規格」很低；

但是，這種有開發介入，發布還在臨時調試的情況本身就不常見；

在實際情況中；

雖然版本發布，有嚴謹的執行步驟，依然避不開個別老六靈光乍現的騷操作；

結果就是，和手搓的BUG正面對線；

這種要是出現在公司系統級的項目中，必然是得祭出點什么，取決于業務模塊和影響面；

必須要鄭重提醒；

不能輕易用手動的方式執行刪除動作，可以用流程管理的方式實現；

這樣整體可控，也有利于測試驗收；

雖然索引刪除的場面比較尷尬；

但是經過實踐考驗的應對流程，值得反思和總結；

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

至于哪里能值得借鑒，這得看實際情況；

關于索引刪除和重建的問題，在以前的文章中有提過，這里更多是記錄一下處理思路；「參考文尾」

圖片

• 【1】快速下線相關功能模塊，問題影響面廣會增加復雜度，當時絕對在5分鐘內下線；
• 【2】索引數據是基于消息隊列調度的，并且可以暫停流程執行，方便處理索引結構；
• 【3】基于線程池高效的實現索引數據恢復，（沒實際對比過，經常倒騰數據用順手的工具腳本）；
• 【4】運維進行索引備份，增強數據安全；

BUG對線過程，半個小時內就處理完畢了；

這里對于團隊的人來說，每個人都迅速找準解決問題的切入點，順暢的合作，準確并高效的解決；

項目負責人說，他那會去給客戶道歉的話都想好了；

可惜，沒給他兜底表演的機會；

最后總結兩句；

雖然發布故障有點出其不意，但是團隊在處理上還算體面妥當；

所以，魔幻的職場不重要，重要的是有魔幻的隊友。