最近，經常有朋友問我在企業做雲的經驗，也有人問我OpenStack二次開發專案經驗。正好這方面也有點經歷，那現在就把我過往有關經歷整理整理，總結出幾條心得體會，分享給大家。

技術：我們OpenStack二次開發做了什麼？

我之前介紹過我們基於OpenStack二次開發做了集團的基礎雲平臺。從環境上看，我們做了一個小型公有云，以及一個分佈在兩地三中心的私有云。 

從 OpenStack角度，主要包括OpenStack底層元件的二次開發，以及CMP的研發。兩者可能無法截然分開，所以我可能兩個都涉及到，但是本文內容以OpenStack元件的二次開發為主。我們主要在OpenStack Mitaka版本中的Glance/Nova/Neutron/Cinder/Keystone/Heat/Telemetry/OVSvAPP/Trove/Ironic等元件的基礎上，根據需求，做了一些二次開發。比如，我們在Telemetry 專案上做了不少改動，團隊之前有發過一篇文章 http://www.infoq.com/cn/articles/how-to-implement-cloud-monitoring-alarm-service。

技術：OpenStack二次開發的一些心得

• 如果有在利用社群程式碼和自研之間做取捨的話，還是儘量用社群開原始碼吧。節省成本又省事，將來還方便升級。

• 如果要自研的話，要儘量控制自研範圍。遵循『能不改就不改，能小改不大改』原則，只有在需要的時候，才修改社群程式碼。

• 根據需求合理選擇所需要才用的模組。在動手修改程式碼之前，多討論，多思考，多測試，多對比，多比較。如果沒把握，就先小動再大動，一步一步動。

• 積極貢獻社群。自研部分的程式碼，如果能合併到社群的，鼓勵貢獻到社群，各個企業要積極參與開源生態。

• 團隊要採用和社群同樣的流程、工具和要求。

團隊：產品和產品經理

OpenStack二次開發往往是以一個專案形式進行。這個專案要成功，一個好的產品經理非常重要。在我們團隊，我自己身兼產品經理這個角色。 

我覺得PM這個角色需要具備以下幾個條件：

• 技術 - 對OpenStack比較懂。這裡的『懂』，我認為更偏重廣度，而不是深度。所謂廣度，就是對OpenStack的主要元件、功能、用途、適用場景、使用方式等都比較瞭解。

• 業務 - 懂業務需求。OpenStack平臺是要支撐業務的，而業務的需求對OpenStack平臺很重要。OpenStack中的元件就像積木，不同的拼裝方式，會有不同的結果。每個企業都有自己獨特的業務場景。因此，產品經理需要充分了解這些業務場景，以及它們對OpenStack的影響和需求。

• 產品 - 具備產品經理的基本業務能力。包括但不限於，溝通能力（能說）、寫作能力（會寫）、各種工具使用（我當時比較土，主要就用Confluence管理文件、用Axure RP畫原型，用Word/Powerpoint/一些線上網站畫圖，用XMind花思維導圖等）、專案管理能力、對使用者體驗有一些瞭解等。這裡，我想區分一下2B產品經理和2C產品經理。我認為兩種角色有比較大的差距。2C的PM很多精力需要放到產品運營、使用者體驗上，而2B的PM的很多精力應該是放到企業使用者的需求上。

我覺得，PM如果具有懂技術的解決方案架構師的背景會比較合適。 

PM的主要職責，包括但不限於：

• 產品規劃。包括中長期的巨集觀規劃，專案分幾期，每期哪些功能，支援哪些業務；也包括短期規劃，一個專案內，有哪些功能，功能優先順序定義，上線計劃等。

• 產品設計。我當時主要的產品輸出是PRD文件。我們的主要參考物件包括青雲、阿里雲、騰訊雲、AWS等幾個公有云。

• 產品研發管理。從產品文件輸出，到產品研發，到產品上線，交付運維等，PM都需要有參與和一定程度的控制。 

我做PM的一點心得：

• 產品經理是要對產品成敗負責的人。

• 產品經理需要在做產品前、做產品中、產品釋出後不斷接觸使用者，不放過任何一個抱怨，不要怕被使用者嘲笑甚至罵，才能真正找到改進產品的點。

• 在參考其他家產品的時候，要充分考慮到每家產品面向的客戶及場景，也就是想明白他們為什麼會那麼實現。以雲彈性伸縮功能來舉例子。在公有云上，它是一個挺重要的功能。但是在私有云上，一來企業應用沒有多少機會需要伸縮，二來即使在某些時間要伸也一般都是提前準備好資源。因此，在私有云上，彈性伸縮並不是一個關鍵功能。

• 做企業基礎雲的產品的目標之一是實現使用者真正的自服務。使用者根據介面上的文字和提示，必要的時候結合使用者文件，可以自助順利地使用各雲產品。要儘量減少使用者找客服、運維，甚至研發的需求。

• 產品上線只是一個階段性的里程碑，不意味著產品開發的結束。只有不斷迭代，才能不斷改進產品。只有達到了設計要求的產品才能上線，否則就一定不要上線。產品經理必須有在需要的時候說『NO』的勇氣和決心。

• 產品經理是產品的第一個使用者。在尋找使用者點的時候，要拋棄一個專業人士的思維方式，把自己當做一個小白使用者，否則你永遠不知道使用者需要什麼，使用者不理解什麼，使用者抱怨什麼。還需要擺脫本位主義，少從個人角度思考，多站在使用者角度看問題。

• 產品不是瞭解點使用者需求，能畫點產品原型就能做好的。一個好的PM，會把產品裝在心裡，時不時拿出來琢磨琢磨，時不時跟使用者聊聊他們的使用感受和抱怨，不放過任何一個使用者反饋。

• 要學會區分真需求和偽需求，強需求和弱需求，緊急需求和一般需求，大需求和小需求等；要學會做長期規劃和短期規劃；要學會區分優先順序。

• 產品需要象小白一樣思考，不能動不動就拿技術實現說事。使用者不管你是如何實現的，只管你的產品能不能用，好不好用。 

團隊：技術團隊

沒有一個比較完整且給力的技術團隊，是做不了二次開發的。我們使用了OpenStack Mitaka版本中的Glance/Nova/Neutron/Cinder/Keystone/Heat/Telemetry/OVSvAPP/Trove/Ironic等元件。不管每個元件的二次開發程度如何，有個人看著肯定是需要的。核心模組，比如nova，cinder，neutron，儲存，網路，運維等，需要有技術能力較強的人看著，其它較小的模組，可只花一小部分時間看著。因此，技術團隊的骨架非常重要，就像足球隊的中軸線一樣。無論成員怎麼變化，只要骨架不大變，那都問題不大。 

我們openstack團隊的組織結構大概包括：產品經理、介面設計師、技術架構師、技術經理、開發、測試、映象和部署、運維等。 

做法：做雲是整個公司的事情

雲不只是一個雲團隊的事情。一公司做雲，需要公司多個團隊的參與。

• 戰略團隊：戰略團隊負責公司的做雲戰略，至少包括優勢、劣勢、機遇和挑戰等四個維度的分析。這個戰略會對公司做雲進行頂層設計。設計好以後，就是落地的事情了。

• 雲研發和運維團隊：這個就不再細說了，其職責是規劃、建設、運維雲平臺。

• IDC團隊：雲平臺在IDC中執行，因此肯定需要IDC團隊的參與。IDC做不好，雲平臺就不會執行得好。

• 運營團隊：雲搭好以後，需要運營團隊來把它推廣給使用者。需要確定推廣策略、計費方式、回款方法等。

• 客服團隊：運營團隊把雲推廣出去後，客戶就會來上雲，客服團隊是負責接待客戶、提供方案、處理問題的。這團隊要熟悉雲，懂得一些雲上實踐，還能做好前後臺的溝通。

