OpenStack開源實踐

這是一個開源的時代，這也是一個開源價值被逐漸認同的時代，大家如何認識開源，如何使用開源？如何平衡社區開發與公司開發的關系？

在10月15~17日召開的 QCon上海2015 上，我們設置了開源專題，探討了開源相關的話題。UnitedStack平臺開發部負責人、OpenStack社區活躍開發者 邵國健 ，分享了他們在參與OpenStack社區開發方面的一些經驗： 《OpenStack開源實踐》 （幻燈片）。本文即根據演講內容整理而成。

一.為什么參與社區開發

OpenStack作為一個全球的開源項目，匯聚了幾千名優秀的開發者參與其中。我們知道一個公司的研發水平總是有限的，作為工程師，參與社區開發能夠讓我們突破這種限制，能夠與全球最優秀的開發者一起交流和工作；學習和吸收社區正規的開發規范和開發流程；同時也能夠系統地培養自學能力。

另一方面，參與社區開發對公司而言也是非常有價值的。可以讓公司能夠更深入地理解OpenStack整個生態體系，理解每個新功能背后的需求，比如，當我們可以去閱讀社區的郵件列表、BP、討論，參與在線會議時，實際上是為了了解一個功能是如何演進的，知道這個功能怎么用，更要理解為什么會有這個功能；另外，參與社區開發能夠讓公司了解社區的發展方向和趨勢，為未來的產品和開發工作提供指導，在變化來臨之前提前做好準備。

在UnitedStack，我們有85%的工程師參與OpenStack社區開發，并向社區提交了代碼，其中有70%的工程師的代碼已經被合并到社區項目。這些工程師平時的工作就與社區有很大的關系，工作的一部分就是研究社區項目。

二.開源項目與公司項目

在基于OpenStack進行二次開發的過程中會遇到許多困難和挑戰，同時在運營OpenStack的過程中，我們也會不斷收到來自內部和客戶的需求。那么，我們是如何處理開源項目與公司項目之關系的呢？

這里說的開源項目主要是OpenStack的官方項目，而公司項目則指我們的UOS項目。 兩類項目的區別還是挺大的。

首先，開源項目的需求來源主要是社區討論，當然實際上可能來自廠商需求，但最終確定需求的一定是社區討論；而我們的公司項目的需求有一部分來自社區，即由產品驅動，而另一部分則由客戶驅動，因為UOS不單單是要讓OpenStack各個組件穩定運行，更重要的是要讓OpenStack真正落地到客戶的具體生產實踐中，這中間肯定會不斷加入客戶的需求。

其次，開源項目的開發流程比較嚴格，發布周期比較長，現在OpenStack社區基本保持每6個月發布一個大版本的頻率；而UOS項目的開發流程稍微靈活，能夠根據具體情況進行調整，比如如果線上出現嚴重bug，我們就會臨時發布一個版本做hotfix，而社區就沒有這種需求；同時，對于一部分自研項目，我們的開發周期也盡可能短，讓客戶能夠盡快用上功能更豐富、體驗更好、更穩定的版本，我們盡可能通過完整的測試流程來保證產品質量，縮短發布周期。

最后，對于交付方式，OpenStack的目標是提供一個穩定版本，只需要在保證功能的基礎上，避免代碼中出現嚴重bug即可交付；而UOS的目標不僅是讓OpenStack真正在客戶生產環境中穩定地運行，同時需要給客戶提供持續運營的能力。

UOS項目

UOS項目主要分為兩類，第一類是社區項目，主要基于OpenStack原生項目進行開發；第二類是自研項目，主要是指在實際生產中，由于社區不提供或者做的不夠好的，我們自研的項目。其中，社區項目大概占所有項目的45%，而自研項目大概是55%左右。

社區項目主要包括OpenStack的主要項目，比如用于認證的Keystone項目，用于計算的Nova項目，用于網絡的Neutron項目等，我們都在這些項目基礎上做了深度的二次開發。

自研項目包括面板項目、計費系統、工單系統、動態配置服務、線上健康檢查服務等。以面板項目為例，我們幾乎重寫了OpenStack整個控制面板，同時提供功能全面的運營管理系統對整個平臺的資源進行統一管理。

社區項目

我們對社區項目采取的策略是這樣的：對于不滿足需求的功能，在社區項目的基礎上做二次開發，但在開發之前必須要深入理解項目的代碼結構和開發方式，這也是我們之前提到參與社區開發的目的，因為只有理解掌握了，才知道怎么去改進它。

在開發過程中，我們遵循一個原則：只做擴展，不做修改。也就是盡量以插件的形式進行開發，不對原生代碼做侵入性的改動。這樣做有幾個好處，一是在未來大版本升級時，可以最大化地減少代碼沖突，以最小的代價更新到新版本；二是保持所有原生API的兼容性，這樣就可以利用OpenStack現有的生態圈，更方便地與OpenStack現有系統和周邊工具進行集成。

