蕭田國表示，DevOps首先是一種文化，它推崇的是集成，如果說一個公司的系統(tǒng)實現(xiàn)了DevOps以后，它能做到一天十次部署或者更多次部署，而在大型的傳統(tǒng)企業(yè)，能做到三個月一次部署就已經(jīng)很不錯了，并且主要的問題在于沒有辦法迭代，沒辦法到一個生產(chǎn)環(huán)節(jié)上做快速問題的驗證。

隨著移動化、社交化的發(fā)展，現(xiàn)在不管什么行業(yè)，他們進(jìn)入到互聯(lián)網(wǎng)的業(yè)務(wù)都會被迫帶著做快速的迭代。所以一個好的運(yùn)維自動化平臺，首先需要能識別出來目前這個業(yè)務(wù)里面的痛點和瓶頸，把痛點和瓶頸先做完了，當(dāng)然一般的痛點和瓶頸首先都是持續(xù)交付。其次，所謂自動化整個價值流，再把這個價值流的事情做一個數(shù)據(jù)分析，如果說有心有力的話，可以再做一個API及服務(wù)化，就是調(diào)用，而不是走直接的服務(wù)器訪問，所有的都是基于API化和服務(wù)化，到最后再做一個評估和持續(xù)的優(yōu)化。

以下為蕭田國演講實錄：

各位老師，各位朋友，大家好！我做一個簡單的自我介紹，這幾年我跟一幫朋友做了些好玩的事情。我們做運(yùn)維十幾年時間了。

這一年多時間做到了五個第一，做了中國第一個運(yùn)維的社區(qū)，高效運(yùn)維；做了中國第一個運(yùn)維行業(yè)協(xié)會——OOPSA開放運(yùn)維聯(lián)盟，中國第一個行業(yè)大會——GOPS全球運(yùn)維大會，以及中國第一個運(yùn)維的標(biāo)準(zhǔn)草案——互聯(lián)網(wǎng)應(yīng)用運(yùn)維框架及能力模型。因為我們知道在國內(nèi)基于互聯(lián)網(wǎng)，因為運(yùn)維沒有任何的標(biāo)準(zhǔn)草案，這個事情我們在做了，以及我們做了中國第一個運(yùn)維的節(jié)日“724”，這個節(jié)日意義很多，“724”就是“cheers”表示歡呼的意思。

今天我跟大家分享一共有三塊，第一塊對于運(yùn)維下一站的趨勢解讀，第二個給大家介紹一下國內(nèi)基于DevOps比較領(lǐng)先的運(yùn)維平臺，第三個，在這個運(yùn)維平臺里面持續(xù)交付平臺的實現(xiàn)方法。

在很多年前ITIL當(dāng)時提出來的時候，大家知道是有背景的，那個時候所謂的巨石架構(gòu)，是基于客戶端的設(shè)計。這時架構(gòu)都是“巨石”型，很龐大，每個新版本的上線都需要半年、一年的時間。那個時候我們說，作為一個版本迭代，或者說部署，不是問題所在。整個運(yùn)維也是一個初始的狀態(tài)，所以說很多時候在最開始的ITIL做的事情，不管是橫向的做IT技術(shù)數(shù)據(jù)管理，還是做豎型的流程管理，其實還是要解決內(nèi)部的問題。

但是在進(jìn)入了互聯(lián)網(wǎng)時代以后，這個情況發(fā)生了變化了?；ヂ?lián)網(wǎng)基于海量用戶，而且整個業(yè)務(wù)架構(gòu)由CS端變成了BS端，還有就是APP形式，一個APP的前端可能非常簡單，但是后端可能極度復(fù)雜。

例如“雙11”的時候，很多用戶會發(fā)現(xiàn)0點0分，看到那個圖標(biāo)就在那兒轉(zhuǎn)，用戶很著急也沒有辦法，他也不知道后面有幾百萬的并發(fā)在跑著。這個階段就會需要快速迭代，需要DevOps，并實現(xiàn)持續(xù)交付。

我們會認(rèn)為現(xiàn)在ITIL對運(yùn)維的理解跟DevOps的理解還是不一樣。作為DevOps而言它對于運(yùn)維的理解是自動化的過程，我們回過頭來看ITIL的時候發(fā)現(xiàn)，里面很多動作或者配置、管理都是基于流程、基于文檔的，作為DevOps的任務(wù)就是要消除掉紙質(zhì)的，讓一切東西都是用系統(tǒng)來運(yùn)行，這個時候更多的危及著基于ITIL廠商的生意，但是我們實際認(rèn)為ITIL的本質(zhì)或者ITIL的核心思想是在DevOps等等里面有一個生根發(fā)芽與成長的，我們改變了形式，當(dāng)然最終結(jié)果也會出現(xiàn)很大的改變。

