Twitter 裁了那麼多人，但還能正常運轉
據稱，Twitter 減少了大約 80% 的員工。無論真實數字是多少，實際情況是整個團隊都沒有工程師工作了。
然而，它還能正常運轉，我們還能正常訪問。這讓很多人想知道這些工程師到底幹了些什麼，他們的存在只是讓公司看起來很臃腫。我想講一下我在 Twitter 的某個小模塊（雖然它並不那麼小）的工作，以及維護這個東西運行做的一些事情。
背景與歷史
我在 Twitter 擔任了五年的站點可靠性工程師（SRE）。其中有四年，我是 Cache 團隊唯一的 SRE。之前在整個團隊中有幾個人和我一起工作，但他們來了又走了。在這四年裏，我在團隊中負責自動化、可靠性和運維。我設計並實現了大部分保持它運行的工具，所以我想我有資格談論這個問題。（可能只有一兩個人有資格談論這個問題）
緩存可以用來使事情變得更快，或者減輕運行成本較高的東西的請求。如果你有一個服務器需要 1 秒鐘的響應，但每次都是同樣的響應，你可以把這個響應存儲在一個緩存服務器中，在那裏可以在幾毫秒內提供響應。
或者，如果你有一個服務器集羣，每秒處理 1000 個請求可能會花費 1000 美元，你可以使用緩存來存儲響應，並從該緩存服務器上提供響應。那麼你將擁有一個 100 美元的小型集羣，而一個便宜的大型緩存服務器集羣可能需要再花 100 美元。這些數字只是爲了說明問題舉的例子。
緩存承擔了該網站的大部分流量。推文、所有的時間線、直接信息、廣告、身份驗證，都是由 Cache 團隊的服務器提供的。如果 Cache 出了問題，作爲用戶的你會知道，這些問題是顯而易見的。
當我加入這個團隊時，我的第一個項目是把即將退役的舊機器換成新機器。當時沒有任何工具或自動化來做這件事，我得到的是一張寫有服務器名稱的電子表格。我很高興地說，那個團隊的運維不再是那樣了！
緩存如何保持運行？
保持緩存運行的第一要點是，它們是作爲 Mesos 上的 Aurora Job 運行的。Aurora 爲應用程序找到運行的服務器，Mesos 將所有的服務器聚集在一起，所以 Aurora 知道它們。Aurora 也會在應用程序啓動後保持運行狀態。
如果我們說一個緩存集羣需要 100 臺服務器，它會盡力保持這 100 臺服務器的運行。如果某臺服務器由於某種原因完全中斷了，Mesos 會檢測到這一點，然後將服務器從它的聚合池中移除，這時 Aurora 會被告知只有 99 個緩存在運行，然後知道它需要從 Aurora 中找到一臺新的服務器來運行。它將自動找到一臺，並將總數恢復到 100。不需要任何人蔘與。
在數據中心，服務器被放置在被稱爲機架的東西里。機架上的服務器通過一個叫做交換機的設備與機架上的其他服務器相連。從這裏開始，有一個完整的複雜系統，將交換機連接到更多的交換機和路由器，最終連接到互聯網。
一個機架上可以容納 20 到 30 臺服務器。機架可能會出現故障，交換機可能會壞掉，或者電源可能會壞掉，這些都會導致所有 20 臺服務器癱瘓。Aurora 和 Mesos 爲我們做的另一件好事是確保不會有太多的應用程序被放在一個機架上。因此，整個機架可以安全地突然停機，Aurora 和 Mesos 會找到新的服務器，作爲運行在那裏的應用程序的家園。
之前提到的那個電子表格，它也在跟蹤機架上有多少臺服務器，電子表格編寫者試圖確保沒有太多的服務器。現在使用當前的工具，當我們配置新的服務器以使其上線時，我們擁有可以跟蹤所有這些的工具。這些工具確保團隊在一個機架上沒有太多的物理服務器，而且一切都以一種在出現故障時不會引起問題的方式分佈。
不幸的是，Mesos 並不能檢測到每一臺服務器的故障，所以我們對硬件問題進行了額外的監控。我們尋找諸如壞磁盤和故障內存之類的東西。其中一些不會導致整個服務器癱瘓，可能只是導致運行緩慢。我們有一個警報儀表板，可以掃描到損壞的服務器。如果發現有一臺服務器壞了，我們會自動創建一個維修任務，讓數據中心的人去看看。
該團隊擁有的另一個重要軟件能提供跟蹤高速緩存集羣的啓動時間的服務。如果在很短的時間內有太多的服務器被視爲停機，那麼需要關閉緩存的新任務將被拒絕，直到它安全爲止。這就是我們如何避免意外關閉整個緩存集羣並壓倒受它們保護的服務的方法。
我們有一些阻止措施來針對一些突發情況，比如有太多的服務器很快被關閉，一次有太多的服務器需要修復，或者 Aurora 無法找到新的服務器來放置舊的任務等。
要爲一個被檢測爲故障的服務器創建一個修復任務，首先我們通過檢查該服務來檢查從中刪除 Job 是否安全，然後一旦它爲空，它就被標記爲安全，以便數據中心的技術人員對其進行處理。當數據中心的技術人員將服務器標記爲已修復時，我們又有工具來尋找這一點，並自動激活服務器，以便它可以運行 Job。整個過程唯一需要的人是數據中心實際修復它的人。（不過他們還在那裏嗎？）
重複應用的問題也得到了修復。我們有一些錯誤，新的緩存服務器不會被添加回來（啓動時的競爭條件），或者有時需要長達 10 分鐘才能添加一臺服務器（O(n^n) 邏輯）。由於所有這些都是自動化工作，我們沒有被手動任務所困擾，因此我們在團隊中形成了一種文化，在這種文化中，我們可以在保持項目進度的同時，去修復這些問題。
我們還有其他的自動修復措施，例如，如果某些應用程序指標（如延遲）是異常值，我們會自動重新啓動任務，這樣工程師不會被呼喚。團隊可能每週會收到通知，但幾乎從來不嚴重。我們經常輪值值班，但沒有人接到傳呼。
容量規劃是網站未出現故障的更重要原因之一。Twitter 有兩個數據中心在運行，可以處理整個網站的故障。運行的每一項重要服務都可以在一個數據中心之外運行。任何時候可用的總容量實際上是 200%。這僅適用於災難場景，大多數時候兩個數據中心都在爲流量服務。數據中心的利用率最多隻有 50%。即使這樣在實際工作中也會很忙。
當人們計算他們的容量需求時，他們會計算出一個數據中心爲所有流量服務所需的容量，然後通常會在此基礎上增加空間！只要不需要故障轉移，就有大量的服務器淨空可用於額外的流量。整個數據中心的故障是相當罕見的，在我工作的五年中只發生過一次。
我們還將緩存集羣分開。我們沒有一個多租戶集羣，爲所有的東西提供服務，並且有應用層面的隔離。這有助於在一個集羣出現問題時，將爆炸半徑保持在只有該集羣和機器上的一些共處的服務器上。同樣，Aurora 通過保持分佈式緩存來提供幫助，因此不會受到太大影響，最終監控將趕上並修復它們。
我在這裏做了什麼？
好吧，我做了上面的一切！我確實與客戶（使用 Cache 即服務的團隊）交流過。在這些事情被自動化之後，我又自動化了更多的事情。我還研究了一些有趣的性能問題，試驗了一些可能使事情變得更好的技術，並推動了一些大型的成本節約項目。我做了容量規劃，並確定要訂購多少臺服務器。我有很多事情在做。不管別人怎麼想，我不是成天喫喝玩樂就能領取薪水。
這就是爲 Twitter 請求提供服務的緩存保持正常運行的方式。這只是日常工作的一部分。爲了達到這一點，多年來我做了大量的工作。現在是回過頭來欣賞這個東西仍在完美運作的時刻了！
雖然，我也承認肯定在某些地方還隱藏着一些沒有被發現的 bug……
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/wrNqIxbtR2wsDinW_JxHaA