[[204314]]

Tanya Reilly 的五個問題：相互依賴的服務(wù)如何使恢復(fù)更加困難，為什么有意并預(yù)先管理依賴是個好主意。

我最近請 Google 的網(wǎng)站可靠性工程師 Tanya Reilly 分享了她關(guān)于如何制定更好的災(zāi)難恢復(fù)計劃的想法。Tanya 將在 10 月 1 日到 4 日在紐約舉行的 O'Reilly Velocity Conference 上發(fā)表了一個題為《你有沒有試著把它關(guān)閉之后再打開?》的演講。

1、 在計劃備份系統(tǒng)策略時，人們最常犯的錯誤是什么?

經(jīng)典的一條是“你不需要備份策略，你需要一個恢復(fù)策略”。如果你有備份，但你尚未測試恢復(fù)它們，那么你沒有真正的備份。測試不僅僅意味著知道你可以獲得數(shù)據(jù)，還意味著知道如何把它放回數(shù)據(jù)庫，如何處理增量更改，甚至如果你需要的話，如何重新安裝整個系統(tǒng)。這意味著確保你的恢復(fù)路徑不依賴于與數(shù)據(jù)同時丟失的某些系統(tǒng)。

但測試恢復(fù)是枯燥的。這是人們在忙碌時會偷工減料的那類事情。這值得花時間使其盡可能簡單、無痛、自動化，永遠(yuǎn)不要靠任何人的意志力!同時，你必須確保有關(guān)人員知道該怎么做，所以定期進(jìn)行大規(guī)模的災(zāi)難測試是很好的?；謴?fù)演練是個好方法，可以找出該過程的文檔是否缺失或過期，或者你是否沒有足夠的資源(磁盤、網(wǎng)絡(luò)等)來傳輸和重新插入數(shù)據(jù)。

2、 創(chuàng)建災(zāi)難恢復(fù)disaster recovery (DR) 計劃最常見的挑戰(zhàn)是什么?

我認(rèn)為很多 DR 是一種事后的想法：“我們有這個很棒的系統(tǒng)，我們的業(yè)務(wù)依賴它……我猜我們應(yīng)該為它做 DR?”而且到那時，系統(tǒng)會非常復(fù)雜，充滿相互依賴關(guān)系，很難復(fù)制。

***次安裝的東西，它通常是由人手動調(diào)整才正常工作的，有時那是個具體特定的版本。當(dāng)你構(gòu)建第二個時，很難確定它是完全一樣的。即使在具有嚴(yán)格的配置管理的站點中，你也可能丟了某些東西，或者過期了。

例如，如果你已經(jīng)失去對解密密鑰的訪問權(quán)限，那么加密備份沒有太多用處。而且任何只在災(zāi)難中使用的部分都可能從你上次檢查它們過后就破環(huán)了。確保你已經(jīng)涵蓋了所有東西的唯一方法做認(rèn)真地故障切換。當(dāng)你準(zhǔn)備好了的，就計劃一下你的災(zāi)難(演練)吧!

如果你可以設(shè)計系統(tǒng)，以使災(zāi)難恢復(fù)模式成為正常運(yùn)行的一部分，那么情況會更好。如果你的服務(wù)從一開始就被設(shè)計為可復(fù)制的，添加更多的副本就是一個常規(guī)的操作并可能是自動化的。沒有新的方法，這只是一個容量問題。但是，系統(tǒng)中仍然存在一些只能在一個或兩個地方運(yùn)行的組件。偶然計劃中的假災(zāi)難能夠很好地將它們暴露出來。

順便說一句，那些被遺忘的組件可能包括僅在一個人的大腦中的信息，所以如果你自己發(fā)現(xiàn)說：“我們不能在 X 休假回來前進(jìn)行 DR 故障切換測試”，那么那個人是一個危險的單點失敗。

僅在災(zāi)難中使用的部分系統(tǒng)需要最多的測試，否則在需要時會失敗。這個部分越少越安全，且辛苦的測試工作也越少。

3、 為什么服務(wù)相互依賴使得災(zāi)難恢復(fù)更加困難?