我們看到ITIL跟DevOps的區(qū)別很大，當(dāng)然最本質(zhì)的區(qū)別，ITIL應(yīng)該是對內(nèi)的，是一個基于這個流程的導(dǎo)向，DevOps不是，它是一個技術(shù)性的導(dǎo)向。DevOps會給ITIL帶來沖擊的地方就在于，原來我們說的ITIL所面對的就是右邊的Ops，但是有些時候Ops是”雙背“，一個是背服務(wù)器，一個是背黑鍋，這個時候他怎么實現(xiàn)更高的價值交付？之前的時候我們知道Dev跟Ops是隔山相望，Dev想你先跳，Ops說你先跳，兩個是相互扯的。我們目前的概念，有了DevOps以后，他們兩個在一起了，或者一起跳，或者一起讓別人跳，這可能是比較大的改變所在。當(dāng)然作為DevOps很多人會有很多不同觀點，待會兒我們會再去闡述。

還有一個圖簡單的表述一下，我們所認(rèn)為的ITIL跟DevOps區(qū)別。一個是流程思維，一個是技術(shù)思維，或者說ITIL是一個更高層次的東西，DevOps會做很多的細(xì)化，他會做很多的實現(xiàn)，雖然這種實現(xiàn)到最后又會去倒逼ITIL。所以如果我們基于DevOps的一些理念做運(yùn)維的話，我們有一個總結(jié)，叫一體雙翼或者一只鳥，這里面的一體，當(dāng)我們基于這個標(biāo)準(zhǔn)與規(guī)范，基于這個服務(wù)化，基于這個狀態(tài)，這里面會有一個實現(xiàn)，兩邊我們再去實現(xiàn)基于它的雙翼，在右邊是自動化運(yùn)維，左邊是數(shù)據(jù)運(yùn)維?；谖覀兪紫仁羌夹g(shù)層的一些事情，以及這個理念層的一些拓展，最后能夠帶著我們運(yùn)維一起飛。

我們對于DevOps還需要有更深的理解。實際上在不久之前開發(fā)跟運(yùn)維是一個天生的仇敵，我們知道作為開發(fā)而言，他做的事情，就是把這個程序做完就不管了，他比較爽的地方，在他的背后還有測試，對測試說我沒問題了，對運(yùn)維說你去上線，這個時候會有很多問題，就在于說，很多時候是開發(fā)，他可能版本的提交是快上線之前了，最后結(jié)果運(yùn)維就是背黑鍋的。運(yùn)維一上線有點慢，最后說看看你，本來這個問題分分鐘能解決的，就是因為你老上線很慢，blablabla。

上線分為三種，一種是上線開發(fā)環(huán)境，一種測試環(huán)境，還有一種是生產(chǎn)環(huán)境，以前很多時候開發(fā)，任何地方的上線都是不做的，很多時候更多的是相互的推諉。我們說這叫做部門墻，開發(fā)指責(zé)運(yùn)維，運(yùn)維指責(zé)開發(fā)。

為什么會這樣？原因非常簡單，在于開發(fā)跟運(yùn)維本質(zhì)上他們的思維模式是不一樣的。開發(fā)的思維模式是要求快，他要求功能快速上線；但是運(yùn)維要求是穩(wěn)，就是說你別給我出事，又快又穩(wěn)這是不太可能實現(xiàn)的東西，所以說這里頭就會出現(xiàn)很多的扯皮。

而且還有一點，開發(fā)如果出問題測試給他兜底，甚至有一些CTO說，所有的問題都是測試上的問題，為什么??？因為那個人是CTO，他做開發(fā)出身的。運(yùn)維很不容易的地方在于說，運(yùn)維實際上很多時候自己既要做操作，還要做測試，還要做檢查，這就是人為事故的根源所在了。

所以我們看一下，在以前的模式里頭分為兩種，這里頭的第二個模式，那就是說開發(fā)，他把東西做完測試，測試完以后由運(yùn)維部門進(jìn)行發(fā)布，后來又改進(jìn)了，后來改進(jìn)我們起一個名字叫敏捷，那就是說開發(fā)跟測試他們很開心的在一起玩了，他們玩的很開心以后再把版本扔給我們運(yùn)維，這個時候運(yùn)維的地位還是沒有改變，整個問題沒有解決，而且最關(guān)鍵的是公司的成本、公司的績效并沒有提高，當(dāng)我們拋棄掉左邊的方式，當(dāng)我們變成右邊的這個DevOps方式以后，我們會發(fā)現(xiàn)這時候?qū)嶋H上要求一個人要同時具備有開發(fā)、測試、運(yùn)維的思想，或者說現(xiàn)在的事情只能變成大家一起愉快的玩耍了。這個時候他們之間的關(guān)系就由敵對變成合作的關(guān)系了，他們只能共享這個目標(biāo)和責(zé)任。

