嘿哈布爾！ 我提請您注意這篇文章的翻譯 作者：阿迪布·道。
如果這個標題沒有讓您感到脊背發涼，您應該跳到下一段或訪問我們的專用頁面 - 我們想談談。
我們是誰
我們是一個由 4 隻企鵝組成的團隊，他們熱愛編寫程式碼和使用硬體。在業餘時間，我們負責部署、維護和營運超過 7000 台運行 Linux 的實體伺服器，這些伺服器分佈在美國 3 個不同的資料中心。
我們還有機會在距離現場 10 公里的地方，在我們自己舒適的辦公室完成這項工作，距離地中海海灘只有很短的車程。
規模問題
雖然由於初始投資相對較低，新創公司從在雲端託管其基礎設施開始是有意義的，但我們 Outbrain 決定使用我們自己的伺服器。我們這樣做是因為雲端基礎設施發展到一定程度後，其成本遠遠超過了我們自己位於資料中心的設備的營運成本。此外，您的伺服器還提供最高程度的控制和故障排除功能。
在我們發展的過程中，問題總是在身邊。而且，他們通常成群結隊。伺服器生命週期管理需要不斷自我完善，才能在伺服器數量快速成長的背景下正常運作。用於管理資料中心伺服器群組的軟體方法很快就會變得笨拙。在滿足 QoS 標準的同時檢測、故障排除和減輕故障就變成了一個需要兼顧極其多樣化的硬體陣列、不同的工作負載、升級期限以及其他沒人願意擔心的好事情的問題。
掌握你的領域
為了解決其中的許多問題，我們將 Outbrain 中的伺服器生命週期分解為其主要元件，並將它們稱為網域。例如，一個領域涵蓋設備要求，另一個領域涵蓋與庫存生命週期相關的物流，第三個領域涵蓋與現場人員的通訊。還有一個關於硬體可觀測性的問題，但我們不會描述所有的要點。我們的目標是研究和定義領域，以便可以使用程式碼對其進行抽象化。一旦開發了工作抽象，它就會轉移到手動流程進行部署、測試和改進。最後，該域被配置為透過 API 與其他域集成，形成一個整體的、動態的、不斷發展的、可部署、可測試和可觀察的硬體生命週期系統。就像我們所有其他生產系統一樣。
採用這種方法使我們能夠透過創建工具和自動化來正確解決許多問題。
需要域名
儘管電子郵件和電子表格在早期是滿足需求的可行方法，但它並不是一個成功的解決方案，特別是當伺服器數量和傳入請求量達到一定水平時。為了在快速擴張的情況下更好地組織傳入請求並確定優先級，我們必須使用可以提供以下功能的票務系統：
- 能夠僅自訂相關欄位的視圖（簡單）
- 開放API（可擴充）
- 我們的團隊知道（理解）
- 與我們現有的工作流程整合（統一）
由於我們使用 Jira 來管理我們的衝刺和內部任務，因此我們決定創建另一個專案來幫助我們的客戶提交票證並追蹤他們的結果。使用 Jira 處理傳入請求和管理內部任務使我們能夠建立單一看板，使我們能夠從整體上查看所有流程。我們的內部「客戶」只看到了對設備的請求，而沒有深入研究附加任務的較不重要的細節（例如改進工具、修復錯誤）。
Jira 中的看板
額外的好處是，佇列和優先權現在對每個人都可見，這使得了解特定請求「在佇列中的位置」以及它之前的內容成為可能。這使得業主可以重新確定自己的請求的優先順序，而無需聯繫我們。拖曳它就可以了。它還允許我們根據基於 Jira 中產生的指標的請求類型來監控和評估我們的 SLA。
設備生命週期領域
試著想像一下管理每個伺服器機架中使用的硬體的複雜性。更糟的是，許多硬體（RAM、ROM）可以從倉庫移至伺服器機房並移回。它們也會出現故障或被註銷並更換並返回給供應商進行更換/維修。所有這些都必須傳達給參與設備實體維護的託管服務員工。為了解決這些問題，我們創建了一個名為 Floppy 的內部工具。他的任務是：
- 管理與現場人員的溝通，彙整所有資訊；
- 每次完成並驗證設備維護工作後更新「倉庫」資料。
反過來，倉庫使用 Grafana 進行視覺化，我們用它來繪製所有指標。因此，我們使用相同的工具來實現倉庫視覺化和其他生產需求。
Grafana 的倉庫設備控制面板
對於在保固期內的伺服器設備，我們使用另一種稱為 Dispatcher 的工具。他：
- 收集系統日誌；
- 按照供應商要求的格式產生報告；
- 透過 API 建立來自供應商的請求；
- 接收並儲存應用程式標識符以進一步追蹤其進度。
一旦我們的索賠被接受（通常在工作時間內），備件就會被發送到相應的資料中心並由工作人員接受。
詹金斯控制台輸出
通訊領域
為了跟上我們業務的快速成長（這需要不斷增加的容量），我們必須調整與本地資料中心的技術專家合作的方式。如果一開始擴大規模意味著購買新伺服器，那麼在整合專案（基於向 Kubernetes 的過渡）之後，情況就完全不同了。我們從「新增機架」到「重新調整伺服器用途」的演進。
使用新方法還需要新工具，以便能夠更輕鬆地與資料中心人員互動。這些工具需要：
- 簡單;
- 自治;
- 效率;
- 可靠性。
我們必須將自己排除在鏈條之外並組織工作，以便技術人員可以直接使用伺服器設備。如果沒有我們的干預，也沒有定期提出所有這些有關工作量、工作時間、設備可用性等問題。
為了實現這一目標，我們在每個資料中心安裝了 iPad。連接到伺服器後，會發生以下情況：
- 設備確認該伺服器確實需要一些工作；
- 關閉伺服器上執行的應用程式（如有必要）；
- Slack 頻道上發布了一組工作說明，解釋了所需的步驟；
- 工作完成後，設備檢查伺服器最終狀態的正確性；
- 如有必要，重新啟動應用程式。
此外，我們還準備了一個 Slack 機器人來幫助技術人員。由於具有廣泛的功能（我們不斷擴展功能），該機器人使他們的工作變得更加輕鬆，也使我們的生活變得更加輕鬆。透過這種方式，我們優化了重新利用和維護伺服器的大部分流程，將我們自己從工作流程中消除了。
iPad 位於我們的資料中心之一
硬體領域
可靠地擴展我們的資料中心基礎設施需要對每個組件具有良好的可見性，例如：
- 硬體故障偵測
- 伺服器狀態（活動、主機、殭屍等）
- 功耗
- 韌體版本
- 整個業務的分析
我們的解決方案使我們能夠決定如何、在哪裡以及何時購買設備，有時甚至在實際需要之前就做出決定。此外，透過確定不同設備上的負載水平，我們能夠實現改進的資源分配。特別是能源消耗。現在，我們可以在將伺服器安裝到機架中並連接到電源之前、整個生命週期直至其最終報廢之前，就伺服器的放置做出明智的決策。
Grafana 中的能源儀表板
然後 COVID-19 出現了…
我們的團隊創建的技術使媒體公司和出版商能夠在線上幫助訪客找到他們可能感興趣的相關內容、產品和服務。我們的基礎設施旨在為發布一些令人興奮的新聞時產生的流量提供服務。
媒體圍繞著 COVID-19 的密集報道，加上流量的增加，意味著我們迫切需要學習如何應對這些壓力。此外，所有這一切都必須在全球危機期間完成，當時供應鏈中斷，大多數員工都在家。
但是，正如我們所說，我們的模型已經假設：
- 我們資料中心的設備大部分是我們無法實際接觸到的；
- 我們幾乎所有的體力工作都是遠端完成的；
- 工作是異步、自主、大規模地執行的；
- 我們採用「零件製造」的方式來滿足設備需求，而不是購買新設備；
- 我們有一個倉庫，可以讓我們創造新的東西，而不僅僅是進行例行維修。
因此，全球範圍內許多公司無法實際存取其資料中心的限制對我們影響不大，而對於備件和伺服器，是的，我們盡力確保設備的穩定運作。但這樣做的目的是防止突然發現某些硬體不可用時可能發生的事件。我們確保我們的儲備已被填滿，但並非旨在滿足當前的需求。
總之，我想說的是，我們在資料中心產業的工作方法證明，可以將良好的程式碼設計原則應用於資料中心的實體管理。也許你會發現它很有趣。
原來的：
來源： www.habr.com