經(jīng)常在新聞里聽到“企業(yè)號航母”并不是新船，它是1962-2012年服役的，其核心功能已經(jīng)穩(wěn)定運行了50年。鐵打的營盤流水的兵，船上的人經(jīng)常變，電控系統(tǒng)和操作流程，既在尊重傳統(tǒng)，也在持續(xù)演進之中。

體驗完ZStack 3.6.0版本的更新，我看到了一個新興商業(yè)軟件的成熟過程。

如果用一個航母戰(zhàn)斗群來比擬一個私有云計算平臺，ZStack從軟件功能上已經(jīng)完成了“造一艘航母”的過程，這幾次更新主要是“完善管理和人為操作的軟裝”，說通俗點就是讓練兵更容易。

01核心功能穩(wěn)定

ZStack很久沒有發(fā)布核心功能更新和關鍵BUG漏洞的補丁了，這并不是ZStack黔驢技窮，而是私有云主機產(chǎn)品已經(jīng)很完善了;我接觸過十幾個ZStack的客戶，大家也都沒反饋有什么BUG。

這里既有虛擬化軟件二十年的經(jīng)驗積累，也是ZStack研發(fā)測試團隊的軍功，還是“私有云/專有云”比公有云更穩(wěn)定可靠的明證。

每當有朋友想了解云主機該有哪些功能，我并不會讓他們盲目上手做實驗，而是推薦他們看ZStack的產(chǎn)品說明書，只要是圍繞云主機開展的功能，1000多頁說明書里應有盡有。

02嚴謹靈活的權(quán)限和流程

企業(yè)軟件的買單決策人是項目負責人、CIO和CEO，在標準軟件功能雷同以后，企業(yè)更看重商業(yè)軟件和自身的管理流程是否匹配。企業(yè)的權(quán)限設計是以活動目錄AD為事實標準的，ZStack是我見到最用心去兼容企業(yè)權(quán)限設計的私有云軟件。

以ZStack 3.6.0的更新為例，本次更新將賬號和角色、權(quán)限和資源池(部門/項目)做了徹底的解耦。這個設計在外行看來是細枝末節(jié)，但對于企業(yè)付費者是核心訴求。

互聯(lián)網(wǎng)產(chǎn)品設計中，一個賬戶代表的自然人是權(quán)限和資源設計的核心，大家以賬戶的角度去管理資源，角色只是個“附加屬性”，資源池統(tǒng)計管理的功能也被弱化了。

但是企業(yè)產(chǎn)品設計中，并不存在一個資源只被一個賬戶管理的情況，賬戶只是個身份登錄憑證。角色實際是一個權(quán)限集合，企業(yè)產(chǎn)品的授權(quán)操作是給賬戶賦予某種角色，據(jù)此清晰表述一堆用戶對一個資源池的授權(quán)粒度。

ZStack的另一重要功能是承載審批和業(yè)務操作的工單。傳統(tǒng)工單更多是郵件的變體，參與者的角色只有客戶和技術(shù)支持，最終工單落實要靠工程師跨到另一個系統(tǒng)去操作;這種工單拿到企業(yè)環(huán)境價值不大，還不如郵件審批來的輕快。

帶審批邏輯的工單，需要將“客戶VS技術(shù)支持”的簡單溝通，變成所有相關角色參與審批的企業(yè)管理過程;ZStack的工單系統(tǒng)還和業(yè)務系統(tǒng)緊密結(jié)合，流程審批結(jié)束時，既可以自動授予權(quán)限，也可以主動完成工作。這種工單系統(tǒng)本質(zhì)上是企業(yè)客戶要的流程自控系統(tǒng)。

我并不信任互聯(lián)網(wǎng)思維的云產(chǎn)品設計，只要客戶還是要“勾選用戶注冊協(xié)議”，這就不是一個平等的甲乙方關系，而是一個牧羊人和羊群的關系，牧羊人不會尊重羊群的管理訴求。

03尊重工程師的操作優(yōu)化

ZStack3.6.0版本希望實現(xiàn)從造船到練兵，要想順暢完成練兵，就要理解和尊重客戶側(cè)的工程師，順應他們的傳統(tǒng)工作習慣，而且減少繁瑣易錯操作，讓客戶專注核心業(yè)務判斷。

順應傳統(tǒng)工作習慣并不是貶義詞，比如在網(wǎng)絡設計中，傳統(tǒng)不等于過時，可能是經(jīng)典場景中的經(jīng)典設計。

ZStack在本次更新中，一個重要網(wǎng)絡功能就是VPC防火墻。很多人會將防火墻和安全組混淆，將架構(gòu)師和軟件研發(fā)提出的防火墻設置建議，直接扭曲成安全組配置。但ZStack的說明文檔很清楚的解釋了，防火墻不等于安全組。

