在淺黑科技《ZStack：這群做云的人有點“軸”》一文中，作者史中提到，這是一篇國產(chǎn)云計算佼佼者ZStack的創(chuàng)業(yè)史，文中記錄了因為熱愛而聚集起來的最早一批ZStacker，他們生活沒有退路，但熱愛未有止息。
實際上，這群人不止是做云“軸”，還很有趣呢。比如什么貓本軸海帶，70后知識儲備的90后......讓我們走進《ZStacker說》專欄，一起看看這些有趣的ZStacker叭。
第四期人物故事：ZStack解決方案與產(chǎn)品架構(gòu)師 蔣迪，一個70后臉的90后(筆者自定義標簽)，曾主導設(shè)計ZStack Mini、GPU池化、智能網(wǎng)卡適配、彈性裸金屬等重點產(chǎn)品和功能原型。
今年是我工作的第10年，距離我第一次體驗ZStack約莫過去了6年，在ZStack大家庭也近5年了，對私有云產(chǎn)品也有一些自己的拙見，希望可以借著這篇文章分享給大家。
又不是不能用
我的第一份工作就是做基于KVM的VDI，當時虛擬化平臺的選擇有很多，那時國外某開源云架構(gòu)在國內(nèi)正如火如荼，所以我也考慮過使用它作為基礎(chǔ)虛擬化平臺，但當我按照它的文檔吭哧吭哧搭出來用了兩天后我就決定放棄了，因為當時從文檔、部署、功能、運維、升級等等各個角度來看，它暫時沒有作為產(chǎn)品的良好基礎(chǔ)。
但后來發(fā)現(xiàn)各地項目一提云就是它，我覺得或許是我自身的問題，于是咨詢了幾個朋友，得到的答案都是“管它好不好，大家都在用，項目多你怕啥”。經(jīng)過再三考慮，本著對產(chǎn)品化的一絲樸素堅持，我最終還是決定放棄它了，后來事實證明這個選擇也算正確。
傲嬌的產(chǎn)品化與共同成長的客戶
中間我把早幾年積累的經(jīng)驗和知識總結(jié)成了一本書——《KVM私有云架構(gòu)設(shè)計與實踐》，機緣巧合這本書讓ZStack的兩位創(chuàng)始人張鑫和康總看到了，就邀請我來到ZStack。來到ZStack以后，除了見識到作為一個創(chuàng)業(yè)公司5年內(nèi)從幾十人到數(shù)百人規(guī)模的成長歷程外，也對to B的企業(yè)產(chǎn)品有了更深刻的理解。
在ZStack的頭兩年我作為售前，會跟著不同銷售全國跑，一起開疆拓土，比原先在研發(fā)崗有更多機會接觸不同的一線客戶，了解他們的各種使用場景。期間項目商機雖然很多，但ZStack作為一款不具備行業(yè)屬性的私有化的IaaS標準產(chǎn)品，起初在某些項目中是有些吃虧的。那段時間國內(nèi)OpenStack公司已經(jīng)把客戶市場教育的差不多了，經(jīng)常有客戶會問：你能不能定制，不能;你能不能代運維，不能;能不能提供PaaS和大數(shù)據(jù)，不能;我想搞個跟AWS一樣的云你們能接嗎?哈哈今天天氣不錯。
ZStack最讓我欣賞的就是這種不做項目制、搞標準化的產(chǎn)品“氣質(zhì)”，有些傲嬌但是又有自己的矜持，這為后面一些典型案例奠定了一個長久的基礎(chǔ)。比如在做某手機一線供應鏈客戶時，他們會拿ZStack對標V記產(chǎn)品，對產(chǎn)品該長什么樣有自己的認知，對細節(jié)的把控也很強。比如：做個配置修改你讓我登陸Linux改配置文件?對接商業(yè)SAN存儲你讓我選你們適配過驅(qū)動的?產(chǎn)品不支持在線升級?安裝部署得你們上門?服務(wù)器還得用你們都兼容過的?對不起出門左拐廠牌交給門衛(wèi)。
在甲方這樣獨立、自主的理念要求下我們PK掉一眾競爭對手并成功進入他們的生產(chǎn)環(huán)境。在后續(xù)的跟進中他們也提了很多中肯的建(需)議(求)，并對ZStack表示高度肯定，也理解我們并不會把所有建議都做到產(chǎn)品中的“傲嬌”態(tài)度，因為在其他客戶場景中可能難以適用。擁有像這樣相互認可并一起成長的客戶，我覺得對產(chǎn)品打磨十分關(guān)鍵。
后來的很多項目證明這種產(chǎn)品“傲嬌”是利遠遠大于弊的，前面客戶提的需求和建議在我們向其他客戶輸出標準產(chǎn)品時提供了很多潛在幫助，在這幾年的信創(chuàng)項目中體現(xiàn)得更為明顯，最典型的幾個比如國密產(chǎn)品標準化、密評功能模塊化等。
做好技術(shù)產(chǎn)品化交付的“最后一公里”
云計算是IT技術(shù)的集大成者之一，比如AWS上不斷有一些既陌生又熟悉的新產(chǎn)品出現(xiàn)，像物聯(lián)網(wǎng)、量子計算、機器人、衛(wèi)星通信、AR/VR等。公有云可以把這些東西以成熟的產(chǎn)品交互呈現(xiàn)給用戶，然后由公有云廠商承擔復雜的后臺運維，但私有云很多場景下并不能這樣。有些大項目乙方可以代運維，但是頭發(fā)尖的客戶能有多少呢?更多不斷涌現(xiàn)且可持續(xù)性發(fā)展的往往是一些所謂的小項目，而這些項目的運維往往是用戶或者渠道商，所以私有云面向的最終用戶應該有兩種，一是最終用戶，二是運維人員。因此，我們做產(chǎn)品要把實現(xiàn)的復雜性隱藏掉，從而讓用戶集中關(guān)注他最該關(guān)注的事兒上。
既然認定了市場，那做出的產(chǎn)品就要去迎合這個市場的用戶，做某個領(lǐng)域的技術(shù)和做某個領(lǐng)域的產(chǎn)品是兩碼事兒，怎樣在提供技術(shù)的同時又充分體現(xiàn)“人文關(guān)懷”也是一個“匠人”活兒。比如ZStack Mini的定位是面向工業(yè)一線場景，那么我們產(chǎn)品設(shè)計時要考慮到一線人員的實際IT能力，所以交互一定要足夠具象，比如硬盤在哪個位置、虛擬機啟動在哪臺物理上、USB設(shè)備插在哪一個口上等等一些細節(jié)問題，有了這個基礎(chǔ)才能讓用戶在使用盡管看起來陌生的虛擬化容錯技術(shù)時有一種“一切盡在掌握中”的感覺。
另外在做異構(gòu)計算的產(chǎn)品適配時，針對像GPU、DPU、智能網(wǎng)卡這些用戶比較容易體驗到IT工程技術(shù)發(fā)展成果的設(shè)備，我們除了要考慮把技術(shù)集成到ZStack并合理的提供出來，更要花費大量的精力思考如何把這些技術(shù)做得易用，包括安裝、配置、升級等等。
舉個例子，業(yè)界比較看好的vDPA方案，它能讓用戶在獲得與SR-IOV方案媲美的虛擬網(wǎng)卡性能的同時，解決SR-IOV虛擬機難以熱遷移的問題。聽起來十分美好，但是實際落地時事情遠非按照文檔把技術(shù)堆出來給用戶就完事兒這么簡單。我們需要考慮DPDK相關(guān)驅(qū)動和配置什么時候下發(fā)安裝、OVS網(wǎng)絡(luò)要不要與已有LinuxBridge集群主機復用或者允許熱升級，如果客戶要外接控制器我們應提供怎樣的接口、如果使用網(wǎng)卡軟vDPA那么犧牲的一個CPU核應該怎樣向用戶呈現(xiàn)或解釋、更換網(wǎng)卡時平臺配置是否要自動適配等等，這樣一些看起來與主要提供的技術(shù)目標關(guān)系不大且很繁瑣的特性，正是走好技術(shù)產(chǎn)品化交付“最后一公里”要克服的困難，也能讓用戶切實感受到被尊重。
信創(chuàng)不僅僅要“能用”，更要“好用”
關(guān)于產(chǎn)品其實我有一籮筐想說的話，但在今天的國際形勢之下，更想聊一聊信創(chuàng)的問題。大家看新聞應該都知道，最近俄羅斯也打算搞“局域網(wǎng)”了，他們很早就規(guī)劃逐步用國產(chǎn)替代基礎(chǔ)設(shè)施中依賴的進口軟硬件了。“以人為鑒，可以明得失;以史為鑒，可以知興替”，信創(chuàng)軟硬件被應用到關(guān)鍵基礎(chǔ)設(shè)施已經(jīng)成為趨勢。但如何選擇產(chǎn)品呢?我的答案是：不僅要“正確”，更要“好用”。
在這兩個原則的框定下，ZStack自研的產(chǎn)品核心以及長期以來堅持的產(chǎn)品化路線剛好能夠把它推進這個象限。這句話怎么理解呢?因為基礎(chǔ)設(shè)施的很多技術(shù)確實存在地緣壁壘，信創(chuàng)初期十分艱辛，做出來的東西可能僅僅達到“能用”的程度，但隨著市場的發(fā)展，這些產(chǎn)品不僅在功能上能滿足，在性能上也開始有指標超過國外同行了。私有云產(chǎn)品市場也是如此，初期確有很多國外開源云架構(gòu)換皮產(chǎn)品來充數(shù)，僅僅達到“能用”的標準，但隨著客戶要求的不斷提高，這些廠商開始有心無力。事實證明，非自研的架構(gòu)核心改起來都非常費勁。
而從我有限的角度來看，ZStack可能是市面上為數(shù)不多全部適配了主流信創(chuàng)CPU與服務(wù)器的私有云軟件產(chǎn)品公司，甚至在不支持硬件加速的虛擬化芯片問題上，ZStack也可以通過“彈性裸金屬”讓這些服務(wù)器順利“上云”，達到讓物理機享受與普通云主機一樣的云盤、云網(wǎng)絡(luò)并同池管理的目的。加之公司有強勁的QA團隊保證(插一句，ZStack的QA人均超過10臺物理服務(wù)器，比研發(fā)都“富有”，他們的理念和技術(shù)也很硬核)，ZStack的信創(chuàng)版本質(zhì)量也能得到充分保證。在目前的信創(chuàng)實際項目客戶看來，ZStack的云產(chǎn)品已經(jīng)遠超“能用”的標準，而在“好用”的賽道加速奔跑了。
（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
