讓facebook自愈：自動化主動機架維護 - 2

讓facebook自愈：自動化主動機架維護 - 2
Making Facebook self-healing: Automating proactive rack maintenance

原文：https://code.fb.com/productio...
做者： Romain Komorn
翻譯： 時序

Pre-disable(預關閉): 這一步主要是保證目前池子中認爲是空閒的主機在主機級別關閉或批量操做期間交換多個主機時不會從新被加入到生產環境。

Host-level disable:(主機級關閉)：在一些場景，因爲在預關閉時已經被批量關閉了因此這步沒有操做。在其餘場景這一步會成爲繼承FBAR的的主機級關閉邏輯的並行操做。

Post-disable(關閉後):這一步主要是用來確認預關閉和主機級關閉成功完成。它也支持做者去檢查主機級關閉步驟的結果來決定是否要忽略特定的失敗類型若是它們仍在預期的閾值之下。

下面動畫展現了這個過程：

啓用流程與關閉流程同樣： 預啓用，主機級啓動，啓用後。使用自動化，咱們能夠安全的在機架或多個機架級執行常規維護，並能夠最小化地影響其餘的工程團隊和使用Facebook的人。

與人交互：當自動化不可行（或失敗）

儘管咱們的目標是自動化全部要在咱們基礎設施上進行的維護工做，有些時候仍是須要人工接入來保證維護能夠安全進行。

起飛檢查失敗或沒有自動化

在一些場景，定時任務可能可能會影響很大一批服務器，起飛檢查會就拒絕自動化執行維護。咱們的自動化故意設置得比較保守，並在可能產生大範圍影響的時候使用手動控制。在另外的狀況，因爲可靠性的緣由或服務處於降級狀態，此時自動化尚未被實現或者被暫時關閉，咱們但願防止自動化變動。

失敗自動化

儘管咱們調用Aggregate Maintenance Handlers時有很高的成功率，仍是有一些狀況會出問題。當故障發生時，咱們的維護進程會通知服務的負責人自動化失敗了。當他們人工確認主機已經被關閉了，維護動做才容許繼續進行。

混合自動化與手工工做

爲了幫助協調自動與手動的進行，咱們開發了Dapper，一個被不少團隊(如，數據中心團隊，技術經理，基礎設施工程師，產品工程師)使用經過提供影響描述並用於調度維護工做的工具。

Dapper的維護執行工做流以下：

學到的經驗

咱們從早期的自動化單主機修復到機架和多機架學到了一些經驗。

關閉邏輯的串行執行

一次關閉一個主機有兩個很差的負面影響。第一是在維護期間可能在某個時間點引發容量不夠，致使維護工做須要被中止直到人工介入：

更差的是，當服務的交換邏輯是在同機架上重用主機時，咱們可能會意外的將主機從新上線到生產環境，或最佳狀況，進入了無限循環：

關閉邏輯的並行使用

相對於一次單個執行，並行進行交換主機能夠防止串行方式的一些問題，但會引入其餘問題。最多見的問題是並行調用單機邏輯可能在獨立操做尋找替換主機時形成條件競爭，但聚合結果可能會形成服務容量不足：

擴展自動化

Dapper和Aggregate Maintenance Handlers提供的框架已經從物理維護工做，擴展到包括軟件發佈/內核/BIOS/OS升級時關閉和啓用主機。

工做在Dapper的產品工程師對進一步擴大自動化和開發工具幫助Facebook工程團隊下降運維工做的成本，幫助他們解決更大更有挑戰性的問題充滿激情。

瞭解更多 FBAR和Aggregate Maintenance Handlers的內容，能夠看這個演講。

---

本文來自微信公衆號「麥芽麪包，id「darkjune_think」轉載請註明。交流Email: zhukunrong@yeah.net