創建更好的災難恢復計劃

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

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

1、 在計劃備份系統策略時，人們最常犯的錯誤是什麼？

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

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

2、 創建 災難恢復 disaster recovery （DR） 計劃最常見的挑戰是什麼？

我認為很多 DR 是一種事後的想法：「我們有這個很棒的系統，我們的業務依賴它……我猜我們應該為它做 DR？」而且到那時，系統會非常複雜，充滿相互依賴關係，很難複製。

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

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

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

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

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

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

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

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

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

4、 你建議人們在感覺需要之前就開始有意管理其依賴關係，以防止潛在的災難性系統故障。為什麼這很重要，你有什麼建議有效地做到這一點？

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

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

早期開始的另一個優點是，你可以將服務拆分為垂直「層」，每個層中的功能必須能夠在下一個層啟動之前完全在線。所以，例如，你可以說網路必須能夠完全啟動而不藉助任何其他服務。然後說，你的存儲系統應該僅僅依賴於網路，程序後端應該僅僅依賴於網路和存儲，等等。不同的層次對於不同的架構是有意義的。

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

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

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

作者簡介：

Nikki McDonald 是 O'Reilly Media，Inc. 的內容總監。她住在密歇根州的安娜堡市。

Tanya Reilly 自 2005 年以來一直是 Google 的系統管理員和站點可靠性工程師，致力於分散式鎖、負載均衡和引導等底層基礎架構。在加入 Google 之前，她是愛爾蘭最大的 ISP eircom.net 的系統管理員，在這之前她擔當了一個小型軟體公司的整個 IT 部門。

via: https://www.oreilly.com/ideas/creating-better-disaster-recovery-plans

作者：Nikki McDonald, Tanya Reilly 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive