パスワードを忘れた? アカウント作成
5995591 story
バグ

ファーストサーバ、データ消失事故の再発防止策を発表 52

ストーリー by hylom
飛んだ顧客は戻ってくるのか 部門より
あるAnonymous Coward 曰く、

10日、レンタルサーバ事業者のファーストサーバが大規模なデータ消失事故に関する再発防止策を発表した。基準やルールに関する「運用」と、2次バックアップの取得という「システム」の両面で対策を講じるという。

運用に関しては、システム変更のための社内マニュアルを、安全性を確認した上で再徹底する。同時に、開発部門と運用部門を分離し、業務分担や責任範囲を明確にする。システム面では、同一筐体内でのデータ複製に加え、7月25日からは外部バックアップシステムを構築して2次バックアップも取得する運用とする「本来の意味でのバックアップ」の仕組みを取ったという。データ復旧を過程で生じた情報流出事故については、再発防止策として「データ消失時の対応マニュアル整備」を行い、この対応マニュアルの中で、データ復旧ソフトによる復旧は実施しない」ことを明確化するらしい。

磯部社長は、「今回の事態を厳粛に受け止め、二度とこのようなことを起こさぬよう、再発防止に万全を尽くし、一日も早く皆様の信頼を回復できるよう社員一同、全力で取り組んでまいります」との声明を発表している(@ITITmedia)。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • Google App Engine の High Replication Datastore のハイテクぶりを見ると、なんとも、物足りないですね。「データ消失時の対応マニュアル整備」ですか。私はもっと原理的にデータ消失を無くすような仕組みを作れないものかと思ってしまうんですが(キャッチアップが得意な人材はいるはずです)

    すぐにというわけにはいかないが、Google のように、シンプルなレイヤー分けがなされて、ウェブサービスが実行中であれなんであれ、ユーザーが扱うデータにアクセス権がなくても、ソフトウェアの更新が可能であるような仕組み、地域的に離れたデータセンターに同じデータを高頻度にコピーするような仕組みをいつかは作るのか。それとも、今から「プライマリディスクに障害が発生した場合の対策について検討」という、この周回遅れかのように見える段階を何年もつづけるのか。技術基盤の選択も、検討し公表していく必要があるかと思います。

    • by Anonymous Coward

      私はもっと原理的にデータ消失を無くすような仕組みを作れないものかと思ってしまうんですが

      強力な電波で、宇宙に放出すればよいでしょう。

      リストアは、未来の人に託しましょう。

    • by Anonymous Coward

      距離が離れるほどデータの照合には時間が必要で,全てを整合させることは困難になります. 頻繁に書き変るものであるほど障害時の影響が大きく, これは物理的な限界ですからGoogleがどんなに技術力があっても解決のしようがありません.

      High Replication Datastore には Paxosアルゴリズムが使用され, 信頼性を確保しているそうですが, 書込む速度が遅くなることは避けられません. High Replication Datastore も保証はしていないのではないですか?

      http://pushit-dev.blogspot.jp/2011/11/high-replication-datastore.html [blogspot.jp]

      のように"困っている人"が検索の上位に上がっているようですが.

      • by Anonymous Coward

        これは遅延書き込みによるデータ整合性の問題で、遅延が許されないようなシステムで複雑なクエリを必要とする場合、設計が大変…という話ですね。
        バックアップまわりのデータ消失の問題とはまた別と考えたほうが良いかと

  • by eukare (2230) on 2012年08月14日 11時26分 (#2211633) 日記

    飛んだ顧客は戻ってくるのか 部門より

    きっと、復旧は実施しない事になっているに違いない。

  • by Anonymous Coward on 2012年08月13日 19時08分 (#2211350)

    「ソフトバンクはそういう対応をする企業グループ」と言うレッテル貼られただけって気がするんだけどなぁ。
    以前の個人情報流出500円とか。

    ※感想には個人差があります。

  • by Anonymous Coward on 2012年08月13日 19時22分 (#2211358)

    いや、もうここのサービス新規でつかう奴はアホだろ。
    信頼は金じゃ買えないし、時間をかけて安全を確証するしかない。
    値段安かろうで文句たれるなとかいってたんだろ?

    • by Anonymous Coward on 2012年08月13日 20時17分 (#2211389)

      東●本大●災復興支援財団が別のところに移動してるっぽい。
      まだ、ファーストサーバ使ってる客もいるというのに....

      親コメント
      • by Anonymous Coward

        どこかと思えば、ファーストサーバの属するソフトバンクグループの孫正義氏が会長を勤める財団でしたか。

      • by Anonymous Coward

        あ、(やっと)移動したの?

        フェイスブックに飛ばされるところまでしか見てなかったw

    • by Anonymous Coward

      というかどの面してサービス再開するつもりなのか。
      信じられん。

  • by Anonymous Coward on 2012年08月13日 19時26分 (#2211363)

    レンタルサーバの利用料以上は払わないって言ってたけど、その通りなのかな?

  • by Anonymous Coward on 2012年08月13日 19時43分 (#2211371)

    > この対応マニュアルの中で、データ復旧ソフトによる復旧は実施しない」ことを明確化するらしい。

    これでまたなにかあったら、マニュアル違反が常態化していたって説明を聞きそうですね。
    むしろ、条件を定めてパッチ適用やデータ復旧処理の自動化を進めて、ミスのおきやすい手動操作する場面を減らすべきだと思うのです。

    • by Anonymous Coward

      こいつらに飛行機操縦のマニュアルを作らせたら運転士は常に手動で操縦しろとか書きそうだな。

      • Re:疑問点 (スコア:3, 興味深い)

        by Anonymous Coward on 2012年08月13日 20時15分 (#2211388)

        自動処理をなぜか信用しない人たちってけっこうな割合で存在します。
        非常系も含めて自分たちが扱っているものを理解しておくことが重要だというのを他山の石と心がけたいと思います。

        2012年4月22日の三井化学岩国大竹工場における爆発・火災事故の例。

        爆発は独断の手動解除が原因
        http://www.chugoku-np.co.jp/News/Tn201208070063.html [chugoku-np.co.jp]

        委員長によると、プラント運転担当の班長男性(58)が冷却速度が遅いと感じ、緊急冷却水よりも通常運転時の循環水の方が早く冷却できると思い込み、システムを手動解除したという。解除のための具体的な条件はマニュアルには記載されていなかったが、必要な上司の了解を得ていなかった。事後報告もしなかったという

        委員長は、解除すれば、冷却に効果のある窒素によるかき混ぜも停止することを班長が失念していたと指摘。この結果、塔内の温度が部分的に上昇して過酸化物の分解が進み、内部の温度と圧力が急激に上がって爆発につながったとしている。

        親コメント
        • by shesee (27226) on 2012年08月13日 21時11分 (#2211418) 日記
          ファイルシステムからファイルを削除してしまったときに、ファイルシステムをいじるようなソフトは使っちゃ駄目というだけの教訓じゃね。ボリュームバックアップを取ってからやれば良かったのだろうけど、世代バックアップもとる余裕が無いのに、ボリュームバックアップなんてすぐには用意できなよね。そもそも人為的な誤操作をファイルシステムからのサルベージで復旧しようなんてそれが世代ファイルシステムで無い限り期待する方がどうかしている。
          親コメント
        • by Anonymous Coward

          自動処理をなぜか信用しない人たちってけっこうな割合で存在します。

          松本零士症候群とでも言いましょうか、生身の人間が機械に打ち克つことを信じて疑わない人達ですね。
          身近にも居て、辟易してます。

          • by Anonymous Coward on 2012年08月13日 21時09分 (#2211416)

            機械が得意なことと人間にしか出来ないことの役割分担に過ぎないですよね。

            私なんか自分が一番信用ならないです。

            親コメント
            • by Anonymous Coward

              自分が一番信用ならないのは完全に同意。
              自動化された物を完全に信用する訳ではないけど
              設計時に想定された範囲内なら、自分の作業なんか
              遅いわ不確実だわと良い事が無いケースがほとんど。

      • by nim (10479) on 2012年08月13日 23時16分 (#2211479)

        「マニュアル」なんだから手動は当然。

        親コメント
    • by Anonymous Coward

      前に説明してくれてた人は、データが混ざった理由をしっかり説明してくれていたよね?
      要約すると「消去されたデータはFATが消えてるから、復旧時にはディレクトリ構成が無くてファイル混ざってしまう」
      という感じだったと思う。(NTFSでFATファイルアロケーションテーブルと言うか知らないけど;)
      で、今回は「バックアップ」を取るんだから、ディレクトリ構造ごと取ればいい。なのに手動?

      結局は経営陣は事態を正確に把握していないし、下はそれに追従する輩しかいないように感じた。

  • by Anonymous Coward on 2012年08月13日 19時43分 (#2211372)

     マニュアルを整備することより守らせること。
    今回の事件も決りを守らなかったから起きた。

    • Re:大事なのは (スコア:5, すばらしい洞察)

      by mishima (737) on 2012年08月13日 20時01分 (#2211382) ホームページ 日記

      マニュアルを守らせることというより、マニュアルを守れる状況にするってことだな。
      「作業者が勝手に規則を破る」なんてことは普通なくて、
      根本に「非効率的な手順を改善する現実的な手順がない」「そもそも人的リソースが足りてない」などといった原因があったりすると思う。
      で、現場の人ではそれを解決できない。それってリソース分配、経営の話なんだよね。

      経営層がそこを理解してなければ、再発するんじゃないかな。

      --
      # mishimaは本田透先生を熱烈に応援しています
      親コメント
      • by Anonymous Coward

        禿同

      • by Anonymous Coward
        いや、マニュアルがそぐわないなら現実に合わせて改訂すればいいだけでは。
        マニュアルを守る決まりがあったのだから、改訂もその決まりに準じて上長の承認を得ればいい。
        改訂内容に穴があれば上長が駄目出しするわけで、それを見落として承認すれば責は上長に移る。

        別に経営の話じゃないよ、現場でできることをやってないだけ。
        それを怠って「人的リソースが足りてない」からリソース配分をと訴えたところで、
        現場の意識が変わってなければ同じ過ちを繰り返してしまう。

        特に、今回の件は現場での単なる手抜きやミスが重なっただけにしか見えないのよね。
        彼らならバックアップを物理的に分けたところで、本番機のデータが吹っ飛ぶってのは起き得ただろうし、
        例え物理的に分けたバックアップがあって、そこからデータを戻すことができたとしても、
        技術者のオペミスでそんな事態を招いた時点で負けだということに気づいて欲しい。
        • いや、マニュアルがそぐわないなら現実に合わせて改訂すればいいだけでは。

          「非効率的な手順を改善する現実的な手順がない」

          検証環境を用意する予算がなかったら…
          確認するエンジニアを確保できなかったら…

          今回の一件では、例のA氏の作業内容を同僚がレビューすることで回避できたんじゃないかと思うんだけど、
          (たぶん上司の承認では作業内容の妥当性はスルーだったんじゃないか)
          なんでそれができなかったんだろう、と思うんだよ。
          だとしたら、そういうリソースを現場に割いていなかったのが原因では? と思ってしまうよ。

          現場が「時間が足りない、予算が足りない」と言わなかったのが悪い?
          上司を納得させる資料を作り、説明できなかったのが悪い? そうだろうね。
          でも、それが現場の意識の問題なんだとしたら、経営陣っていうのは自分のビジネスのことをなんにも知らずに、
          口を開けて下からの報告を待ってるだけでもできる仕事なんだな〜って思うよ。

          --
          # mishimaは本田透先生を熱烈に応援しています
          親コメント
          • by Anonymous Coward
            次元の違う話をごっちゃにしてないか?

            ルールを
            「守る」「守らない」のと
            「守れる」「守れない」のは
            似ているけど全く違うぞ。

            今回はA氏が「守らなかった」。
            上司も黙認していた、つまり「守らなかった」。

            もっと効率のよい管理手順に変えることができれば「守れた」ってのはおかしい。
            他の社員は非効率と思っているかどうか分からないが「守っている」。

            少なくとも、A氏が守らなかった理由が不可抗力ってことはないだろう。
            ましてベテラン社員だ、手の抜き方も分かっているはず。
            上司ともども手を抜いてはならないところで手を抜いた結果じゃないか。
            それは経営者云々とは違う話だと思うが。
            • 今回はA氏が「守らなかった」。

              上司も黙認していた、つまり「守らなかった」。

              自分は、会社側の説明をそのまま鵜呑みにはできないなぁ。
              そりゃ会社としては「担当者が悪いだけで、組織には問題はありませんでした」という体の報告をするだろうからねぇ。

              システムを運用してたら、表には出てこなくても、小さい失敗は必ずある。ベテランなら絶対に経験してる。
              本番環境いじるなら、誰かにレビューしてもらいたい、それで自分の責任を軽くしたいと担当ならまず最初に考えるよ。

              それとも、ファーストサーバはそんなことも起きないような、のほほんとした職場だったのかなぁ。
              そっちの可能性のほうが小さいと思うんだけど…

              --
              # mishimaは本田透先生を熱烈に応援しています
              親コメント
    • by Anonymous Coward

      ごもっとも、

      だけど自前の自動化ツールを作りたくなっちゃう気もよくわかるんだわ。

      つか、そもそも会社だって、そういう技量を見込んで雇ってる部分もあるだろうしね。

      こういうのは単に「守らせる=強制する」って意識では解決しない。
      ありきたりだけど、危険事例の継承、気づき、共有、でリスク意識を持ってもらうしかないんだろうね。
      工場とか医療現場では、そういう取り組み、普通にやってるよね。

  • by Anonymous Coward on 2012年08月13日 20時10分 (#2211386)

    事故前も、「別ディスクにバックアップとってるよ」と言ってて、実際は同一ディスク上に取ってたような話でしたが…。
    信用できるんですかね。

    > 外部バックアップシステムを構築して2次バックアップも取得する運用
    これも事故後に、「一般的なバックアップというのは、我々のような低価格の料金で提供するのは難しい」
    と言い訳されてますんで、本当にやってるのか疑問です。

    • by wolf03 (39616) on 2012年08月13日 21時32分 (#2211427) 日記
      >「別ディスクにバックアップとってるよ」と言ってて、実際は同一ディスク上に取ってた
      それは、サイト更新を忘れていたとか何とか言い逃れしてましたが
      親コメント
      • by Anonymous Coward

        次はどの部分の更新を忘れるんですか?って質問したらいいんじゃないかな。

      • by Anonymous Coward

        忘れていたで済ませてるけど、宣伝と実態が異なってる商売は、一般に「詐欺」と呼ばれているように思う。
        …あれ?だます意図がない場合は、詐欺には当たらないの?

    • by Anonymous Coward

      >一般的なバックアップというのは、我々のような低価格の料金で提供するのは難しい
      この言い訳ですと、今後も一般的なバックアップを取るのは無理ってことになっちゃいますね・・・

      無理なら無理で「当方の瑕疵であってもバックアップからの復旧は行いません。バックアップは一切とりません」って堂々と明記しちゃえばいいのに。
      この会社の技術レベルだとその方がマシな気がしますね。

      • by Anonymous Coward

        > 無理なら無理で「当方の瑕疵であってもバックアップからの復旧は行いません。バックアップは一切とりません」って堂々と明記しちゃえばいいのに。

        同感。

        レンタルサーバ業界では、彼らより安くてもバックアップ取ってて、
        事故っても半日分程度の欠落で復旧できる業者は幾らでもあるんだけどね。
        まぁ、その代わりと言うか何と言うか、安定性や速度はかなり残念な感じなのだけど(例:ロリポ)、
        「低価格だからバックアップ無理」とか言われると、ちょっとモニョモニョするなぁ。

        会社の方針として、他社では優先している非常時の備えに注力していない、と言うだけの話でしょうに。
        直接そう書かないにしても、「弊社は同価格帯の競合他社と比較して××に注力します。その代わりバックアップ取りません」等と、
        自分達のサービスの勘所を明確にアピールすべきだと思うよ。

  • by Anonymous Coward on 2012年08月14日 0時40分 (#2211504)

    本当に消えたら困るデータは,ミラー+バックアップ+ディザスタリカバリぐらいでないと安心できませんね・・・
    RAID-5とスペア1本の構成でほぼ2本同時にディスクが故障し,えらい目にあったことがあります。
    データの重要度は人それぞれだと思いますが,今回の件に懲りてこれぐらいは組んでもよいかもしれませんね。

    手動で操作する場面を減らすという点はとっても賛成です。
    (オペミスでやらかした後輩がいましたので。)

  • by Anonymous Coward on 2012年08月14日 15時59分 (#2211828)

    お盆に発表するんだ?とちょっと思った。
    疑いすぎだと思うがソフバン系というだけでな。

typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...