BonTfの日記： ファーストサーバの過失、免責条項の有効性、損害賠償の有無 8
管理プログラムにバグがあった事が原因って報道されているけど、これが本当だとする仮定するとと幾つか疑問を覚えた。
1つ目は、そのプログラムをプロダクション環境で走らせる前に、テスト環境などでテストしなかったのか?
今まで問題なく動いていて今回問題が発生したってことは、最近管理プログラムに何らかの変更が加えられたと考えられる。ファーストサーバ側はその変更を実働環境以外でテストしていないのか? 考えるまでもなくバックアップも含めた一切合切まとめて消し飛ばすようなバグって限りなく極悪。そうでなくても、メンテナンス時に走らせる管理プログラムって事と今回発生した事象を考え合わせると、そのプログラムは仕様通りに動いていたとしても顧客のデータに触っているんじゃないかと私は推測した。ファーストサーバ側にとって、顧客のデータのインテグリティの保持というのは、アップタイムを高水準で維持する事と共に事業の根幹を成すと考えられる。よって、その類の重要データに触るプログラムである以上、非常に慎重な品質管理を行なうべきである。その品質管理の一端と考えられるのが、開発環境やテスト環境における各種のテストである。もちろんテストを行なう事で全てのバグが発見出来る訳でないのは常識であるが、今回の場合は障害が広範囲に渡っているのでテストで何らかの兆候を捉えることが可能だったではないかと思う。もし、テストして今回の結果だったのならば明かにテスト要件が不十分であったと考えられるし、もしテストしていなかったとしたら論外だ。どちらにしても、ファーストサーバ側の能力不足、認識不足が露呈したと言えるんじゃなかろうか。
2つ目は、ファーストサーバ側の過失の有無。
今回の件は管理プログラムの誤動作が原因という事なので、明らかにファーストサーバ側の人為的過失による障害と考えられる。ハードディスクの故障が原因によるデータロスよりも確率論的な要素が少ない分、ファーストサーバ側の過失の度合いはより高いんではないか。
3つ目は、約款にある免責条項の有効性。ファーストサーバ側の過失が重過失(どんな意味かは知らんけど)に相当した際は、契約者が消費者契約法における消費者に該当する際(個人)は第31条5項によって免責は成立しないと述べられている。また、その直後(第31条6項)は
当社は、本サービスに関連して生じた契約者および第三者の結果的損害、付随的損害、逸失利益
等の間接損害について、それらの予見または予見可能性の有無にかかわらず一切の責任を負いま せん。但し、契約者が消費者契約法上の消費者に該当する場合で且つ当社がこれらの損害につい て予見し、または予見し得た場合については、この限りではありません。
となっているので、契約者が消費者に類される場合は損害賠償が発生するんじゃなかろうか。ただし、契約者が法人の際には当然これらの項は該当しない。今回はファーストサーバの謳い文句を信用するならば、契約者は大多数が法人である訳で、契約者側も当然泣き寝入りとはならず少なからぬ数の民事訴訟が発生するだろう。その際、免責条項の有効性が争点となるのは、ジェイコム株誤発注問題に目を向けるまでもなく分かりきっている。また、過失の度合いも重要な筈で、松島弁護士のページによれば、"被告（システム運用事業者）の積極的な行為"によってデータが消失した事例では、事業者の免責が無効とされた判決もあるみたい。この判決の背景などは全然知らないので、同様の事が今回も言えるのは知らない。しかし、少なくても、免責条項の有効性の判断には、過失の有無及び度合いが関連してくるのは間違いなさそうだ。そうすると、今回の際は管理プログラムのバグの性質が重要になってくるのでは。いずれにしても、今回の事件は相当長びきそうな気がする。
4つ目は、ファーストサーバの事業の今後。
今回の騒動でファーストサーバのサーバ管理能力及び危機管理能力の一端が世間の目に晒された。サーバ管理能力に関しては、管理プログラムのバグでデータ消失という積極的にはお付き合いしたくないレベルを露呈し、危機管理能力も当初のアナウンスの遅さに加えその後の対応も疑問符が付く。直接の知り合いはいないが、ファーストサーバ、顧客双方の実働部隊には同情するし、過去数日または現在も続いているであろうストレスフルな環境でのトラブル対応には頭が下がる思いである。ただし、今回の件で直接影響の有無に関わらず、多数のファーストサーバの顧客が今後の対応を検討するのは自明である。その選択肢の中には、ファーストサーバとのお付き合いを止めるというのは当然あるだろう。いずれにしても、短期的、中期的に見てファーストサーバの業績は下がることはあっても上がることはないんじゃあるまいか。また、別のサービスを利用している会社の中でも今後の動きを検討する動きが出てくるのでないか。この事件の余波は結構大きくなる予感。
以上、関連業種に関係もない全くの門外漢の感想。
テストをやっている会社は殆どない (スコア:3, 興味深い)
この手のプロバイダーは、大抵テストを導入SIerに押し付ける。
SIerは納品会社にテストを押し付ける。
納品会社は「テスト用の」デバイス/プログラムを使ってテストをするので、実は導入されたものと全然違う…
もうこの段階でプロバイダーが想定している条件などの情報は霧散しているので、テストがテストになっていない。
本質的に悪いのはプロバイダーで、そもそも：
「自前でテストをしない」
「テスト環境を自前で作って導入前テストを十分に行わない/結果不合格だとしても、テスト環境を購入したコストは当然のものとして払わない」
「社員を各デバイス製造会社の教育プログラムに参加させて、それぞれがどういうものなのかを学ばせてから、自分でどれを導入するか考える、という発想がない」
などというのは、おおよそ日本・韓国・中国の3カ国ぐらいしかありえない。
その次に悪いのはSIerで、そもそも SIerが価値を持つのは、この手の障害に関しては「事前にテスト等のコストを払ってリスク部分を洗い出しておく」から。それを納品会社に押し付けている段階で、お前ら存在価値0じゃないか、と言うことを理解していない。これらをやらないなら、そもそも機種選定権限をSIerが持つこと自体がおかしいし、推奨機種すら存在し得ないはず。
とまぁ、これは日本では起こるべくして起こった現象。責任のたらい回しという名のババ抜きのゲームが１つ終わったのに過ぎない。
fjの教祖様
Re:テストをやっている会社は殆どない (スコア:1)
コメントありがとうございます。勉強になりました。
歴史的なものも含めて色々な理由はあるんでしょうけれども、okkyさんのおっしゃられている事とACの方が書かれている事がこの業界周辺の現状だとしたら、怖いというのが部外者の立場から見ている私の正直な感想です。なんにせよ、せめて今回起きた事を教訓として、ファーストサーバ、同業他社、そして顧客側もこのような事の再発が発生し難い、また発生した際のリカバリーが可能な環境の構築に努力して欲しいです。
似たような事例が繰り返されている現状を鑑みるに、こんな意見は予算面や運用面の現実の苦労を知らない者の世迷い言なんでしょうけども。
Re:テストをやっている会社は殆どない (スコア:1)
最も常識的な戦略は、DCの中に「空間貸し」の領域を作って、サーバを借りている人たちはそこにマスターストレージを置く、という方法です。サーバはこのマスターストレージを iSCSI とか NFS とかでマウントして使う。顧客DBなんかは典型的にこのパターンで対処する。
レンタルサーバー屋さんが貸してくれるストレージには、大事な情報/短期間で高速に変化していくデータは置かない。意外とそういうデータは少ないので、upload 時のバックアップだけでも十分だったりする。
で、マスターストレージから、外部にある遠隔バックアップストレージに10分～30分毎に、非同期バックアップを取る。
.
あと、利用者側がデータの寿命を考える、というのも大事です。
一般的に永久にアクセスされ続けるデータ/ファイルって存在しません。
なので、どの種類のデータはどれぐらいの必要寿命があるのか考えて、それ以上は保存されていることを前提としない。
むしろ、寿命が来たら積極的に消すことを考えるし、サービス側のお客様にもそれを宣言する。
「一定期間が過ぎたら消して欲しい」データ管理のニーズって結構あるものですし、実はサイズ的にも結構でかい。
こういうデータについては、一応バックアップは取るけれど、破綻的にデータを失った場合の保証コストは運用コストの一部として織り込んでしまう。無限の期間を考えなくてよいので、保険なども組みやすい。
fjの教祖様
Re: (スコア:0)
>などというのは、おおよそ日本・韓国・中国の3カ国ぐらいしかありえない。
これを断言できる、根拠が知りたいな。国民性とかに押しつけるのは思考停止じゃないかしら？
単に管理が甘い会社を身近に見れるだけじゃ無くて？
Re:テストをやっている会社は殆どない (スコア:1)
思考停止ではなく、本当にそういう性質があるのですよ。
まぁ、「国」単位なのは、経済統計値が国単位でしか出ていないからですが。
# なので「中国でも四川省はそんなことはない」とか言われても困る。
.
基本的にデータの「寿命」を考えるかどうか、というのがポイントです。
Far East ３カ国は、どんなデータでも「自分が消したいと思うまで、絶対保持しろ」という要求スペック。
他の国は、「一定期間以内は保持して欲しいが、それが過ぎたらどうでもよく、ある時期を過ぎたら絶対消して」というふうにデータに寿命を求めます。もうちょっと正確には「バックアップ・アーカイブの形では保存するが、常時アクセスはしない」「バックアップやアーカイブの状態になったら、もう社外のシステムは使わない」ので、自前以外のDCに保存されていることはありえません。
.
で、寿命を考えない国程、SIerという業種のマーケット規模が大きい、ということも判っています。
ようするに要求段階が無茶なので、自分でシステムを組めずに外注に出す(責任を外に追い出す)わけです。
で、その責任をさらに他の人に押し付け…という連鎖をすることで、責任のババ抜きが起こります。
どこかで障害が起こると、ババがどこにあったか、というババ探しが始まり、ババを持っていた人が責任を取らされる(お金をふんだくられて破産するが、それ以外の人も被害をカバーしきれるほどお金はもらえない)。
fjの教祖様
キャッチボール主義論が効いているなあ (スコア:1)
ババがどこにあったか、というババ探しが始まり、ババを持っていた人が責任を取らされる
閉じた組織内であれば有効かもしれない(個人的には信じていないです)仕事/仕掛の対処であるところの“(キャッチボールの)球がどっちにあるか”が関心の大半で、向こう側の手元なら手を出さない流儀の人たち多いですね。
開いた集団にまでその思想を拡大して目先のコスト最小化ばかり追っかけていてリスクやビジネス全体を見ていない、アクションを起こしてもっと有利な立場になることができないというのが閉塞状況なのかな。
バグでデータ消失は (スコア:0)
さくら [srad.jp]もMS [srad.jp]もやらかしてるし、むしろ意外と簡単に発生しうる事象だという認識が不足しているのではないか
どのみち (スコア:0)
どのみち、ここは長くはないのではないかな。
NTTデータのブログサービスも大きな事故起こして、信用落としてるし、
相手が規約一辺倒で、くるならそれはもう長くはない証拠では