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

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