crontab database ～君がしでかしてくれたもの～

この記事は本番環境でやらかしちゃった人のアドベントカレンダー２日目の記事です。
内容的にそろそろ時効だと思うので供養のために書きました。

追記。そういえば時期をちゃんと書いてなかったけど事件が起きたのは去年2018年、つまり仕込み（ヲイ）は2017年の話です

ぶっちゃけネタ記事ですｗ
（たまたま見つけて参加してみただけなのに昨日の記事の伸びっぷりを見て戦々恐々としてる

TL;DR

DB移行作業において、テスト期間中は常に最新のデータで処理できるように書いておいたプログラムをcrontabで実行していた。最終的に本番に合わせて日時を調整していたが、そのことを失念し１年後に再実行されてしまい、本番データが１年前に巻き戻る事故発生。

crontab は分、時、日、月、曜日を指定できるが、１年後に帰ってくるから気をつけてね。という話。

惨劇はなぜおこってしまったのか

結論から言えばcrontabの設定を消し忘れたのが原因。

• DB移行作業（某プライベートクラウドからGCP。MySQL to MySQL）

• NWを繋いでいなかったので、レプリケーションではなくdumpしてimportさせる計画

• 正確には次の３つのシェルを書いておいてcrontabで実行させていた（計画実行なのでコマンドを叩かなくてもフルオートで実施できる検証も済んでいた）

  • 移行元サーバでdump（デイリーバックアップを流用）
  • ローカルにダウンロードして移行先サーバにアップロード（自分のPCはどちらのNWにも繋がる）
  • 移行先でimport

• 本番移行自体は問題なかった

• 移行元は解約したので問題なかった

• ローカルは移行ファイルがなければ何もしないので問題なかった

• 移行先サーバに移行データとシェルとcrontabを置きっぱなしにして後始末を失念した（万が一に備えてデータファイルをそのまま置いておいた）

• 結果としてこの移行作業からちょうど１年後、importする処理がcrontabで実行されてしまい、当時のDBを上書き、全損させた

• 当日早朝のデイリーバックアップから復元したので被害自体は大きくはなかった（ロストしたユーザデータがあるのでなかった、あるいは少なかったとは言わない。当時のチームメンバーには多大な迷惑をかけた。反省している）

二度と惨劇を起こさないためにどうしたのか

• 該当DBサーバのcrontabから当該シェルを削除した
• 計画メンテの作業予定に後始末という項目を追加して使用したリソースの片づけを徹底することを 心に刻んだｗ
• ポストモーテムとしては下の下
• が、一回きりの移行作業自体は問題なく出来ていて、後片付けを計画に含めていなかったという話であり、やるなら作業計画書等に後始末の記載を徹底する、等があるんだと思うが、当時の職場にはそういう雰囲気も、次の機会もない（DB移行なんて何度もやらない）というのがあってなぁなぁに終わった

最後に

• 手順書を書くよりコードで予定通りフルオートにしたのは今でも間違ったとは思ってない
• 当時書いたシェルファンクションは今も役に立ってるのでインフラ屋もコード管理大事
• crontab は年をまたいで再実行されるので、月日日時を指定していても安心するな
• 使い終わったリソースを片づけるのを手順書やチェックリストに記載するべし。手順書等のひな形に後始末の欄を作っておくのは有用

それでは聞いてください。crontab database ～君がしでかしてくれたもの～

君とジョブの終わり　将来の夢
大きなサイズ忘れない
1年後の8月14日午前7時00分（実際の日時）
また出会えるのを信じて
最高の思い出を

出会いはふっとした瞬間
帰り道の交差点でひらめいてくれたね
「シェルで書いてcronで処理すれば当日コマンド打たなくてよくね？」
僕は照れくさそうに
crontab -e を打ちながら
本当はとてもとても
手抜きをしてた

あぁvimでシェルを綺麗に書いて
ちょっとドヤ顔
あぁログが時間とともに流れる

嬉しくって楽しくって
冒険もいろいろしたよね

二人の秘密のリポジトリ

君とジョブの終わり　将来の夢
日付でファイル作成し
1日後の朝7時
また出会えるのを信じて
痛恨の権限エラー

＜中略＞

君が最後まで
心から「消すの忘れないで」
叫んでたこと知ってたよ
涙を堪えて笑顔でrm -f
せつないよね
でかすぎるそのサイズ

突然の実行でどうしようもなく
始末書書くよログも残すよ
忘れないでね crontab -r
いつまでも

カーン。ありがとうございましたー。