テーブル全部消しちゃった笑 -ヒヤリハットから学ぶ当事者のメンタルと鎮火方法-

ROSCAFE
本当にあったエンジニア恐怖体験2024
での登壇資料

Transcript

1. テーブル全部消しちゃった笑 -ヒヤリハットから学ぶ当事者のメンタルと鎮火方法- 2024/6/24 roscafe 本当にあったエンジニア恐怖体験2024
2. 自己紹介 ・名前: Ibuki Yoshinaga ・誕生日: 2001/02/24 ・最近テックリードを名乗り始めました 🎉
3. 所属している会社 Misson eスポーツで一人ひとりの可能性がひろがる教育機会を 設立 2018年1月 正社員数 26名 契約社員/英会話講師などを含めると+200名ほど ゲシピ株式会社
4. 開発しているサービス 概要 主に小学生~大人向けの英会話レッスンを提供するtoCサ ービス 特徴 ネイティブスピーカーの講師陣とFortniteやマイクラを遊 びながら、英会話を教えてもらえる。 レッスン中の会話は基本英語、ゲームを用いたカリキュラ ムが組まれているため子供達が自主的に取り組みやすく 英語への苦手意識も克服できる。 eスポーツ英会話
5. 技術構成 STG/本番共通
6. タイトル、ヒヤッとしたんじゃないですか？
7. 事件当時の開発組織の構成 CTO BOKU デザイナー フルタイム 2年目 1年目 1年目 業務委託 インターン 新メンバー
8. ついに後輩ができた！！！
9. オンボーディング中 STG環境は他の部署の人も使えるテスト用の環境にもなってるから、好きに使って大 丈夫だよ。 機能によっては他の人にメールが飛んじゃったりするから気をつけてね。STG/本番に 関わらずバグを起こしちゃったり、何か困った時は必ず報告してね。 大先輩僕 わかりました！！！！！ インターン生 よろしい！ではタスクを渡します。 大先輩僕
10. その週末(日曜日)...
11. 状況説明 1. Vコーチという、Vtuberに英語の講師をしてもらうコースを開発していた 2. 新規のテーブルやカラムを追加する必要があった 3. たまにSTG環境/本番環境から流れるエラーログを調査してみたり... TablePlusというGUIのクライアントツールを使い複数環境のDBを行ったり来たりして いた 当日の流れ
12. ちょっと開発中のテーブル消そうかな... テーブルおかしくなってしまった。リセットしよう。(テーブル消去ポチ！w) やけにいつもより時間かかるな...？あ！！！！
13. テーブルを全て消し切った後に、DBを切り替え忘れたことに気が付く
14. 当時の心境 ・ 普通にやってしまった ・ え、これもしかして本番DBのデータ消しちゃってない...？ ・ 復旧できたとして、重大な障害につながりかねないことをしてしまった とにかく焦ってしまった
15. 頭をよぎった行動 深呼吸した後、2・3は人として論外だと考え直し除外。1を選択する。 ・やってしまったことはしょうがないから報告して謝る ・場合によっては日曜日に緊急事態を起こしてしまう 1. 報告・謝罪 ・どうにかこうにかログを追ってこっそり直す 2. もみ消す ・自分は楽になれる 3. どこかへ行く
16. そうこうしているうちに落ち着いてきた
17. そして謝罪へ... 落ち着いて調査した結果、思ったよりも被害がないことに気がついた ・ 消してしまったのはSTG環境のデータベースだった ・ STGでは恐らくバックアップは取っていない ・ 日曜日ということもあり、STGは開発者以外誰も使っていない可能性が高い 謝罪するにあたって行った調査
18. そして謝罪へ(2)... とりあえず報告 ・朝会で報告とごめんなさい ・他の部署へSTGが利用不可になっていることの報告 ・修正方法の立案と予防策を出す 他にやったこと
19. データの復旧まで 報告、復旧方法のレビューをした上で月曜日の午後一番に復旧終了 1. STGのバックアップが存在するかの確認 ➡️ なかった 2. 本番DBで個人情報が存在するテーブル/カラムの精査 3. 本番DBからSTGにデータを移植する 4. 個人情報を含むデータをマスキングする 5. 復旧確認(ログイン/メールが飛ぶかなど) 復旧フロー
20. 失敗を経て
21. ・ 業務上便利なツールを使ってしまっている自覚はある ・ TablePlusの場合SafeMode機能があるので現状はそれを使っている SafeMode機能の使用 ・ 元々正社員と一番歴の長い業務委託のみがアクセス可能➡︎ 今後もそれは継続 ・ 自分が変更を加える際はPRでバッチを発行して対応 ・ 今後: 本番DBを触る開発者が増えたらReadonly Userも発行 ・ 今後: 更新系SQLのログを全て保存できる仕組みの用意 本番DBへのアクセスの制限
22. まとめ
23. 焦るな 焦らずに考えれば、これだけまだ余裕がある ・本番環境のデータベースを消してしまった ・データは復旧できない ・会社に大損害を与えてしまった 思い込み ・STG環境でした ・本番環境から移植する形で復旧可能 ・本番環境はバックアップがあります 事実
24. 環境は確認しよう サービスに関わる誰しもが触れるということは、DBの削除以外にも誰しもが僕と同じ環 境切り替えミスによる失敗を経験をする恐れがある ADMIN向けの管理画面などでも、ヘッダーの色を変えるなどして開発者、他部署問わず 事故が起こりにくい環境を作った 1. 作業手順を明確にし、文章に起こしておく 2. 2人以上のメンバーを用意する 3. 今いる環境がSTG/本番のどれかをちゃんと確認する 4. 手順書に従い、アップデートをかける 5. 環境からはちゃんと切断する 本番環境を触る際の理想のフロー
25. 何かが起こったらすぐ報告 何かやってしまった時全力で、 「助けてください」が言える組織を作っていきたい。 ・事故が起きた時、もみ消すのは絶対に良くない ・気をつけようねではなく、出来るだけ事故が起こらないような環境づくりが大事 ・どれだけ小さいものでも、自分で解決できないミスでも、大小問わずすぐに周囲に 報告する ・何かが起きてもリカバリーできる空気感・仕組みを普段から用意しておく 報告してもらえる理想の環境を作る
26. ご清聴ありがとうございました！ 正社員・副業募集しています。