外企也半夜發佈上線嗎?

0 別把問題想得太複雜

  • 如果有灰度發佈的能力,最好白天發佈;
  • 如果沒有灰度發佈,只能在半夜發佈。

即使有灰度發佈能力,也不要沾沾自喜,好好反思一下你們的灰度發佈是否真的經得起考驗,還是僅僅是裝裝樣子。

回滾方案最好在上級環境中使用生產數據演練,避免在0.1%的情況下需要回滾時,發現無法簡單地通過發佈上一版本服務來回滾,屆時會非常尷尬。

同時,服務類型也需要考慮,比如大型網絡遊戲(如《王者榮耀》),都是在午夜時間停服維護,這其實說明了問題。

1 形式上,必須凌晨!

必須得在凌晨上線。程序員的工作有一個“原罪”,就是別人很難看出來你有多努力,尤其是管理層。如果你不上班搞凌晨發佈,管理層看不到你的努力,尤其是部門的整體表現。既然能選擇凌晨上線,那就凌晨上線!

如果有加班費或者調休補償,凌晨上線大家嗑着瓜子兒,喫着零食,公司提供的外賣和飲料,像開派對一樣,和樂融融地等待凌晨。如果有領導或者HR路過,大家一個個愁眉苦臉,盯着屏幕苦苦思索,心裏想,怎麼還不結束呢。

即使上線跟你沒關係,也要來,大家要在一起,部門派對。技術上早就不需要這麼幹了,但我們這裏就是喜歡看苦情戲,必須得凌晨,只是這種凌晨非彼凌晨,一起開party~

2 說點實際的

外企的發佈流程

對於外企來說,發佈流程相對規範:

  1. 項目規模小,客戶不多:
    這種情況下,隨時可以上線,比如一些管理系統或新項目的上線。

  2. 項目規模大,用戶量大:
    這種情況下,通常選擇訪問量較少的時間上線,一般是凌晨,有時甚至是週末的凌晨。

  • 年底會確定下一年的上線日期(release day),每個上線日之間會間隔一個半月,這個週期相當於敏捷開發中的迭代週期。如果業務組有需要,可以通過流程,在規定的上線日之外進行發佈。
  • 每年都有代碼凍結期(code freeze period),通常是12月凍結一個月,因爲聖誕假期維護人員放假,處理問題不方便,所以這個月不允許發佈。如果需要發佈,需要高級別領導批准。
  • 發佈環境分爲測試、集成測試和生產環境。測試環境每個組可以自由發佈,集成測試環境需要郵件通知支持組進行發佈,生產環境只能在發佈日發佈。發佈通常是一鍵部署(one click deployment),開發組提前在Jenkins或Udeploy等部署工具中寫好腳本,經過支持組審覈後,由支持組在發佈日進行實際操作。
  • 發佈日前一週的週五會封閉集成測試環境,各開發組應該提前一週將代碼部署到集成測試環境並通過測試,確保發佈時風險最小。如果在發佈周內發現問題,需要重新部署測試,需要部門領導審批。
  • 發佈日一般在美國時間週五下午9點(中國時間週六上午9點),各組提前填寫發佈申請報告,通過審批後通知支持組進行發佈。發佈完成後,各組需要在生產環境上確認,沒有問題則表示發佈成功。

小公司的發佈流程

一些小公司的發佈流程類似於上述流程,都是敏捷開發流程,發佈前在測試環境上測試代碼,發佈前代碼會封版,確保代碼質量。

互聯網公司發佈流程

對於包含高併發組件(如Redis集羣、Kafka等)的互聯網公司,發佈過程更加複雜,不僅需要管理代碼,還需要重啓中間件,或使用中間件清洗或導入數據。如果能在面試中證明自己參與過發佈,並解決過發佈中的問題,那麼一定能有效證明自己的商業項目經驗。

結論

無論是大公司還是小公司,凌晨發佈都是爲了確保用戶影響最小化,同時也是爲了在特殊情況下能快速響應並回滾。理解並掌握髮布流程,能夠幫助開發人員更好地應對上線過程中的各種問題。

關注我,緊跟本系列專欄文章,咱們下篇再續!

作者簡介:魔都技術專家,多家大廠後端一線研發經驗,在分佈式系統、和大數據系統等方面有多年的研究和實踐經驗,擁有從零到一的大數據平臺和基礎架構研發經驗,對分佈式存儲、數據平臺架構、數據倉庫等領域都有豐富實踐經驗。

各大技術社區頭部專家博主。具有豐富的引領團隊經驗,深厚業務架構和解決方案的積累。

負責:

  • 中央/分銷預訂系統性能優化
  • 活動&優惠券等營銷中臺建設
  • 交易平臺及數據中臺等架構和開發設計
  • 車聯網核心平臺-物聯網連接平臺、大數據平臺架構設計及優化

目前主攻降低軟件複雜性設計、構建高可用系統方向。

參考:

本文由博客一文多發平臺 OpenWrite 發佈!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章