[[204314]]

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

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

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

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

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

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

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

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

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

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

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

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

3、 為什么服務相互依賴使得災難恢復更加困難?

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

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

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

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

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

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

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

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

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

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