本文出自《SRE：運維解密》，由資深SRE 孫宇聰 擔任譯者，首次深度剖析 SRE。
Music——2012 年 3 月 :一次意外刪除事故的檢測過程
此事故特殊點在于，海量數據存儲所帶來的后勤方面的挑戰：去哪里存放5000盤磁帶，以及如何能夠迅速地(甚至是可行的)從離線媒介中讀出數據—— 而這一切還要發生在一個合理的時間范圍內。
1. 發現問題：災難來臨
一個 Music 用戶匯報某些之前播放正常的歌曲現在無法播放了。 Music 的 用戶支持團隊通知了工程師團隊，這個問題被歸類為流媒體播放問題進行調查。
3 月 7 日，負責調查此事的工程師發現無法播放的歌曲的元數據中缺少了一個針對具體音頻數據文件的指針，于是他就修復了這個歌曲的問題。
但是， 工程師經常喜歡深究問題，也引以為豪，于是他就繼續在系統中查找可能存在的問題。
當發現數據完整性損壞的真正原因時，他卻差點嚇出心臟病:這段數據是被某個保護隱私目的的數據刪除流水線所刪掉的。 Music 的這個子系統的設計目標之一就是在盡可能短的時間內刪除海量音頻數據。
2. 評估嚴重性
的隱私策略強調保護用戶的個人數據。在 Music 服務中，該隱私策略要求音樂文件，以及對應的元數據需要在用戶刪除它們之后在合理時間范圍內在系統中徹 底刪除。
隨著 Music 使用量呈指數級增加，數據量也飛快地增長，以至于原始的 刪除機制被拋棄了，在 2012 年進行了重新設計。
在 2 月 6 日那一天，更新過的數據刪除流水線任務進行了一次運行，當時看起來沒有任何問題，于是工程師批準了流水線任務的第二階段執行——真正刪除對應的音頻數據。
然而，難道真的是這次刪除任務造成的問題嗎？該工程師立刻發出了一個最高級別的警報，同時通知了相關的工程師經理，以及SRE團隊。
Music的開發者和SRE組建了一個小團隊專門調查這個情況，同時該數據刪除流水線也被暫時停止了，以防擴大 問題范圍。
接下來，手動檢查分散在多個數據中心內部的百萬條，甚至數十億條文件元數據信息是 不可能的。該團隊匆忙編寫了一個 任務來評估問題的影響范圍，焦急地等待 著任務執行結果。
3 月 8 日，任務終于完成了，看到結果時所有人都驚呆了：該流水線任務大概誤刪除了 60 萬條音頻文件，大概影響了 2.1 萬用戶。由于這個匆忙編寫的檢測程序還簡化了一些檢測步驟，實際的問題只會更嚴重。
距離有問題數據刪除流水線第一次運行已經超過一個月了，正是那次首次運行刪除了幾十萬條不該刪除的音頻數據。
現在還有恢復數據的希望嗎？
如果這些數據無法恢復，或者不能及時恢復，用戶還會使用 Music嗎？
我們怎么能沒有注意到這個問題的發生呢！
3. 問題的解決· 定位 Bug 和數據恢復的并行進行
解決問題的第一步是定位真正的 Bug 根源，以便了解 Bug 產生的原因和過程。如果不修復根源的問題，任何數據恢復工作都是做無用功。
團隊承受著來自用戶壓力要求我們重新啟用數據刪除流水線，而無辜用戶將會繼續丟失剛剛購買的音樂，甚至是他們自己辛苦錄制的音樂。這個 22 條軍規的場景的唯一出路， 就是修復根源問題，并且要快。
然而數據恢復流程也沒有任何時間可以浪費。音頻文件雖然備份到磁帶上，但是和 Gmail 不同， Music 由于數據量太大，加密過的備份磁帶是由卡車運往異地存放于獨立的 存儲設施中的——這些設施可以存放更多磁帶。
為了能夠更快地為受影響的用戶恢復數據，團隊決定在調查根源問題的同時并行進行異地備份磁帶的恢復操作（這將耗時很長）。
工程師分為兩組。經驗最豐富的 SRE 負責數據恢復，同時開發者負責分析數據刪除邏輯代碼，試著修復根源問題。由于問題的根源尚不清晰，整個數據恢復過程會按數個階段進行。
首先，第一批超過 50 萬條音頻數據被選中進行恢復，負責磁帶備份系統的團隊 在美國西海岸時間 3 月 8 日下午 4 :34 分收到了恢復通知。
整個事件中只有一個好消息 :公司組織的年度災難恢復演習剛剛在幾周前結束。磁帶備份團隊由于在 DiRT 演習中剛剛評估過子系統的能力和限制，剛剛制作了對應的數據恢復新工具。
利用這個新工具，新團隊開始緩慢地首先將幾十萬條音 頻文件和磁帶備份系統中注冊的備份文件一一對應，然后再將備份文件與具體的物理磁 帶一一對應。
通過這個方法，團隊評估得出第一批恢復過程需要將 5000 盤磁帶用卡車全部運回來。并且之后數據中心的技術人員需要清理出足夠場地來放置這些磁帶。
接下來還要通過一個極為復雜和耗時的流程來從磁帶上讀取這些數據。同時，還要處理磁帶損壞、磁帶讀取設備損壞，以及其他不可預料的問題。
更不幸的是，60 萬條丟失數據中只有 條數據存在備份，也就意味著其他 條數據在備份之前就已經丟失了。數據恢復團隊最后決定先啟動恢復流程，再想辦法如 何恢復這 條無備份數據。
同時，負責調查根源問題的團隊找到了一個潛在問題，結果卻最終被證偽 :他們本以為 Music 的底層的數據存儲服務提供了錯誤數據，以至于數據刪除流水線刪除了錯誤的數據。但是經過詳細調查，這個可能性被排除了。這個團隊只能繼續尋找這個看起來好像不存在的 Bug。
· 第一批數據的恢復
數據恢復團隊確認了備份磁帶之后，第一批數據恢復在 3 月 8 日正 式開始了。從分布在異地離線存儲設施中的幾千個磁帶中請求超過 1.5PB 的數據看起來很難，從這些磁帶中真正讀取數據就更難了。
自己定制的磁帶備份軟件設計時沒 有考慮過這么大的恢復任務，所以第一批數據的恢復過程被切分成 5475 個小任務。
如果由真人每分鐘輸入一條命令，光輸入就需要超過三天的時間。人在這個過程中很可能還會引入很多錯誤。僅僅是這一點準備工作，就需要 SRE 寫代碼來完成。
在 3 月 9 日午夜的時候，SRE 終于將 5475 個恢復請求輸入了系統中。磁帶備份系統計 算了 4 個小時，得出 5337 盤磁帶需要從異地存儲設施中恢復。8 個小時后，一系列卡 車運載著這些磁帶抵達了數據中心。
在卡車奔波在路上時，數據中心的技術人員清空了幾個磁帶管理庫，撤下了幾千個磁帶以便給這次大型數據恢復工作讓路。接下來，工作人員又開始一點一點手動將剛剛抵達的幾千盤磁帶裝進磁帶管理機中。
由過去的 DiRT 演習證明，這種手動裝載的方式要比磁帶管理機廠商提供的基于機器手臂模式的裝載方式快很多。3 個多小時過后，磁帶管理機終于恢復了運行，開始將幾千個恢復任務逐漸寫入分布式存儲中。
雖然之前有 DiRT 的經驗，1.5PB 的海量數據恢復還是比預計時間長了 2 天。到 3 月 10 日早晨， 個文件中只有 74% 的文件從 3475 個磁帶上成功轉移到了數據中心中的 分布式存儲中。
其他 1862 個磁帶在第一次運輸中完全漏掉了。更糟的是，整個恢復過 程還被 17 個壞磁帶拖慢了。由于已經預計到會有磁帶損壞，寫入時已經采用了帶冗余的編碼。于是還需要額外安排卡車去取回這些冗余磁帶文件備份錯誤數據繼續，一并再去取回第一次漏掉的 1862 盤磁帶。
到 3 月 11 日早晨，超過 99.95% 的恢復任務已經完成了，剩余文件的冗余磁帶的取回也在進行中。雖然數據已經安全地存到了分布式存儲中，還有額外的數據恢復過程需要完 成，才能使用戶真正可以訪問。 Music團隊開始在數據的一小部分上進行數據恢復過程的最后步驟，同時不停校驗結果以確保這個恢復過程仍然能夠成功執行。
同時， Music生產系統的報警信息又來了，雖然與數據丟失不相關，但卻是非常嚴重的用戶直接可見的生產問題——該問題又消耗了恢復團隊整整兩天的時間。
在 3 月 13 日，數據恢復過程得以繼續，最終 條文件再一次可以被用戶訪問了。僅僅花了 7 天時間，我們恢復了 1.5PB 的用戶數據，7 天之內的 5 天用于真正的數據恢復操作。
· 第二批數據恢復
當第一批數據恢復過程結束之后，團隊開始關注如何恢復剩下的 條音頻數據，這些數據在備份進行之前就被錯誤地刪除了。這些文件中的大部分都是商店出售的，或者是推廣性質的音頻，原始文件都還存在。這些文件很快被恢復了。
但是，條中的一小部分是由用戶上傳的。 Music團隊發出了一條指令， 遠程遙控這些受影響的用戶的 Music客戶端軟件自動重新上傳3月14日之后的文件。整個過程持續了一周時間，最終全部數據恢復工作結束。
4. 解決根源問題
最終， Music團隊找到了重構過的數據刪除流水線中的Bug。為了更好地解釋這個Bug，我們需要先了解大型離線數據處理系統的演變過程。
和針對一個包括很多子系統和存儲服務的大型服務來說，徹底刪除已經標記為刪除的數據需要分多個階段進行，每個階段操作不同的數據存儲服務。
為了使得數據操作服務更快地結束，整個過程可以并行運行在幾萬臺機器上，這會給很多子系統造成很大壓力。這種分布式操作會影響到用戶，同時導致某些服務由于壓力過 大而崩潰。
為了避免這些問題，云計算工程師通常會在第二階段保存一些短期數據，用它們來進行數據存儲。如果沒有仔細調整過這些短期數據的生命周期，這個方法可能會引入數據競 爭問題。
例如，該任務兩個階段被設計成為嚴格隔離的，運行時間相隔 3 個小時。這樣第二階段的代碼可以大幅度簡化某些邏輯，否則這個階段的處理邏輯可能很難并行化。
但是隨著數據量的增長，每個階段需要更多時間才能完成。最終，當初設計時候的某些假設，在 這個新條件下就不再成立了。
一開始，這種數據競爭問題可能只會影響到一小部分數據。但是隨著數據數量的增加， 越來越多的數據可能會受到該數據競爭的影響。這種場景是隨機化的——對絕大部分數據，絕大部分時間來說，整個流水線任務是正確的。
但是一旦發生數據競爭問題，錯誤的數據就會被刪除掉。 Music 的數據刪除流水線任務設計時考慮了協調機制，并且加入了很多防錯機制。
當整個流水線的第一階段花費的時間越來越長時文件備份錯誤數據繼續，工程師加入了很多性能優化以保障整個 Music的隱私策略不受影響。
結果，這導致了這種數據競爭問題發生的概率的提升。當整個流水線任務重構時，這個概率被再次大幅提高了，直接導致了這個問 題經常性的發生。
經歷過這次數據恢復之后， Music團隊重新設計了該流水線任務，徹底消除了這 種數據競爭問題出現的可能性。
同時，我們增強了生產系統的監控和報警系統，使得它們可以提前檢測類似的大規模刪除問題，以便在用戶發現之前檢測和修復這類問題。
SRE在京最大面基會，就在這里
在12月16-17日兩天，北京站將在國際會議中心舉辦，屆時將有整整半天，上百人一起參加的 SRE 讀書和實踐交流會。等你來喲。
現在報名可享受9折優惠