經(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ā)布核心功能更新和關(guān)鍵BUG漏洞的補丁了，這并不是ZStack黔驢技窮，而是私有云主機產(chǎn)品已經(jīng)很完善了；我接觸過十幾個ZStack的客戶，大家也都沒反饋有什么BUG。
這里既有虛擬化軟件二十年的經(jīng)驗積累，也是ZStack研發(fā)測試團隊的軍功，還是“私有云/專有云”比公有云更穩(wěn)定可靠的明證。
每當有朋友想了解云主機該有哪些功能，我并不會讓他們盲目上手做實驗，而是推薦他們看ZStack的產(chǎn)品說明書，只要是圍繞云主機開展的功能，1000多頁說明書里應(yīng)有盡有。
02 嚴謹靈活的權(quán)限和流程
企業(yè)軟件的買單決策人是項目負責人、CIO和CEO，在標準軟件功能雷同以后，企業(yè)更看重商業(yè)軟件和自身的管理流程是否匹配。企業(yè)的權(quán)限設(shè)計是以活動目錄AD為事實標準的，ZStack是我見到最用心去兼容企業(yè)權(quán)限設(shè)計的私有云軟件。
以ZStack 3.6.0的更新為例，本次更新將賬號和角色、權(quán)限和資源池（部門/項目）做了徹底的解耦。這個設(shè)計在外行看來是細枝末節(jié)，但對于企業(yè)付費者是核心訴求。
互聯(lián)網(wǎng)產(chǎn)品設(shè)計中，一個賬戶代表的自然人是權(quán)限和資源設(shè)計的核心，大家以賬戶的角度去管理資源，角色只是個“附加屬性”，資源池統(tǒng)計管理的功能也被弱化了。
但是企業(yè)產(chǎn)品設(shè)計中，并不存在一個資源只被一個賬戶管理的情況，賬戶只是個身份登錄憑證。角色實際是一個權(quán)限集合，企業(yè)產(chǎn)品的授權(quán)操作是給賬戶賦予某種角色，據(jù)此清晰表述一堆用戶對一個資源池的授權(quán)粒度。
ZStack的另一重要功能是承載審批和業(yè)務(wù)操作的工單。傳統(tǒng)工單更多是郵件的變體，參與者的角色只有客戶和技術(shù)支持，最終工單落實要靠工程師跨到另一個系統(tǒng)去操作；這種工單拿到企業(yè)環(huán)境價值不大，還不如郵件審批來的輕快。
帶審批邏輯的工單，需要將“客戶VS技術(shù)支持”的簡單溝通，變成所有相關(guān)角色參與審批的企業(yè)管理過程；ZStack的工單系統(tǒng)還和業(yè)務(wù)系統(tǒng)緊密結(jié)合，流程審批結(jié)束時，既可以自動授予權(quán)限，也可以主動完成工作。這種工單系統(tǒng)本質(zhì)上是企業(yè)客戶要的流程自控系統(tǒng)。
我并不信任互聯(lián)網(wǎng)思維的云產(chǎn)品設(shè)計，只要客戶還是要“勾選用戶注冊協(xié)議”，這就不是一個平等的甲乙方關(guān)系，而是一個牧羊人和羊群的關(guān)系，牧羊人不會尊重羊群的管理訴求。
03 尊重工程師的操作優(yōu)化
ZStack3.6.0版本希望實現(xiàn)從造船到練兵，要想順暢完成練兵，就要理解和尊重客戶側(cè)的工程師，順應(yīng)他們的傳統(tǒng)工作習慣，而且減少繁瑣易錯操作，讓客戶專注核心業(yè)務(wù)判斷。
順應(yīng)傳統(tǒng)工作習慣并不是貶義詞，比如在網(wǎng)絡(luò)設(shè)計中，傳統(tǒng)不等于過時，可能是經(jīng)典場景中的經(jīng)典設(shè)計。
ZStack在本次更新中，一個重要網(wǎng)絡(luò)功能就是VPC防火墻。很多人會將防火墻和安全組混淆，將架構(gòu)師和軟件研發(fā)提出的防火墻設(shè)置建議，直接扭曲成安全組配置。但ZStack的說明文檔很清楚的解釋了，防火墻不等于安全組。
安全組誕生于大二層網(wǎng)絡(luò)時代，做不好二層隔離那就先做好三層隔離，其部署位置在云主機的網(wǎng)卡上，其重點防范的是其他云主機的非授權(quán)訪問。在二層隔離VxLan普及以后，安全組的東西向流量隔離功能已經(jīng)略有雞肋，其南北向訪問的配置規(guī)則則過于簡陋。安全組沒必要識別目標IP和端口，因為作用點就是本網(wǎng)卡；我們曾經(jīng)熟悉的“放行所有ESTABLISHED狀態(tài)報文”，在安全組模式下也無法設(shè)置。
防火墻是部署在VPC路由器上的，并不關(guān)注內(nèi)網(wǎng)傳輸，但對外部訪問的控制粒度很細，不僅可以識別源IP目標IP，對協(xié)議中的報文狀態(tài)也有清晰的識別能力。對于老網(wǎng)絡(luò)工程師來說，防火墻規(guī)則中的“拒絕”和“丟棄”的區(qū)別，可以當做經(jīng)典面試題，而防火墻規(guī)則中復雜的優(yōu)先級設(shè)計，是網(wǎng)絡(luò)工程師炫耀邏輯和工程能力的最好戰(zhàn)場。此外VPC路由器支持了NetFlow，在VPC內(nèi)排查故障，跟在物理環(huán)境上已經(jīng)相似了。
ZStack每次更新都有大量操作簡化優(yōu)化，3.6.0版也不例外，目標是讓使用者從邊思考邊操作一堆繁瑣命令，變?yōu)橹凰伎家淮魏诵膯栴}，只發(fā)出一條簡單指令。
前文談過權(quán)限設(shè)計之后，管理員就要做一個工作——在私有云平臺上創(chuàng)建用戶。ZStack提供了AD對接、表格導入的方式批量創(chuàng)建用戶；云平臺管理員不用把時間花在如何點鼠標新增用戶上，而是集中精力判斷該添加哪個list的用戶。類似的操作優(yōu)化還有諸如主機硬盤同時快照、云主機優(yōu)先在舊宿主啟動，當主機和硬盤遷移時對目標物理機按負載高低排序。
如果說批量創(chuàng)建用戶功能是個非常規(guī)的單薄操作，那我們就看V2V的自動遷移，ZStack很早就支持vCenter云主機批量遷移，本次更新后支持了KVM云主機批量自動遷移。
V2V遷移本來是個重度依賴遷移工程師人力的工作，要求遷移工程師對業(yè)務(wù)了解、對通用虛擬化標準了解、對新舊V2V資源池的配置了解，然后瞪大了眼睛一臺一臺遷移。現(xiàn)在ZStack做了足夠多的適配，將V2V遷移自動化，那遷移工程師的工作量會極大降低，他們的重點精力放在選擇遷移對象和時機上。
高危操作并不能通過“操作優(yōu)化”來避免，平臺能做的只是精細化權(quán)限和明確審批過程，但絕對不是無故拖長審批過程甚至干擾高危操作，執(zhí)劍人終歸要承擔執(zhí)劍人的責任。
04 利器在手活學活用
我經(jīng)常強調(diào)一個概念，成熟的商業(yè)軟件絕對不會讓甲方工程師邊緣化和失業(yè)；而是給甲方工程師留下“肥而不膩”的工作量。甲方工程師始終是一個有決策能力的專家，而非給供應(yīng)商打工的苦力。
“肥而不膩的肥”，指的是高含金量的工作是有業(yè)務(wù)價值、無法被簡單匯總的工作；比如ZStack的權(quán)限設(shè)計只是個趁手的好工具，甲方工程師仍然要結(jié)合實際業(yè)務(wù)做精細調(diào)試；比如防火墻的策略設(shè)置比安全組復雜多了。
“肥而不膩的膩”，指的是別讓甲方工程師太過勞累繁瑣，比如我不確認V2V自動遷移能切掉幾個友商KVM的項目，但我相信遷移工程師不會因為選擇了ZStack而面臨過大的工作量。
現(xiàn)在ZStack給甲方工程師打造的這套私有云軟件，是有意識也有能力讓客戶側(cè)工程師開心放心的練兵，最終用這套軟件證明自身團隊的價值。
再先進的武器也是為人設(shè)計的，即使無人機也要聽司令官下命令。科幻小說里經(jīng)常YY出脫離人類控制的滅世AI軍隊，但能毀掉使用者的程序，就是有嚴重BUG的程序，或者空談式Y(jié)Y。
【ZStack學堂】第二季第10期：ZStack 3.6.0 功能講解
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
