Linus：就算我被巴士撞了，Linux內核也不會有事

編輯 | 小智

在 8 月 31 日舉行的北美開源峰會上，Linux 的創造者 Torvalds 在與 VMware 的首席開源官 Dirk Hohndel 的談話中分享了他對 Linux 未來的看法。他稱如果他被巴士撞了他不擔心內核會受到衝擊。雖然這個假設不太吉利，但卻很有道理，為什麼呢？

工作流程比代碼更重要

「我真正擔心的是補丁的流程，工作流程比代碼更重要，」Torvalds 說。「如果你有正確的工作流程，代碼就會自行解決，如果出現錯誤，我們知道如何處理。」

他承認他現在不清楚內核中的每一行代碼，但這並非是一件壞事。Torvalds 說，內核的龐大規模導致了它日益複雜化，而開源模式是內核成功的核心。因為在複雜的世界裡，應對複雜性的唯一方法是公開交流想法。你不能在一個封閉的環境中管理複雜性。

自 1992 年起 Linus 開始採納其他開發人員的補丁，如今，Linus 擁有一個實力超群的內核維護小組，Linux 系統的協助模式是 Linus 負責總體的協調和溝通，他會對接十餘名核心貢獻者，每個人都有自己負責的具體領域和項目內容，每次有新的開發任務時 Linus 會將它分配給對應的人；而這十餘位核心貢獻者又有各自的熟知並信賴的高手小團隊。Linus 只需知道將任務交給他自己團隊中十餘名成員哪個人即可。

Dirk Hohndel 曾經問 Linus，這樣的開發模式是否可持續？Linus 笑著回答如果當前團隊中有程序員變老變胖（感覺像在說自己哈哈）不想繼續做下去的話也沒有問題，因為會有新的程序員補充進來。Dirk 又追問 Linus 道，在內核不斷提升迭代的過程中，是不是你具有著絕對的決定權？Linus 回答到「不是的」，他發自內心地鼓勵大家按照自己的需求建立 fork，如果最終這樣的想法有良好的結果做證明，其精華部分就會被吸收到 Linux 內核項目中。Dirk 對此總結，當今的分支發展再吸收代碼的模式其實反映的就是 Linus 本人或其團隊的決定性。

不難看出，Linus 等技術大神對於軟體開發的流程都非常看重。一個設計完備、良好運轉的軟體開發流程，對於提升軟體工程的效率，解決突發問題都大有裨益，那麼問題來了，怎麼做呢？我們看一下 Facebook 的經驗案例。

Facebook 是怎麼做開發與部署的？

Facebook 是世界上最大的社交網站，早在 2017 年，其月活就超過了 20 億，是微信的一倍還多。支持這樣一個站點的運行，還要不斷發布新的功能，Facebook 的工程師是如何做到這一切的？

Facebook 的工程師們不會像傳統軟體行業那樣使用瀑布模型進行開發，他們不斷地開發新的功能，並迅速上線，讓用戶能夠訪問到這些新功能，這就是大家口中經常提到的持續部署（continuous deployment）。在他們看來，Facebook 的開發永遠沒有到頭的那一天，代碼庫在不停地增長著，代碼隨時間呈現超線性增長的趨勢。

在 Facebook，所有前端工程師都工作在同一個穩定的分支上，這也能加快開發速度，因為省去了繁瑣的分支合併過程。在日常開發中，每個人都用 git 在本地進行開發，當代碼就緒之後，就會將它推送到 SVN 上（之所以是 SVN，這是出於歷史原因），這樣就很自然地區分開了開發中的代碼和可以上線的代碼。

但是為了保證網站的穩定運行，並非是工程師將代碼推送到 SVN 上，認為可以上線，代碼就能發布上線的。Facebook 採用了一種兼顧了速度與穩定性的做法——將每日發布與每周發布結合到一起。所有的代碼變動默認是每周發布，每次發布會包含相對比較多的變更，在每周日的下午，代碼會被發布工程師推送到 SVN 上，隨後會進行大量的自動測試，其中包含很多針對正確性和性能的回歸測試，這個版本會成為 Facebook 員工內部使用的默認版本，正式的發布通常被安排在周二下午。

