你好呀，我是歪歪。
昨天晚上語雀發佈了關於 10 月 23 日的故障公告，公告中關於故障的時間點梳理如下：
這是公告鏈接：https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw
14:07 數據存儲運維團隊收到監控系統報警，定位到原因是存儲在升級中因新的運維工具 bug 導致節點機器下線； 14:15 聯繫硬件團隊嘗試將下線機器重新上線； 15:00 確認因存儲系統使用的機器類別較老，無法直接操作上線，立即調整恢復方案爲從備份系統中恢復存儲數據； 15:10 開始新建存儲系統，從備份中開始恢復數據，由於語雀數據量龐大，此過程歷時較長； 19:00 完成數據恢復，同時爲保障數據完整性，在完成恢復後，用時 2 個小時進行數據校驗； 21:00 存儲系統通過完整性校驗，開始和語雀團隊聯調。 22:00 恢復語雀全部服務，用戶所有數據均未丟失。
我們一起盤一下這個時間點，多從別人的事故中總結經驗教訓，學習避坑指南。
14:07
首先第一個時間點，14:07，數據存儲運維團隊收到了健康系統的報警，然後開始定位問題。
我翻了一下微博，這個時間點幾乎和微博話題“#語雀崩了#”下的一條微博的時間點能對應上，而且還早了 7 分鐘。
不要小看這 7 分鐘，這說明系統人員先於用戶感知到了問題的存在，說明監控系統的預警是有效的。
不知道在其他公司是什麼規定，但是在歪師傅所在的公司，一切生產問題，只要是有監控手段、是通過監控系統自主發現的、上報故障時間早於用戶反饋的，不管最後的情況又多嚴重，都會一定程度上的減輕懲罰力度。
甚至對於一些屬於嚴重 BUG 但是沒有造成嚴重後果的，因爲有監控的存在，監控及時生效，出了問題你立馬就監控出來了的，是可以免責的。
監控，全方面、細粒度、低噪音、高觸達的監控，非常非常重要。
這一點，從公告上來，語雀的運維團隊是做到了。
但是這一點也不值得表揚，因爲這樣的監控本來就是應該要做到的。
14:15
這個時間點的操作是“聯繫硬件團隊嘗試將下線機器重新上線”。
這句話我確實看不懂，就不亂評論了。
但是我盲猜一個，因爲我讀到這句話的時候，看到“硬件”兩個字的時候就自動聯想到了機房裏面的硬盤，所以腦海裏面浮現出來的一個莫名其妙的畫面是這樣的：
一個運維老哥，穿着鞋套，帶着帽子，站在機房裏面，把硬盤一個個的拔出來，吹口氣，又一個個的插進去，並仔細的觀察着信號燈的情況。
15:00
從 14:15 分到 15:00，中間有 45 分鐘的時間。
這 45 分鐘我想應該是極其精彩的 45 分鐘。
因爲在這 45 分鐘內，確定了之前制定的“將下線機器重新上線”方案是不可用的，而且不可用肯定不是一句話的事情，硬件團隊的負責人或者其他的某個同事，需要給領導大致的彙報清楚，並探討新的解決方案。
是的，我猜測領導也是在這 45 分鐘內才知道發生了這麼大的事情，因爲當新方案制定出來之後，需要給領導同步一個噩耗：這個方案執行完成，需要很長的時間，樂觀估計需要 3 個小時，這 3 個小時內，我們的服務將完全不可用。而且經過討論，我們當前只有這一個方案可以使用。
所以，這 45 分鐘內，發生了幾個重要的事情：原方案斃了；新方案討論；新方案執行時間太長，事件必須升級到上級領導；編寫公告，同步用戶。
由於運維工具的 BUG 導致當前的存儲系統已經不行了，我簡單的理解爲就是數據庫崩了，整個崩的稀碎，裏面的數據“死傷無數”，救活的成本比重新搭一個還高。
因此制定出來的新方案就是：從備份系統中恢復存儲數據。
所以在官方的公告下，我們纔看到了這樣的一句話：
預計最晚今天內，最快6點前
這個時間怎麼估算出來的？
15 點到 16 點，3 個小時是給領導彙報的時候最樂觀的情況，屬於老天開眼，幫一把這個可憐的孩子，恢復數據的過程異常絲滑、毫無疑問的情況。
而最晚今天內，15 點到 24 點，有 9 個小時，多出來的 6 個小時，應該是夠處理恢復過程中的異常情況了...吧？
15:10
開始架勢，正式從備份文件中開始恢復數據。
在官方的公告中說到“由於語雀數據量龐大”，這個龐大到底到了什麼級別就不得而知了。
反正數據恢復的事件和數據量的大小成正比。
昨天我在微博看到一個評論說的是：8 個小時，我重新開始把服務全部部署一遍也綽綽有餘了。
是的，服務部署是分分鐘的事情，哪怕是人肉運維也服務全部重啓一邊也要不了 8 個小時。
其實當時我心裏就在嘀咕：不會是數據方面的問題吧。
歪師傅也算是一個久經沙場的程序猿了，以我淺薄的經驗來說，對一個生產事故，定位生產 BUG，修復生產 BUG 是一件相對容易的事情，最難受的一個環節就是修復由於 BUG 導致的數據問題。
這玩意，誰遇到過，誰就知道有多痛了。
我曾經遇到過一個生產 BUG，由於參數配置錯誤，導致跨了好幾個系統的一串數據全都算錯了，而且數據的量級還不少，而且還疊加了正常業務下這些數據還在動態變化的 BUFF，要把這一批數據修復正確，我搞了半個月的時間，基本上每天都搞到 23 點之後。
從第二週的時候，心態就完全崩成渣渣了，一邊搞數據一邊嘟囔着：這波搞完了，我 TM 的必須要離職了，太難受了。
後來你猜怎麼着？
數據搞完之後，心情一下就舒暢了，發現自己又能支棱起來了，同事私下問感受如何，我也只是輕描淡寫的說了一句：這能有啥感受，能通過修數修復的問題，都不是大問題。
所以我非常理解這個“恢復時間”長的原因，涉及到數據了，沒辦法，急也沒用。
19:00
從 15 點開始恢復，到 19 點恢復完成，用時 4 個小時，比樂觀預計時間只長了一小時而已，可以說是老天保佑了，沒出啥大岔子。
數據修復完成之後，語雀幹了一件什麼事情？
看看公告上的這句話：爲保障數據完整性，在完成恢復後，用時 2 個小時進行數據校驗。
首先我不管他們是真的在進行數據校驗，還是爲了從公告上縮短恢復數據的時間，或者其實這個時間段內還有其他步驟，或者其他什麼不方便透露的原因等等，我都不關心。
我只關心這個動作：在完成恢復後，用時 2 個小時進行數據校驗。
這個動作真的是太重要了，你想想，如果語雀團隊在數據修復完成之後，不做這個事情，或者說只是花了幾分鐘時間進行了一些極其簡單的驗證，最後導致用戶發現他的數據丟了，勢必會掀起更加瘋狂的輿論浪潮，導致更加嚴重的用戶流失和口誅筆伐。
所以我認爲這兩個小時雖然很長，但是是非常重要的一環，哪怕最後驗證的結果是確實沒有數據丟失，也是非常值得的，團隊心裏有了底。
而在時間已經到了 19 點，宕機 6 個小時的情況下，願意拍板再拿出 2 小時時間進行數據完整性校驗的人，是個團隊大心臟，穩得一筆。
處理生產事件，大家都是火急火燎的，這個時候出來一個說話有分量的人說：大家千萬別急，既然事情已經發生了，我們就一點點的把事情做好，不要引入新的問題，防止事態進一步擴散。
這個人，他簡直就是在發光。
之後的這兩個時間點，就不再展開說了：
21:00 存儲系統通過完整性校驗，開始和語雀團隊聯調。 22:00 恢復語雀全部服務，用戶所有數據均未丟失。
語雀再次強調了“用戶所有數據均未丟失”，這點確實很重要，從各個平臺的反饋來看，也沒有看到有用戶反饋數據丟失的情況。
（但是歪師傅還是不明白，明明是從備份中恢復的數據，怎麼可能不丟失數據呢？哪怕一小時一備份，也至少丟一小時的數據呀。）
關於改進措施
這裏面以這次故障爲抓手，結合各團隊通力協作，上下游拉通對齊，打出了一套組合拳，對焦本次事故，沉澱出了一份可複用的方法論，想要給系統更好的賦能：
保命箴言：可監控，可灰度，可回滾 能力建設：從同 Region 多副本容災升級爲兩地三中心的高可用能力 定時演練：進行定期的容災應急演練
在改進措施的部分，我建議所有開發，運維，包括測試同學，都應該把“可監控，可灰度，可回滾”這九個字貼在工位上，刻在腦子裏，做方案、寫代碼、提測前、上線前都把這九個字拿出來咂摸一下。
這九個字，說起來簡單，但是落地是真的難。
雖然落地難，但是是真的可以保命的，至少保過我的命。
另外這次事件從描述上來看，是運維人員的鍋，所以改進措施裏面也多次提到了“運維”這個關鍵詞。
不知道這個運維老哥是否被開除了，這很難說。
但是通過這個事情，或者我遇到過的一些生產事故來說，我想要表達的，如果一個公司或者團隊，遇到事情之後，第一反應是找對應的責任人出來處罰、開除某些人、扣某些人的績效等等這些懲罰手段，那麼帶來的後果是大家再次遇到事情的時候，第一反應就是先甩鍋，把自己撇乾淨，或者先隱瞞，瞞住了就過去了，瞞不住就導致更大的問題，這樣很不好。
正確的做法應該是拿着相關人員進行整個事件的覆盤，看看這次事件到底暴露了哪些問題。
就拿語雀的這次事件來說：生產運維操作，運維工具有 BUG，那麼是否經過充分的測試？是否留有足夠的灰度觀察時間？是否有雙人複覈機制？是否有生產緊急事件預案？等等...
這些都是流程上的問題，而不是某個運維人員的問題。
或者說應該是先找流程上的問題，那麼最後纔是找到某個具體的人身上。
有了流程，經過了流程評審，形成了規則制度，宣講了規章制度，操作的人沒有按照流程來，那麼這個人確實該罰。
而且這個流程，應該是通過一次又一次大大小小的事件不斷演進優化的流程。
最後
以上就是歪師傅通過語雀這個事情的一點看法吧，它的嚴重生產故障，對於我來說也是一個學習的過程。
最後，語雀給的賠償方案還是比較有誠意的，直接給六個月會員：
那沒啥說的了，反正對我沒有產生什麼實質上的影響，還蹭到了一波熱度《語雀，這波故障，放眼整個互聯網也是炸裂般的存在。》
還免費領了六個月會員。
好了，我就當沒事發生了。
