我在產品上線前不小心刪除了7 TB的影片

作者｜thevinter

翻譯｜核子可樂

編輯｜燕珊

今天我們想分享的是一位初級開發者對於自身犯的某個錯誤的記錄。這個帖子在日前在 Hacker News 之所以引起很多人的討論和共鳴，或許是因為許多經驗豐富的工程師都是這麼走過來的。

雖然這是一個“新手貼”，但它也是個不錯的帖子。犯錯不可怕，最重要的是，犯錯後能吸取經驗教訓，讓自己會變得更強大。這位開發者把它寫下來鞏固自己學習過程中的理解，這對任何有類似經驗的初級開發人員來說都是有積極意義的。人人都會犯錯，關鍵是你下一步如何做。以下是帖子內容，我們將其翻譯出來，希望能為讀者帶來參考價值：

前 言

先跟大家打個招呼，我是個剛工作還不到一年的初級開發者，所以很多在各位看來不言而喻的道理我自己還沒摸索清楚。本文權當記錄成長過程中的點滴，請大家輕拍。

在很多高手們看來，這個故事簡直不可理喻……沒錯，裡頭有太多壞習慣、太多低階錯誤，在矽谷巨頭看來完全不可想象。但這就是世界各地小型 IT 企業的真實生存狀態，而且還在繼續困擾著無數像我這樣的從業者。

我目前是在義大利一家小開發公司（一共 10 個人）上班，主要是為當地企業開發管理各種網站和工具。另外，我們還跟義大利、英國和南非最大的幾家健身企業簽訂了大額合同。既然說是最大的健身企業，那他們應該知道自己想要什麼嘍？錯，他們完全不知道……當然，我不打算把鍋甩給他們，畢竟這裡的甲方和乙方都是一屁股爛賬、誰也別說誰。總之，讓咱們客觀回顧事件原委。

從專案說起

受保密協議所限，這裡我沒法透露太多。簡而言之，我們目前開發的專案需要使用大量影片，這些影片素材託管在 Vimeo 之上。公司當前用的是 VimeoOTT，也就是負責內容交付的前端平臺，但上頭打算逐步遷移至 Vimeo Enterprise。VimeoOTT 上需要遷移的影片大概有 500 段，但 Vimeo 並不提供簡單易行的遷移方法。去年 10 月左右，我曾經寫信給對方的支援團隊，詢問他們能不能幫助遷移，回覆中說他們“會調查一下”。然後就沒有然後了。

所以說，我們得重新上傳這些影片素材。我提議構建一個自定義 API 指令碼，從 OTT 那邊下載影片、再把素材上傳至 Enterprise（和我們的產品）。但管理層拒絕了這套方案，而是決定花錢請人來手動完成。接下來的一個月中，有人上傳了來自 OTT 的 500 段影片外加 400 段新影片，於是我們一下子就用光了 Enterprise 提供的全部 11 TB 儲存容量中的 9 TB，好在一切進展順利（雖然效率不高）。時間很快來到今年 4 月。

出問題了

突然之間，Vimeo 那邊似乎開了竅，想起我們之前提出的申請。於是在並未告知我司的情況下，他們決定把 OTT 上的所有影片都轉儲到 Enterprise 新平臺上。但為什麼不打個招呼呢？可能 Vimeo 根本就不關心吧。

他們重複上傳了我們這邊已經傳過的影片。

現在影片素材的總大小在 15 TB 左右，超出上限 4 TB。

就是說除非我們刪除一部分內容，否則根本沒法繼續上傳影片。我們詢問 Vimeo 能否恢復更改，但得到的卻是否定的答覆。最要命的是，再有一個禮拜左右產品就該上線了。

唯一的選擇就只能是手動刪除多出來的影片了，這活歸我來幹。很遺憾，我犯了個巨大的錯誤。

“解決方案”

（介紹一下背景，之前 7 個月裡我一直在使用 React，這也成了引爆問題的直接導火索）