安全組誕生于大二層網(wǎng)絡時代，做不好二層隔離那就先做好三層隔離，其部署位置在云主機的網(wǎng)卡上，其重點防范的是其他云主機的非授權(quán)訪問。在二層隔離VxLan普及以后，安全組的東西向流量隔離功能已經(jīng)略有雞肋，其南北向訪問的配置規(guī)則則過于簡陋。安全組沒必要識別目標IP和端口，因為作用點就是本網(wǎng)卡;我們曾經(jīng)熟悉的“放行所有ESTABLISHED狀態(tài)報文”，在安全組模式下也無法設置。

防火墻是部署在VPC路由器上的，并不關注內(nèi)網(wǎng)傳輸，但對外部訪問的控制粒度很細，不僅可以識別源IP目標IP，對協(xié)議中的報文狀態(tài)也有清晰的識別能力。對于老網(wǎng)絡工程師來說，防火墻規(guī)則中的“拒絕”和“丟棄”的區(qū)別，可以當做經(jīng)典面試題，而防火墻規(guī)則中復雜的優(yōu)先級設計，是網(wǎng)絡工程師炫耀邏輯和工程能力的最好戰(zhàn)場。此外VPC路由器支持了NetFlow，在VPC內(nèi)排查故障，跟在物理環(huán)境上已經(jīng)相似了。

ZStack每次更新都有大量操作簡化優(yōu)化，3.6.0版也不例外，目標是讓使用者從邊思考邊操作一堆繁瑣命令，變?yōu)橹凰伎家淮魏诵膯栴}，只發(fā)出一條簡單指令。

前文談過權(quán)限設計之后，管理員就要做一個工作——在私有云平臺上創(chuàng)建用戶。ZStack提供了AD對接、表格導入的方式批量創(chuàng)建用戶;云平臺管理員不用把時間花在如何點鼠標新增用戶上，而是集中精力判斷該添加哪個list的用戶。類似的操作優(yōu)化還有諸如主機硬盤同時快照、云主機優(yōu)先在舊宿主啟動，當主機和硬盤遷移時對目標物理機按負載高低排序。

如果說批量創(chuàng)建用戶功能是個非常規(guī)的單薄操作，那我們就看V2V的自動遷移，ZStack很早就支持vCenter云主機批量遷移，本次更新后支持了KVM云主機批量自動遷移。

V2V遷移本來是個重度依賴遷移工程師人力的工作，要求遷移工程師對業(yè)務了解、對通用虛擬化標準了解、對新舊V2V資源池的配置了解，然后瞪大了眼睛一臺一臺遷移?，F(xiàn)在ZStack做了足夠多的適配，將V2V遷移自動化，那遷移工程師的工作量會極大降低，他們的重點精力放在選擇遷移對象和時機上。

高危操作并不能通過“操作優(yōu)化”來避免，平臺能做的只是精細化權(quán)限和明確審批過程，但絕對不是無故拖長審批過程甚至干擾高危操作，執(zhí)劍人終歸要承擔執(zhí)劍人的責任。

04利器在手活學活用

我經(jīng)常強調(diào)一個概念，成熟的商業(yè)軟件絕對不會讓甲方工程師邊緣化和失業(yè);而是給甲方工程師留下“肥而不膩”的工作量。甲方工程師始終是一個有決策能力的專家，而非給供應商打工的苦力。

“肥而不膩的肥”，指的是高含金量的工作是有業(yè)務價值、無法被簡單匯總的工作;比如ZStack的權(quán)限設計只是個趁手的好工具，甲方工程師仍然要結(jié)合實際業(yè)務做精細調(diào)試;比如防火墻的策略設置比安全組復雜多了。

“肥而不膩的膩”，指的是別讓甲方工程師太過勞累繁瑣，比如我不確認V2V自動遷移能切掉幾個友商KVM的項目，但我相信遷移工程師不會因為選擇了ZStack而面臨過大的工作量。

現(xiàn)在ZStack給甲方工程師打造的這套私有云軟件，是有意識也有能力讓客戶側(cè)工程師開心放心的練兵，最終用這套軟件證明自身團隊的價值。

再先進的武器也是為人設計的，即使無人機也要聽司令官下命令。科幻小說里經(jīng)常YY出脫離人類控制的滅世AI軍隊，但能毀掉使用者的程序，就是有嚴重BUG的程序，或者空談式Y(jié)Y。

【ZStack學堂】第二季第10期：ZStack 3.6.0 功能講解

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。