Captain Obvious 告訴我們，在夏季，購買活動和網路專案基礎設施的變化強度通常都會減少。 原因很簡單，即使是 IT 專家有時也會去度假。 還有 CTO。 對於那些留任的人來說，這更加困難，但這不是現在的重點：也許這就是為什麼夏季是慢慢思考現有預訂計劃並製定改進計劃的最佳時期。 葉戈爾·安德烈耶夫 (Yegor Andreev) 的經歷 ，他在會議上談到 .
建置備份網站時可能會陷入幾個陷阱。 而且絕對不可能陷入其中。 就像許多其他事情一樣，在這一切中毀掉我們的是完美主義和……懶惰。 我們努力把每件事、每件事、每件事都做到完美，但我們不需要做得完美！ 你只需要做某些事情，但要正確地做，完成它們，這樣它們才能正常工作。
故障轉移並不是一件非常有趣的事情；它是一種非常有趣的事情。 這件事應該只做一件事——減少停機時間，以便服務、公司損失更少的錢。 在所有預訂方法中，我建議在以下背景下思考：錢在哪裡？
第一個陷阱：當我們建立大型、可靠的系統並採用冗餘時，我們可以減少事故數量。 這是一個可怕的誤解。 當我們進行裁員時，事故的數量可能會增加。 如果我們一切都做得正確，那麼我們將共同減少停機時間。 事故會發生更多，但發生的成本會更低。 什麼是預訂？ - 這是系統的複雜性。 任何複雜化都是不好的：我們有更多的齒輪，更多的齒輪，總而言之，更多的元件 - 因此，故障的可能性更高。 他們真的會破裂。 而且它們會更頻繁地破裂。 一個簡單的範例：假設我們有一個使用 PHP 和 MySQL 的網站。 而且急需保留。
Shtosh (c) 我們佔據第二個站點，建立一個相同的系統...複雜性變得兩倍 - 我們有兩個實體。 我們還推出了將資料從一個站點傳輸到另一個站點的邏輯，即資料複製、複製靜態資料等。 因此，複製邏輯通常非常複雜，因此，系統的總複雜度可能不是2倍，而是3、5、10倍。
第二個陷阱：當我們建造非常大型的複雜系統時，我們會幻想最終想要得到什麼。 瞧：我們希望獲得一個超級可靠的系統，可以在沒有任何停機時間的情況下工作，在半秒內（或者更好的是，立即）切換，然後我們開始讓夢想成真。 但這裡也有一個細微差別：所需的切換時間越短，系統邏輯就會變得越複雜。 我們必須讓這個邏輯越複雜，系統就越容易崩潰。 你最終可能會遇到一個非常不愉快的情況：我們正在竭盡全力減少停機時間，但實際上我們讓一切變得更加複雜，當出現問題時，停機時間最終會更長。 在這裡，您經常會發現自己在想：好吧……最好不要預訂。 如果它能夠單獨工作並具有可以理解的停機時間，那就更好了。
你怎麼能對抗這個呢？ 我們需要停止對自己撒謊，停止自我吹噓我們現在要在這裡建造一艘太空船，而是要充分了解這個計畫可以持續多久。 在這段最長時間內，我們將選擇實際使用的方法來提高系統的可靠性。
現在是「w 的故事」的時間了……當然是生活中的故事。
範例一
想像 N 市 1 號軋管廠的名片網站。上面用大寫字母寫著 - 1 號軋管廠。 下面是標語：“我們的煙鬥是 N 區最圓的煙鬥。” 下面是執行長的電話號碼和姓名。 我們知道您需要預訂 - 這是一件非常重要的事情！ 讓我們開始弄清楚它是由什麼組成。 Html-statics - 也就是說，總經理實際上正在浴室的桌子上與他的搭檔討論某種下一步交易的圖片。 我們開始考慮停機時間。 我想到：你需要在那裡躺五分鐘，不能再多了。 那麼問題來了：我們這個網站整體有多少銷售額？ 多少——多少？ 「零」是什麼意思？ 這意味著：因為將軍去年在同一張桌子上進行了所有四筆交易，與他們一起去澡堂和坐在桌子旁的同一個人進行了交易。 我們知道，即使網站停留一天，也不會發生任何可怕的事情。
根據介紹性訊息，有一天提出這個故事。 讓我們開始考慮冗餘方案。 我們為此範例選擇最理想的冗餘方案：我們不使用冗餘。 任何管理員都可以在半小時內吸煙休息時提出整個問題。 安裝網頁伺服器，新增檔案 - 就是這樣。 它會起作用的。 你不需要留意任何事情，不需要特別注意任何事情。 也就是說，從範例一得出的結論是非常明顯的：不需要預留的服務不需要預留。
例子二
公司部落格：受過專門訓練的人在那裡寫新聞，我們參加了某某展會，但我們發布了另一個新產品，等等。 假設這是帶有 WordPress 的標準 PHP、一個小型資料庫和一點靜態。 當然，我再次想到，在任何情況下都不應該躺下——「不超過五分鐘！」僅此而已。 但讓我們進一步思考。 這個部落格是做什麼的？ 人們從 Yandex、Google 根據一些查詢有機地來到那裡。 偉大的。 銷量跟這個有關係嗎？ 頓悟：不是真的。 廣告流量流向位於另一台機器上的主站點。 讓我們開始考慮預訂方案。 從好的方面來說，它需要在幾個小時內籌集到，最好為此做好準備。 合理的做法是從另一個資料中心取出一台機器，將環境部署到上面，即 Web 伺服器、PHP、WordPress、MySQL，然後將其留在那裡。 當我們明白一切都壞了的那一刻，我們需要做兩件事 - 將mysql轉儲推出50米，它會在一分鐘內飛到那裡，並從那裡的備份中推出一定數量的圖片。 天知道這也不存在多久。 就這樣，半小時之後，一切就都起來了。 沒有複製，或上帝原諒我，自動故障轉移。 結論：我們可以從備份中快速推出的內容不需要備份。
例三，更複雜
網上商城。 敞開心扉的 PhP 稍作調整，MySQL 有堅實的基礎。 相當多的靜態（畢竟，線上商店有漂亮的高清圖像和所有這些東西），用於會話的 Redis 和用於搜尋的 Elasticsearch。 我們開始考慮停機時間。 當然，很明顯，在線商店不可能一天都無憂無慮地閒置。 畢竟，躺的時間越長，我們損失的錢就越多。 值得加快速度。 多少？ 我想如果我們躺一小時，就沒有人會發瘋。 是的，我們會失去一些東西，但如果我們開始努力，情況只會變得更糟。 我們定義了每小時允許的停機時間計劃。
這一切如何被保留？ 無論如何你都需要一輛車：一個小時的時間相當短。 Mysql：這裡我們已經需要複製，即時複製，因為一小時內 100 GB 很可能不會加入轉儲。 靜態、圖片：同樣，一小時內 500 GB 可能沒有時間添加。 因此，最好立即複製圖片。 Redis：這就是事情變得有趣的地方。 在 Redis 中，會話是被儲存的 - 我們不能只是拿走它並埋葬它。 因為這不會很好：所有用戶都將被註銷，他們的購物籃將被清空，等等。 人們將被迫重新輸入使用者名稱和密碼，許多人可能會退出並無法完成購買。 同樣，轉換率將會下降。 另一方面，Redis 是直接最新的，可能也不需要最後登入的使用者。 一個好的折衷方案是使用 Redis 並從昨天的備份中恢復它，或者，如果您每小時執行一次，則從一小時前恢復。 幸運的是，從備份恢復它意味著複製一個檔案。 最有趣的故事是 Elasticsearch。 誰學過 MySQL 複製？ 誰學過 Elasticsearch 複製？ 之後對誰來說可以正常運作？ 我的意思是我們在系統中看到了某個實體。 它似乎很有用 - 但它很複雜。
複雜是因為我們的工程師同事沒有使用它的經驗。 或有負面的經驗。 或者我們知道這仍然是一項相當新的技術，存在細微差別或原始性。 我們想…媽的，elastic也健康，從備份恢復起來也需要很長時間，怎麼辦？ 我們知道，在我們的例子中，彈性用於搜尋。 我們的網上商店如何銷售？ 我們去找行銷人員，詢問人們來自哪裡。 他們回答：“90% 來自 Yandex Market 的直接進入產品卡。” 他們要么買，要么不買。 因此，10%的用戶需要搜尋。 保持彈性複製，特別是在不同區域的不同資料中心之間，確實有很多細微差別。 哪個出口？ 我們從保留的站點獲取彈性並且不對其進行任何操作。 如果事情拖延下去，我們可能有一天會提出這個問題，但這還不確定。 實際上，結論是相同的，無論是加或減：我們再次強調，不保留不影響金錢的服務。 為了使圖表更簡單。
例子四，更難
積分商：賣花、叫計程車、賣貨，一般什麼都可以。 這是一個 24/7 為大量用戶工作的嚴肅的事情。 擁有成熟的有趣堆疊，其中有有趣的基礎、解決方案、高負載，最重要的是，躺下超過 5 分鐘會很痛。 不僅僅是因為人們不會購買，而是因為人們會看到這個東西不起作用，他們會感到沮喪，可能根本不會回來。
好的。 53分鐘。 對此我們該怎麼辦？ 在這種情況下，我們像成年人一樣，用所有的錢建立一個真正的備份站點，複製所有內容，甚至可能盡可能自動切換到這個站點。 除此之外，您需要記住做一件重要的事情：實際上，編寫切換規則。 即使一切都自動化了，規則也可能非常簡單。 來自系列“運行這樣那樣的 ansible 腳本”、“單擊路線 XNUMX 中這樣那樣的複選框”等等 - 但這必須是某種精確的操作列表。
一切似乎都很清楚。 切換複製是一項微不足道的任務，否則它會自行切換。 DNS中的網域重寫也是同一系列。 問題在於，當這樣的專案失敗時，恐慌就會開始，即使是最堅強、留著鬍子的管理員也可能會受到影響。 如果沒有明確的指示“打開終端，到這裡來，我們的伺服器位址還是這樣”，很難滿足5分鐘的復甦時限。 嗯，另外，當我們使用這些法規時，很容易記錄基礎設施中的一些變化，例如，並相應地更改法規。
好吧，如果預訂系統非常複雜，並且在某些時候我們犯了一個錯誤，那麼我們可以破壞我們的備份站點，並且另外將數據變成兩個站點上的南瓜 - 這將是完全可悲的。
例五，完全硬核
一項國際服務，在全球擁有數億用戶。 所有時區，最高速度下的高負荷，你根本無法躺下。 一分鐘——這將是悲傷的。 怎麼辦？ 再次根據完整的計劃進行預訂。 我們做了我在上一個範例中談到的所有內容，甚至還做了更多。 這是一個理想的世界，我們的基礎設施符合 IaaC devops 的所有概念。 也就是說，一切都在 git 中，你只需按一下按鈕。
缺什麼？ 一——練習。 沒有他們這是不可能的。 似乎一切對我們來說都是完美的，一切都在我們的掌控之中。 我們按下按鈕，一切都會發生。 即使事實如此（我們知道事情不會以這種方式發生），我們的系統也會與其他一些系統互動。 例如，這是來自路由 53 的 dns、s3 儲存、與某些 api 的整合。 我們無法預見這個推測性實驗中的一切。 在我們真正拉動開關之前，我們不知道它是否有效。
大概就是這樣。 不要偷懶或過度。 願正常運轉時間與您同在！
來源： www.habr.com