戻る

障害と可用性

コンピュータシステムの信頼性

コンピュータシステムの品質は、次の三つの頭文字をとってRASと呼ばれます。

信頼性(Reliability)
故障するまでの平均間隔MTBF (Mean Time Between Failures)で表します。
	       総稼働時間
	MTBF = ----------
	       総故障件数
可用性(Availability)
予定されたサービス提供期間に、実際にサービスが利用できる期間の割合である稼働率で表します。
	            MTBF
	稼働率 = ------------
	         MTBF + MTTR
保守容易性(Serviceability)
故障が発生してから通常のサービス提供までに掛かる平均期間MTTR (Mean Time To Repair)で表します。
	       総修理時間
	MTTR = ----------
	       総故障件数

RASに、保全性(Integrity)と機密性(Serurity)を加えて、RASISと呼ばれることもあります。これらは古くからある指標であって、ハードウェアのメンテナンスがベースとなった考え方ですが、ハードウェアのコスト減少と信頼性の向上/ソフトウェアのコスト増大/使用目的の多様化によって、ソフトウェアに対する信頼性の要求品質が高まっている今でも、RAS/RASISの考え方は信頼性の指標になります。

信頼性の高いシステムとは、故障間隔MTBFが長く、修理期間MTTRが短いシステムです。言い換えると、問題が発生せず。問題が発生しても短期間に回復するシステムだといえます。そのためには、開発中にバグを作り込まず、障害発生を減らし、発生しても影響度を低く押さえ、原因を容易に解明できて、修正範囲を最小限度にとどめ、修正をすばやく実施することが必要になります。

何よりも大事なことは、バグを作りこまないことで、できれば設計段階で潰しこみ、開発段階でも新しいバグを作りこまないようにすることです。後工程にバグを持ち込むと、実際に発生してしまってから対応することによる負荷は莫大なものになります。

システム障害の分類

システム障害にも重要度に応じたレベルがあります。

本番稼動後の障害

まず、ライフサイクルに応じて重要度が異なります。サービスイン前とサービスイン後では、まったく重みが異なり、影響/対応も異なります。開発中であれば、ユーザへの影響はありませんし、他チームに影響を掛けずに修正可能かもしれません。大規模プロジェクトでは、開発中でも、本番並みの問題管理/変更管理/構成管理を経ることになり、納期が迫っている場合は、修正後の稼動確認テストの期間が問題になりますが、クライアントのクライアントに影響を及ぼさないという点で、再現テスト/修正コードのリリースなどが比較的自由に行えるでしょう。

一方、リリース後の障害は最悪です。最悪ですが、特にリリース直後は頻繁に発生します。リリース初期段階で発生するようなプリミティブなバグは、テスト期間に潰しておくことが理想なのですが、納期の短縮化やコスト/開発体制の関係で、本番同然のテストが十分にできることは稀だといわなければなりません。大規模なシステムになればなるほど、テストの対象項目は多岐に渡り、本番同然の環境で全てを網羅することはできなくなります。

業務別の障害

システムで稼動している業務によっても、最悪の障害は異なります。顧客情報を扱っているようなデータベース中心のシステムであれば、最悪なのは個人情報漏洩とデータ破壊です。プログラムの異常終了、システム停止は最悪とはいえません。銀行のATMが止まることよりも、口座のデータが破壊/改竄されること、個人情報が漏洩することの方が深刻です。一方、製造系/運輸であれば、制御系の停止/誤動作が最悪でしょう。溶鉱炉の停止、原子炉の暴走や緊急停止、空港の管制システムの誤動作などは、企業の死活問題であり、生命の危険にも直結します。

故障率のバスタブ曲線

リリース直後の故障頻発期間を初期故障期間と呼びます。初期故障期間から偶発故障期間を経て磨耗故障期間にいたる故障率の曲線を、バスタブ曲線(図1)と呼んでいます。MTTR, MTBFと同様に、バスタブ曲線もハードウェア/機器の故障に対する解析に由来していますが、コンピュータ・システム全体の信頼性を扱うためにも大事な概念です。

バスタブ曲線
図:バスタブ曲線

障害対応

実際に障害が発生したときに重要なことは、早急に解消して、通常のサービスの提供を再開することです。そのためには、発生後の対策が事前に準備されていることが重要です。起こるかもしれない障害は、負荷の高い大規模システムになればなるほど、いつか必ず起こります。 障害対応のプロセスは、まず、発生を検知するところから始まります。プロジェクト/運用管理用のプロセスには多くの種類がありますが、概ね次のプロセスが関係しあいます。

まず、通常のサービス提供を阻害するイベントが発生すると、インシデントとして登録して、既存障害かどうかを確認し、新規であればその進捗を管理します。インシデントの根本原因の解析は問題管理が受け持ちます。問題管理は障害資料を採取し、問題を切り分け、原因を解析し、解決策を策定します。構成/変更管理は、コード修正によるレベルや初期設定パラメタ、サイド・エフェクトや前提条件を確認して、リリース計画を管理します。インシデント管理は、その後のトラッキングやユーザやクライアントへの報告/オブジェクション・ハンドリングを含めて、登録したインシデントをクローズします。

セキュリティ上の障害であれば、コンピュータ・セキュリティ・インシデント(Computer Security Incident)として、単にインシデントを解消するだけでなく、被害の見積もり/その後の社会的対応まで含まれます。

これらのプロセスは、何も生産しないにも関わらず、莫大な労力と時間が費やされます。最善なのは、開発中に全てのバグが潰しこまれて、本番には持ち越されないことです。しかし、障害は日常的に発生するものであって、これらの管理プロセスがないと、その対応は後手になり、被害が広がり、回復のために莫大なコストが必要になり、最悪の場合、手遅れになることもあります。

大事なことは、設計/開発中にバグを作りこまないこと、障害発生時に耐えられる冗長構成にしておくこと、全面障害を含めた障害発生時の対応をしっかり作っておくことに尽きます。

戻る

Copyright 2004 SUGAI, Manabu. All rights reserved.
SEO [PR] !uO z[y[WJ Cu