一般認(rèn)為因為瀑布式傳統(tǒng)的開發(fā)模式導(dǎo)致了開發(fā)測試和運(yùn)維的割裂，現(xiàn)在的DevOps要把這個扯到一起去了，但是根據(jù)《三國演義》的觀點，那就是分久必合、合久必分，我們不知道什么時候他們又會分開，都是根據(jù)當(dāng)時的時勢做的變化。

作為DevOps擁有兩種理解，有一種理解就是開發(fā)的能力延伸到了運(yùn)維，還有第二種就是運(yùn)維能力傳遞到開發(fā)，最后他們的結(jié)果就是一個高質(zhì)量持續(xù)快速部署的價值。這就帶來一個問題，大家認(rèn)為你是運(yùn)維更適合做DevOps，還是說開發(fā)更適合做DevOps？認(rèn)為開發(fā)更適合做DevOps的輕舉手。我們還是認(rèn)為，還是站在我們運(yùn)維側(cè)DevOps，強(qiáng)是運(yùn)維做更合適。

DevOps我們來做一個解讀，首先DevOps是一種文化，它所推崇的就是一個集成，如果說一個公司的系統(tǒng)實現(xiàn)了DevOps以后，它能做到一天十次部署或者更多次部署，那就很厲害。我們知道在大型的傳統(tǒng)企業(yè)他們能做到三個月一次部署就已經(jīng)很不錯了，而且每次部署都是嚴(yán)陣以待，每次部署都是上百號人，在晚上零點或者零點以后進(jìn)行，每個人都繃緊神經(jīng)。這個方式的弊端在于哪里？或者說之前傳統(tǒng)的，很多次的測試、很多次開發(fā)，最后卻還是很緊張，問題在于哪里、在于他沒有辦法迭代，他沒辦法到一個生產(chǎn)環(huán)節(jié)上做問題的快速驗證。

DevOps是一種思維，很明顯，我們盜用一句話，互聯(lián)網(wǎng)思維叫“極致、口碑、專注、快速”，DevOps就是“精益、價值、跨界、敏捷”。作為DevOps而言，其實是一個共享責(zé)任，就是說你沒有辦法去踢皮球了，從現(xiàn)在開始自己挖個坑含著淚也得往下跳。而且在我們要應(yīng)用到DevOps的時候很明顯，我們對于工具的依賴就要比以前重很多了，現(xiàn)在你要想實現(xiàn)一個自動化，我們知道商業(yè)軟件也不可能說那么快的跟得上，這個時候你一定得要大量的去用到各種各樣的開源軟件，而且這個時候你需要系統(tǒng)去做更多的分層，為什么？因為現(xiàn)在你的這個迭代次數(shù)變得更快了，你今天部署的版本可能10次、20次，你后續(xù)的調(diào)度、后續(xù)的數(shù)據(jù)分析是不是也需要跟得上？如果說他們跟不上的話，你一個人在前面跑，那是瞎跑。

這里頭當(dāng)我們把Dev跟Ops合到一起的時候，他們之間的部門墻就被拆掉了，拆掉完以后它的價值實際上是能夠去提升公司效率更加聚焦到商業(yè)和用戶價值，一會兒我們會有一個例子，用那個例子仔細(xì)的跟大家講一下，這個事情DevOps的持續(xù)交付最終的結(jié)果是什么，以及他最終所帶來的好處是什么。

我們剛才說到了DevOps這種思維，像以前的時候，大家習(xí)慣于本位的去做一些仗對，綠色、黃色、紅色就是開發(fā)運(yùn)維，相互指責(zé)去罵街?，F(xiàn)在每個人都要互通有無一下了，所以說這時候就沒辦法說你說你有理、我說我有理了。

這個時候作為DevOps而言，底層的持續(xù)交付平臺不管說他是由Dev所實現(xiàn)的、還是Ops所實現(xiàn)的，不管怎么樣，最后他們對外都是要提供一個穩(wěn)定、高可用的系統(tǒng)出來。這個時候就是Dev運(yùn)維跟系統(tǒng)運(yùn)維測試被迫走在一起。而且我們知道DevOps為什么起來？他也跟現(xiàn)在很流行的云、微服務(wù)，包括很多別的技術(shù)在一起有些綁定。

