僕は焦っていた。そろそろ講義が始まるというのに、準備が思うようにできていない。去年と違ってオンライン実施なので、変更点が多い。しかし、ようやく初回のガイダンスの資料を作り、オンデマンド講義ビデオの録画の準備までできた。それが先週のこと。

で、いろいろ忙しくしてて、さて、講義の準備を再開するかと見てみたら、作ったはずのガイダンス資料が無い。正確にはあるのだが、去年のままになっており、今年用に書き換えた修正がなくなっている。おかしい、絶対に作ったはずだ。

この時点ではまだ慌てていない。僕が管理するドキュメントは全てバージョン管理されており、履歴がクラウドに残っている。間違えて上書きしたのなら戻せばよい。で、チェックすると、履歴が残っていない。どうやらバージョン管理していたと思っていたファイルが管理されておらず、その後の整理で間違えて消してしまい、一時間近い作業が失われたらしい。ここで頭に血が上った。

待て、別のPCにデータが残っているかもしれない。プログラム開発用と、普段使い用に加え、講義の録画用に新しくセットアップしたノートがあり、ごちゃごちゃしていた。それら全部を調べたが無い。念のため再度履歴をチェックしたが、やっぱりない。こんなことなら最初からあきらめてすぐに作り直せばよかった。

サンクコストという言葉がある。「回収できなくなった投資」という意味だ。僕はすぐにあきらめてガイダンス資料を作りなおすこともできたが、わりと長い時間かけて探してしまった。今あきらめたら、探した時間が全く無駄になってしまう。もう少し頑張ってみよう。典型的なサンクコスト効果である。

とりあえず消えたファイルが復活できないか、検索してみると、わりとトップにヒットした記事に「Windowsのシステムの復元で、削除されたデータを復元できる」という記述があった。僕は「システムの復元」の対象がシステムファイルのみで、個人ファイルは対象外であることは知っていたのだが、「Windows 10から個人ファイルも対象になったのかな」と思って、とりえあず「システムの復元」を見てみると、ちょうどガイダンスファイルを作った直後あたりに復元ポイントがあった。僕は完全に正気を失っていたのだろう。迷わずにシステムの復元を選んでしまった。

PCが復元ポイントからのリカバリに入る。ここで僕はようやくミスに気が付いた。やはり「システムの復元」はシステムファイルのみが対象で、個人ファイルは(別途設定していない限り)影響を受けない。さらに、僕はガイダンスファイルを作ったあと、このPCを録画用にするためにいろいろ設定した。その設定が「システムの復元」によって元に戻り、苦労が全て水の泡になってしまった。さらに、「システムの復元」中はPCが使えないため、終わるまで講義の録画ができない・・・

結局、ガイダンス資料は作り直し、録画用PCの「復元」が終わるのをまってから全て再設定することになり、膨大な時間が溶けてしまった。焦って頭に血が上った状態で復旧作業をしたせいで、傷口を大きく広げてしまった。

ここで、2017年のGitLabのデータベース吹っ飛ばし事件を思い出した。その日、GitLabのデータベーススペシャリストのYP氏は、ネットワーク越しに攻撃を受けて処理が重くなる、という問題の解決に取り組んでいた。攻撃者はすぐにブロックできたのだが、攻撃の余波でデータベースが重くなってしまっていた。そのため、YP氏は重くなった原因の「ゴミ」を削除しようと、二つあるデータベースサーバの待機系のファイルを全部削除することに。しかし、彼が実際に作業していたのは待機系ではなく本番系であり、彼は大事なデータを全てふっ飛ばしてしまった。

大事な顧客データなので、当然何重にもバックアップがとってあったはずなのだが調べてみると、その全てが機能していなかったことが判明。GitLabは緊急メンテナンスに入る。その時の顛末は以下の記事に詳しい。システム運用にかかわったことがある人なら、読んでいて胃が痛くなる内容だ。

しかしここで、データベースをふっ飛ばした「犯人」であるYP氏は、「今日はもう、自分は大事な処理にかかわらない方が良いだろう」と、復旧作業を同僚に任せてしまう。大事な顧客データを単純なミスでふっ飛ばしたのだから、正常な判断ができない精神状態であることは間違いない。そんな状態で「ミスを取り返そう」と作業をしたら、傷口を広げる可能性が高い。僕がやってしまったように。

これは非常に合理的な判断だが、今の日本でこの決断が受け入れられる会社はどれくらいあるだろう？「犯人」が先に帰ることなど許されず、針の筵の状態のまま復旧作業をさせられ、さらに大きな事故を引き起こしてしまうのではないだろうか？

今日、東証のシステムがダウンし、てんやわんやしているのを見て、GitLabの事故処理について思いをはせてしまった。今、エンジニアさん達は大変だと思うけれど、変な「犯人捜し」や「責任の押し付け合い」に巻き込まれないで欲しいな、と思う。

余談だが、GitLabのデータをふっ飛ばしたYP氏のプロフィールにはもともと「Database Specialist @GitLab」と書いてあったが、この事故の後、しばらくの間「Database "Removal" Specialist @GitLab」を名乗っていた。こういう自虐ネタが許されている、というのもGitLabの雰囲気が良いことの証左じゃないかな、と思う。なお、現在彼は「Staff Backend Engineer @ GitLab」と名乗っている。