經常在新聞裡聽到“企業号航母”并不是新船，它是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資源池的配置了解，然後瞪大了眼睛一台一台遷移。現在ZStack做了足夠多的适配，将V2V遷移自動化，那遷移工程師的工作量會極大降低，他們的重點精力放在選擇遷移對象和時機上。
高危操作并不能通過“操作優化”來避免，平台能做的隻是精細化權限和明确審批過程，但不是無故拖長審批過程甚至幹擾高危操作，執劍人終歸要承擔執劍人的責任。
04 利器在手活學活用
我經常強調一個概念，成熟的商業軟件不會讓甲方工程師邊緣化和失業;而是給甲方工程師留下“肥而不膩”的工作量。甲方工程師始終是一個有決策能力的專家，而非給供應商打工的苦力。
“肥而不膩的肥”，指的是高含金量的工作是有業務價值、無法被簡單彙總的工作;比如ZStack的權限設計隻是個趁手的好工具，甲方工程師仍然要結合實際業務做精細調試;比如防火牆的策略設置比安全組複雜多了。
“肥而不膩的膩”，指的是别讓甲方工程師太過勞累繁瑣，比如我不确認V2V自動遷移能切掉幾個友商KVM的項目，但我相信遷移工程師不會因為選擇了ZStack而面臨過大的工作量。
現在ZStack給甲方工程師打造的這套私有雲軟件，是有意識也有能力讓客戶側工程師開心放心的練兵，最終用這套軟件證明自身團隊的價值。
再先進的武器也是為人設計的，即使無人機也要聽司令官下命令。科幻小說裡經常YY出脫離人類控制的滅世AI軍隊，但能毀掉使用者的程序，就是有嚴重BUG的程序，或者空談式YY。
【ZStack學堂】第二季第10期：ZStack 3.6.0 功能講解
免責聲明：本文僅代表作者個人觀點，與每日科技網無關。其原創性以及文中陳述文字和内容未經本站證實，對本文以及其中全部或者部分内容、文字的真實性、完整性、及時性本站不作任何保證或承諾，請讀者僅作參考，并請自行核實相關内容。
本網站有部分内容均轉載自其它媒體，轉載目的在于傳遞更多信息，并不代表本網贊同其觀點和對其真實性負責，若因作品内容、知識産權、版權和其他問題，請及時提供相關證明等材料并與我們聯系，本網站将在規定時間内給予删除等相關處理.
