http://availability.livedoor.biz/ ニュース、トピックス、日々の雑感など。 ja http://availability.livedoor.biz/archives/50208162.html 　このブログは高可用性、ディザスター・リカバリー、業務継続、クラスタなどの高可用ソフトウェアについて、ニュースなどのインターネットリソースをブログ形式で提供するものです。 　個々の体系だった情報は、本宅のウェブサイトで公開する予定です。（まだ工事中です... kxa00121 2008-12-31T21:12:52+09:00
　個々の体系だった情報は、本宅のウェブサイトで公開する予定です。（まだ工事中ですが…）

　本宅のサイトマップは以下のようになっています。
続きを読む]]> http://availability.livedoor.biz/archives/51339219.html 　ブログと言いつつ長らく放置状態になっております。 （どうせ誰も見てないという声も・・・） 　さて、世間を騒がせている青山学院大の瀬尾佳美準教授という方、専門はリスク管理だとか、防災技術研究所の客員研究員をしたこともあるとか。 　ブログの内容を見るとち... kxa00121 2008-05-07T18:32:53+09:00 ニュース （どうせ誰も見てないという声も・・・）

　さて、世間を騒がせている青山学院大の瀬尾佳美準教授という方、専門はリスク管理だとか、防災技術研究所の客員研究員をしたこともあるとか。
　ブログの内容を見るとちょっと稚拙な感じがするのですが、専門分野ではそれなりの研究をしているのでしょうかね？
]]> http://availability.livedoor.biz/archives/51017333.html 　Blueprints for High Availabilityにも書かれていたが、セキュリティー上、パスワード管理がけっこう重要だったりする。 　IT Mediaの記事から二題。 安易なパスワードのトップ10（英国の場合） 優れたパスワードの選定と記憶法 Blueprints for High Availabilit... kxa00121 2006-12-04T14:19:15+09:00 　IT Mediaの記事から二題。

安易なパスワードのトップ10（英国の場合）

優れたパスワードの選定と記憶法

Blueprints for High Availabilityの中にも、適切なパスワードの選び方について書かれているので御参考に。
]]> http://availability.livedoor.biz/archives/51011700.html キーマンズネットの記事から、 【1】退職社員の亡霊IDを退治せよ！「アイデンティティ管理ツール」 　　　　　　　　　　　　　　　　　　　　　　　　…製品購入ウラづけガイド だそうです。 　『Blueprints for High Avalilability』にも、退社した社員のアカウン... kxa00121 2006-11-28T13:48:34+09:00
【1】退職社員の亡霊IDを退治せよ！「アイデンティティ管理ツール」
　　　　　　　　　　　　　　　　　　　　　　　　…製品購入ウラづけガイド

だそうです。
　『Blueprints for High Avalilability』にも、退社した社員のアカウント管理について書かれていましたが、こういうツールも出ているんですね。
　このサーバー自身がSPOFにならないようにご注意を。
]]> http://availability.livedoor.biz/archives/50993534.html NTTデータの 米国マンスリーニュース 2005年8月号 連邦政府における業務継続性確保の取り組み 政府のビジネス継続計画「COOP」 災害やテロ攻撃など、緊急時にも政府業務やITシステムの稼動を継続させるためには、ビジネス継続計画（BCP: Business Continuity Plan）... kxa00121 2006-11-09T18:33:45+09:00 米国マンスリーニュース 2005年8月号

連邦政府における業務継続性確保の取り組み

政府のビジネス継続計画「COOP」
災害やテロ攻撃など、緊急時にも政府業務やITシステムの稼動を継続させるためには、ビジネス継続計画（BCP: Business Continuity Plan）の存在が欠かせない。米国政府では、BCPを業務継続計画（Continuity of Operations: COOP）と呼ぶことが多い。政府関係者は、いかなる危機的状況においても政府の主要業務が停止することがないよう、業務継続計画の作成、状況変化などに合わせた見直し、そして計画が実行可能であるかどうかのテストを実施する必要がある。本レポートでは、連邦政府におけるCOOP導入に向けたさまざまな枠組みや取り組み、そして現状について紹介する。