• 應用團隊：應用團隊是雲資源的申請者和使用者。該團隊需要懂得如何在雲上部署業務，如何做高可用架構，如何運維雲上應用。

• 市場和銷售團隊：如果有云產品對外銷售，那就需要這兩個團隊了。雲產品往往需要技術型市場和銷售人員，需要對雲產品和方案有一定了解。

• 後臺支撐團隊：包括採購、人事等團隊，需要考慮具體情況，對既有流程做一些調整。 

做法：按次序做事

我兒子在上課外課時，老師反覆強調一個做法，就是要『有序思考』。大部分題目，通過有序思考，都能解決。回到我們做專案，有序做事也很重要，很有價值。我想說不要想一口吃掉大象。 

我們做基礎雲，從不同維度有序地進行：

• 先搞OpenStack一個region，到兩個再到三個region。

• 先用集中式儲存，再搞分散式儲存，資料逐步遷移。

• 從核心功能到擴充套件性功能。

• 對於大的功能，需要多次迭代，不要一上來就整大而全的。一步一步做紮實，獲得使用者認可，這才是王道。

• 先從外圍業務上雲，再到核心業務上雲。

• 團隊也由小而大，逐步擴張。 

這麼做有幾個好處，比如：

• 領導不擔心，因為你給他們看了總體規劃，還有具體的實施計劃，一步一個腳印，走得很踏實，領導當然放心。

• 團隊不緊張，有一個成長和適應的過程，能力平穩增長，承受的壓力平穩增長，心裡就舒坦。

• 使用者不擔心，看到前面的階段性成果後，使用者對新的功能和平臺會越來越放心。

• 投入更合理，不需要一次性大投入。

做法：按規律做事

任何事情都有其獨特的內在規律。違背了規律做事情，是要被懲罰的，只是時間問題。

• 做事情肯定需要投入。搞雲也不例外，甚至投入要更高。因為搞雲的人的工資確實比較高，這不是負責招聘的人決定的，而是行業決定的。而且，人家還要看你的平臺如何。好平臺，薪水還能打個折；平臺不夠好，人家還要加錢。所以企業對此要有心理和財務準備，一定要提前算好，能投入多少，能投幾年，投入產出比如何等，要是半途而廢對大家都不好。

• 雲技術真的很複雜。不要想著幾個人就能搞好，是需要一個團隊的，而且還要講究搭配，看團隊成員的水平。

• 雲平臺從規劃、研發、上線、運維等是一個流程性過程，不能想著一個月招聘，再一個月寫程式碼，然後第三個月就上線，然後還跑得又快又好。

• 做新技術的人有些不一樣，因此，有些管理政策需有些差別。比如，不能老想著搞雲的人一天到晚寫程式碼，人家還要學習新的技術，參加參加黑客鬆之類的碼農聚會，平時還要時不時聚會討論討論技術呢。

• 雲產品上線到穩定有個過程，不是上線了就穩定沒有問題了。這個過程中，需要有小白鼠來試用，不要想著放在那裡幾個月平臺就自己好起來了。很多時候，需要有推手，讓一些不那麼重要的應用先在上面跑起來。發現問題，及時修改，不斷迭代，才會有想要的結果。

• 雲產品從研發出來到看到經濟效益有個過程，還需要多種角色參與，比如運營、市場、銷售等。不能覺得有個好產品，很快就能賣出去回來錢。而且，這些都是必要條件，還不是充分條件。

• 開源社群、各種評獎大會、各種meetup的錢，PR的錢，該花還是要花。這就是所謂生態，和你看得慣看不慣無關。

心得：給做雲的技術人的幾句話

• 給企業做雲，穩定是第一位的。穩定，穩定，穩定，重要的事情說三遍！

