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