御参考まで。]]> http://availability.livedoor.biz/archives/50948994.html ITmediaでディザスターリカバリーの特集記事を見つけました。 シリーズ：ディザスタリカバリで強い企業を作る 現場の視点で見る災害対策（3）：WAN回線の設計とリハーサル kxa00121 2006-09-29T13:57:57+09:00
シリーズ：ディザスタリカバリで強い企業を作る

現場の視点で見る災害対策（3）：WAN回線の設計とリハーサル
]]> http://availability.livedoor.biz/archives/50932077.html 　ベリタス社（今はノベル？）がホームページで掲載している（いた？）STORAGE COMPASS連載講座というのが、ディザスターリカバリー＋ストレージに関して参考になる。 STORAGE COMPASS もう二年近く更新されていない（このブログみたい）が、過去の目次は以下のような... kxa00121 2006-09-14T19:58:20+09:00
STORAGE COMPASS

もう二年近く更新されていない（このブログみたい）が、過去の目次は以下のような感じ。
例のニューヨーク商品取引所の話も書かれてますね。



現在連載中の講座

全1回読みきり: ディザスタリカバリ プランのテスト （2004年11月から掲載）

「よくわかる」シリーズ （2002年10月から掲載）
過去に連載された講座

全2回連載シリーズ: ディザスタリカバリ サイト （2004年9月～10月連載）
全3回連載シリーズ: ディザスタの管理 （2004年6月～8月連載）
全5回連載シリーズ: 企業の回復能力 （2004年1月～5月連載）
全2回連載シリーズ: ディザスタとリカバリ プラン （2003年11～12月連載）
全4回連載シリーズ: ディザスタリカバリ事例研究 （2003年10～11月連載）
全3回連載シリーズ: アプリケーションをディザスタから守る （2003年8月～9月連載）
全3回連載シリーズ: ディザスタからのデータファイルの保護 （2003年5月～7月連載）
全6回連載シリーズ: ストレージ ネットワークとディザスタ リカバリ （2003年2月～5月連載）
全6回連載シリーズ: データベースをディザスタから守る （2002年11月～2003年1月連載）
全3回連載シリーズ: オラクルのバックアップとリカバリ （2002年9～10月連載）
全6回連載シリーズ: バックアップとディザスタ リカバリ （2002年8～10月連載）
全8回連載シリーズ: SQL Server のベーシック アベイラビリティ （2002年4～8月連載）
全6回連載シリーズ: ニューヨーク商品取引所の DR 対策から学ぶ （2002年4～7月連載）
全4回連載シリーズ: IT 管理者の効率を高めるためのガイドライン （2001年11月～2002年1月連載）
全8回連載シリーズ: ファイバチャネルとストレージ エリア ネットワーキング （2001年10月～2002年2月連載）
]]> http://availability.livedoor.biz/archives/50930712.html 　ずいぶん久しぶりの更新になってしまって申し訳ないです。 　最近、クラスタの切替え時間について人から聞かれる機会があったのですが、結論は、 「クラスタの切替え時間を保証することは誰にもできない」 です。 　少し乱暴な言い方かも知れませんが、３０秒な... kxa00121 2006-09-13T17:12:14+09:00
　最近、クラスタの切替え時間について人から聞かれる機会があったのですが、結論は、

「クラスタの切替え時間を保証することは誰にもできない」

です。
　少し乱暴な言い方かも知れませんが、３０秒なり３分なり、絶対この時間内に切替えが完了するなど、誰にも保証できない。私はそう思ってます。

　「多くのケースでは○○分（秒）以内に切替えが行われます」とは言えても、ハードが故障してホットI/O状態になったり、ディスクのI/Oエラーでリトライが多発したりする（レアな）ケースで切替えに時間がかかることは、可能性としては十分あり得ます。これは、確率の問題なのです。

　もちろん、可用性を高めるための不断の努力は必要だし、
　だからこそ、あらゆるケース（ワーストケース）を想定して準備する（例えば手動で切替えを行うなどエスカレーション手順を準備する）ことが重要なのです。
]]> http://availability.livedoor.biz/archives/50616424.html 　可用性とは離れますけど、前に触れたデマルコに関して。 　おととしにデマルコが来日した時、かくゆう私もミーハー根性丸出しで講演を聞きにいってサインまで貰って来ました。 　その時にサインを貰った『ゆとりの法則』をパラパラめくってたら、管理されることを嫌う... kxa00121 2006-02-23T20:31:15+09:00 四方山話
　おととしにデマルコが来日した時、かくゆう私もミーハー根性丸出しで講演を聞きにいってサインまで貰って来ました。
　その時にサインを貰った『ゆとりの法則』をパラパラめくってたら、管理されることを嫌うエンジニアを、聖書の創世記のアダムとイブの話のイブに例えた下りが目にとまった。

