究極の選択――落ちないシステムとすぐ直るシステム：ITIL Managerの視点から（1/3 ページ）

MTTR（平均修理時間）が短いシステムとMTBF（平均故障間隔）が長いシステム、あなたならどちらを選択するだろうか。システム管理者にとっての究極の選択である――。

[谷誠之，ITmedia]

　SLAで合意しておくべき項目はさまざまだが、その中でもビジネスの継続的な活動に大きな影響を与えるのが、可用性に関する項目だろう。

　ウィキペディアでは、可用性は次のように説明されている。

可用性（かようせい）とは英語のAvailability（アベイラビリティ）の訳語で、システムが継続して稼働できる能力のこと。（後略）

　これを見れば、システム管理者やIT運用者にとっては当たり前のことしか書いていないような気がする。しかし、この「システムが継続して稼働する」という言葉には、大きく次の2つの意味があることを忘れてはならない。

• システムが壊れても、すぐに直せること
• システムが壊れにくいこと

　「壊れにくいこと」と「壊れてもすぐに直せること」は、原則として完全に独立している。まったく別物、と考えても良い。目指す目的は同じだが、手法や活動の手順などはまるで異なるからである。

　ここで、それぞれの原則に欠かせない、2つの指標を紹介する。これらの指標は情報処理試験の午前の問題に出てくるし、システム管理に携わる人であれば、目にしたことがあるだろうと思う。

MTTR（Mean Time To Recovery）

　MTTR（Mean Time To Recovery）は、平均修理時間、と訳される。障害が発生してから復旧するまでにかかる平均時間のことである。障害のためにシステムが使えない時間のこと、すなわちダウンタイムである。

　もっと単純に言ってしまえば、「壊れた時にどれだけ迅速に直せるか」ということであり、可用性を考える上での「システムが壊れても、すぐに直せること」に直結している。決して現実的ではないが、MTTRのことだけを考えれば、システムが壊れてもそれを1秒以内で直せて元のサービス可能な状態にまで戻せるのであれば、システムは何度壊れたってかまわないわけである。

　可用性を高めるためには、MTTRを減らす努力が必要である。MTTRを減らすための方法には、次のようなものが考えられるだろう。

• 障害が発生したら即座に管理者に知らせるようなツールを導入する
• 可能であれば、自動的に障害を復旧するようなツールを導入する
• 障害箇所の特定をするための手順をマニュアル化しておく
• 障害箇所の修復を行うための手順をマニュアル化しておく
• スタッフを教育し、障害が発生した時に迅速に動けるように体制を整える
• 修復やメンテナンスが容易な機器に買い換える
• よく壊れる部品は、常に交換部品を手元に置いておく
• 予備のネットワーク回線やサーバシステムなどの準備をあらかじめ用意しておく

　さらにこのMTTRは、狭義の「可用性」という言葉に関係する。広義の「可用性」は前述の通り「システムを継続して稼働させる」ことである。それに対して狭義の「可用性」とはシステムがどれだけの時間使えているか、すなわち稼働率のことである。例えばSLAによって合意した「単位期間あたりの稼働時間」が100時間であり、そのうち故障で30分間使えなかったとすれば、稼働率は次のように表せる。

99.5時間÷100時間＝99.5％