首先簡單快速來聊一下我對DevOps的理解可能我們今天的分享都會有這個環節，大體來聊一下我們對DevOps的理解。其實我也聽過很多分享，也看過很多DevOps的書，大體上的框架都是一樣的，但是可能各自的表達略有不同。
　　我對DevOps的理解是這樣的，分幾個環節，概念環節、流程環節、工具環節和目標環節。我們在DevOps理解上，首先是在概念方面，我們去做一件事的時候先要知道這件事是什麼，為什麼去做它，做它有什麼意義，有什麼好處。只有我們完全真正理解DevOps到底是什麼的時候，我們去做的時候才會知道在哪裡動手，知道怎麼樣做，知道自己在幹什麼，這樣我們做的會產生一種極高的效率。
　　我們在理解的時候，首先在概念方面，DevOps是一種思想，是在我們軟體開發生產實踐過程中產生的一種思想，這種思想是經過我們漫長的開發過程來歷練出來、提取出來的一種極致效率的，來解決我們在開發過程中遇到問題的這麼一種新的思想，形成我們的方法論，最後通過實踐來落地，最終我們的團隊裡形成一種DevOps文化。
　　我們在DevOps的實踐過程中有個很重要的，就是在團隊中形成DevOps文化，這種DevOps文化的形成要大於我們對DevOps工具的應用，因為工具可以變可以換，但是這種文化如果沒有形成，空有工具產生不了很大的效果。
　　我們在流程上也是，DevOps對流程改造是巨大的，DevOps落地的情況下，我們對原來很多的流程過程都要進行改變，都要進行優化，冗餘的要縮減，時間長的要壓縮，不應該有的要刪掉，缺失的要補上。
　　在流程裡要涉及四個方面，開發、測試、運維，這是我們常常說的，另外一個是管理，管理很重要，管理是什麼，讓領導參與進來，參與到我們整個的DevOps流程制定，還有DevOps目標實現這個過程中，領導不能說我只負領導責任，別的具體都不管，一句話就完了，這不行。
　　這種在傳統公司可能會出現為了管理而管理出現的情況，但是我們DevOps真正落地的創業公司、網際網路公司沒有這個事，所有的責任大家都要一起來扛，管理必須參加進去，如果管理沒有參加進去，DevOps落地比較難。
　　我們有一系列的程式碼管理的工具，持續整合的，自動化測試或者部署的，有很多工具。最終我們要在實施DevOps之前想清楚一件事，我們為了什麼來實施DevOps，把這個弄清楚了，可能我們的切入口就好辦一些，我們就為了實現生產力的提高，快速交付，保證生產環境的穩定、安全，降低成本。這四個目標加在一起是非常難的。

　　在組織方面，以我的實踐來說，我在公司的DevOps團隊組織方面，我建議按照我們傳統裡面理解的產品線這種方式來進行DevOps團隊的組織，這樣整個的效果會好一些，大家在一個團隊裡來共扛KPI，對於所有的質量都是共扛的。
　　但是我們在實踐過程中，可能部門是不拆的，部門還有，開發、測試、運維還有，但是部門的人進行虛擬的劃分，劃分到一個產品線裡。我的經驗是產品線的考核佔70%，30%的考核還是傳統部門那些任務的考核，這個各公司有自己的實際情況，可以根據自己的實際情況來做一下。
　　我們在每個產品線裡都有自己產品線專案的領導，大家都在一個船上了，這個產品成，大家都拿錢，敗，大家都扣錢。

　　成熟度模型，這個是給大家的一個參考，這裡面的這些要求，我們通過成熟度模型，拿著成熟度模型來衡量我們公司目前處於的系統狀態，系統是處於原始階段還是在可優化階段還是在某一個階段。
　　在每個階段，它在某一個環節裡體現的現象是不一樣的，比如在環境和部署階段，在測試階段，我有沒有進行自動化測試，通過這一系列的考核來發現自己企業和公司的短板到底在哪裡，我現在處於一個什麼樣的狀態，這樣我們才有一個切入的點。
　　如果你想直接一下落地整個DevOps的生產線是很難的，所以你必須要找一個點，我在哪一個點上發力突破，用我公司有限的人力和資源，把這個點做好，再做下一個點，這樣以點帶面，最終形成DevOps的落地。

