[[412176]]

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

故事之一

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

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

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

故事之二

第二個故事來自于一個商業(yè)的網(wǎng)頁和手機(jī)應(yīng)用。后端有一個由一組工程師負(fù)責(zé)的微服務(wù)體系結(jié)構(gòu)。這意味著部署需要協(xié)調(diào)，但是使用正式的發(fā)布過程和自動化簡化了一些。新代碼在準(zhǔn)備好后會被審查并合并到主干中，并且高層開發(fā)人員通常會為每個微服務(wù)標(biāo)記版本，然后自動部署到臨時環(huán)境。臨時環(huán)境中的版本會被定期收集到一個元版本中，在自動部署到生產(chǎn)環(huán)境之前，該版本會得到各個人的簽署（這是一個合規(guī)環(huán)境）。

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

故事之三

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

事后分析

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

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

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

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

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