おはようございます!

ようこそ当ブログへお越しくださいました。
いろいろなものを取り扱っております。

もしよろしければ兄弟ブログ「単身という立場の楽しみ方」もお立ち寄りください。


兄弟Blog「単身という立場の楽しみ方」(しーのBLOG)最近の記事

RSS表示パーツ




上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
web拍手 by FC2
このエントリーをはてなブックマークに追加
--.--.-- -- l スポンサー広告 l top
単身赴任者が帰省しているとき、
概ね、飲みに出ているってのは如何なものか・・・と思いつつ、
今日も飲みに行ってしまい、帰宅がこんな時間。
まぁ、許していただける寛容な家族に感謝・・・

先日、クラウドに関する記事を書いてみましたが、
みずほ銀行の不具合問題の記事をいろいろ見ているなかで、
面白い記事にたどり着きました。

杞憂?クラウドで展開されるシステムの障害が企業活動の息の根を止めたりしない?
配信元:オルタナティブ・ブログ

私ごときが言う話じゃないとは思うのですが、たとえば何であれ関係者が増えてくると当然その間の連携というのは難しくなります。それでもモノゴトをある程度分散させる事を決意した時点で、誰かがその全体調整をする必要があります。あるいは全体が複雑さを増せば増すほど全体調整という機能に対する負荷が上がります。

いわば、統括ディレクターが必要になるわけですが、なんだか諸々の動きを見るにつけ、本当に大丈夫なのかなぁ?と言う気持ちが時々沸いて来ます。現状私は厳密にはIT業界の人ではありませんので、現在の色んなサービスやら何やらの提案活動、開発、そして運用の本当のところを理解しているわけではありません。ただ、自分の仕事の範囲から見てもちょっと大丈夫?見たいなところが見えることがあって・・・

想定外の状況は必ず起きる。問題はあわてずに対処できる訓練を受けているか

自分が今でも時々関わる展示会やセミナーを含めたイベント事の場合、事前の準備というのは基本的な流れを全部運営マニュアルに落とし込み、現場で必要とされるリソースを全て事前に用意し、それらがキチンと機能するかどうかを検証するという部分が非常に大きなウェイトを占めます。その中で例外対応として考えられるものは全て明文化し、現場に入ればそれぞれの持ち場がマニュアルに従って基本的な運営、そして想定される例外事項への対応を行うのですが、もちろん例外の例外が起きることは稀ではありません。そうなると、どういうパスでエスカレーションし、誰がどの時点でどういう判断をするかというのを決めます。

上手く行って当然。
でも、想定できる限りの例外は想定しておく。
でもでも、本当に例外の例外が起きたときの判断レベルはキチンと規定しておく。

状況にもよると思いますが、基本的な考え方はイベントの種類や規模の大小に関わらず同じだと考えていますし、実際にそういう風に信じるに足るだけの経験はしてきたつもりです。とはいえ、100個の例外を考えていても101個目の例外が出るのが本番です。

で、此処で大事なのは、何があっても現場の基本的な運用を止めず、全体への影響を最小限にしながらも迅速にトラブルに対処するということ。

更にそれだけではなく、実はスタッフの全員が「想定外の事態は起きるものだ」という心構えだったりします。そこが共有でき、かつ実際にそういう修羅場をくぐったスタッフがいる現場っていうのは、何が起きても絶対に大丈夫、という安心感があるものです。

ただ、規模の大きさや広がりによっては収拾がつきにくくなる場合もあるわけで

これは当然です。ある一定の許容範囲以上に連絡経路が増え、連絡のためのパスが長くなるとどうしても収拾が付かなくなりがちです。これは組織論の基本ですが、それでもどうやって全体を機能させるか。これが問題。

これをどうやってマネージするかはそれぞれの組織体が決める事ですが、余りに強引とは言え、この辺りの事情を社外のクラウドに色んなアプリケーションを分散させるような環境に当て嵌めた場合、何が起きるんだろうなぁ?と色々と考えたりします。

もちろんそれぞれのサービスプロバイダーが万全の障害対策をやっていますから大丈夫ですよと言うのは当たり前だと思いますが、それでも障害が起きたときにどうするのかといった話をする、そういった資料を公表している提供元ってどれくらいあるんだろうか?と思ったり。

あるいは、ユーザー側としても社外のリソースが障害を起こして利用不能になり、たとえばそれがある一定の期間継続してしまうような状況に陥ったときにリカバリーできる手段を検討し、かつそれを訓練してるのかとか思ったり。

