アカウント名:
パスワード:
この手のプロバイダーは、大抵テストを導入SIerに押し付ける。SIerは納品会社にテストを押し付ける。納品会社は「テスト用の」デバイス/プログラムを使ってテストをするので、実は導入されたものと全然違う…
もうこの段階でプロバイダーが想定している条件などの情報は霧散しているので、テストがテストになっていない。
本質的に悪いのはプロバイダーで、そもそも：「自前でテストをしない」「テスト環境を自前で作って導入前テストを十分に行わない/結果不合格だとしても、テスト環境を購入したコストは当然のものとして払わない」「社員を各デバイス製造会社の
コメントありがとうございます。勉強になりました。
歴史的なものも含めて色々な理由はあるんでしょうけれども、okkyさんのおっしゃられている事とACの方が書かれている事がこの業界周辺の現状だとしたら、怖いというのが部外者の立場から見ている私の正直な感想です。なんにせよ、せめて今回起きた事を教訓として、ファーストサーバ、同業他社、そして顧客側もこのような事の再発が発生し難い、また発生した際のリカバリーが可能な環境の構築に努力して欲しいです。
似たような事例が繰り返されている現状を鑑みるに、こんな意見は予算面や運用面の現実の苦労を知らない者の世迷い言なんでしょうけども。
最も常識的な戦略は、DCの中に「空間貸し」の領域を作って、サーバを借りている人たちはそこにマスターストレージを置く、という方法です。サーバはこのマスターストレージを iSCSI とか NFS とかでマウントして使う。顧客DBなんかは典型的にこのパターンで対処する。
レンタルサーバー屋さんが貸してくれるストレージには、大事な情報/短期間で高速に変化していくデータは置かない。意外とそういうデータは少ないので、upload 時のバックアップだけでも十分だったりする。
で、マスターストレージから、外部にある遠隔バックアップストレージに10分～30分毎に、非同期バックアップを取る。
.
あと、利用者側がデータの寿命を考える、というのも大事です。
一般的に永久にアクセスされ続けるデータ/ファイルって存在しません。なので、どの種類のデータはどれぐらいの必要寿命があるのか考えて、それ以上は保存されていることを前提としない。むしろ、寿命が来たら積極的に消すことを考えるし、サービス側のお客様にもそれを宣言する。
「一定期間が過ぎたら消して欲しい」データ管理のニーズって結構あるものですし、実はサイズ的にも結構でかい。こういうデータについては、一応バックアップは取るけれど、破綻的にデータを失った場合の保証コストは運用コストの一部として織り込んでしまう。無限の期間を考えなくてよいので、保険なども組みやすい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
テストをやっている会社は殆どない (スコア:3, 興味深い)
この手のプロバイダーは、大抵テストを導入SIerに押し付ける。
SIerは納品会社にテストを押し付ける。
納品会社は「テスト用の」デバイス/プログラムを使ってテストをするので、実は導入されたものと全然違う…
もうこの段階でプロバイダーが想定している条件などの情報は霧散しているので、テストがテストになっていない。
本質的に悪いのはプロバイダーで、そもそも：
「自前でテストをしない」
「テスト環境を自前で作って導入前テストを十分に行わない/結果不合格だとしても、テスト環境を購入したコストは当然のものとして払わない」
「社員を各デバイス製造会社の
fjの教祖様
Re:テストをやっている会社は殆どない (スコア:1)
コメントありがとうございます。勉強になりました。
歴史的なものも含めて色々な理由はあるんでしょうけれども、okkyさんのおっしゃられている事とACの方が書かれている事がこの業界周辺の現状だとしたら、怖いというのが部外者の立場から見ている私の正直な感想です。なんにせよ、せめて今回起きた事を教訓として、ファーストサーバ、同業他社、そして顧客側もこのような事の再発が発生し難い、また発生した際のリカバリーが可能な環境の構築に努力して欲しいです。
似たような事例が繰り返されている現状を鑑みるに、こんな意見は予算面や運用面の現実の苦労を知らない者の世迷い言なんでしょうけども。
Re:テストをやっている会社は殆どない (スコア:1)
最も常識的な戦略は、DCの中に「空間貸し」の領域を作って、サーバを借りている人たちはそこにマスターストレージを置く、という方法です。サーバはこのマスターストレージを iSCSI とか NFS とかでマウントして使う。顧客DBなんかは典型的にこのパターンで対処する。
レンタルサーバー屋さんが貸してくれるストレージには、大事な情報/短期間で高速に変化していくデータは置かない。意外とそういうデータは少ないので、upload 時のバックアップだけでも十分だったりする。
で、マスターストレージから、外部にある遠隔バックアップストレージに10分～30分毎に、非同期バックアップを取る。
.
あと、利用者側がデータの寿命を考える、というのも大事です。
一般的に永久にアクセスされ続けるデータ/ファイルって存在しません。
なので、どの種類のデータはどれぐらいの必要寿命があるのか考えて、それ以上は保存されていることを前提としない。
むしろ、寿命が来たら積極的に消すことを考えるし、サービス側のお客様にもそれを宣言する。
「一定期間が過ぎたら消して欲しい」データ管理のニーズって結構あるものですし、実はサイズ的にも結構でかい。
こういうデータについては、一応バックアップは取るけれど、破綻的にデータを失った場合の保証コストは運用コストの一部として織り込んでしまう。無限の期間を考えなくてよいので、保険なども組みやすい。
fjの教祖様