最后，也是做社區項目最重要的一點，必須時刻保持與社區的同步，這并不是說需要保持代碼的時時更新，而是需要關注社區的發展和趨勢，對變化做到未雨綢繆。

從上面我們可以看出，基于社區項目做二次開發是一個比較辛苦的過程，不僅需要深入了解社區代碼，還需要對需求和OpenStack生態系統有深度的把握能力，這對團隊的要求是比較高的。

自研項目

對于自研項目，我們要求以社區規范進行開發，要求有完善的文檔和測試用例，并且在需要的時候能夠反饋社區。

三.開源文化如何影響公司

既然開源社區和開源文化對我們如此重要，那么我們公司在開源文化的影響下，又做了哪些改變呢？ 個人感觸較深的主要有三個方面： 新人培養機制、信息傳遞方式和公司組織結構。

新人培養機制

我們希望利用社區優秀的資源對新員工進行培養。在UnitedStack，新員工在入職的第一個月會全職參與社區開發，我們會要求他先閱讀社區文檔，了解OpenStack社區的項目結構和開發流程；然后挑選一個項目，讓他向這個項目提交代碼。通過這種方式，我們希望他能夠完整地經歷一遍社區的開發流程，這樣能夠對代碼風格、測試用例、Git分支管理等未來開發中常用的知識，都能有比較系統的感受和了解。

我們相信工程師在參與社區開發以后，能夠在技術能力和工作協作方式這兩方面得到提升，能更全面了解OpenStack的技術棧，熟悉文檔、開發、測試各個環節。比如我們有位工程師，為了合并一百行的代碼，先后向社區提交了五十幾個Patch，這從另一方面也說明社區開發的嚴謹性。

信息傳遞方式

開源文化讓我們的信息傳遞更加開放透明。在公司內部，我們要求所有技術文檔完全開放，所有會議紀要完全公開，這些要求其實很多公司都能做到，但最重要的一點，這一點我認為也是社區文化的精髓，我們要求所有的文檔都要做到無障礙閱讀。

什么是無障礙閱讀呢？

對于技術文檔，無論是一個對該領域完全陌生的初學者，還是在某一方面比較資深的工程師，在閱讀完你的文檔以后，都能夠有收獲，技術文檔必須要做到深入淺出，這樣才能鼓勵公司內部的知識流通，讓更多同事能夠自由選擇自己的感興趣的內容進行學習，同時他們也能夠幫助完善文檔，讓技術知識在公司內部沉淀和傳播。而會議紀要的無障礙閱讀，就是要讓沒有參加會議的人在閱讀完會議紀要以后，也能夠知道你們在會上討論了什么事情，形成什么樣的結論。

公司組織架構

最后，在組織架構上，開源文化促進我們更加扁平化。雖然扁平化這個詞已經泛濫了，但我認為很多公司只做到了形式上的扁平化，而沒有真正做到內在管理和工作方式的扁平化。

在典型的金字塔結構的公司中，指令由上到下傳達，一線工程師按照指令執行工作。 為了消除這種金字塔的結構，我們參照社區的方式，整個研發中心只由幾個主要項目組組成。在每個項目組里選出一位PTL作為項目負責人，負責管理項目組內部的所有工作，PTL在項目組內部有很大的自主權。為了協調項目組之間的工作，以及解決整個研發層面的事務，我們還成立一個技術委員會，由幾位在各自領域非常資深的PTL構成。

PTL作為整個項目組的負責人，負責項目組內部從產品、研發、測試、運維到部署等各環節的工作。我們對PTL的要求是要以社區方式運營項目組，比如開放內部文檔給全體員工，接納來自公司任何人的代碼提交和建議。并通過提升項目組的質量，吸引更多的工程師加入項目組。

技術委員會（TC）代表整個研發的最高水準，負責公司研發相關的方向和決策的制定。TC的所有工作并不是向某一個領導匯報，而是需要向全員公開。我們對TC有一個很重要的要求：問題止于TC。也就是研發層面的事情，如果由項目組上升到TC，那么在TC這一層面必須得到解決，沒有再往上拋的余地，所以我們要求TC成員必須是公司里某一領域非常專業的工程師。

我們要求每個工程師必須歸屬一個項目組，在此基礎上，工程師可以按照自己的興趣加入任何項目組。我們相信，只有興趣才是工作最大的動力。基于這樣的組織結構，項目組內部可以形成研發閉環，產品、開發、測試、部署、運維都可以在項目組內部完成，大大消除了部門之間的溝通成本。當然這對團隊成員也有很高的要求，他們不單單要專注于自己的工作，還需要對其它領域的工作內容也比較熟悉。

總結

我們在開源實踐中最重要的收獲，歸結起來只有兩點：首先是技術，我們學習和利用開源社區的技術，同時也貢獻自己的工作；但更重要的是，我們要學習和運用開源社區的管理精神，時刻保持開放透明！