推ter的故障處理機制：故障測試

對于推ter這樣的基礎設施規模，硬件和網絡錯誤是不可避免的，但無論是哪一種錯誤都可能對用戶體驗造成消極的影響，因此對一個系統而言彈性的錯誤處理能力是非常重要的，那么推ter是怎樣做的呢？最近推ter基礎設施工程團隊的負責人 Mazdak Hashemi 在官方博客上發表了一篇文章，介紹了 推ter的故障測試機制 。

為了測試服務如何響應異常，推ter創建了一個能夠將受控的故障條件注入到基礎設施中的框架，通過該框架推ter能夠發現漏洞，從而更好地為全站范圍內的事件處理做好準備，保證系統對意外故障具有較好的容錯性。

框架

推ter的故障測試框架由一個Python類庫和一個命令行可執行程序組成，通過該框架工程師能夠將故障條件直接引入到產品基礎設施中，然后能夠在測試執行期間監控全站范圍的健康指標，并在狀態發生變化的時候發送系統通知。

該框架包含三個模塊：

• 故障引入（Mischief）模塊，在產品服務和基礎設施中引入或者撤回故障測試
• 監控模塊，檢查 服務的健康指標 ，查找可能導致全站范圍事件的狀態
• 通知模塊，與HipChat和JIRA等系統交互，在故障測試執行期間提供實時的狀態更新

到目前為止，框架支持的故障條件包括：

• 發送命令給IPMI控制器和PDU的功率損耗
• Mesos 中服務集群的部分或者全部丟失
• 推送新轉換配置造成的網絡丟失

下面是一個介紹工程師如何使用框架測試故障條件的示例，該示例為abc機架上的所有Hadoop DataNode引入了一個30分鐘的功率損耗，然后監控健康指標并向聊天室發送狀態更新：

failure_test:
  name: Power loss within rack abc in datacenter abcd
  duration_mins: 30

  mischief:
    - power_loss:
        datacenter: abcd
        selectors:
          - group:
              type: role
              name: hadoop.datanode
          - group:
              type: rack
              name: abc

  notifiers:
    - chat:
        rooms:
          - Failure Testing

  monitors:
    - observability:
        datacenter: abcd
        queries: !snippet

將這些配置發送到框架的命令行工具上之后，框架首先會解析這些配置，確認其有效性。接下來框架會進入準備階段，收集引入故障條件所需的所有信息，例如目標機器的主機名和IPMI BMC接口的地址等。準備成功之后，框架會檢查需要測試的所有系統是否健康，并嘗試引入請求的故障條件。如果條件引入成功，框架就會定期地（每分鐘）檢查監控，確保測試期間所有系統都運轉正常，如果這期間有任何一個監控發送了錯誤的狀態，那么測試就失敗，否則測試就成功。但是無論是成功還是失敗，框架都會在測試執行完成之后立即取消引入的所有故障條件。

完整的流程圖如下：

挑戰

推ter運行的基礎設施具有異構且動態的特性，所以在為一個具體的服務引入故障測試時需要細心的設計和計劃，考慮要全面。例如，托管在Apache Aurora上動態調度的服務與直接運行在硬件設備上的服務不同。為了找到引發異常的真正原因，必須捕獲完整的測試環境，包括機架配置、服務類型以及流量等信息，因為在某些情況下，異常可能是由上游或下游的問題，或者是服務恢復行為引發的。

使用情況與經驗教訓

在過去的6個月，這一框架驅動了推ter所有的故障測試，幫助推ter發現了大量的漏洞，讓推ter對 Apache Mesos 和 Apache Aurora 等主要系統的彈性故障處理機制有了非常強烈的信心。

另外，推ter還總結了一些經驗教訓。例如，從機架頂部開關損壞的故障中總結出：當這種情況發生的時候，運行在該機架上的服務要么全部從網絡上丟失，要么丟失部分包，對于前一種情況推ter的服務能夠很好地處理，但是后一種情況卻幾乎總是會造成某些內部的影響，這種影響的嚴重程度取決于機架的配置和Mesos從機上運行的服務種類。

未來的工作

推ter將繼續使用該框架測試基礎設施對隨機故障的處理能力，找到系統的瓶頸。同時，故障測試程序的范圍也會增加，將來擴展RPC系統層也將支持這種機制。