幸運的是，我們在資料庫裡為每段影片都分配了一個“VimeoId”，所以我腦袋裡蹦出的第一個解決方案就是：

這兩條請求都是分頁的（只是具體方式略有不同），所以我編寫的實際程式碼是：

大家肯定一看就知道錯在哪了，現在我也看得出來。但當時我檢查了好幾遍，覺得它沒有任何問題。這裡劇透一下答案：

我當時已經習慣了 React，所以天然認定 url 會在頁面變數更改後立即重新整理，但事實並非如此。 所以在使用這個指令碼之後，所有不存在於我們資料庫第一頁裡的影片都會被從 Vimeo 中刪除。

這裡還有另一個問題：我測試了程式碼，並使用了以上示例中的這個錯誤迴圈。

我還做了幾次手動測試，但測試範圍就只有資料庫上的第一頁。哎，這本該很容易避免的一系列錯誤。

善後工作

好訊息是，Google Drive 資料夾裡還有一份影片備份，而且相關資訊也好好儲存在資料庫內。壞訊息是，這時候時間已經來到星期五，而我們最晚也得在星期二早上就把影片還原回去。當時公司的網路頻寬大概是每秒 30 MB，上傳資料總量在 8 TB 左右。不現實……我們得想點別的辦法。

我想到的第一個解決方案就是用 Google Drive API。我們這邊有全部上傳到資料庫的影片檔名，所以我很快寫下以下程式碼：

這意味著我可以用不同頁面多次執行指令碼，從而在不同網路上“並行化”整個過程。（我也想過換個高速網路環境，但一是沒有比較快捷的提速途徑、二是出站流量成本過高。）效果還是不理想，畢竟就算是飽和傳輸也得佔滿整整 4 天，再出一丁點問題就要超時。於是我又想到了一個辦法：

另一個解決方案

能不能直接把影片從 Google Drive 上傳到 Vimeo？我檢查了一下上傳頁面，並發現確實可以這麼操作。只是還有個小問題：它只支援手動操作，無法使用 API 自動優化，但優勢是上傳幾乎可以即時完成。也許還有更好的辦法，但我當時真的想不到了，所以我滿心歡喜地啟動了 Playwright。

Playwright 是一款自動 E2E 工具，可用於模擬使用者互動。具體來講，它可以按我們程式設計的指引點選網站上的不同位置。有它在，不就把人給解放出來了？

下面來看程式碼：（我剛開始用 Playwright、而且時間緊迫，所以寫得確實粗糙，請大家原諒）

這段程式碼確實不怎麼樣（特別是其中用超時來解決 Playwright 中.click() 的部分），但它還是發揮了符合預期的效果，只有一個意外：我沒能讓它正確點選查詢到的影片，而只是點到了“Select”按鈕上。直到現在，我也不知道這個問題該怎麼解決。所以就算是用上這段程式碼，我也得每 10 秒就手動單擊一次來選擇影片，這樣才能讓程式持續執行。我坐在螢幕前點了 10 分鐘，然後開始懷疑自己這是在搞什麼鬼……

我下載了一個自動點選器（xclicker），並把它設定成每 5 秒點選一次。成功！每段影片大概耗時 13 秒，一共 1000 段影片，用了 4 個小時所有影片就都上傳完成了。現在只剩最後一步：它們都有了新的“vimeoIds”，所以我得回到公司這邊的資料庫，用正確的 Id 值更新所有影片。但這次要簡單得多，用跟之前類似的 Python 指令碼就能輕鬆完成。

最後，所有影片上傳完成，產品終於能順利上線了。

總 結

這事讓我學到了什麼？首先就是在執行破壞性操作之前，先充分進行測試。也希望 Vimeo 和外包商也能從中吸取教訓吧，雖然我懷疑他們根本不在乎。（肯定不在乎，直到現在這種上傳方式還是隻支援手動，想想這是為什麼！）

http://blog.thevinter.com/posts/vimeo