發布工程師會為每個工程師的歷史表現打分，內部稱為「Push Karma」，比如那些代碼經常出問題的人，分數就會相對較低，他們的代碼自然也會受到更多的「關照」。這樣做的目的是控制發布的風險，而非對某人做出評判，因此這個分數是保密的。除此之外，越是大的變更，或者在 Code Review 時討論越是多的代碼，也是風險較高的地方，同樣會受到更多的「關照」。

在被納入發布之前，代碼已經經過了開發者的單元測試和 Code Review，在 Facebook，Code Review 是非常重要的事情，他們使用名為 Phabricator 的工具進行 Code Reivew，該工具是和代碼版本管理整合在一起的。

在大量的自動化測試之外，每位員工在內部使用 Facebook 時也相當於進行了高密度的測試，每位員工都能報告自己發現的問題，寫代碼的人多了，代碼增長的快了，相對而言，對代碼進行測試的人也多了。

在性能方面，Facebook 使用 Perflab 對新老代碼的性能進行對比，如果新的代碼性能不理想，並且開發工程師無法及時修復，那麼相關代碼就會從本次發布中剔除出去，待問題修復後再進行發布。每個小的性能問題都是不容忽視的，因為小問題會很快累積起來，變成影響容量和性能的大問題，Perflab 能通過圖表的形式直觀地展現系統的性能。

Facebook 每周的發布是分階段進行的，首先是 H1，即部署到僅有內部訪問的伺服器上，進行最後的測試，很多公司也稱其為「預發布」；隨後是 H2，部署到幾千台伺服器上，開放給一小部分用戶；如果 H2 階段沒有發現問題，則進入 H3，部署到全部伺服器上。

如果在這個過程中發現問題，工程師會立即進行修復，隨後重新開始分階段的部署。當然，也可以選擇回滾代碼，有兩種回滾方式——常見的是回滾某個變更及其依賴的文件，另一種則是回滾整個二進位包。

這個「准持續（quasi-continuous）發布周期」的最大優點在於：它迫使我們開發下一代工具、自動化和流程，以使公司能夠擴大規模。

在發布時，與變更相關的開發者必須在線，發布工程師會通過 IRC 機器人進行確認，如果人不在，那麼他的變更會被回滾。這樣保證了問題能夠在上線之初就被快速發現並修復，當然，想在這麼大的一個系統里及時發現一些問題有時也是很困難的，所以 Facebook 會結合內部工具 Claspin 和外部的信息源（比如 Twitter）持續地監控系統的健康狀態。

通過 Gatekeeper 系統，工程師們可以方便地控制多少用戶能夠訪問特定的新功能，篩選的條件可以是地區，也可以是年齡，在遇到問題時也能迅速關閉某個功能的入口。在 Gatekeeper 的幫助下，工程師們能方便地進行 A/B 測試，藉此迅速收集用戶的真實體驗，對產品做出調整。不要忘了，在 Facebook，是工程師來選擇自己做什麼的，那麼工程師們肯定是選擇把東西做出來，看看用戶的反應，而不是坐在會議室里和一堆人開會去猜測用戶想要什麼。

現在，Facebook 有數千名名開發工程師，但卻沒有獨立的測試工程師。每位工程師都可以看到全部的代碼，並且能提交補丁，或者提交詳細的問題描述。工程師們需要自己編寫詳盡的單元測試，他們的代碼還要通過所有的回歸測試，並能支持後續的各種運維工作。

除了要對自己的代碼負責，他們還要面對各種巨大的挑戰，往往要針對多種解決方案進行大量試驗。比如，當時為了解決 PHP 的性能問題，有 3 個不同的方案同時在進行開發，當某個方案的負責人發現另一個方案更好時，他們就會停下來；最後 HipHop 勝出了，但另兩組人的精力也沒白費，他們提供了重要的備份能力。

看了 Facebook 的經驗以後，你有什麼感想？

你能分享下你現在公司的軟體開發與管理流程是怎樣的嗎？

今日薦文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！