如果你只有一個二進(jìn)制文件，那么恢復(fù)它是比較容易的：你做個二進(jìn)制備份就行。但是我們越來越多地將通用功能分解成單獨的服務(wù)。微服務(wù)意味著我們有更多的靈活性和更少地重新發(fā)明輪子：如果我們需要一個后端做一些事情，并且有一個已經(jīng)存在，那么很好，我們就可以使用它。但是一些需要保留很大的依賴關(guān)系，因為它很快會變得糾纏。

你可能知道你直接使用的后端，但是你可能不會注意到有新的后端添加到你使用的庫中。你可能依賴于某個東西，它也間接依賴于你。在依賴中斷之后，你可能會遇到一個死鎖：兩個系統(tǒng)都不能啟動，直到另一個運(yùn)行并提供一些功能。這是一個困難的恢復(fù)情況!

你甚至可以最終遇到間接依賴于自身的東西，例如你需要配置啟動網(wǎng)絡(luò)的設(shè)備，但在網(wǎng)絡(luò)關(guān)閉時無法訪問該設(shè)備。人們通常會提前考慮這些循環(huán)依賴，并且有某種后備計劃，但是這些本質(zhì)上是不太行得通的方式：它們只適用于極端情況，并且以不同的方式使用你的系統(tǒng)、進(jìn)程或代碼。這意味著，它們很可能有一個不會被發(fā)現(xiàn)的問題，直到你真的，真的需要它們的工作的時候才發(fā)現(xiàn)。

4、 你建議人們在感覺需要之前就開始有意管理其依賴關(guān)系，以防止?jié)撛诘臑?zāi)難性系統(tǒng)故障。為什么這很重要，你有什么建議有效地做到這一點?

管理你的依賴關(guān)系對于確保你可以從災(zāi)難中恢復(fù)至關(guān)重要。它使操作系統(tǒng)更容易。如果你的依賴不可靠，那么你就不可靠，所以你需要知道它們是什么。

雖然在它們變得混亂后也可以開始管理依賴關(guān)系，但是如果你早點開始，它會變得更容易一些。你可以設(shè)置使用各種服務(wù)策略——例如，你必須在堆棧中的這一層依賴于這組系統(tǒng)。你可以通過使其成為設(shè)計文件審查的常規(guī)部分，引入考慮依賴關(guān)系的習(xí)慣。但請記住，依賴關(guān)系列表將很快變得陳舊。如果你有程序化的發(fā)現(xiàn)依賴關(guān)系的方式，甚至強(qiáng)制實施依賴，這是***的。 我的 Velocity 談話涵蓋了我們?nèi)绾巫龅竭@一點。

早期開始的另一個優(yōu)點是，你可以將服務(wù)拆分為垂直“層”，每個層中的功能必須能夠在下一個層啟動之前完全在線。所以，例如，你可以說網(wǎng)絡(luò)必須能夠完全啟動而不借助任何其他服務(wù)。然后說，你的存儲系統(tǒng)應(yīng)該僅僅依賴于網(wǎng)絡(luò)，程序后端應(yīng)該僅僅依賴于網(wǎng)絡(luò)和存儲，等等。不同的層次對于不同的架構(gòu)是有意義的。

如果你提前計劃，新服務(wù)更容易選擇依賴關(guān)系。每個服務(wù)應(yīng)該只依賴堆棧中較低的服務(wù)。你仍然可以結(jié)束循環(huán)，在相同的層次服務(wù)上批次依賴 —— 但是它們可以更加緊密地包含，并且在逐個基礎(chǔ)上處理更容易。

5、 你對 Velocity NY 的其他部分感興趣么?

我整個星期二和星期三的時間表都完成了!正如你可能收集的那樣，我非常關(guān)心大型相互依賴的系統(tǒng)的可管理性，所以我期待聽到 Carin Meier 關(guān)于管理系統(tǒng)復(fù)雜性的想法、Sarah Wells 的微服務(wù)和 Baron 的可觀察性 的談話。我非常著迷聽到 Jon Moore 關(guān)于 Comcast 如何從年度發(fā)布到每天發(fā)布的故事。作為一個前系統(tǒng)管理員，我很期待聽到 Bryan Liles 對這個職位走向的看法。