「イブは、人間の尊重すべき資質をすべて備えている。抑えきれない好奇心、勇気、権威を恐れない豪胆さ。なによりも自分自身の成長に意欲的であり、少しだけでなくすべての約束を果たそうと決めている。
　イブの「堕落」の話を思い出してほしい。神は、楽園のものはなにを食べてもよいが、ただ一つ、善悪を知る木の実は食べてはならないと言い渡す。この木の実はそもそも食べ物ではなく、「理解」である。それを食べれば、知るべきではないことを知ることになり、楽園から追放される。
　これに対するイブの態度は「おことわり！」である。自分自身の成長を狭い枠の中にとどめるつもりはなかった。イブは木の実を食べ、その結果を受け入れる。私も同様の立場に立ったとき、同じような勇気を持てたらと思う。」（下線筆者）

　いかにもソフトウェア開発の現場でのヒューマン・ファクターの重要性を一貫して主張してきたデマルコらしい文章で、何か自分のことを言われてるような気がして、ぐっとくるものがある。
（しかも、これは何もソフトウェアやコンピューターに限った話ではなく、クリエイティブで創造的な職業すべてに当てはまる。そしてクリエイティブでない職業なんて実は存在しない。）

　もっとも、宮仕えの悲しさというか何というか、ただ言われたことに歯向かっているだけでは仕事は進まない。そこのバランス感覚というものも必要だ。
　先の「ダンプが必要なOSを作った覚えはない」についても、色んな人のブログを見てると「これが、これからの新しい設計思想なんだ！素晴らしい！」とかただ讃美するだけのバカがいて、本当にどうしようもない。人知れず世の中を支えているLinuxシステムもあることが分かっていない。そんな人は本当にクリティカルなシステムに関わったことがない日曜プログラマなんだろうな。
]]> http://availability.livedoor.biz/archives/50583191.html 　このブログの趣旨からは少し外れますが、「虚業」とか言われて叩かれてるライブドアが「意外(?!)」と技術系であることを援護する記事をいくつか読みました。 ITmediaニュース:こんな時だからこそ安定したサービスを」――ライブドアの技術者魂 はてなCTO伊藤さんのブ... kxa00121 2006-02-09T12:05:06+09:00 ニュース
ITmediaニュース:こんな時だからこそ安定したサービスを」――ライブドアの技術者魂

はてなCTO伊藤さんのブログ「ライブドアの技術の話」

ライブドアが意外と技術系っぽいことについて - 圏外からのひとこと
ライブドアが普通に技術系であることについて -- 圏外からのひとこと

404 Blog Not Found:TVではかき消せない、permalinkの威力

　一般の新聞や週刊誌では虚業だ何だって論調が目立ちます（確かに発行株式とか時価総額は大分水増しされたものだったけど）が、ライブドアの技術陣は地道にそして先鋭的にウェブビジネスのインフラを構築し運用しているのだ。偉いんだ！って記事です。

「自社でサーバーを設計するなどレイヤ0から独自の技術を持っており、連日のテレビ放映による影響でも落ちないサイトを維持し、オープンソースの自社製フレームワークで大規模なサイトを超短期で構築して自分たちで運用している。オープンソースのライブラリ開発者、メディア執筆者を多数輩出した企業であり、特に Lightweight Language を活用するウェブプログラマに与えた影響は非常に大きい...ライブドアはそういう技術的な側面を持っている企業です。（中略）
一日何億もあるページビュー、何万というトランザクションをエラーを出さずにさばき続けるのにいったいどんな技術が必要か、想像したことはありますか。」（上記伊藤さんのブログ）

「だから、「中の人」として「数の暴力」に対抗する方法は、サービスを遺漏無く走らせ続けるという点に尽きる。「止めぬが勝ち」であり、そして価値なのだ。どんなOBの証言より、そのことは雄弁なのだ。少なくとも、「東証は止まったけどうちのサービスは止まりませんでしたよ」ぐらいは、言う資格があると思う。」（404 Blog Not Found）

