1 ポイント 投稿者 GN⁺ 2023-12-08 | 2件のコメント | WhatsAppで共有
  • Google Driveで一部ユーザーのファイルが消えた後、Googleは11月27日に問題を認め、1週間後に復旧手順を公開したが、復旧に失敗した事例が出続けている
  • Googleは原因をDriveデスクトップアプリ84.0.0.0~84.0.4.0の「同期の問題」と説明しているが、Webで作成したドキュメントやスプレッドシートの消失事例まで説明するには不十分である
  • 復旧はDriveデスクトップアプリ85.0.13.0以上の隠しUIとコマンドラインフラグを通じて、アプリのデータフォルダやキャッシュに残ったファイルを探す方式に見える
  • GoogleはGoogle Drive Communityの主要な問題スレッドを170件の返信でロックし、追加スレッドも重複扱いにしたため、ユーザーが復旧結果や診断情報を共有しにくくなった
  • 個人や企業が大容量データを預けるDriveにおいて、沈黙、ロックされたフォーラム、曖昧な原因説明はサービスの信頼を大きく揺るがせた

Google Driveのファイル消失と「修正」発表

  • Google Driveで一部ユーザーのファイルが消える問題が発生し、Googleは11月27日にこれを認めた
  • 約1週間後に復旧手順を公開したが、問題は依然としてDriveデスクトップアプリの「同期の問題」としてしか説明されていない
  • 影響を受けたバージョンはDriveデスクトップアプリ84.0.0.0~84.0.4.0である
  • 単なる同期の問題であれば、ファイルがクラウドにアップロードされない、またはダウンロードされない状況に近いはずだが、ユーザーはファイルが完全に消えたと述べている

「同期の問題」と一致しない消失事例

  • Google Drive Communityの主要な問題スレッドには、スプレッドシートやドキュメントが消えたという事例が多数投稿されている
  • 一部の事例は、デスクトップアプリではなくWebインターフェースで作成・保存されたドキュメントとみられる
  • 複数のユーザーは、ドキュメントの保存が止まった時点として2023年5月を挙げている
  • Driveデスクトップアプリを使ったことがないというユーザーもいる
  • こうした事例は、デスクトップアプリの同期問題だけでは全体の現象を説明しにくいことを示している

Driveの同期方式と疑われる挙動

  • Driveには複数の同期方式があり、原因の診断を複雑にしている
  • デフォルトのファイルストリーミングモードはクラウド優先方式である
    • ファイルはコンピュータから削除され、クラウドに保存される
    • ローカルにはWebリンクだけが残り、容量を節約する
  • 同期の問題によって、ファイルをアップロードする前にコンピュータから削除してしまう状況は起こりうるかもしれない
  • ただし、Webで作成したドキュメントが消えたという事例までこの方式で説明できるわけではない
  • Googleは、正確に何が起き、どう修正したのかを具体的に明かしていない

Googleの復旧手順

  • Googleの復旧案内は、ファイル復旧を試みるいくつかの方法を提供している
  • 1つ目の方法は、Driveデスクトップアプリ85.0.13.0以上にある隠しUIを使うことである
    • システムトレイまたはメニューバーのDriveアイコンをクリックする際にShiftを押すと、特別なデバッグUIが表示される
    • ここで「Recover from backups」オプションを選択できる
    • 復旧が終わると、デスクトップにGoogle Drive Recoveryという新しいフォルダが作成され、同期されていないファイルが入ると案内されている
  • 2つ目の方法は、コマンドラインを使うことである
    • 新しいDriveバイナリは--recover_from_account_backups--recover_from_app_data_pathフラグを提供する
    • Googleは最初に問題を認めた際、Driveのアプリデータフォルダを削除したり移動したりしないよう警告していた
    • この手順は、消えたファイルがDriveのキャッシュやアプリデータパスに残っていることを前提にしているように見える
  • Googleは、Windows BackupやmacOS Time Machineでファイルを探す方法も提案している