• 雲技術真的很複雜。沒有金剛鑽，攬不了瓷器活。好好學習天天向上是王道。如果沒這心思，或者沒有體力，估計就得考慮轉型了。

• 除了鑽研技術以外，還要看看業務。技術是為業務服務的。業務是目標，技術是實現手段。不能在產品討論的時候一言不發，然後程式碼實現時候問題N多，使用者來問怎麼用一臉懵逼。

• 要將DevOps落到實處，不能只停留在理論和口頭上。比如，產品上線後到穩定前，建議研發積極主動參與運維工作。這麼做會有很多好處，比如看看自己做的東西跑得咋樣，使用者是怎麼用的，運維都在幹嘛等等。

• 為使用者做東西。有使用者用才是王道。介面畫得再好，新技術用的再多，如果沒有使用者用，一切就會白費了。

• 要低頭做事情，擡頭看榜樣。除了在某幾個方向有深入鑽研以外，還需要時不時看看技術發展大勢。雲這概念來自IBM，首先是AWS做出來的，當前公有云在引領著技術和產品發展趨勢。需要經常看看公有云廠家都在玩啥新東西。

• 產品、開發、測試、運維都是一個團隊，只是分工不同。只有齊心協力，才可能給使用者交付一個好的雲平臺。 

心得：給打算做雲的企業的幾句話

• 關於做雲的動機：是真的需要做雲嗎？要做的是哪種雲？打算投多少錢？打算投幾年？本來有個各種雲的列表，但是後來擔心對號入座就刪了。每種雲都有不同的做法，有些甚至迥乎不同，在動手之前一定要想清楚了。

• 關於自研和購買第三方產品之間的取捨：真要搞雲的話，要在自己搞雲研發團隊和購買第三方雲產品和服務之間做出合理抉擇。自己弄的話，算錢的時候要算仔細了，不能只算研發團隊那點工資，還有裝置、運維團隊、IDC等各種費用都得算。找外部團隊的話，要考慮的事情也不少，比如，現在團隊會測試外面廠家的產品不？報價合理不？口碑好不？有爛尾專案歷史不？是真做產品和技術的，還是做外包的？是有真本事的，還是動嘴皮的？團隊的人都在哪裡呢，是不是都撲在某個大客戶那裡了呢？有找三四家做下對比測試嗎？

• 關於雲的功能：真的要那麼多雲功能嗎？SDN是幹啥的，有哪些坑得先了解清楚；分散式檔案系統是幹啥的，市面上有便宜又好用的產品不？分散式儲存和SAN儲存啥關係，是替代呢，還是互補呢，還是什麼都不管反正就是要用？容器雲平臺真的需要嗎？公司現在和短期內有幾個應用能是面向容器開發的呢？研發團隊玩過容器沒？沒的話，是培訓呢，還是換團隊呢？

• 關於雲的目標：公司都有哪些應用系統呢？是不是有很多windows2000上跑的應用系統啊？KVM上跑windows虛機還好使不？是不是還有很多古老的系統放在某個角落？公司業務應用研發團隊主要是基於linux程式設計呢，還是基於windows程式設計呢？

• 該請的人要請，該花的人要花，該等的時間要等。需要的話，多問問專家吧。

• 尊重規律做事，不要想一口吃個胖子，不要幻想著很快一朵成本低又穩定效能又好各種應用都能跑的雲就降臨IDC。

• 一開始就考慮後路：想好雲團隊將來的出路。轟轟烈烈把內部雲平臺做完後，團隊要幹嘛去？是解散呢，還是去做外部市場呢？每種做法都需要有不同的方案，建議提前準備好。

• 做雲是一個公司的事情，不是某個事業部的事情。要有公司層次的總體部署。 

囉嗦了這麼多，有些是自己親身經歷的，有些是道聽途說的，有些是拍腦袋想的。希望做雲的人，和做雲用雲的企業單位都好運！ 

謝謝您的閱讀，也歡迎關注本人的公眾號：