個人一點企業作雲經驗

時間 2019-11-21

標籤個人一點 1點企業經驗简体版

原文原文鏈接

最近，常常有朋友問我在企業作雲的經驗，也有人問我OpenStack二次開發項目經驗。正好這方面也有點經歷，那如今就把我過往有關經歷整理整理，總結出幾條心得體會，分享給你們。linux

技術：咱們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。windows

技術：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。
一開始就考慮後路：想好雲團隊未來的出路。轟轟烈烈把內部雲平臺作完後，團隊要幹嗎去？是解散呢，仍是去作外部市場呢？每種作法都須要有不一樣的方案，建議提早準備好。
作雲是一個公司的事情，不是某個事業部的事情。要有公司層次的整體部署。