Facebookのエンジニアリングチームは、Facebookで使用されており、データセンターで高度なハードウェア可用性を維持する助けとなるさまざまな方法論について書いている。
Facebookは、世界中の15の地域にデータセンターを持ち、定期的に拡大している。ネットワークを含むインフラストラクチャのプロビジョニングが自動化されているため、このようなことが可能となる。ハードウェア障害は、この規模のもを想定しており、Twine（以前はTupperwareとして知られていた）と呼ばれるFacebookの内部クラスター管理システムによってある程度軽減される。Facebookが高度なハードウェア可用性を維持するのに役立つ4つの観点がある。これらは、アプリケーションのパフォーマンスに大きな影響を与えることのない、検出と修復、監視と軽減のためのシステムである。これには、異常を予測するためのML技術を使用した、自動化された根本原因分析（RCA）システムを使っている。これらの4つの観点は、Facebookのエンジニアによって個々の論文でも詳細に説明されている。
Facebookの検出・修復システムは、サーバログを分析するMachineCheckerツール、Facebook Auto-Remediation（FBAR）、Cyborgで構成されている。MachineCheckerチェックには、「ホストping、帯域外（OOB）ping、電源ステータスチェック、メモリエラーチェック、センサーチェック、セキュアシェル（SSH）アクセス、ネットワークインターフェイスカード（NIC）速度、dmesgチェック、S.M.A.R.T.チェック、電源供給チェック」がある。このチェックでは、中央システムでアラートを作成し、FBARがカスタマイズ可能なスクリプトを実行して修正を試みる。ほとんどがPythonで記述されているため、FBARは新しいシステムではない。FBARは約10年前から存在しており、改善されてきた。Cyborgは下位レベルのチェックを実行し、修復が失敗した場合は手動介入のチケットをログに記録する。ワークフローの一部として、FBARとCyborgの両方がMachineCheckerを再実行して、障害を確認する。ある講演によると、「94％のアラームは人間の介入なしに解決される」。
論文の著者は、一時的な性質のために見逃される可能性のある障害があると述べている。このような障害には、高負荷がトリガーなった障害がある。この障害は、負荷が軽くなると消えるため、MachineCheckerを再実行しても検出できない。これを回避するために、CPU、メモリ、ネットワークに合成負荷を作成することを提案している。
一般的なハードウェア障害はCPU割り込みを引き起こし、アプリケーションのパフォーマンスに影響を与える可能性がある。著者らは妥協案を採用することを提案している。それは、ハイブリッドアプローチによって、パフォーマンスに影響を与えることなく精度を維持するために2つの異なる方法を利用するものである。
新しいハードウェアとソフトウェアの構成は、自動修復システムを新しいルールで随時更新する必要があることを意味する。一部のチケットは未診断または誤診断としてマークされる可能性がある。それは、新しいルールでシステムを更新することと、新しいソフトウェアおよびハードウェアが展開されることとの間にギャップがある場合である。これを回避するために、チームは、現在のチケットに対して「過去に障害がどのように修正されたかから学習し、どのような修復が必要になるかを予測しようとする」機械学習フレームワークを構築した。MLモデルの入力データには、MachineCheckerチェックから収集された障害信号、サーバメタデータ、およびサーバの最近（約6か月）の修復チケットなどがある。
グループの最後のツールは、サーバのハードウェアログをソフトウェアおよびツールのログと関連付けるRCAシステムである。パターンマイニングアルゴリズムを使用して、数百万のログエントリ間の相関関係を見つける。
Facebookには、ここで説明したものとは別に、Maelstromのようなさまざまなレイヤーのスタックでの停止を軽減するための他のシステムがある。