　私も可用性には設計やら日頃の運用が大切だとか偉そうなことを書いてますが、会社的にも個人的にも大変な時期なのに、こうやって大規模なサーバー群をノーダウンで維持し続け黙々と仕事を続けているエンジニアたちの事を考えるとすごく偉いなと思って、ちょっと涙が出てきます。（少しプロジェクトＸ風）
　正直、今までライブドアが技術的にどうかとか余り評価してなかったんですが、24/356システムを維持している方々の技術力と努力を分かってないのは私自身でした。かなり反省です。
　広い意味でのIT業界の端くれにいる人間としては陰ながら応援しちゃいましょう。
　そういえば、このサーバもほとんどタダみたいな金額で使わせてもらってるんだから、もっと応援しなくちゃね。

　堀江さん自身、本当は経営オンチの技術屋さんで、そんで変な方向に行っちゃったんじゃないでしょうかね。
]]> http://availability.livedoor.biz/archives/50547616.html 　面白い映像を見つけました。 　SunGardが運用している移動データセンターです。（iPIXプラグインが必要） 　大型トレーラーの中にデータセンターがそっくり収まっていて、災害が発生すると出動するようです。 kxa00121 2006-01-26T14:27:47+09:00 四方山話
　SunGardが運用している移動データセンターです。（iPIXプラグインが必要）

　大型トレーラーの中にデータセンターがそっくり収まっていて、災害が発生すると出動するようです。
]]> http://availability.livedoor.biz/archives/50544854.html 以前、Linuxのビジネスユースに関して、オープンソースコミュニティーとの品質に関する認識論的切断(!?)について触れましたが、もう少し考えてみました。 私は仕事柄、海外（米国&ヨーロッパ）のソフトウェア開発者を相手にする機会があるのですが、彼らは割といい加減... kxa00121 2006-01-25T12:57:26+09:00 四方山話 私は仕事柄、海外（米国&ヨーロッパ）のソフトウェア開発者を相手にする機会があるのですが、彼らは割といい加減というか良い加減で、再現しないんならいいじゃないかとか、回避できればいいじゃないかとか良く言います。（プロセスの見直しはやって欲しいんですが・・・）

実際、ドイツなんかだと2000年問題の時も、まぁ手を尽くしてダメだったらしょうがないじゃないかというのが社会的コンセンサスになっていて、日本ほどピリピリしてなかったみたいです。
オープンソースコミュニティーの感覚に近いですね。

日本では過剰に品質を求めすぎるのかもしれません。

「ピープルウェア」や「ゆとりの法則」で有名なデマルコも、おととし日本に来た時の講演で過剰な品質は必要ないと言っていました。
「効率化しすぎると、作業が遅くなり変化にも対応できない」とトム・デマルコ氏――“デブサミ2004”開幕
「“早さ”と“クオリティー”の過剰な要求は開発者やその企業をダメにする 」なんだそうです。

デマルコに関しては、こんなブログも御参考。

ただ、ディザスター・リカバリーとか業務継続の分野だとどうなんでしょうね？？？
]]> http://availability.livedoor.biz/archives/50527112.html １４時４０分から株式全銘柄の売買停止＝東証 　東京証券取引所は１８日の１４時２５分時点で注文件数が７００万件程度、約定件数が４００万件程度に増加。処理能力の限界に接近したため、１４時４０分以降、全銘柄の株式やＣＢ、社債などを終日売買停止にすると発表した... kxa00121 2006-01-18T16:59:04+09:00 ニュース １４時４０分から株式全銘柄の売買停止＝東証

　東京証券取引所は１８日の１４時２５分時点で注文件数が７００万件程度、約定件数が４００万件程度に増加。処理能力の限界に接近したため、１４時４０分以降、全銘柄の株式やＣＢ、社債などを終日売買停止にすると発表した。（Ｈ．Ｋ）
[ラジオNIKKEI２００６年０１月１８日]

　これは結果論ですが、近いうちに取引量が処理能力を越えることが見えていたのでしょうから、もっと効果的な手が打てたのではないでしょうか？
　予想以上にネット取引が急増（ホリエモン的には「想定外」？）したとはいえ、見通しが甘かったのかなぁと思います。

