リスク

　○○というリスクが顕在化した場合■■なる被害がある。これを軽減するための手順は＊＊で、費用は□□で、軽減度はhogeだ。このリスクを回避するためには…とまあリスクマネジメントの手順みたいなものがあるわけだが、これはこれで字面通り運用するにはなかなか悩ましいことが多い。
　サーバのクラスタリングとか、データの配置などの要素を考えると、「機器の二重化」以上のハードルが、「サービスの二重化」もしくは「サービス設備の二重化」にはあるように思える。セッションレプリケーションが注目を集めるのもこういう点もあるんじゃないかな。
　あるコンテンツダウンロードの仕掛けで

• コンテンツそのもの(数GB)はどのサーバに置くか,もしくはどちらにも置くのか
• コンテンツのダウンロード履歴・ユーザ管理はどこに置くのか
• Webアプリケーションはどこに置くのか
• etc...

　とまあ、そりゃいくらでも「配置物」はあるわけだが、それぞれをどこに置くとこういうリスクがあって・・・と本来ならがっつり洗い出すべきだが、なかなか定量化の難しいところもある。ある配置物が使えなくなったときにサービスに対してどれぐらいのダメージを与えるか、というあたりで「発生した場合どうこう」というのは言えるが、発生確率の見積りが難しい。まあ、MTBF,MTTRの見積りにしても同じことで、このへんを定量化して、かつ"ちゃんとした理由"を持つにはベンダーの協力が不可欠なわけだが、残念、ここで議論している例の対象サーバは、いい加減なラックサーバーにLinuxという組み合わせ。このへんで「こっちのサーバーだと破損確率はhogehogeです」と定量的に説明するのはなかなか難しい。
　こうなると、発生確率は均等と定義するしかない。確率はとある定数として、リスク軽減策、回避策を練ることになる。細かい手法は『熊とワルツを』などの名著に譲るとして、上記のような「いい加減なケース」の場合だと、軽減策として理路を保つにはどうしたらいいのか…。
　確率をケース間では共通と定義しているので、「比してあきらかに確率が減らせる」ケースでないと、回避策(確率軽減)は定義できない。たとえば電源の二重化を計ればまあ、前より故障率は減らせる、とか(いや、そうでもないかもしれないが)。
　回避ではなくて軽減策としては、例えば読み出し専用コンテンツについては分散して配置する、とかが考えられる。ホットスタンバイとコールドスタンバイの別もこの例に含まれる。ホットなほうがダメージは小さい。ましてや、もともとクラスタリングに参加して負荷分散状況で稼動しているほうがさらにダメージは小さい。
　対策を打ち出すのに「お金」「時間」がかかる以上は、その他のバリューも数量化されていることが理想だ。しかし明確に定義できないケースも世の中にはたくさんあるような気がするなあ。定義しようと努力していないだけだ、と言われるかもしれないな。

　ちなみに上記の例は適当に数値をでっち上げつつ資料を作成してもらい、稟議も通ったらしいが ;-P

　ま、いかにも日記らしいとりとめのないメモだな。