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

語言: CN / TW / HK

作者|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 和外包商也能從中吸取教訓吧,雖然我懷疑他們根本不在乎。(肯定不在乎,直到現在這種上傳方式還是隻支持手動,想想這是為什麼!)

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