ロックされたフォーラムと遮断されたフィードバック

  • GoogleはDrive Community Forumsの主要な問題スレッドを170件の返信でロックした
  • 追加スレッドも重複として扱ったうえでロックしている
  • 「解決策」の投稿にも返信できず、ユーザーが復旧の成否を共有しにくい
  • ロック前に残っていた一部の返信では、Googleの修正策が機能しないという反応が多かった
    • あるユーザーは、「solution」は大半の人に機能しないと述べた
    • 別のユーザーは、Google Driveがファイルを削除したため復旧対象がないと述べた
  • 復旧に成功したという事例は多くなく、アプリデータフォルダに数か月前のファイルコピーが残っているという前提にも納得しがたいという反応が出ている

製品への信頼を揺るがした対応

  • Driveは個人向け製品であるだけでなく、テラバイト単位のストレージを必要とする企業向けサービスとしても提供されている
  • 有料ティアの価格が非常に高くなりうる製品であるだけに、ユーザーがデータを預けられるという信頼が中核である
  • バグそのものは起こりうるが、通常のIT障害対応であれば、ステータスページの継続的な更新と、原因や修正内容をまとめた事後分析が期待される
  • 実際の対応は数日間の沈黙、ロックされたフォーラム投稿、曖昧な説明へと続き、ユーザー支援とフィードバックの経路は狭められた

2件のコメント

 
ndrgrd 2023-12-09

