編者注：以下內容根據FIT2CLOUD飛致雲東區總經理徐桂林在4月22日“FIT2CLOUD飛致雲在線講堂”的直播內容整理而成。
大家好，今天我們直播的主題是《JumpServer爲什麼是多雲環境下更好用的堡壘機?》。我們和大家分享的內容包括：
一、堡壘機的背景介紹
二、堡壘機面臨的變革是什麼?
三、JumpServer如何思考這些變革?
四、JumpServer的使命與期待
一、堡壘機的背景介紹
堡壘機的誕生這件事情可能業界有不同的說法，目前比較普遍的認知是認爲在2005年堡壘機誕生了，也在這一年出現了支持字符運維審計，在此之前大家把它叫做跳板機或前置機。
2006年堡壘機進入了等保要求。堡壘機經歷了比較大的變化，堡壘機變成了等保的強制要求，得到了大量的推廣和普及。在這一年，堡壘機開始支持圖形界面的運維審計，所謂“圖形界面的運維審計”指的是以Windows爲代表的圖形界面。
2007年堡壘機加入了文件傳輸審計，上傳/下載文件通過堡壘機也有審計記錄。
2008年堡壘機加入應用訪問審計，這個功能也是現在大家普遍使用的功能，不管是Windows資產，還是Linux資產的審計，也不僅僅是對下載文件做審計，而且還可以對目標資產的某個應用的訪問和操作做審計。
2010年，堡壘機又開始涉及到SQL操作審計，堡壘機支持數據庫SQL審計，所有的SQL操作都可以審計記錄下來，可以做一些審計操作，阻斷操作。
2011年的時候，堡壘機開始支持線上運維操作的審覈，做什麼操作需要對方去審覈一下，看能不能操作。
從2005年誕生堡壘機垂直產品來看，到2011年，這七、八年的時間堡壘機的發展速度非常快，尤其是在等保要求的推動下，堡壘機每年都會有非常重要的功能誕生，並且持續加入產品裏面去。所以，像等保以及安全合規要求在這段時間內快速推動堡壘機往前進。
看這個時間軸你會發現，到2011年之後我就沒畫什麼東西了，我覺得這個也跟堡壘機目前的市場現狀有很大的呼應。我們發現，進入到2010年代時，堡壘機不管從自身功能，還是用戶的使用場景，以及用戶體驗上確實進入了發展相對緩慢的階段。很長時間內堡壘機的商業市場也就那幾家競爭，大家按部就班地使用那幾類的產品。
但不幸的是，從2010年企業IT迎來了一個非常重要的變革，那就是雲時代的到來。
在國外可能要更早一點，從2006年亞馬遜開始運營AWS開始，到國內2010年阿里雲開始對外服務，雲時代進行了非常快速的迭代。在這個時間點堡壘機卻按兵不動，好像保持了原來的狀態。但實際上堡壘機所處的時代和周邊的環境已經發生了巨大的變化，這些變化如果展開來說可以把它分成幾個方面。
■ 堡壘機訪問端
堡壘機有它的訪問端，有它的目標資產，中間是軟件，不管是從訪問端還是目標資產以及堡壘機自身，其實都在發生變化。比如說在訪問端，你用什麼東西來訪問堡壘機?在過去的十年裏，泛客戶端的現象非常普遍，不僅僅是臺式機、筆記本來使用你的堡壘機，你的手機都有可能有堡壘機的訪問需求。操作系統層面也會發生一些變化，原來客戶端以Windows爲主，現在Windows、Mac以及安卓、IOS這些系統都進入到用戶日常使用堡壘機的場景了。
更爲重要的是，“瀏覽器爲王”成爲這個時代最主流的一個變化。大家每天打開電腦，有多長時間是在瀏覽器內工作的?可能80%的時間都在瀏覽器內工作，通過瀏覽器內處理你的事務，做文檔編輯，瀏覽信息，做軟件操作，大部分的軟件操作都是在瀏覽器內完成的，這時客戶端已經發生很大的變化了。
■ 堡壘機目標端
目標資產同樣也發生很大的變化。資產快速雲化，尤其是非監管行業和非金融行業雲化在加快進展。隨着用戶業務的快速拓展，面臨一些安全合規的要求，用戶發現他的資產越來越分散，在全國各地都會有資產，而不僅僅是全國就一個地方有資產，一個地方集中建設就完了。
另外是目標端資產的規模化。因爲企業在做數字化轉型過程當中，越來越多的企業經營階段都需要依賴於IT。原來可能IT很小，僅僅是企業整個經營鏈條當中很小的一塊，但現在已經遍佈整個經營鏈條，所以這必然導致數字資產的快速膨脹。
■ 堡壘機自身
堡壘機訪問端和目標端在快速的變化，堡壘機自身的軟件架構以及軟件適配的周邊環境也面臨着變化。分佈式架構催生出大量非常優秀的軟件，同時各種成熟的公共服務也在出現。我們看到堡壘機所處的環境在過去十年內發生了巨大的變化，在這個時候我們必須要去思考一個問題——面對所處環境的變化，我們是需要一個更好的“斧頭”還是一個更高效的“電鋸”呢?
斧頭和電鋸最大的差別在哪裏?最大的差別是驅動力發生了變化。斧頭的驅動力是人力，電鋸的驅動力是電力，這顯然是兩個不同的時代。
對應到堡壘機也是這樣的。堡壘機在2005年誕生，到2011年這個階段，你會發現驅動堡壘機快速往前進展的其實是來自於用戶的等保需求，以及用戶的應用安全審計需求。進入2010年代之後，你會發現驅動堡壘機再往前走的動力已經發生了很大的變化，反而變成了它所處環境的變化，有來自雲化的變化，有來自用戶資產快速膨脹的變化，有來自軟件發展的一些變化。可以看出驅動力在發生變化，所以我用了這個比喻——我們需要一個更好用的“斧頭”還是一個更高效的“電鋸”?
正是基於這樣考慮，2017年FIT2CLOUD飛致雲和JumpServer走到了一起。JumpServer從誕生第一天開始就是一個非常優秀的堡壘機產品，它也得到了非常好的社區發展和支持，有很多人來使用。尤其在擁抱軟件發展趨勢這方面做的非常好，誕生第一天就很好。
FIT2CLOUD飛致雲作爲中國領先的多雲管理平臺軟件及服務提供商，我們對用戶使用雲以及怎麼樣和雲適配有非常深入的理解。我們兩家走到一塊，強強聯手，希望給用戶打造一個在多雲環境下更好的堡壘機。
在回顧堡壘機發展歷史的時候，我們發現，到2010年代之後，堡壘機的發展原來動力好像變得不是那麼足了。與此同時，多雲時代反而催生了極強的變革，給堡壘機帶來很多的挑戰。接下來我們跟大家分享一下堡壘機所處環境的挑戰到底是什麼?這些東西給傳統堡壘機的解決方案帶來的挑戰有什麼?
二、堡壘機面臨的變革是什麼?
堡壘機面臨的變革包括目標基礎設施的變革、軟件新技術的變革，以及軟件研發交付模式的變革。
過去這些年，堡壘機所處的環境發生了巨大的變化，堡壘機從中能不能受益?我覺得要從幾個方面去理解雲時代給堡壘機帶來的變革。
首先從目標基礎設施的變革說起，這個可能是最直觀，也是對大家衝擊最大的變革。我們發現，在過去的十年內，不管是用戶所擁有的資產，還是用戶需要訪問堡壘機的人員都在快速增加。2010年初，一家公司有1000臺資產其實已經很大了，大部分的可能只有50臺、100臺或200臺的資產。但現在隨便一家名不見經傳的互聯網公司或製造業企業，即使是你覺得非常傳統的製造業，IT的規模可能就已經過千臺、甚至萬臺的資產，我們有些客戶IT資產已經上十萬臺了。
資產快速增加，同時因爲IT不斷地嵌入到用戶生產鏈條的每個環節，原來可能就是做辦公支持，但現在從供應鏈開頭到客戶端的銷售都需要涉及到IT資產的訪問，帶來的問題就是需要通過堡壘機訪問目標資產的用戶也在快速增加。
在這種場景下，傳統堡壘機給出瞭解決方案，一般來說就是原來一部分資產和人一套堡壘機，現在可能好多資產好多人，那你就做好多套。這也是很自然的解決方案，它可以工作，也帶來很多現實的挑戰。
1、部署的成本快速增加;
2、授權的成本也在快速增加。不管是套數增加，還是在目標資產的授權都在快速增加，對用戶來講形成了很大的成本壓力;
3. 管理成本在快速增加。每一套堡壘機是獨立存在的。作爲獨立的孤島，裏面的目標資產管理、授權管理、用戶管理都是相互獨立的，沒有一個視角可以看到公司裏面所有的資產，甚至我們看到有些客戶在不同網段部署獨立的堡壘機。你可能有20個網段，你要部署20個堡壘機，管理的成本是很大的。
另一件事也在同步發生，相信很多朋友會有真切的體會。原來一個企業依賴IT的鏈條非常短，很多時候他在依賴IT那個點來部署數據中心或同城部署主從災備就結束了，這樣數據中心相對集中，數字資產也相對集中。
但現在隨着用戶整個業務鏈對IT的依賴越來越增加，隨着用戶業務的擴張，其基礎設施和IT資產也在快速擴張。他可能在全國有很多分公司，每個分公司可能都會有一個非常小的邊緣節點，這個邊緣節點都會需要一些資產去管理。
這個現象出現以後，最直觀的傳統堡壘機解決方案是這樣的，每個邊緣節點可能去部署一套堡壘機，或者說相對靠近的節點部署一套堡壘機。這樣一來，資產規模快速增加時會帶來一系列問題，比如集中管理難度增加，跨區訪問的效率非常低，部署成本、授權成本都在增加。從這裏可以看出，不管是從絕對數量和分佈上，基礎設施都會給堡壘機帶來一些新的挑戰。
除了上面的兩個挑戰外，還有第三個挑戰。這就是用戶越來越多的資產上雲，也就是廣泛雲化了。因爲資產是堡壘機管理最主要的對象，一旦資產已經發生了雲化，我們再回頭去看堡壘機資產管理的方式。
堡壘機資產管理的方式有幾個重要的點，一是資產發現。傳統堡壘機是輸入進去，或做得好的堡壘機可以Excel導進去，或者說通過IP掃一下，這是傳統堡壘機資產的發現;
二是資產納管。所謂“資產納管”是說這20臺歸這個項目，那20臺歸另外一個項目，分門別類，傳統堡壘機在資產管理時基本上都是手動做;
第三，堡壘機資產重度依賴於網絡。在雲時代因爲網絡的複雜度，尤其是還會面臨多雲環境，傳統堡壘機直通網絡的部署方式在雲時代面臨很大的挑戰。雲時代的資產分佈在不同雲上、不同的VPC、不同子網下面，堡壘機對它們的管理是不是能做到更好地適配?這些挑戰是在主機時代誕生的堡壘機不曾遇到的問題。我們應該思考這個問題，堡壘機從產品層面能否幫助用戶做得更好?
隨着資產的雲化不斷深入發展，我們發現，雲給資產帶來可編程基礎設施。在這種情況下，堡壘機對資產的管理是不是能做得更好?我們能不能通API來自動發現資產?能不能通過API獲取資產的一些元數據?這些元數據能幫助我們分門別類。比如說IP、名字、標籤、操作系統之類的東西，這些我們都可以通過API獲取到。
再看一看軟件在過去十年的變革所帶來的新變化。堡壘機本質上是一套軟件，不管它是軟件交付給你，還是以一體機的形式，它本質就是軟件。在過去十年裏，如果我們去看軟件體系架構的變化，最主要的趨勢就是從產品一體化架構向分層解耦架構的轉變。這個變化可能在術語上有很多的說法，以前叫分佈式，現在叫微服務，繼續往前走可能變成無服務器架構，但都是快速地從傳統一體化的架構向分層解耦架構在走。這樣會帶來什麼好處?顯然一旦分層解耦了，每一層都可以做水平擴展，你也可以更容易地部署了。
分層解耦還帶來了越來越專業的外部工具產生，數據庫層面有MySQL，緩存有Redis。分層解耦之後開始還沒有這些公共組件的時候大家還是自己寫緩存，我原來在十年前就幹過類似的事情，但現在有太多這樣的開源產品，公有云廠商也出現了各種各樣的公共組件。隨着軟件的架構的分層解耦推進，你可以非常容易地複用這些能力。
作爲一款軟件產品，堡壘機是不是也應該往這個方向努力?是不是也應該更好地複用外面的這些公共組件來給我們用戶提供更好的服務呢?這也是從軟件創新的角度，尤其是從軟件創新的後端來看。
從軟件創新的前端來看，我們會發現特別有意思的一件事情。過去十年軟件創新在後端不斷迭代，從一體化走向分層解耦，前端的迭代也絕對不弱，現在已經誕生了非常專業的前端工程師這個職位，而且這個職位的體量在中國是非常巨大的。
非常不幸的一件事情是，儘管我們的前端技術已經從最開始的靜態頁面經歷YUI、EasyUI、Angular JS，到現在非常主流的VUE，甚至還有更新的框架出現，但是我們現在在市面上看到很多的堡壘機廠商提供的堡壘機仍然是上個世紀的界面，還不是2000年代之後的。
JumpServer誕生在2010年代之後，誕生的第一天我們就非常注意用戶體驗，在很早的時候就推出了基於Angular JS的全新界面。這個界面推出已經有四五年時間了。2020年年中，JumpServer將推出全新的基於VUE的UI，也希望大家盡情期待這個改進。
軟件創新在前端的變化確實能給我們的用戶帶來更好的體驗，顏值更高的堡壘機產品。線下很多朋友如果是做運維操作的，你可能每天到公司裏來，一天8個小時上班時間，大概有4個小時會使用堡壘機界面，一個清爽、好看、操作友好的界面給你帶來的工作體驗肯定也是不一樣的。如果你每天對着的還是上個世紀那個界面，你可能自己就會覺得有點怪怪的，我覺得這也是軟件創新給堡壘機帶來的一些東西。我們認爲，堡壘機軟件應該積極擁抱這個變化，積極採納這個變化，給我們客戶帶來好的東西。
接下來講一下軟件在交付模式發生的變化，過去十年大家都知道是軟件交付模式發生巨大變化的十年。這裏面列了幾點：
第一，關於產品的獲取;
現在幾乎所有的產品獲取都可以通過線上來完成，不僅是軟件類產品，甚至一些硬件類的產品都可以在線上預定快遞到你家去試用。但你會發現，堡壘機這個行當特別有意思，即使要試用也得去找供應商，給你弄一臺服務器，然後上架，這個過程極其複雜冗長。堡壘機的使用真的應該這樣嗎?是不是能夠變得更方便一點?
第二，關於產品的迭代;
我見到不止一個客戶跟我反饋，他買了一臺堡壘機，上架之後三年從來沒有更新過，就放在那裏。我們很難想象今天一套軟件產品放在客戶那裏三年都不做任何更新，這樣做真的對嗎?其實我們已經進入軟件快速迭代交互的時代了，從軟件生產到最終軟件在數據中心上線，流水線已經變得極其順暢了。但是，堡壘機卻仍然還保留着傳統物理世界的模式在做產品迭代。
第三，關於系統集成;
用戶越來越期待把用戶數據中心內的各種各樣的工具鏈打通，尤其像堡壘機這樣每天都在用的工具打通很重要。但有些堡壘機廠商提供的就是一個黑盒，只能通過他們自己的UI界面去登錄操作。沒有API或API非常少，仍然是保留了很老的API風格，也不是主流的API的方式，用戶做集成是非常困難的。其實，不需要讓堡壘機變成又一個黑盒，我們需要改變這些，需要擁抱互聯互通的數據中心新世界。
以上這些都是我們看到的一些真真切切的變化。面對這些變化，不管是基礎設施層面，還是軟件架構、軟件研發還是交互方式層面，JumpServer是如何來思考這些的問題的呢?JumpServer如何進行變革的呢?爲什麼我們說JumpServer是多雲環境下更好用堡壘機?我覺得，最核心的認知是，針對這些變革JumpServer做了更好的改變，我們更好地適應了多雲時代的需求，所以我們認爲它在多雲時代會是一款更好用的堡壘機。
三、JumpServer如何思考這些變革?
面對這些改變，JumpServer從產品、運營和商務層面做出了自己的思考。
1. 產品層面
JumpServer從誕生第一天就基於分層解耦架構。在這張圖上我們列出了JumpServer的分層架構，從最下面錄像、日誌、審計數據，到MySQL元數據的存儲，Redis做緩存，中間的CORE是做核心鑑權、資產管理。上面作爲接入端，Linux可能用KOKO，Windows用GUA，再上面是負載，它的每一層都是解耦開的。比如說接入端是可以做水平擴展的，解耦之後我們可以把它做容器化部署，也可以放到你的Kubernetes容器平臺裏面去跑。
分層解耦的架構給我們帶來了什麼樣的好處呢?
首先，我們之前一直說用戶資產特別多，原來可能就20個人用，10個併發，30個併發，200臺、500臺資產。現在可能動不動一個用戶就有2000臺、3000臺甚至上萬臺的資產，幾百人用，併發可能上千。傳統的堡壘機肯定是抗不住的，採用分層解耦架構後，你會發現所有堡壘機負載的壓力在於接入端，是連入資產的終端，不管是KOKO還是GUA。
這層我們解耦開了，我們可以把接入端做水平擴展，一個KOKO能支持200個併發，如果說你現在需要500個併發，我就部署3個節點接進來，把它連到核心就可以了。不管用戶資產有多大，授權多少，其實都在覈心裏面。如果不是分層解耦架構，你會發現很難在這一點上做擴展，分層解耦架構之後這點擴展就非常容易了，這是針對資產多、大併發的場景。
針對資產非常分散的情況下，因爲我是一個分層解耦架構，我可以把接入端和核心端完全分開來部署。比如說你是一家總部在深圳的公司，你就把JumpServer的核心資產和授權管理部署在深圳的JumpServer這邊。你所有的數據中心需要接入到這裏，在本地部署接入端，這裏寫的是Proxy，實際上就是接入端。把它連接到你的中間鑑權節點，這樣的話就做了統一管理、統一認證，包括錄像和存儲都是放在你深圳的總部的。
當要訪問本地的資產時，首先到JumpServer在深圳的核心節點做鑑權之後告訴是否可以訪問，但一旦告訴可以訪問之後，其實就是在本地連我本地的接入端，再到本地資產。
比如說我是上海的分支機構，我的機構想訪問上海的資產，我就沒必要像傳統堡壘機那樣，所有的鏈路是從上海去深圳，再從深圳回到上海，沒有必要。我只想問一下從上海到深圳能不能訪問資產?可以了以後，所有的就可以通過上海本地的接入端連接上海的資產，這樣就可以做到即使是很分散的資產仍然能做到統一管理、認證、存儲，但同時仍然是就近訪問。這都是分層解耦架構帶來的優勢，如果沒有分層解耦架構的存在，這些事情都沒辦法落地。
上面提到的JumpServer架構優勢體現是在後臺。前面我們提到了“瀏覽器爲王”，傳統的堡壘機當你要訪問資產時基本上都是通過客戶端來訪問的。我們說了在“瀏覽器爲王”的時代，我們有沒有提供一個純瀏覽器的訪問方式?傳統堡壘機也是通過瀏覽器訪問資產，但它需要訪問資產的時候基本上調用瀏覽器裏面的插件，本質上是插件調用本地客戶端來做的。
JumpServer從誕生第一天就有一個獨立的層叫LUNA層，這也是傳統堡壘機所沒有的。傳統堡壘機有接入層，LUNA層做了一件事情，就是讓普通用戶可以利用純的瀏覽器，不需要任何插件，就可以像傳統客戶端一樣地訪問目標資產，不管是Windows界面，還是字符界面，這個體驗的改善是非常大的。
這也得益於瀏覽器技術在過去十年的快速提升。作爲堡壘機軟件的供應商，我們應該快速地使用這個能力，尤其是我們這麼多的用戶已經開始習慣於每天用堡壘機來訪問各種各樣的東西。尤其是越來越多的非IT用戶需要去用堡壘機訪問一些東西的時候，你要讓他們在瀏覽器裏安裝一個插件或者讓他裝客戶端其實挺難的，尤其是在疫情期間。你要遠程指導一個財務人員安裝一個IE瀏覽器的插件再訪問後面的某一個軟件，是非常痛苦的。但是你要是告訴他給你個URL連接就可以訪問了，哪個體驗好是顯而易見的。我覺得這都是JumpServer爲了適應這個時代所做出的一些改變。
這裏給大家展示的是通過PC、Mac電腦、臺式機瀏覽器訪問目標資產的界面，左邊是字符界面，右邊是一個Windows界面。我上面寫了一句話——“瀏覽器能解決的問題就別依賴插件!”。畢竟前端瀏覽器已經爲王了，瀏覽器是用戶最主要的入口，我們希望在瀏覽器裏解決問題。但我們也不是說完全拋棄了傳統的方式，所以在前面大家也看到了我們仍然保留着傳統客戶端的登錄方式，只不過我們提供了一個更友好的方式。
隨着瀏覽器的訪問體驗出現之後，我們發現把瀏覽器的體驗移植到移動設備比客戶端容易許多，你要把XSHELL弄到手機上去，弄到安卓、IOS的系統那很累，但瀏覽器不一樣，因爲瀏覽器是業界公認的東西。
JumpServer在產品層面的第三個改進是——多租戶使用管理模式。這一點也是雲時代的一個特徵。進入雲時代之後，尤其是進入SaaS時代之後，我們發現大家都拼命地講多租戶，最本質的問題是希望一套系統可以由多個人來使用。
在堡壘機場景下的體現是什麼呢?比如你是一個很大的集團公司，你希望購進一套堡壘機給下面各分公司去用，你可能需要構建一個行業雲，面向你的客戶提供堡壘機服務。你可能自己是一個很大的公司，公司下面每個部門都希望有獨立管理的權限，這時候顯然就對堡壘機提出了多租戶的要求，這是在傳統堡壘機使用場景中很少遇到的。JumpServer因爲是一個開源的堡壘機產品，同時在積極拓展一些商業客戶使用，我們發現這個需求非常普及，也非常普遍。
JumpServer在2017年加入了多租戶用戶管理體系。假設集團分公司的場景，集團購進一套堡壘機，每個分公司可以有自己獨立的分公司管理賬號。他可以管理自己的資產、授權、訪問、用戶，總公司可以看下面所有分公司的用戶、資產等，而所有的這些東西是由一套堡壘機完成的。
多租戶模式的引入讓JumpServer可以一套堡壘機當多套用，這也是一個很重要的雲時代特徵，也給我們的用戶帶來很多新的可能。你是集團分公司的模式可以用，是總部分支機構模式可以用，你是一個大公司IT部門和下面各個不同的IT子部門也可以這麼用，給了你很多新的選擇和可能，這也是一個很重要的改進。
下面分享一下JumpServer在雲適配方面的改進。前面講到，我們的目標資產已經雲化了，JumpServer堡壘機可以給你自動同步這些資產，甚至可以按照你的元數據做分組，大大降低了日常資產管理的工作。而且同步之後堡壘機還可以定時更新你的資產信息，有API每天都會同步一遍，每天都會更新看有沒有變化。你在這臺機器有些別的變化我也給你同步下來了，資產管理完全通過API來解決。所以我們講“API能解決的問題就別動手!”，我覺得這也是對客戶帶來實實在在的幫助。
雲適配不光是同步資產，堡壘機有一個很大的問題是錄像存儲。尤其是當你的資產特別多，訪問特別頻繁的時候，你的錄像數據其實是很大的。雖然說JumpServer的壓縮算法還是很可以的，在堡壘機裏面算是領先的，但存儲的量仍然是很大的。現在雲時代來了，提供了非常好的對象存儲系統，天生就適合存儲錄像的服務，我們爲什麼不把這些東西存到那上面去呢?好處體現在：
1、全託管;
2、幾乎無限容量;
3、成本非常低;
4、自帶完整的數據生命週期管理。
再講一講JumpServer在網絡適配層面的改進。這裏面畫了一張圖是說JumpServer怎麼樣去適配用戶在多雲、多VPC情況下的部署。
因爲用戶一旦上了公有云之後就很難像傳統數據中心裏二層或者三層網絡打通，在公有云上網絡的安全策略就是最小安全的原則，儘可能開少的端口和暴露面。JumpServer對此也做了適配，在多雲環境，我們可能在每個雲都會部署一套JumpServer的接入節點，所有的鑑權、緩存和存儲都是集中的，在每個雲上有不同區域的不同VPC利用網域功能加進來，這樣的話就可以儘可能少地暴露端口出去，儘可能少地暴露你的點出去。
JumpServer可以做到在不同雲上的訪問到達，不會影響你的體驗，這都是JumpServer在雲時代的一些改進。我們覺得這些都是實實在在用戶面臨的問題，這是在傳統主機時代堡壘機很少遇到的問題，但現在用戶就面臨着這樣的問題，作爲堡壘機的創新產品我們也應該往前走一走。
接下來談談JumpServer在運營層面的改進。最好的產品如果沒有好的運營，客戶也很難受益。JumpServer從誕生第一天就基於開源的模式，代碼託管在GitHub上，現在已經接近13000個Star，是開源堡壘機第一品牌。FIT2CLOUD飛致雲在2017年收購JumpServer，大家當時可能有個擔心，說會不會把它變成閉源?但顯然我們收購JumpServer絕對不是要把開源變成閉源，這顯然是逆潮流的行爲，我們會持續地運營開源產品。
我們認爲，不應該忘記JumpServer創立的初心，就是給儘可能多的人提供一個好用的堡壘機，這一點我們是非常堅定的。JumpServer加入FIT2CLOUD飛致雲之後兩年多時間，70%多的研發功能仍然是以開源版本提供給客戶的。我們希望，讓用戶在不花一分錢的情況下就可以拿到一個足夠好用的版本。這個版本可以滿足他日常各方面的需求，而且也適應了現在大部分的一些場景。這一點是我們一直堅持的，過去、現在和未來都會這麼做，我們不會放棄開源版本的推廣。到目前爲止，JumpServer開源的版本下載部署的次數已經超過30000次。
在運營層面，我們還堅持採用快速迭代的方式。JumpServer加入FIT2CLOUD飛致雲兩年多已經發布了20多個版本。今年開始基本是按照每月一個版本的節奏在對外發布版本。我們不希望客戶用了JumpServer之後三年不更新。三年很多東西都變化了，憑什麼一個堡壘機軟件不變化?用戶三年內面臨很多新的問題，這些新的問題難道就應該忽略掉，讓用戶每天去忍受嗎?軟件產品肯定是有Bug的，難道不應該及時被修復嗎?這些都是我們在運營層面上考慮的，也是我們爲什麼堅持按月迭代的一個原則。
最後講一下我們在商業層面的考量。我們做了一些JumpServer的商業化工作，而且取得了非常不錯的商業化結果，這些商務層面的考量都是在不違背JumpServer初心的前提下展開的。在商業層面我們採用了兩個非常重要的手段：
1. 軟件訂閱模式
大家按年來付錢給我們，不是一次性買斷放在那裏。
2. 海量資產授權
我們給用戶一個非常大的資產上限。
這兩個方式背後思考邏輯就是用戶在雲時代資產的兩個特徵：
首先，資產的彈性波動非常大。平時可能100臺資產，到“618”的時候變成200臺資產，“雙十一”的時候變成500臺，讓用戶一臺一臺地數資產是一件很殘酷的事情。
第二，用戶的業務在快速迭代向前發展。今年是這樣，明年可能是另外一個規模。我們給用戶足夠低的成本來啓動，用戶只要付一年的錢，以很低的成本就可以使用上一個很好用的堡壘機。
在提供優質服務的前提下，我們希望通過這兩種手段來大幅度地降低用戶使用堡壘機的商業成本。
以上是我們做出的變革，也是JumpServer產品遵循的原則。這包含了JumpServer研發團隊的努力，還包括很多社區用戶給我們的反饋。開源產品用戶給我們反饋共同打造產品，這是令我們非常欣慰的一件事情。我們針對雲時代在思考變革、行動，給用戶提供了一個非常好用的產品，這也是爲什麼我們一直說“JumpServer是多雲環境下更好用的堡壘機”。
四、JumpServer的使命與期待
最後做一個簡單的收尾，談談JumpServer的使命與期待。
JumpServer的使命是什麼?老廣(JumpServer項目創始人廣宏偉)創立JumpServer第一天的時候構思的使命是什麼?這個使命就是——“成爲最爲廣泛採納、更好用的堡壘機”。FIT2CLOUD飛致雲和JumpServer合併之後，我們沒有改變這個使命。
第一，JumpServer已經是一個被廣泛採納的堡壘機。在JumpServer之前，堡壘機是一個相對專業的領域，只有少數能夠使用的企業，甚至是有很高的成本才能使用起來的。因爲JumpServer的出現，你會發現一個新成立公司在有很少資產的情況下就可以使用JumpServer的開源版本了，我們把它變成一項普惠的技術推到所有的客戶面前;
第二，我們希望JumpServer是一款更好用的堡壘機，是在雲時代更適合用戶實際需求的堡壘機。這個“更好用”是一個持續往前走的狀態，下一個時代可能有下一個時代“好用”的定義。
這裏放了一張圖，這張圖是百度指數的需求圖譜。中間一個藍色的大圈是堡壘機三個字，離這個圈最近的表示關聯度越高。JumpServer是離它最近的，意味着通過百度的大數據分析得出的結論，當用戶在百度輸入“堡壘機”三個字時，絕大部分用戶最想找到的結果其實是JumpServer。
從某種程度上，這已經說明了“堡壘機=JumpServer”這個說法已經變成大家默認的認知了。這是一件對我們來講很欣慰的事，確實可以看得到JumpServer在被廣泛地採納和使用，這也是我們使命中的一部分。
我們將堅持這樣的使命往前走，非常期待大家能夠參與進來。我們希望，JumpServer能夠成爲你職業生涯的第一臺堡壘機，這是我們的口號。你可能覺得我用了很多堡壘機，JumpServer根本不是我職業生涯使用過的第一臺堡壘機。但我想說的是，你可能使用過很多堡壘機，但它不一定會成爲你的堡壘機。“你的堡壘機”我覺得至少要滿足兩點：
第一，不管在哪家公司工作都可以獲得它，不會因爲財務和公司變化而變化;
第二，對這個堡壘機所擁有的技能會隨着你的職業生涯的任何地方都可以使用到。
這是JumpServer希望達到的目標，我們也在爲這個目標不斷地努力。在這個過程中我們也非常歡迎大家來使用JumpServer的開源版本，我們會堅持提供功能完整的開源版本，同時也歡迎大家加入到JumpServer的項目建設當中，不管是提需求、Bug或在社區裏回答別人的問題，都是一件非常好的事情，你也可以分享一下使用JumpServer的體會。
如果說你在一些商業場景下希望得到更好的商業支持，也歡迎聯繫我們，我們可以提供非常專業的服務團隊，從實施、安裝、部署、緊急救援等方面提供相應的商業支持，讓你在真正的大規模生產使用過程中沒有後顧之憂。
前面講了堡壘機的過去、現在和麪臨的挑戰，堡壘機的未來會是什麼樣的呢?
IT是一個高速發展的行業，一切都在快速變化。堡壘機是誕生在主機時代的，現在已經進入雲時代了，下一個時代是什麼時代?
雲時代的下一個時代是容器時代或無服務器時代?在無服務器時代服務器是沒有的，下一個時代堡壘機會長成什麼樣?
我覺得這也是非常值得大家思考的事情，坦率說到目前我們還沒有答案，我們也在不斷地摸索。但有一點我們堅信，只要有運維審計、運維操作的時代就一定需要用到操作審計，哪怕那時候它已經不叫堡壘機了。
希望大家在未來繼續支持JumpServer，積極地爲社區做貢獻，我們也肯定會持之以恆地在JumpServer社區發展上投時間、精力和資金，讓JumpServer真正踐行它的使命——“多雲環境下更好用的堡壘機”。我們將繼續爲大家提供更好的產品，讓大家在雲時代擁有一個稱心實用的堡壘機。