主持人：很多企業一直探索如何互聯網化，如何上雲，接下來的老師是來自北京睿至大數據解決方案總監叫鄭偉，給我們帶來DevOps是如何助力企業互聯網+的轉型落地。
鄭偉：我來自睿至，睿至主要是做我們大數據相關解決方案的一家公司，同時也會有自己的自有產品。我主要負責雲跟DevOps相關的產品線。
今天跟各位講的是基於我們睿至的客戶實踐，在傳統企業的一些業務轉型，跟DevOps相關的一些場景與各位做一些分享。
今天主要從三個維度與各位做整體分享：
- 第一個是我們對於DevOps的理解，它整體的訴求是什麼。
- 第二個我們定位是傳統企業DevOps的能力落地規劃。
- 第三個是我們的一個實踐場景。
相對於剛纔雷老師講的比較細節測試的內容，我講的會偏宏觀一點，有問題可以後續交流。
首先是我們需要一個什麼樣的DevOps？我們對於傳統企業DevOps定位是什麼？
其實我們從定位來講，通過調研發現，現在DevOps應用實踐在我們傳統企業的實踐分佈來看，最主要的一個問題可能不是從技術上來看，我們發現從技術上的困難或實現的難度來講，遠遠達不到當時的預期，更多的是從組織和人員上、流程上的困難。
所以，我們客戶來聊的時候，一般會有這樣的問題，DevOps到底能解決我們什麼樣的問題？我們爲什麼要基於互聯網的最佳實踐來提升我們業務發佈的水平，還有我們在現有的平臺下、體系架構下，如何能快速地實現我們的眼界，這也是我們跟客戶溝通的時候碰到的很多問題。
我們去解釋這些問題，通常會從我們的現狀去看，其實我們傳統企業的業務發佈模式是有多樣性的，不像互聯網，因爲它的業務特性是快速變現、快速試錯，快速交付，我們對於它的理解跟傳統企業有一些差別，傳統企業可能更多的是保證我的業務連續性、穩定性，所以我覺得是有本質區別。
從我們業務交付或者軟件發佈的模式上也可以看出一二，第一是我們從軟件發佈的模式，通常會有幾種，傳統企業會在一二是大多數的模式，在座的各位都是類似這種模式。
- 第一個是我們基於固定版本的排期，這個熟悉IPD的都瞭解，因爲我在華爲做過很多年的IPD，類似於這種固定版本排期的開發模式，它能保證我們版本的穩定，而且每年可能一到兩個版本比較穩定。而且，它是按照我們傳統業務來講，對於前端、後端整個協調能力也是比較優秀。
它帶來的問題就是對於需求的反饋比較滯後，可能我們一個版本沒有趕上需求，就只能到下一個火車把需求補上，這對於前端的反饋來講是不夠的。
- 第二個會基於我們固定的版本或者產品的單一模式來講會有一些優化，會有項目的模式。它的特點就是多個產品在不同的項目交付裏都有體現。這樣好處就是我可以發多個產品版本在不同項目裏實現我們需求的變化，但是同時帶來的問題就會有多套生產環境的發佈，造成了我們對於生產環境版本的壓力，這也是造成的一個額外問題。
- 第三個是我們現在談的最多的敏捷開發模式，我們當然希望我們所有的業務場景都是第三種，基於我們DevOps最佳實踐就水到渠成的。
但是恰恰是第三種開發模式是一個相對有限，或者相對封閉的一個場景。就拿金融來講，一些紅包類的創新場景纔會有這樣的可以應用的場景，它的特點就是相對獨立，跟其他的業務系統關係不大，而且它可以做相對獨立的開發測試發佈，就容易實現我們剛纔雷老師講的自動化實現方式。
所以，我們從軟件發佈的模式可以看到，傳統企業跟我們互聯網的企業還是從業務訴求上是有所不同，這是從我們的理解來看。
第二是我們從組織架構來看，本身我覺得大部分傳統企業都是這樣的豎井結構按照職能來劃。
其實有一些創新的業務場景已經按這種產品的團隊或者職能產品團隊來做切分，這種切分的好處就是能夠實現這種直接面向業務端到端，所以從企業組織的架構來講，這也是有它的一個差異變化。
從剛纔的這些分析，從我們業務發佈的模式，從我們組織的架構，我們可以看到當今我們傳統企業軟件發佈面臨的主要挑戰是什麼。我大概做了一個總結，第一點就是傳統企業也有快速業務發佈的訴求，這是一定的。
因爲現在整個市場的競爭對於前端需求的把握，快速去把握前端需求的一個變化，其實已經是這種不論是互聯網還是傳統企業一個核心的競爭力。
所以，這部分我們快速交付的業務需求跟我們已經設置好傳統的這些開發測試的流程上的矛盾，我們已經固化了從開發到測試這樣的標準流程，如何能適配現階段的快速迭代的需求，這是第一點。
第二個就是我們對於穩定性的要求，因爲現在企業內部大部分有大量的手工操作的存在，有些企業上了自動化工具，也只是在一些固化的一些非核心的應用場景去實現的。一些核心的變更、配置變更等等，它還是依賴於我們手工的操作。所以，手工操作與企業對於質量的一致性、穩定性要求的矛盾，所以這是第二點。
第三點是剛纔雷總講的，我們對於風控跟我們已經做好這種簡單化、快捷化標準流程之間的矛盾，風控要求你儘量合規，滿足我的各種監管要求，監管要求的滿足就會有一定的流程去適配它，我們現在如果是做一些流程化的精簡，或者是一些變更，勢必會有衝擊的產生。所以，我們覺得從整個的過程來講，每個環節都會有我們去碰到的一些問題。我就提到一點，我們現在傳統企業對於DevOps的核心訴求是什麼？現在講創新其實不是我們最終的目標，我們的目標是什麼？是業務的發展，業務的穩定，這是我們的核心。
現階段的業務現狀是什麼？不可能一步到位，我們也希望容器化爲服務，希望儘可能少的人工干預。
所以，現在更多講的是一個融合的過程，就是怎麼樣在你現有的基礎架構的平臺之下，實現你技術的平滑過度，整個的技術融合。
所以，這裏面從幾個維度來看，第一個是技術上我們其實是利用好你現有的工具平臺，我們不是說我要重新再給你搭一套流水線平臺，包括睿至的解決方案也是一樣的，我們是基於你現有的平臺基礎上，幫你設計你的開發流水線整體的步驟。所以，我們是一個整合的過程。但是它一定是一個端到端的打通，不能說只到開發測試，或者是運維的一部分。
第二是我們架構上融合效益穩定的精益管理。我們更多大部分業務要求都是我的穩定性，或者是保持我們業務的連續性，還有一些互聯網化的特性，就是能快速地去試錯，快速地做創新的嘗試。所以，我覺得這兩個是我們從架構上是一個慢慢並存，最後逐漸融合演化的過程，這是從架構上來看。
流程上來講，既然我們有一些監管的要求，我們有人員的現有組織架構的一些現狀，其實我們就要在你不斷優化人員架構基礎之上做我們標準化業務發佈的一個落地。
所以，從幾個維度來看，核心我覺得就是融合，其實講的就是一個平衡的過程，我們講效率、穩定、標準三個維度的平衡，目標就是業務的穩定，業務的快速上線，就是我們這樣的整體訴求。
第二個我們會接下來聊基於我們剛纔融合的訴求，我們剛纔講的整個現狀來講，我們再去看我們整個能力落地的規劃。
其實我們講規劃之前先把整個端到端的過程，業務交付也好，軟件發佈也好端到端的流程做整體的梳理。其實本身從產品到開發測試到運維，這是一個標準的過程，我覺得這個大家都比較瞭解，從產品的設計層面，包括一些需求、評審，有一些優先級的這些很多都是有管理流程合規性的要求。
對於我們產品來說有產品進度的把握、產品進度的跟蹤是我們關注的一些點，到開發層面就會有排期，整個的評審，然後具體到開發測試的工作，然後到一些測試等等相關的工作，這裏邊有一些關鍵點，我們的一些規範，我們做一線開發任務的前提，或者先決條件是要做規範化的制定，所以說我們特別把開發規範的落地也拿出來。
我們在做DevOps項目的時候，一般都會推薦用戶先做一次開發測試的一個諮詢梳理，這個服務是基於你以後的這種產品化、工具化的平臺落地，是一個基礎。所以，這個層面我覺得是不可少的。
然後涉及到我們自動化工具的引入，我們會有一些平臺工具、自動化工具的接入，構建我們整個的一致性保障，從開發測試的流程來看。
到運維側的更多的就是環境跟配置項目的一些準備，這也是運維側比較重的任務，這裏面就會有圖形化的部署、自動化部署層面的東西。
所以說，最後會有一個監控分析，後面實踐的時候會講，從你的產品開發到運維它其實應該是一個閉環，最後再會有一些基於你運維側，分析側的產出物再給到我們產品側做整個產品優化過程，所以這是我們整個端到端的融合分析。
我們分析的目的是找出我們的關鍵點做關鍵的設計。
我們需求目標主要的目的還是對於上層的業務交付，中間的是我們實現核心能力，環境管理、版本管理等等，最終是我們的平臺落地，就是我們平臺能力管理其實就是流程，最終是我們底層的產品。
我們總結起來就是三個維度。
第一個是可視，這一定是端到端的可視，對於業務發佈場景，CI和CD全過程的可視化管理，基於我們現有工具場景，就是我們現在的一些測試化的工具，自動化測試的工具，我們一些代碼管理的工具等等，其實更多的我們去體現的是一個更益於我們前端業務人員、開發人員運維人員去使用的平臺化的工具，這是我們的定位。
第二是自動化，自動化的前提是要有統一的資源管理，這是要有一個共識，如果你要實現我們整個全站的自動化，統一資源管理是一定的，統一資源管理就需要在你的資源層，包括你雲跟非雲資源的打通你不同資源層面的關聯，所以這裏邊就會有資源管理的訴求。
還有我們儘可能少，剛纔雷總講了我們一定會有人工干預的場景，我們希望我們把固化的一些流程走下來之後，這些流程裏邊的自動化場景我們都能使用它，而不是再有一些額外的干預。
智能化，我們從代碼的開發到後續的產品交付，其實每個過程我們都可以用監控的手段實現，所以我們現在更多的一些實現場景是在你的運維側，我們很容易實現一些監控的場景，而且基本上用戶都會有這樣的場景。
我們希望從你的產品代碼設計階段就會考慮我們的一些監控層面的一些東西，這也是後邊要講的端到端的分析，這是我們講的目標分析。
然後是我們的平臺架構，其實我們核心的東西就是流水線的工具平臺，就是基於我們現有的應用工具平臺場景做的設計，這個平臺對上是我們有針對不同環境場景的管理門戶，管理門戶之上是我們對接不同的、現有的流程，現有的一些體系、項目管理、流程管理、發佈管理等等，這些其實有一些是我們標準化的東西，我們可以直接對接它。所以說從上來講，它是對接的一個動作，對中來講是整合現有的，剛纔已經一再強調了，而不是我們要做一套這樣的東西，沒有一個用戶的場景，除非是一個初創企業，沒有一個用戶場景是推倒以前的工具平臺我重新做一套的，這是不現實的。
對下就是我們剛纔講的採集、分析、調度、管理，現有的資源體系，所以這是我們的一個核心的理念，就是對於上中下的適配。基礎層其實就是我們剛纔講的統一資源管理平臺，這個平臺爲什麼叫基礎層？它既能實現我們的自動化調度，自動化的管理操作，還能實現我們對於底層的基礎數據的一個監控採集，所以這是我們做整個的一些反饋分析的一個基礎層面的平臺。
然後基於我們的平臺能力，我們的架構規劃，我們看一下整個的典型實踐場景。因爲我要展開來講，產品的層面就比較細、比較多，所以我就把整個東西大概用三四頁幻燈片做了歸納，看看有沒有大家需要的場景，或者哪些是我們現階段在運維也好、開發測試階段也好，我們比較迫切的一個需求場景。
大概分爲幾個維度，因爲本身DevOps是一個融合的過程，我們其實就是開發到運維的融合和運維再反饋給開發的過程。
開發到運維理解的從我們開發延伸到生產中的一個過程，就是我們流水線打通的過程，我們提到的持續集成交付。
第二個開發嵌入到運維中，我們講的監控或者是應用分析一般都是從運維側來入手，運維側有一個問題，有時候在我們技術架構層面很難去找到問題，反饋給應用端也說它整個產品和代碼層面也沒有問題。其實我們更希望於我們在開發層面，或者說在我代碼的每個層級之間能看到整個的應用端到端的監控管理，而不是隻在運維側的基本訴求，這是從開發到運維的角度來理解。
反過來從運維到開發，就是我們可以在開發中加入一些生產反饋，就是有一些針對開發人員有益的一些監控，或者可視化的監控視圖，比如說一些自動化的測試場景，能夠幫助它去做一些判定。所以，我覺得這不只是在運維側有這樣的定位。
還有我們會有一些運維側的一些運維分析的反饋再反饋給我們的產品和運維開發，這是我們一直提，但是很少有去實踐的內容。因爲我覺得這應該是一個聯動的過程，就是我們要有一些運維側的大數據分析也好，我們的預測也好，給我們開發人員做平臺的東西。
所以，這是我們從幾個場景來看，針對每個場景我們展開來做細化的分析。
第一個是我們持續集成的體系建立，其實我們已經講了很多了，基本上DevOps每個主題都會有這些內容，更多的是從開發測試到整個運維端到端流程的管控。具體到睿至來講，包括你的開發工具平臺，我們都會幫你預製，包括統一代碼管理，你的統一開發測試環境的準備，這都屬於在我們開發測試構建的環節。
到生產，到運維之後就會有部署、版本管理、自動化部署的能力，所以這就是很傳統的一個流水線平臺。
我們最終要實現的還要有一個優化的過程，所以這種監控，其實今天我覺得我們大會也是以AIOps作爲一個主題，其實DevOps是它的一個子選項，或者說是一個包含的過程。我們希望整個過程是一個AIOps的過程，所以這個監控跟反饋也是一個核心的內容。
這是我們剛纔講的端到端，講持續集成的流水線過程。這裏面實施的過程也會有一些建議，從我們睿至的角度來看有一些建議，剛纔有一個諮詢的過程，針對我們用戶側現狀的諮詢，你開始測試運維的基本情況，基於你基本情況做流水線的設計，然後制定我們基本的一些流程，然後我們的一些自動化，包括一些測試，一些部署。這個過程其實還是在我們開發測試階段會多一點。運維是基於我們的部署之後會有應用體系的一些監控，然後再反饋給我們做一些運維大數據的分析，所以整個的過程來講，我覺得是一個端到端的過程。
這張圖講的就是我們一直在講的CI和CD全過程，流水線的過程。這部分恰恰就是我們DevOps裏面最容易實現的內容，可能有一些同行不太同意，恰恰是最容易實現的。
因爲你其實只是利用了客戶現網的實際一些情況，而不是你去做一些你對於用戶現網的一些創新或者變革，這是有本質區別的。
第二個我覺得是透明化應用交易過程，這對於開發人員的要求會更高一點，我們實現交易過程的追蹤和記錄，我們其實實現的過程還是基於我們整個的監控體系，但是這樣的好處不是在我們測試，或者說不是在我們運維側去實現這樣的內容，而是在我們測試或者開發側預製的能力。所以本身的相關數據過程需要我們在代碼級做設計，我們從面向2B的業務發佈場景，我們也傾向於跟客戶一起來做這樣的嘗試，有這樣的一些方法。當然，我們監控的手段也會去適配它，更多的是在我們整個端到端過程有這樣一個基於應用側的能力而不是純運維側。
場景3是所謂的立體化監控，我們一般都是講運維側的東西，我們其實監控體系是給我們整個業務線來用的，其實我一直強調我們業務的人也可以用監控，開始測試運維都可以用監控，其實我們現在更多的是把它定位於一個領域，就是運維側。
所以，這裏邊我們希望在我們整個的立體化監控體系裏，以應用爲維度，展現不同的應用視角，可能是我們應用的一個加高層面端到端的視圖，或者是應用層的連接數的分析、反饋時間的分析等等，它應該是一個針對我們開發測試運維一體化的一個監控平臺。
所以，這裏邊我們講的一個是我們運維側要在生產環境，保證我們生產的穩定運行。第二，我們測試人員也需要這樣的平臺去保證我們測試性能的合規。所以，我覺得這是一個融合的過程。
第四點是我們整合現有的運維數據，實現我們運維大數據的分析。這塊現在也比較火，相關做運維大數據的也比較多，我們也是希望於在整個的數據層面，我們儘可能地提供完整的運維分析場景。
還有我們針對於整個不同的人員會有不同的運維數據的一些導入。
比如說對於運維人員更多的是我想定位關鍵的問題，或者是核心根源問題的分析。開發人員剛纔已經講了，應用程序的一些缺陷、代碼質量。
可能對於安全人員更多的對於我們日誌層面，對於一些系統日誌來看有沒有一些不合規的地方。
所以，針對不同的應用場景，我們希望於，藉助於運維側採集的數據，不管是我們的監控數據還是日誌，實現我們統一的監控或者分析。
最後看我們講的現狀能力規劃，一些典型的應用場景，再去看所謂的落地。我們到底需要怎麼去實現典型應用場景，或者是我們的一些規劃。
其實從我們剛纔講的，我們如果要實現完整的DevOps，它其實單靠技術是行不通的。我覺得現階段從現有的組織體系架構來看，也沒有必要形成完整的DevOps，因爲我們不可能改變我們的體系，我們的運維體系，我們的開發流程，這個也很難。所以我們講的是又回到剛剛的問題，是慢慢融合演進的過程。
第一個首先容易實現的技術改造，實現我們自動化，消除我們手工的干預，構建我們垂直交付的流水線，這是現階段基本大部分用戶都在嘗試，或者有意向去嘗試的內容。
第二個剛剛有朋友在問微服務容器化，我覺得這部分內容是慢慢的過程，首先要有業務場景支持它，第二個主流的核心架構要支持它的演進過程，這也不是我們現有的技術人員統一去把握的，我覺得還需要時間。
第三個需要整體流程組織的一些變化，所以我覺得這部分也是需要時間，需要我們至少有這樣的消化過程。
所以，第一步一定是先在我們既有的平臺架構上做好整合工作，基於實際情況做架構或者產品的優化，慢慢帶動我們整個流程，我們人員架構的一些變革，我覺得這個不是一蹴而就的，是一個逐漸演進的過程。
謝謝大家。
===================================
提問環節
提問：我現在有一點監控和優化，因爲會涉及到線上只有兩個點，如果政策流量突然增加很多，我想在線擴五個點，怎麼樣通過DevOps去監控到流量已經爆了已經擴容到三個點？
鄭偉：這裏有一個誤區，我們用容器化的目的就是想要實現它的伸縮性，實現它的快速響應能力，對於容器化的前期設計就是要保證我們有彈性的度，這個度我覺得是不應該我們人爲干預的，而是應該在我們整個包括我們的容器化規劃層面上去解決的。
也就是您剛剛提的問題，我們到底多少個點能支持我們的業務，應該是由它本身的調度平臺，或者是KBS來實現這樣的能力，而不是我們指定它，那樣還達不到我們的目標。
提問：因爲會設置內存和CPU，這時候業務過來了，開發就是要了解它能承擔多大的流量。監控層面，因爲監控是一個反饋，我們怎麼通過監控的機制，能夠適當讓我們調整一些策略，比如說給我們去創建的時候給一個參考值，或者是給我們運維，或者給研發，或者給建議，這一點是個問題。
第二點就是灰度發佈，線上線下第二次升級的時候，怎麼樣用一個文件去實現這個功能？
鄭偉：我們現在容器監控其實也是有很多產品，這塊具體到您剛纔講的怎麼樣通過我理解的應該是預先的一些監控、告警來實現我們後續別撐爆的場景。第一步做前期的規劃很重要，你業務承載壓力的規劃應該是有的。
第二就是我們對於你整個內容器的監控我們也有，我們不推薦人工干預是因爲我們基於有一個平臺規劃去做這個事情，但如果我們確實有一些基於我們實踐確實有一些突發性的東西，我們需要手工調整它，我覺得這是沒問題的。
第二個改變我們所謂的灰度發佈，具體是用一個壓縮文件來實現整個的多場景的灰度發佈，這我們還沒有實現，我們更多的還是不同的應用發佈場景，還是有一套單獨的來支援。
提問：你們是怎麼實現測試或者UAT環境怎麼去實現的呢？因爲會有開發環境、測試環境。
鄭偉：我指的是一套或者分套當然是一個業務場景是一套，這是肯定的，而不是多個業務場景共用一套。我們一個業務系統，剛纔您講的，如果沒有一個文件支持，它不可能做到端到端流水線的操作，但是我們因爲有一些場景是多業務場景的，這是我們把它分離開的，整個一個流水線還只對於一個產品線我們這樣來做。
提問：我們公司有多個產品線，很多產品都各自有自己的DevOps流水線還有一套落地的方案，對於整個公司是否要去統一DevOps的方案，或者需要統一如何去做這些有什麼建議嗎？鄭偉：傳統企業這種情況還是很多見的，我們其實也不能叫它DevOps流水線，因爲人家還沒有DevOps流水線的概念，就是有不同的發佈流程。這個層面，我們建議你如果確實業務場景是相關聯的，或者有一些相似度的，我們建議把它做一個規整和整合。 如果我們有一些是完全傳統的體系跟一些新形態的敏捷的業務場景，我覺得這就沒必要去做整合，我覺得這部分的內容，可能留待我應用架構上做一些調整，然後再做後續DevOps的工作。
提問：是不是理解爲傳統的非雲產品以及新興的雲產品，對於雲這部分的產品，我們可以做這樣的嘗試整合？
鄭偉：就睿至來講，我們既有傳統的互聯網化的DevOps完全一套的敏捷架構，其實也支持剛剛您講的傳統的，對於我們這種傳統體系，我們如何來去基於你現有的需求，而不是做大的動作的解決方案，所以這兩個應該是並存的。
提問：我們認爲整個DevOps轉型是一個融合，而不是整個推倒重來的創新。
所以，您說的端到端流程的對接和管控是很重要的。因爲我們也面對這個問題，想問一下鄭老師，對於在實踐過程中，肯定會遇到一些技術上和組織上的問題，您那邊是怎麼解決的？或者對於我們這種體量比較大的傳統企業做轉型有什麼方案和建議？
第二個問題是剛纔您在第四個場景，大數據或者智能運維的場景，對於我們做運維分析反向去給開發都是有很重要的幫助，您那邊是怎麼落地實施，還有它的應用場景是怎麼實現它的價值？
鄭偉：第一個是轉型的問題，您是哪家公司？
提問：四大行之一。
鄭偉：我們是五大行做相關的諮詢服務，包括一些產品化的東西，其實我覺得我們很多東西也都是金融客戶交給我們的，金融場景是整個新技術的陣地，我覺得如果同金融角度來談 DevOps 的話，我覺得一定是先從一些試點的場景來做，所謂的試點場景就是相對獨立的，比如說以前在上海的客戶是保險做的一些搶紅包的業務，他在做這個業務場景的梳理，他們也希望先通過一個簡單可控，影響範圍較小的業務來嘗試我們的流水線動作，這個嘗試過程我們可以靈活一點。一旦固定下來之後，我們後續的一些可以做流程化轉化的，我的前提是可以。
因爲一些核心的東西永遠做不了，可以做了之後，我們再去嘗試做一些推廣的動作，基本上我們在金融的場景一般都是這樣的，用戶先指定一些特定的業務場景，我們跟他一起來把這個場景做通做透，然後再去做其他的可以推廣的一些場景，影響範圍儘量控制，這是我們的一些經驗。
第二個您講的是我們運維大數據的應用場景，其實我覺得運維大數據都把它固化在運維側，這個沒問題，因爲它本身就是我們運維側發起的，我們做一些運維數據分析，做一些前瞻性的預測，這個沒問題。
但是，我們希望睿至的角度希望於有一些測試場景，它也需要有一些很類似於運維側的訴求，這些數據的來源，我們可以通過監控來統一做採集，我們肯定是希望用一套運維大數據的平臺架構來實現我們既給運維側，也給我們開發測試側做支撐的分析。
所以，我覺得基本上像您這種體量的用戶，或者部門規模稍微有一定體量的都可以有這樣的訴求，因爲它需要標準，而不是測試人員自己給的標準，我覺得應該是統一的標準，運維大數據的平臺是一個最好的實踐平臺，所以我覺得是這樣的定位。