以前OneDriveを使っていたときも、データが1つ2つと消え続けて深い怒りを感じて以来、NASに移しました。
ネットでは「NASはいつ壊れるかわからない」「大企業が管理してくれるクラウドのほうがむしろ良い」といった意見が多いですが、5年使っていて一度もそんなことはありませんね〜。電気代もそれほどかからないです!

 
GN⁺ 2023-12-08
Hacker News の意見
  • こういう問題をこのように扱うべきではなく、Google の対応は本当に奇妙だ
    ブログ記事で何が起きたのか、誰がどの程度影響を受けたのか、復旧可能なのか、いま何をしているのか、再発防止のために何をするのかを説明すべき
    Drive for Desktop クライアントに隠れた修正のように見えるものを入れて、ローカルでファイルを復旧できるか見ようとするのは、問題がクラウド上でファイルが消えたことならまったく筋が通らないように思える
    本当に問題の範囲が「アップロードされるべきだったがされなかったファイル」だけで、クラウドから削除されたものはないのなら、その点も説明し、根拠を示すべき。人々が言っている内容はそうではないからだ
    実際にデータ損失があったのなら、なかったふりをするのは絶対に答えではない。「隠蔽は犯罪より悪い」という言葉のように、Google がなぜこの問題を完全に透明性をもって認めないのか理解しがたく、こうした状況での企業の対応方法はすでによく知られており、透明性と責任が核心だ

    • Google を擁護するつもりもないし、Google で働いているわけでも代表しているわけでもない
      ただ、大規模な顧客を相手にする似たような状況を経験すると、本当に難しい。一部の顧客は病的に振る舞い、問題を解決した後も噂を止めない
      いったん修正されたなら、すべてのコミュニケーションは前向きであるべきだと思う。一部は完全におかしかったり、無能だったり、悪意があったりするので、すでに解決済みの件についての会話を止めるためにスレッドをロックしなければならないこともある
      大規模な顧客基盤はまったく別の生き物で、経験してみれば意味が分かる。だからといって Google が正しい道を選んだという意味ではなく、全体の文脈を持つ人だけが評価できる。私は具体的な内容を知らないフォーラムの間抜けにすぎない
    • 顧客対応に慣れたまともな会社ならそうするだろうが、Google はそういう会社ではない
      Google は顧客関係という概念にまったく慣れていない。Google という事業体は、顧客を自分たちが売ると決めたものを買ってくれる都合のよい農民くらいに見ているのでは、とさえ思う
      カスタマーサポートという発想自体が、Google とはほとんど正反対の概念だ。GCP サポートを受けようとして経験したさまざまな話を見れば、その典型例になる
    • Google がなかったふりをしているわけではない。記事によれば問題を認め、ヘルプセンターの記事も公開している
      影響を受けたソフトウェアバージョンも明記しており、そもそも問題はデータが同期されなかったことなので、影響を受けたユーザーに直接知らせるのは不可能に見える
      ヘルプセンター記事のリンクをたどると、障害中にサポートフォーラムの固定投稿で、バグを引き起こさない方法や悪化させない方法を何度も投稿していた
      結局、望んでいたもののうち原因分析ブログ記事だけが欠けているということではないかと思う
      「クラウドから何も削除されていないなら説明し、正当化せよ」という要求は、Google が認めたバグとは別に、同じ時期にまったく別の機能と症状を持つ別のバグがあり、一方のバグは隠さず、もう一方のバグは隠蔽したという意味になる。明白で単純な説明があるのに、かなり複雑な説明だ
      しかも、そういうことを断定的に証明するのはほぼ不可能で、平均的なユーザーが理解できる形で証拠を伝えるのも難しい。「本当に一生懸命確認しましたが、報告を確認できませんでした」と言うべきなのか?
      可能ではあるだろうが、ファイル名と作成日から消えたというファイルを信頼性高く特定できる報告を100件集め、監査ログのようなものを分析する必要がある。実際には、そもそも存在しなかったファイルがいくつあるのか、ユーザーが明示的に削除したものはいくつか、個人アカウントではなく職場アカウントに誤ってアップロードしたものはいくつか、Drive 内にあるのにユーザーが見つけられないものはいくつか、すべての可能性を尽くした後に痕跡なく消えたものはいくつかを集計しなければならない。内部的に問題の有無を確認するためにそうした調査をするのは筋が通るが、データが実際には失われていなかったとしても結果を公開するのは、広報戦略として非常に悪く見える
    • 「なぜ」という疑問は、Google ならもっと上手くやるべきだと思うから出てくるのだと思う
      数週間前、Google でほぼ20年近く働いてから去った人が、会社文化が変わり、無能な企業型・政治型の人材がより引き寄せられるようになったと書いた記事を思い出す
      訂正すると、数十年ではなく18年勤務した後に去った人だった
      https://ln.hixie.ch/?start=1700627373&count=1
      HN のコメントも参考になる
      https://news.ycombinator.com/item?id=38381573
    • Google からすれば、問題が小さくて個人が少額訴訟を起こせば喜んで小切手を渡す程度か、あまりに大きくて自分で足を撃ったという記録を残したくない程度なのだろう
      また、噂を防ぐにはロックしておかなければならない変な人たちが長く尾を引くのもその通りだと思う
      心から「警察には絶対に話すな」と「企業は自分のミスを公開すべきだ」の両方を信じる人が、この2つをどう調和させるのか説明してほしい。私には同じコインの裏表に見えるが、別の形で説得されるなら興味深い
  • 人々にクラウドの外にデータのバックアップがあるかと聞くと、狂人を見るような目をする。クラウドはデータを失わないと信じていて、実際に失ったら、その次はどうするのか?

    • 以前 Reddit でこのような広告を出したことがある
      「インフラが Amazon AWS にあり、バックアップも Amazon AWS にあるなら……やり方を間違えています……」
      ところが人々が怒ったので中止しなければならなかった
      AWS にゼロではないリスクが少しでもあるという概念そのものに、かなり激しく攻撃的に反応した
    • 「クラウド」がバックアップソリューションとして推される一方で、同時に「オンデマンドファイル」でローカルデータを消すことを推奨したらどうなるか? こんにちは OneDrive! 笑える
    • 基本コピーを今もローカルに持っているなら、クラウド外のバックアップがなくても概ね大丈夫だと思う
      データがクラウドにしかないわけでないなら、クラウドプロバイダーがデータを失うまさにその日に、偶然ローカルデータも失わない限り破綻しない構造だからだ
    • 「データは3か所に存在しなければ存在しないものであり、そのうち少なくとも1か所は自分で管理できなければならない」という表現が好きだ
  • 今、Google サポートとやり合っているところ。
    アプリをストアに出そうとして Play アカウントを作ったのだが、本人確認メールを見逃してしまい、今ではそのメール内のリンクは「Google が本人確認できない」という理由でもう機能しない。「試行回数が多すぎる」としてアカウントが制限され、アプリを公開できない。
    サポートは、試行回数が多すぎてアカウントが制限されており、返金もできない、という話を繰り返すだけ。
    こういう単純なことを解決するサポート品質が悲惨。開発者 Play アカウントを作るときは、そのメールを見逃してはいけない。
    もし直せる人がいるなら、自分の開発者 Play アカウント ID は 7827257533299144892。

    • アプリを作らずに PWA を作ればいい。
  • https://rachelbythebay.com/fun/som/

    • JavaScript をオフにしている場合にページ下部に出る文言が気に入った。
      「NoScript ユーザー、または JavaScript なしの皆さん、こんにちは。あなた方のやり方は好きです。だからこのページはほとんど静的で、リストを動的生成していません。見逃すのは、だんだん暗くなっていく進行エフェクトと、下に行くほどだんだん痛々しくなる笑顔だけです。ああ、一番下の合計もありますが、NoScript を使う人なら自分で数えられるでしょう。そのままクールでいてください!」
  • だんだん NAS の時代になってきている感じがする。
    ドラマや映画を探していると、もう同じサービスにはなかったり、文字どおりどこでも提供されていなかったりすることが多い。いいねした YouTube 動画のかなりの数も、今ではただ [deleted] と表示される。
    クラウドに保存したデータも、エンジニアたちがキャリアに大きく影響するような事件を経験したらどうなるか分からない。

    • コンシューマー向け NAS は、興味深いことに 3 段階を経てきたように思う。
      1. 内蔵ハードディスク入りの Western Digital 製品、おそらく MyBook だったと思うが、バグが多く信頼しにくいゴミとして悪名高かった。
      2. その後、クラウドが答えのように見えて、NAS はほとんど姿を消した。
      3. 今は Synology の NAS エンクロージャと独自 OS の DSM があり、使い勝手は夢のよう。
        NAS の新しい時代があるとすれば、Synology が単独でそれを可能にしたと言ってもいいくらいで、かなり驚くべきことだ。
    • ほとんどの米国人には、専用 NAS が必要なほどのデータはない。
      データがあるとしても、費用が大きな壁になる。ドライブ込みで400ドル以上というのは、大多数がコンピューターハードウェアに使おうと思う金額をはるかに超えている。
  • 前回 HN でこれが議論されたとき [1]、こうしたファイルはすべてテープバックアップがあるので完全に復旧されるはずだ、と皆が言っていた。
    そのテープバックアップシステムの近くで働いたことがあると言う人もいて、嘘ではなさそうだったので、実際に存在すると信じている。
    では、なぜテープから復旧できなかったのだろうか? テープバックアップが知られているよりも限定的で、このデータはバックアップされていなかったのだろうか? それとも、テープを洗い出して各ファイルの正本を決める作業が難しすぎ、コストも高すぎたのだろうか?
    [1] https://news.ycombinator.com/item?id=38427864

    • ファイルを失ったユーザーが多いなら、Google は復旧に時間がかかるか、そもそも復旧したがらない可能性がある。
  • この問題が Drive だけに限られているのは確実なのだろうか? Ars の記事では、デスクトップアプリをまったく使っていない一部ユーザーもデータを失ったとあるので、バグの一つは Google のインフラ内にあったという意味のように見える。
    Colossus か現在使っている何かで見えないデータ破損があり、Drive での影響が最も目につきやすかった可能性もあるのではないかと思う。ただ、壊れた部分が GCP に属していたなら今ごろ気づいているはずなので、それは違うのだろうか?

    • Google Drive という製品のバックエンドコードに何か問題があった、という方がずっとありそうに見える。
  • Google は Bastard Operator From Hell から少し着想を得たように見える。
    [1]: https://bofh.bjash.com/bofh/bofh1.html

  • 昨日も Google Drive を使っていて問題があった。
    スマホアプリで画像をアップロードした後、デスクトップで探してダウンロードしようとしたが、最近使ったアイテムの一覧になかった。検索で見つけてダウンロードしようとすると、Web サイトが「You have selected a file that does not exist」と言ってきた。

  • 3月に一部のファイルが何らかの形で削除されたことは確認できる。
    この問題は、500万ファイル制限がもはや制限ではないと発表した件に関係しているのではないかと疑っている [1]。
    最初はチームメンバーの誰かがミスしたのだと思っていたが、今では申し訳ない気持ちだ。
    [1] https://news.ycombinator.com/item?id=35329135