“私のマシンでは動いたのに…”…本番メディアフォルダを消去するまで。
最近、Glintecoに新しいDevOpsインターンが加わりました。彼の最初の仕事の一つは、GitHub Actionsを使ってCI/CDをセットアップし、Djangoアプリケーションを開発サーバーにデプロイすることでした。
比較的安全なタスクだと思っていました。
メディアファイルの30％を失ったミス
デプロイテストを実行しようとした際、インターンはCI/CDパイプラインを構成して、アプリを開発サーバー上のテストサイトにデプロイしました。
しかし、開発サーバーは、稼働中のクライアントサイトで使用されているマウントされたフォルダを含む、本番データと共有ディレクトリを持っていました。
CI/CDパイプラインの設定ミスにより、デプロイによって共有MEDIAフォルダが上書きされ、ライブDjangoプロジェクトのアップロードされた画像とファイルがホストされていました。
バックアップなし。警告なし。ただ消えただけ。
突然、ライブサイトのページには壊れた画像リンクが溢れ、顧客に影響が出ました。そして、私たちは迅速に対応しなければなりませんでした。
災害からの復旧方法
私たちのDevOpsチームは迅速に動きました。
-
GitHubのコミットとCIログをチェックして、削除が発生した時点を特定しました
-
古いデータベースの参照とアプリケーションログからファイル名とパスを検索しました
-
チームが使用していたすべてのローカル開発マシンとデプロイターミナルを調べて、キャッシュされた画像や以前にアップロードされた画像を復旧しました
-
不足している画像を置き換えるために、ブログ投稿の新しい画像を手動でレビューおよび作成しました
最終的に、メディアファイルの約70％を復旧することができました。残りの30％は、主にブログ関連の画像で取り返しのつかないほど失われましたが、幸いにもユーザーにとって重要な機能には影響しませんでした。
しかし、もっとひどい事態になっていた可能性もありました。
重要な教訓（あなたも学ぶべきです）
この話は珍しいものではありませんが、痛みが非常に現実的です。私たちが学んだことを以下に示します。
1．本番データやキーを開発/テストサーバーで絶対に使用しないでください
開発環境は本番環境から完全に分離する必要があります。
-
異なるデータベース
-
異なるファイルパス
-
異なる環境変数（本番S3バケットキーは使用しないでください！）
2．デプロイ前に必ずバックアップしてください
開発サーバーであっても、重要なデータや共有データが含まれている場合は、デプロイ前にバックアップを自動化してください。サーバーが小さい場合は、簡単なtarballバックアップスクリプトを作成することもできます。
“バックアップが多すぎるということはありません。”
3．共有インフラストラクチャをテストに再利用しないでください
テストと本番ワークロードの両方で同じサーバー（または共有フォルダ）を使用しないでください。リソースが限られている場合は、少なくとも分離されたコンテナ、VM、またはマウントポイントを使用してください。
4．レビューと承認プロセスを実施してください
インターン（そしてフルタイムのエンジニアも）は常に：
-
PRを通じてデプロイ構成の変更を提出する必要があります。
-
レビューのためにシニアチームメンバーにタグ付けする必要があります。
-
デプロイ前にターゲット環境とファイルパスを確認する必要があります。
5．CI/CDパイプラインにセーフティネットを構築してください
次の保護策を追加してください。
-
実際のデプロイの前にドライランまたはステージングモードを実行します。
-
条件付きデプロイロジック（ブランチ、環境、またはディレクトリのチェック）を使用します。
-
ファイル操作のログとアラートを設定します。
6．デプロイ構成を文書化し、バージョン管理してください
何かが壊れた場合、バージョン管理されたインフラストラクチャがあれば、次のようなことができます。
-
変更を迅速に追跡する
-
必要に応じて元に戻す
-
ミスから学ぶ
結論
DevOpsは単なる自動化ではなく、安全な自動化です。
このインシデントは、小さな設定ミスが大きなデータ損失につながる可能性があることを、最善の意図を持っていても起こりうることを思い出させてくれました。
ブログの画像だけで済んでよかったです。しかし、次回はもっとひどい事態になる可能性があります。
この話を、あなたのチームのための戒めとチェックリストにしてください。