　　我們引入DevOps以後，其實我們要來跟以前比較，要考量要評估，也就是說我們在引入DevOps以後，看看我們歷史的趨勢。
　　我們在第一個，在瀑布流開發的時候，我們只看重點，我們看在瀑布流的時候，我們看時間佔比是47%，一個軟體整個組織過程中所有的時間，開發的時間只佔了47%，其他時間都幹嗎了？設計佔了25%，測試佔了15%，我的部署佔了13%，我們在瀑布流的時候，這種大的規劃細化，整個開發時間佔比比較少，開發人員始終在等著前面產品經理、專案經理、架構師等等。
　　我要把這些事都弄清楚了，都考慮了再開發，結果開發以後，經過很長時間的開發，N多功能一起來進行整合測試的時候，發現各種各樣的問題，這樣導致我們開發的節奏比較慢。後來我們通過敏捷的實施，小步快跑，通過每一個週期，這種週期變快了，有問題能快速解決。但是Scrum有一個問題，沒有考慮交付的問題，只有開發，形成一些迭代週期，只考慮開發了，後面交付以前一直被我們忽視。
　　所以當我們時代變到我們現在雲端計算時代了，基礎設施的部署上線能力已經很快了。我們到敏捷的時候，對於環境部署還有交付這些的要求變得非常高。所以我們迫切需要一個新的理論來解決這個問題，我們通過DevOps的實施，將我們原來敏捷裡沒有解決的這些問題，把它解決掉，部署的問題。

總結一下整個軟體的發展過程，從瀑布流到敏捷到DevOps，應用架構是從大而全的架構到SOV的架構再到現在微服務的架構。在運維技術的方面，通過原來的命令列、指令碼到後來我們用Python進行大規模的運維工具的開發，到現在我們進行平臺化的開發。

我們現在在實施DevOps的時候，要解決一系列的問題，基礎設施的問題，中介軟體應用還有服務的問題，把所有一切的在四重環境。我們的研發測試、生產環境上全部自動化，讓它run起來，只有在需要我們控制和暫停的地方才暫停，其他的全部可查詢、可回滾。

　　我們對DevOps進行了一個定義，我們通過這個定義來分析我們公司在哪塊來做這件事，我們的定義是這樣的，我們公司現在原始碼管理做得好不好，我們的持續整合做沒做，我們有沒有自動化測試環節，我們來持續部署。
　　我去年給一個很大的國家機構做了一次DevOps的諮詢，我去的時候他們在做什麼，他們在測試環境到生產環境去上線的時候用U盤拷，把這個包拷過來，交給那個工程師，他再插到哪個伺服器上。
　　他們這樣的環節特別多，每到一個環節裡去都要很長時間才能把環境執行起來。經常出錯，每一次升級的時候都非常困難，二三十個工程師或者是更多的工程師，靠到晚上多少點，然後第二天早晨熬到幾點。後來我們經過一系列的變革，我們所有的升級全都是在白天做，沒有問題。

我們到原始碼管理這塊來考量什麼問題，就是我們的原始碼管理夠不夠先進，我們有沒有原始碼管理，如果沒有我們馬上要上原始碼管理了，現在仍然有公司用資料夾來管理。

　　我們在原始碼管理裡，我們在DevOps裡，我們推薦用GIT的生態體系來管理我們的原始碼。這裡也涉及整個團隊Git的學習，構建Git的私有庫，通過Gitlab。還有Gitflow、CR，整個過程run起來以後，每一個環節都是很流暢的，而且這個環節是我們歷練出來以後它必須的環節。

　　剩下的我們程式碼管理用什麼流程的管理，這個很重要，用Git以後會發現什麼問題，Git過於靈活，到底用什麼流程來控制我的程式碼。我們主要有三種方式，githubflow是最簡單的是，直接開一個主幹，開一個Master，我把Master克隆到本地，我在開發功能的時候，我建立一個功能的分支。從Master建立克隆到本地，開一個分支，開發完了推上去。如果再有人需要，再把它預設到本地，再合併到自己分支裡去。這種比較適合大家都對Git比較熟，整個團隊裡面對Git用得還不錯，幾個人的效率也比較高，所以沒有必要搞那麼多花樣去限制自己的效率。但是稍微大點的團隊可能又要考慮了，這種有點不太合適了。

　　下面我們考慮Gitlabflow，在剛才那個基礎上，建了幾個分支，建了Master分支、預生產分支和生產分支，每次開發完之後，到預生產環境，他把它放到預生產那，如果到生產，再把它預設到生產那。是為了解決什麼問題。

　　比如說我們發一個蘋果，你在底下都測試好了，但是蘋果想要上線需要很長時間，你上不去，你又不能老在測試環境呆著，所以你要建一個生產分支，把它放那，因為我已經開發完了，它在生產分支上堆著，堆了好幾個生產分支的版本，是因為稽核沒有過。