看一下，如果說基于DevOps去做一個運(yùn)維平臺的話是什么樣子的，那就是我們的一種具體實踐了。首先，我們需要看一下運(yùn)維的價值是什么。實際上運(yùn)維的價值不應(yīng)該是一個搬磚的，而且運(yùn)維的價值不應(yīng)該是搬服務(wù)器的，為什么？一則運(yùn)維目前為止沒有服務(wù)器可搬了。

那么，運(yùn)維下一站價值在哪里？考慮到運(yùn)維能力范圍分四塊：質(zhì)量、效率、成本、高可用性架構(gòu)?；谶@個價值體系我們推出來基于什么服務(wù)，包括性能優(yōu)化、體驗優(yōu)化、安全、成本，包括具體的，為了實現(xiàn)這些提升我們要做些事情，要做標(biāo)準(zhǔn)化、規(guī)范、方法化。最后的落地會有平臺，一個是持續(xù)交付平臺，還有數(shù)據(jù)平臺，還有安全平臺。剛剛這里頭提到了那個“一體兩翼”，其實這里頭的一個持續(xù)交付平臺就是是現(xiàn)在右邊的自動化，數(shù)據(jù)平臺是實現(xiàn)了左邊數(shù)據(jù)運(yùn)維，安全平臺看情況，因為一個公司如果太大的話，運(yùn)維還是最好把安全分開比較好，不然死的很慘。

這里我們跟大家簡單看一下，一個基于DevOps的運(yùn)維平臺它的能力設(shè)計環(huán)，我們知道，運(yùn)維平臺制作的時候不要一開始講究大而全，這會死的很慘，因為跟老板說我需要三年做運(yùn)維平臺的時候，老板可能三個月就把你開掉了，老板耗不起。

現(xiàn)在不管各行各業(yè)傳統(tǒng)行業(yè)也好，他們進(jìn)入到互聯(lián)網(wǎng)的業(yè)務(wù)都會被迫帶著做一個快速的迭代。所以說一個好的運(yùn)維自動化平臺，首先是最左下角，需要去識別出來目前這個業(yè)務(wù)里面的痛點和瓶頸，把痛點和瓶頸先做完了，當(dāng)然一般的痛點和瓶頸首先都是持續(xù)交付。第二步所謂自動化整個價值流，再把這個價值的事情做一個數(shù)據(jù)分析，如果說心有力的話，可以再做一個API及服務(wù)化，就是說調(diào)用，不是走直接的服務(wù)器訪問，所有的都是基于API化和服務(wù)化，到最后再做一個評估和持續(xù)的優(yōu)化。

這里頭需要有面向角色做提升，需要面向場景以及面向能力域，我們說實際上在以前的時候，在運(yùn)維內(nèi)部也是割裂的，那就是說系統(tǒng)運(yùn)維、業(yè)務(wù)運(yùn)維存儲、數(shù)據(jù)庫、網(wǎng)絡(luò)、服務(wù)器運(yùn)維他們是分開的。這個分開是錯誤的，我們實際上要是改為面向場景，運(yùn)維的內(nèi)部部門怎么去配合，以及我想實現(xiàn)這樣的池化怎么辦。第二個場景做完以后，對于老板而言就會很爽了，因為這個時候他已經(jīng)有產(chǎn)出績效了，如果我們心有余力可以再做各種各樣的服務(wù)化的事情。

這是我們所推出來的一個現(xiàn)在通用的運(yùn)維平臺的概念模型，整個運(yùn)維模型分三層，第一個IaaS層，第二個PaaS層，PaaS層基于IaaS層的，正是因為我們把運(yùn)維很多的事情抽象化了，變成了一個API的形式，把它不用再去依賴于具體的人力了，所以說基于此在上頭才有可能去做一個持續(xù)交付平臺、一個監(jiān)控平臺、一個ITOA平臺，還有一個安全平臺，這兩塊加起來叫PaaS層。往上走才是我們真正的價值所在，就是OaaS。這里頭運(yùn)維即服務(wù)就是說我們對外能夠提供什么服務(wù)。實際上我們現(xiàn)在很多朋友告訴大家運(yùn)維不是那么Low，部署只是我們第一步而已，只要我們底下做好了可以對外提供例如說產(chǎn)品的用戶體驗優(yōu)化服務(wù)，我們可以提供一個連續(xù)支持服務(wù)，可以提供質(zhì)量優(yōu)化服務(wù)，還可以提供故障知率服務(wù)，還可以提供成本的優(yōu)化服務(wù)。