　Blueprints for High Availabilityの高可用性設計原理＃７が「成長をデザインしろ」でした。（本宅参照）

　CPU、メモリ、I/O、ディスクはいつかは必ず枯渇するし、関連して電源容量や空調の容量も増やす必要が出てきます。そして、もしかしたらデータセンターも。
　システムを設計する時のゆとりや将来のスケーラビリティーを考えさせる事例です。
]]> http://availability.livedoor.biz/archives/50513641.html 　最近、あちこちで日本版SOX法の話題で盛り上がっているが、当然SOX法以前にもITシステムに関係してくる法律は存在する。 　"Blueprints for High Availability(BHA)"でも、可用性やディザスター・リカバリーに関連するいくつかの法律を挙げている。 （ちなみに、SOX法... kxa00121 2006-01-13T15:00:21+09:00 四方山話 　"Blueprints for High Availability(BHA)"でも、可用性やディザスター・リカバリーに関連するいくつかの法律を挙げている。

（ちなみに、SOX法とは法案を提出した二人の議員の名前であるSarbanes-Oxley actの略で、正式には「Public Company Accounting Reform and Investor Protection Act of 2002: 上場企業会計改革及び投資家保護法」という長ったらしい名前の法律だ。)

1. 1996年の健康保険ポータビリティー・アカウンタビリティー法（HIPAA）
   
   　この法律はセキュリティーの話題で引き合いに出されることが多いが、患者のプライバシー権及び患者、手続き、保険記録に関連するデータの格納、管理、保護の方法について、患者のプライバシーとデータ保有に特別の注意を払うように求めている。
   
   
2. 1977年の海外腐敗行為防止法(Foreign Corrupt Practices Act of 1977: FCPA)
   
   　この法律は、ロッキード事件のような外国の公務員への贈賄の禁止で有名。
   　BHAでは、この法律で「正式なDR計画を持つことを要求している」とある。
   　下の参考サイトでは「株式公開会社は情報システムに対し適切な保護をする責任がある」となってます。
   （DRについて、どこまで具体的に規定されているのか、詳細は法律の原文を読んでいないので不詳→調査中）
   
   
3. 1934年の証券及び取引所法
   
   公開会社とその監査法人はすべての記録を最低7年間保管しなければならないことなどが規定されている。
   当然、データがハードディスクにあろうが災害に遭おうが斟酌してくれるはずもない。
   
   
4. 内国税収入庁(IRS)規則71-20
   
   法人税の記録はそれらが関連している限り保管されなければならないと規定している。
   なお、IRS規則86-19では税務上のデータのバックアップ・リカバリーについて規定している。

参考：DR/BCに関連する法律

　これらはアメリカでの話ですが、日本で言えば1977年告示の「電子計算機 システム安全対策基準」なんかがあります。正直言って余り詳しくないので識者の方におまかせします。
]]> http://availability.livedoor.biz/archives/50509518.html 　ちょっとググっていたら、ITマネージメントについて解説しているIT Management Reference Guideというのを見つけた。 　当然のようにBusiness Continuity Managementという章もあるわけだが、その中でディザスター・リカバリーと業務継続の違い（Differences Between Disa... kxa00121 2006-01-11T21:29:52+09:00 ウェブサイト IT Management Reference Guideというのを見つけた。
　当然のようにBusiness Continuity Managementという章もあるわけだが、その中でディザスター・リカバリーと業務継続の違い（Differences Between Disaster Recovery and Business Continuity）を語っていたりして興味深い。

　英語ですが、興味がある人は御覧あれ。

ちなみに、両者の違いを簡単な表にすると、こんな感じになるそうです。
（ちょっと一面的という気もしないではないですが）

カテゴリ	ＤＲ	ＢＣ
重要視されるエリア	データセンター	企業
アプローチ	反応	順応
志向	テクノロジー	ビジネス
起源	７０年代	９０年代
顧客の関わり合い	最小	広範囲
サポートグループの種類	小	多様
関与するユーザの数	無	多
主要なメトリクス	MTBF／MTTR	RPO／PTO
マネージメントスタイル	独裁的	協力的
主導する重役	CFO／CIO	CEO／CRO
監督する管理者	オペレーション・マネージャー	ビジネス・コンティニュティー・マネージャー
認証	補助的	多数
キャリア・パッシング	限定的	広い

]]>