我的一點企業做雲經驗

最近，經常有朋友問我在企業做雲的經驗，也有人問我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。

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

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

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

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