我們看一下第二級，這個看不清楚，之后再提供給大家。這是IaaS第一層，第二次是CMDB，大家都知道很重要，但是作為互聯(lián)網(wǎng)而言，做的是把手動配置變成了自動發(fā)現(xiàn)，雖然有的時候自動發(fā)現(xiàn)失敗，但是不管怎么樣，這是一個很重要的步驟。但是互聯(lián)網(wǎng)去聊到CMDB的時候，不會只是說對服務(wù)器、對基礎(chǔ)資源，還有第二大塊，對于應(yīng)用、配置文件、配置參數(shù)，也屬于CMDB的一部分，這是一個應(yīng)用層，還有一個邏輯層，包括人員、角色、代理商、組織機(jī)構(gòu)、服務(wù)商，都放到CMDB里面去了，所以說不是以前的CMDB，這里頭所有的調(diào)用基于API化。

中間這個一個是ITIL的服務(wù)管理，包括事件管理，還有配置管理。就像我們剛剛所強(qiáng)調(diào)的一樣，我們這里頭所有事情都會做到盡量的自動化。我們說自動化不是因為中國缺人，而是因為中國人太多了。什么意思呢？國內(nèi)海量用戶，導(dǎo)致說變更很頻繁，只能用機(jī)器代替人做事情。

第三級，我們這里面強(qiáng)調(diào)的，會做一個自動化服務(wù)的管理，特意把一些公共服務(wù)拿出來，例如說負(fù)載均衡，自己內(nèi)部的內(nèi)容，還有存儲服務(wù)，還有大文件的存儲服務(wù)，還有消息隊列。

剛剛我們向大家呈現(xiàn)了一個基于DevOps運(yùn)維平臺的全景，這個全景里面的點還是挺多的。

這里頭最關(guān)鍵的也是對于公司帶來最直接的效益部分，就是持續(xù)交付，很多人都很容易的會把持續(xù)交付、持續(xù)部署和持續(xù)集成混淆到一起去了，很明顯這個時候我們應(yīng)該做一個原始的定義，就是說持續(xù)交付是一種全面的工程實踐，是能用最小的成本、最快的速度實現(xiàn)價值的端對端面對用戶的交付。自動化的持續(xù)交付就是持續(xù)部署，或者說持續(xù)部署是持續(xù)交付的一個高階段。這是持續(xù)交付整體的架構(gòu)，包括平臺、能力、管理。

這是一個持續(xù)交付的最佳實踐，這個章節(jié)是來自于《持續(xù)交付》那本書，時間有限，今天就不說太多了。

我們看看在實現(xiàn)了這樣交付流水線以后，開發(fā)者自己觸發(fā)一個源代碼的更新，再去實現(xiàn)持續(xù)集成，獲取了代碼上線打包，這里面可以上傳到開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境，意味著開發(fā)者要為自己付的債自己去買單，就是說你可以自己去上線代碼了，要出問題跟我運(yùn)維是沒關(guān)系的，你可以第一時間去發(fā)現(xiàn)問題。所以說最大的價值就是減少扯皮。

這里我們的價值鏈實際上就是整個交付鏈了，包括持續(xù)部署、持續(xù)測試、交付、持續(xù)運(yùn)營、需求隊列，然后就是PDCA的過程。

當(dāng)我們?nèi)崿F(xiàn)持續(xù)交付，如果說要把它做到自動化的端對端，首先應(yīng)該是打造一個作業(yè)的交付層，然后是應(yīng)用的交付層，然后才是業(yè)務(wù)的交付層，歸根到底也是分層結(jié)構(gòu)。我們需要做的事情包括，資源及服務(wù)IaaS層，系統(tǒng)服務(wù)層、架構(gòu)服務(wù)層、應(yīng)用服務(wù)層、業(yè)務(wù)調(diào)度層，其實我們這個圖跟剛剛的平臺是相一致的。

作為持續(xù)交付的一個構(gòu)建階段，持續(xù)部署它的業(yè)務(wù)目標(biāo)包括什么？它的業(yè)務(wù)目標(biāo)首先最直接是一鍵化的業(yè)務(wù)變更能力，包括左邊的包/配置、服務(wù)、環(huán)境等資源生命周期管理，還有其他部分。

我向大家推薦這本書，Google SRE最佳實踐，這本書的中文版就要出版了，會在今年9月23日-24日的GOPS上海站上全球首發(fā)，到時候Google SRE的原作者，譯者及Google SRE主管工程師都會去現(xiàn)場。這也是一個盛舉，大家如果想要買門票找我。

我本次演講就到這里，謝謝大家！

zhoub