Git flow是一個比較嚴格的Git的流程。Master只放線上生產的程式碼，所有的開發都從Dev的分支上開發，如果出現bug，現場修bug，再合併回去。整個Gitlab也是被業界最為接受的一個開發過程。像Jira、SourceTree這些都內建了對於Gitlab的支援。

　　我們對自動化測試的要求是，我們從傳統上不怎麼做單測，介面測做，轉換到我們做TDD，做單元，必須做單元測試，介面測，最小化的UI測，等到UI測的時候其實沒有問題了，後端的BUG都已經處理完了。我們整個的單元測的要求覆蓋率是要求達到70%。剩下我們還要做到一些程式碼的style的控制。

　　我畫了一個簡單的圖，持續部署。對於整個的運維環境裡，現在在我們生產裡面，底層所有的賬號是通過LDAP打通的，所有的運營環境沒有暴露在公網上的，運維繫統變得越來越重要，運維繫統被黑，整個生產系統就被黑了。這是持續部署簡單的邏輯圖。

我們的工作通過DevOps組織起來之後，最終我們形成一個迴圈，我們始終在這種周而復始的迴圈中進行我們的管理和工作。我們讓這個迴圈run的平滑流暢，整個過程中我們工程師會親送一些。我們這些運維工程師要去承擔更大的任務，去開發公司的一些基礎性運維管理的平臺，讓我整個公司系統執行得更加強壯。

谷歌的SRE，SRE的要求是什麼，一個運營工程師應該50%的時間是在自己的日常任務中的，50%的時間是在寫程式碼、在維護自己的運維平臺的，這是一種理想的狀態。做不到這樣的狀態，我們也不能把100%的時間都放在處理故障上，這種團隊是沒有成長的，這種團隊整個的氣氛也會很差，工作壓力太大，大家都在一種惡性的環境中來工作。所以我們作為工程師，為自己也好，為別人也好，要把環境改變，讓自己的工作環境變得良好。

DevOps一個釋出流大概是這樣的，我們在GOPS上還會發佈一個更強壯的版本。我們開發工程師把程式碼提交上來以後，出發生產build，通過Maven，包括單元測，沒有問題都通過以後，我們可以對測試團隊進行提測，通過冒煙，那些基本的測試要做一下，但是不會所有的都回歸。

到我的預釋出環境，再到我的正式釋出，通過灰度的方式來逐步將線上的叢集把它釋出，是這麼一個流程。所以我們整個的過程做了很大的簡化，這裡面有很多的工具和來控制我們的過程。

這是我用到的工具，這裡面大家很多都耳熟能詳。我們用Git來做版本管理，SaltStack來做開發的PC端的版本管理，用Jenkins做編譯和持續整合，用ansible、Puppet來做配置管理、環境管理，用JMeter做壓力測試，底層可能是公有云、私有云，日誌用ELK，我們用Docker來做持續整合的小平臺等等。

這是Gitlab的一個截圖，整個專案裡有746個庫，有371個開發人員，這是當時我在這個專案的時候，37個團隊，這裡面每天各種任務或者push，這都是上萬次的任務。

這是Jenkins的介面，我們有幾十個產品、APP等等，這是個整合測試，我們將JMeter整合到Jenkins這邊來了。

DNS系統有個泛域名是指到Nginx上去的，每當提交一次專案，會直接發個郵件給相關的開發和測試人員那邊去，測試人員通過域名就可以訪問這個專案，進行相關的測試，這是我們自己寫的一個容器平臺。

CMDB每個公司應該都是需要的，我在不同的公司做了不少這樣的專案，但是沒有一個能夠開源的，為什麼，因為和系統耦合度過高。

今年春節的時候我閒著在家沒事，寫了一個開源的CMDB，功能大部分都有，但是如果自己用的話，根據我這個基準大家可以調一下，如果有公司沒有CMDB，可以把這個用下去，因為你好多基礎的工作可以不用做了，包括一些基礎資訊的配置。

這是一個導航介面，我做這個是要把我們說話的平臺做一個入口，這個很簡單。

這是一個CMDB的介面，這裡面我們CMDB的基礎功能都有，也會有自動錄入的功能，我們有一個指令碼直接在目標機器上執行之下，它就會把資訊自動上報到CMDB裡，有直接來匯入的API的介面。

我還寫了一個任務編排，當然這個任務編排還沒寫完，目前只支援推送任務。我和ansible來進行一個結合，我把CMDB裡面的資訊，我在這可以做一個下拉的選擇，我在選擇安裝什麼樣的，一點執行直接就推到目標機器上去了。也做稽核，所有的任務都在後臺的日誌打出來了。還有個shell的執行，和這個類似。

這是開源的，叫做AdminSet，在github上已經公開了。