[[412176]]

現代應用程序開發的一大優點是，像硬件故障或如何設置 RAID 這類問題是由云提供商操心的。優秀的云供應商不太可能丟失你的應用數據，所以有時我會被詢問現在為什么還要備份？下面是一些現實世界的故事。

故事之一

第一個故事來自一個數據科學項目：它基本上是一個從正在進行的研究中來收集數據的龐大而復雜的管道，然后用各種不同的方式處理以滿足一些尖端模型的需要。這個面向用戶的應用程序還沒有推出，但是一個由數據科學家和開發人員組成的團隊已經為建立這個模型和它的數據集工作了好幾個月。

在項目中工作的人有他們自己的實驗工作的開發環境。他們會在終端中做一些類似 export ENVIRONMENT=simonsdev 的事情，然后所有在終端上運行的軟件都會在那個環境下運行，而不是在生產環境下。

該團隊迫切需要推出一個面向用戶的應用程序，以便那些花錢的人能夠從他們幾個月的投資中真正看到一些回報。在一個星期六，一位工程師試圖趕工一些工作。他在晚上很晚的時候做完了一個實驗，決定收拾東西回家。他啟動了一個清理腳本來刪除他的開發環境中的所有內容，但奇怪的是，這比平時花費了更長的時間。這時他意識到，他已經忘記了哪個終端被配置為指向哪個環境。（LCTT 譯注：意即刪除了生產環境。）

故事之二

第二個故事來自于一個商業的網頁和手機應用。后端有一個由一組工程師負責的微服務體系結構。這意味著部署需要協調，但是使用正式的發布過程和自動化簡化了一些。新代碼在準備好后會被審查并合并到主干中，并且高層開發人員通常會為每個微服務標記版本，然后自動部署到臨時環境。臨時環境中的版本會被定期收集到一個元版本中，在自動部署到生產環境之前，該版本會得到各個人的簽署（這是一個合規環境）。

有一天，一位開發人員正在開發一個復雜的功能，而其他開發該微服務的開發人員都同意將他們正在開發的代碼提交到主干，也都知道它還不能被實際發布。長話短說，并不是團隊中的每個人都收到了消息，而代碼就進入了發布管道。更糟糕的是，那些實驗性代碼需要一種新的方式來表示用戶配置文件數據，因此它有一個臨時數據遷移，它在推出到生產環境時運行，損壞了所有的用戶配置文件。

故事之三

第三個故事來自另一款網頁應用。這個有一個更簡單的架構：大部分代碼在一個應用程序中，數據在數據庫中。然而，這個應用程序也是在很大的截止日期壓力下編寫的。事實證明，在開發初期，當徹底更改的數據庫架構很常見時，添加一項功能來檢測此類更改并清理舊數據，這實際上對發布前的早期開發很有用，并且始終只是作為開發環境的臨時功能。不幸的是，在匆忙構建應用的其余部分并推出時，我們忘記了這些代碼。當然，直到有一天它在生產環境中被觸發了。

事后分析

對于任何故障的事后分析，很容易忽視大局，最終將一切歸咎于一些小細節。一個特例是發現某人犯了一些錯誤，然后責怪那個人。這些故事中的所有工程師實際上都是優秀的工程師（雇傭 SRE 顧問的公司不是那些在長期雇傭中偷工減料的公司），所以解雇他們，換掉他們并不能解決任何問題。即使你擁有 100 倍的開發人員，它仍然是有限的，所以在足夠的復雜性和壓力下，錯誤也會發生。最重要的解決方案是備份，無論你如何丟失數據（包括來自惡意軟件，這是最近新聞中的一個熱門話題），它都能幫助你。如果你無法容忍沒有副本，就不要只有一個副本。

故事之一的結局很糟糕：沒有備份。該項目的六個月的數據收集白干了。順便說一句，有些地方只保留一個每日快照作為備份，這個故事也是一個很好的例子，說明了這也會出錯：如果數據丟失發生在星期六，并且你準備在星期一嘗試恢復，那么一日備份就只能得到星期日的一個空數據備份。

故事之二并不算好，但結果要好得多。備份是可用的，但數據遷移也是可逆的。不好的部分是發布是在推出前完成的，并且修復工作必須在生產站點關閉時進行編碼。我講這個故事的主要原因是為了提醒大家，備份并不僅僅是災難性的數據丟失。部分數據損壞也會發生，而且可能會更加混亂。

故事之三還好。盡管少量數據永久丟失，但大部分數據可以從備份中恢復。團隊中的每個人都對沒有標記極其明顯的危險代碼感到非常難過。我沒有參與早期的開發，但我感覺很糟糕，因為恢復數據所需的時間比正常情況要長得多。如果有一個經過良好測試的恢復過程，我認為該站點應該在總共不到 15 分鐘的時間內重新上線。但是第一次恢復沒有成功，我不得不調試它為什么不能成功，然后重試。當一個生產站點宕機了，需要你重新啟動它，每過 10 秒鐘都感覺過了一個世紀。值得慶幸的是，老板們比某些人更能理解我們。他們實際上松了一口氣，因為這一場可能使公司沉沒的一次性災難只導致了幾分鐘的數據丟失和不到一個小時的停機時間。

在實踐中，備份“成功”但恢復失敗的情況極為普遍。很多時候，小型數據集上進行恢復測試是可以正常工作的，但在生產規模的大數據集上就會失敗。當每個人都壓力過大時，災難最有可能發生，而生產站點的故障只會增加壓力。在時間合適的時候測試和記錄完整的恢復過程是一個非常好的主意。