絶対にダウンしない情報システムの開発を狙うよりも，素早く障害から復旧するシステムを構築するほうがはるかに現実的である。とりわけビジネス上で重要なシステムの復旧に失敗は許されない。我々は，複数の防御ラインを設けてシステム障害をマネジメントすることを推奨する。
パソコンではよく，クラッシュやフリーズが起こる。Webサイトは，最もアクセスしたいときに用をなさなかったりする。問題なく動いていたシステムが，アップグレードによって使えなくなるのはよくある出来事である。オペレータによってシステムが混乱に陥る事態にも，しばしば出会う。
システムを安心して使えるようにするための改善の余地が，ソフトウェアにはかなり残されている。大規模ソフトウェアを稼働させるときに，システム・マネジメントのコストがTCO（総所有コスト）の大きな部分を占めることはごく当たり前である。マネジメントのコストの大半が，障害の発生を防ぎ，障害を管理するために費やされている。
ネット・サービスを対象に研究
米スタンフォード大学と米カリフォルニア大学バークレイ校は，障害からシステムを迅速に復旧させる有効な手法を研究するプロジェクト「リカバリ指向コンピューティング（ROC:Recovery Oriented Computing）」を共同で進めている。ROCのメイン・ターゲットは，インターネット・サービスである。なぜなら，インターネット・サービスではチャレンジングな試みが続けられ，しかも急激な拡大が見込まれているからだ。
例えば米Google社のサービスを考えてみる。Googleは，世界中に10万カ所を超えるコンピュータ・ノードを抱え，今も拡大を続けている。ソフトウェアを毎週アップデートするのは普通であり，1日のうちでも負荷の重さは大きく変動する。こうした環境のなかで，Googleは週7日，1日24時間無休でサービスを提供しなければならない。インターネット・サービスから学んだものの多くは，デスクトップや小規模ネットワーク・サービスなどのコンピューティング環境にも適用できることは間違いない。
我々の研究は，コンピュータの信頼性に関する膨大な調査がベースにある。特にDaniel SiewiorekとRobert Swarzの著書は有名で，すでに第3版が出版されている＊1。しかし我々は，急拡大を続けるインターネット・サービスの環境に対応するために，彼らとは異なるアプローチをとった。ROCの研究は，ソフトウェアは不可避な問題を抱えていることを前提にしている。すなわち，原因不明のバグ，複雑なアーキテクチャ，うっかりミスや過失を犯しがちなオペレータ，予想できない過負荷などである。障害は現実問題として避けがたい。したがってROCは，障害発生時に素早く復旧できるシステムを構築することに重点を置くことにした。
具体的には二つのビルディング・ブロックを組み込み，復旧とマイクロリブート（Microreboot），システムレベルでのUndo（やり直し）を実現し，故障に対応する上で極めて有効であることを示した。また，システムの信頼性に対する効果を定量化するためのベンチマークも開発した。
リカバリ指向の設計概念：復旧時間の短縮に注力
システムの稼働率は，MTTF（Mean-Time-To-Failure，平均故障時間）とMTTR（Mean-Time-To-Recover，平均復旧時間）を用いて次の式で定義される。
Availability=MTTF/（MTTF+MTTR）
過去10年間にわたりMTTFを長くするために行われた努力を考えると，MTTFを無限大にする（絶対に故障しない）ために苦労するよりも，MTTRを限りなくゼロにする（つまり復旧時間を非常に短くする）ように努力することによって稼働率を100％に近づけるほうが容易だと言えるだろう。すなわち，次のように考えることができる。
lim(Availability)=100%
MTTR→0
もちろん，復旧は早いだけでなく正しくなければならない。しかしソフトウェアと同様，復旧のメカニズムにも完ぺきなものは存在しない。したがってリカバリ指向システムでは，相互に行き来できる複数階層に復旧レベルを設けて，徹底的に自分自身を守る必要がある。復旧のメカニズムは，二つの軸に分けて考えることができる。すなわち，復旧にかかるコスト（Cost of recovery）と復旧可能な故障の割合（％ of failure cured）である。この座標軸で，我々のアプローチを位置づけると図1[拡大表示]のようになる。
ROCプロジェクトがカバーする範囲は，システムにおける不具合の検出と復旧法だけではない。実際に発生したシステム障害に関する調査も含んでいる。3年間にわたるROCプロジェクトから，我々は将来のシステム設計に役立つであろう四つの法則を学んだ。
法則(1)システム状態の確保が最優先
障害からの復旧とは，障害時に実行していた処理を再開できる状態にまでシステムを戻すことを意味する。ここで重要なのがシステムのステートである。ステートとは，処理のためにプログラムが使う，すべてのデータの集まりを意味し，どういった処理ができるかを決定づけるものである。ここでいうデータは，リモート・サーバーのデータベースに存在したり，ファイル・システムに含まれていたり，メモリーに格納されていたりする。復旧に要するコストは，システムのステートを元に戻すまでにかかる時間と，復旧するまでに失われるステート情報の多寡で決まる。
例えば単純なWebサーバーは多くの場合，読み出し専用ファイルからデータを取り出して要求に応えるという仕組みを採っている。つまりステートレスである。この場合にサーバーは，個々のHTTPリクエストについてのステートを保持する必要がない。したがって，サーバーを安全に再起動することができる。再起動後のHTTPリクエストは，サーバーが再起動されたかどうかについて関知しない。
一方OSは，アプリケーションを実行するために，さまざまなステートを読み出し変更を加える。ステートを捨てることは，システムが使えなくなることを意味する。つまりOSは，きわめてステートフルなプログラムである。Windowsレジストリが破壊された場合，OSやアプケーションを再インストールして復旧することになる。膨大な数のステートを再構築するために，数時間から数日もかかってしまう。
信頼度の高いシステムのほとんどは，なんらかのロールバック機能を備えている。システムのステートを復元するために，ステート・チェックポイントあるいはアクティビティ・ログを用いる。ロールバックはコストがかかる手法なので，プログラム・ロジックからできるだけ多くのステートを保護することが重要になる。
信頼性は，アプリケーション・ロジックとデータ管理の分離の度合いを高めることで向上できる。プログラムは高レベルなインタフェースを介してデータにアクセスする。データベースの発明者はこの性質を10年以上前に気づき，信頼性を高めた。
法則(2)負荷を分散する
復旧に影響するもう一つの要素は，システムが実行する作業量である。設計者が作業負荷を互いに独立な小さな単位に分けることができれば，障害からの復旧を早められる。少数のステートだけを再構築すればよくなるからだ。
例えば，先に挙げたシンプルなWebサーバーを考えよう。こうしたサーバーを再起動する場合，失われるステートは再起動のときに実行中だったHTTPリクエストだけである。ステートレスというHTTPリクエストの特徴は，クライアントのリトライ機能と組み合わせることで，正確かつ迅速な復旧を可能にする。
法則(3)プラットフォームに復旧機能を
本論文で紹介するROCのプロトタイプは，アプリケーションではなくプラットフォームで復旧処理を実行する。若干難しい部分もあるが，現時点だけでなく将来にわたって多くのアプリケーションに適用できる利点を備えている。
法則(4)可観測でないものは改良不能
ROCプロジェクトの重要な目標の一つに，システムの信頼度を定量的に評価するベンチマークを作ることがある。システムを動かす人だけでなく，システムを利用する人にとっても有効なものを目指した。ベンチマークを作成する過程で，システムのどこに脆弱な部分があるのかを学べた。
作成したベンチマークはシステム設計にも大いに役立った。つまり，定量的に評価可能な復旧技術とプログラム作成能力が身に付いたし，こうした能力を現実のシステムに適用する自信を深めた。
マイクロリブートコストのかからない復旧法
復旧処理の第1弾は，障害を解決する確率が高く，低コストで低オーバーヘッドでなければならない。もし期待通り機能しなかったときにも，適用したことによるコスト損失が少ない必要がある。
再起動は，ソフトウェア・エラーに対する復旧法として一般的である。障害の正確な原因が分かっていないときにもよく利用されている。再起動は，リソースにリークが生じた場合などに最も着実な方法だ。システム管理者は対象とするシステムのソフトウェアが応答しているか否かにかかわらず，再起動を試みることができる。再起動は実装や自動化がやりやすいし，最も分かりやすく，最もテストが簡単な初期状態にソフトウェアを戻す。したがって我々は，強制再起動を復旧法の最有力候補と考えている。
不測のクラッシュからの復旧は，広範囲にステートの再構築が必要なときに時間がかかる。さらに，クラッシュに対する安全対策がとられていないシステムでは，予期しない再起動によってデータが消滅する可能性が高い。