クラウドに限った話ではないですから当たり前なのですけれど

たとえば情報処理のためのリソースを全部中で持つという、ある意味伝統的な情報処理環境であっても、大規模な障害が起きると当然何かしらの影響は出るわけです。で、その障害に対応するためにどの程度の対策を普段から行い、たとえば障害発生時の縮退運転などにおける運用訓練とか、バックアップからデータをリロードしてアプリケーションが最終的に復活するまでの一連の流れを、机上のシミュレーションだけではなく実際に訓練として定期的に実施しているケースってどれくらいあるのだろうかとか・・・

で、この辺りの極端な例で言うと、日本時間の4月6日にスペースシャトルが上がりましたが、たとえばコレを打ち上げるためのプロジェクトの中で非常に多くのプレイヤーが役割を果たしているわけですよね。クルーの乗船は数年前から決まり、個々のクルーは本来持つミッションとは別にありとあらゆる事態に対処できる訓練を受けるわけです。そしてその多くが「好ましくない状況が起きたときの対応」を目的としているという話は色んなところで紹介されています。

非常に規模の大きな複雑なシステムは必ずそこらじゅうに脆弱性を抱えているわけで、全体が完全に動いている状況を前提としつつ、何が起きても対処できる状況がないと、最終的には地上に戻って来れないという、本気でクリティカルなミッションな訳ですよね。

これは余りにも特殊な例かもしれませんが、それでも何かが起きるのを前提として備えるという基本的な考え方自体はあらゆることに応用されるべきなんじゃないかとは思います。もちろん「そんなのお前に言われる筋合いのものじゃねぇよ」と言うお話があれば、それはそれで正しいのですが。

トラブルが起きないための最大限の対策、ではなくトラブルは起きるという前提での運用継続対策

BCPというカテゴリーにおいての運用継続(というかこれは事業継続ですが)というコトは良く語られると思います。ただ、システムはダウンするものだという前提でどれほどのものが現在利用されているのか、運用されているのか、そして実際にはダウンするんだけれどユーザー向けのサービスを可能な限り(実はココが大事ですが)止めないための実際の訓練を含めた対策をやっているのか。

このあたりの情報で言うと、たとえばGoogleのセンターは山のようにあるサーバーが非常に特殊なOSで動いてるわけですが、落ちるときは落ちるんで、そのときは裏側でどこか別の空いているリソースに切り替えて後で修理するんですよという主旨のインタビュー記事を見たことがあります。

もちろんそんなのGoogleしかできないよって話もあるでしょうし、いや、Googleとは違うアプローチでやっているのだよって話もあるんだとは思います。たとえば実際私が勤務する通信事業者の場合、もちろんいろんな事は起きるのですが、それでも最大限ユーザー向けのサービスは継続できるような仕組みがあり、運用体制から何からがあるのが基本だったりはします。

ふむ、でも、実際にはどうなんだろう?万全の障害対策に関する資料は幾つも見たことがありますが、障害対応状況などについて公表しているところってあるのかな?あるしても、どれくらいあるのかな?どんな情報を公表してるのかな?これが公表されちゃうと、それぞれのスキルレベルまでわかっちゃいそうですが・・・ あるいはそれがあればプロバイダーごとに格付けとか出来そうだけれど・・・



まぁ、いずれにしても現在は純粋IT業界の部分についてはシロウトも同然だし、例えが変なのも重々承知。ということで何だか各方面に対しては大変申し訳ないのですが、ちょっとだけそんな事を考えてみたりしています。



これは2010/04/08の記事。
一見あたりまえの様な感じも受けますが、当たり前のようでリスク管理の原点が明快に書かれていると思い、引用させていただきました。

みずほの話にしても、原発の話にしても、一生懸命考えていても想定外のことが起きる。
それを踏まえたうえで、どうするかを考えるべきなんでしょうね。

地震の際のマニュアル・・・今回の地震でどれだけのマニュアルが役に立ったでしょうか。
1000年に一度、されど1000年に一度。
今回の地震は、日本に大きな「きっかけ」を作ってくれた・・・という解釈をしてはダメですか?


関連記事
web拍手 by FC2
このエントリーをはてなブックマークに追加
2011.03.26 Sat l IT的な情報 l コメント (0) トラックバック (0) l top

コメント

コメントの投稿












トラックバック

トラックバック URL
http://tanshinbutsuyoku.blog.fc2.com/tb.php/68-2b1c9a85
この記事にトラックバックする(FC2ブログユーザー)
ブログパーツ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。