7月15日，優維科技和數人云在上海舉辦了“DevOps&SRE超越傳統運維之道”第三期，現場座無虛席。在這裡再次感謝頂著酷暑來參加活動的小夥伴們！以下為優維科技劉勁輝的演講實錄。

---

劉勁輝 優維科技高階解決方案架構師

曾就職於阿里巴巴移動事業群，具有多年的業務運維和運維研發經驗。曾負責開發建設基於阿里遊戲中心JWS框架的自動化運維平臺，對DevOps實踐落地有豐富經驗。

---

《優維科技內部DevOps研發實踐》

一、Why DevOps？

首先，我先簡單跟大家講一下DevOps基本的理念，可以簡單問一下現場對DevOps有比較深刻了解的舉一下手。好的，大部分都是比較不清楚的。

我先講一下這部分內容，其實在企業生產的過程裡，他們關注的核心都是3個東西，就效率、質量和成本，不管是哪個企業，不管是網際網路金融還是科技公司還是傳統的製造業，他們關注的點，在生產過程裡面關注的點一定是這三個目標，基於這三個目標傳統行業裡是怎麼做的？

傳統行業製造業裡面會提出一些模組化的生產、流水線生產、自動化廢品檢測等等很多的自動化流水線，精益管理是想幫助他們做製造業的生產過程，精益化的過程，但是對傳統的IT服務業來說是怎麼樣的？

IT服務業不會生產實際的產品，它會生產服務，而服務來源我們使用者需求，比如說我們要聽網易雲音樂，要玩遊戲等等其實是線上的使用者服務，不會產生實際的東西，但同樣這也是一個生產過程，只不過這兩個生產過程生產的東西不一樣而已，這兩個生產過程同樣要遵循剛才所看到的企業在生產過程中遵循的三個核心。一個是質量，還有成本、還有效率。

對於我們的IT製造過程裡面遵循這三個目標會去關注什麼方面？會關注這些方面，如下圖所示。比如說我們把使用者的需求變成線上的服務，比如說你能夠多快去釋出我們的使用者需求，還有你釋出這個需求需要多長時間？還有你釋出這個需求出問題了，該怎麼去解決？還有最終怎麼防止？

這裡列出一些是不是你組織高效能的一個衡量標準。比如說我們的谷歌、facebook 在這四個指標上執行上是非常好的。谷歌每天釋出量高頻率會達到3萬次。

然後，面對這些挑戰的話，我們提出了DevOps 的概念，其實它也是來源於傳統制造業裡面的精益管理的思想，跟傳統制造業其實是一樣的，只不過換一種方式變成了IT服務業裡面的一個落地而已。最開始它的思想是來自於傳統制造業的精益管理，精益管理抽象成到IT裡面會變成3個基本的模組，一個是敏捷管理，一個是持續交付，還有一個是IT服務管理。所以DevOps是一種文化，基本模組就是分成這3個模組。

在這些模組裡，這些東西以前都已經有了，也就是不是DevOps提出的，而是它以前都已經有了。比如說敏捷管理裡面，涉及到很多敏捷開發，版本管理，SE開發等等這種規範或者一些版本規範、分析規範、部署規範這些，這些都是屬於敏捷管理裡面的內容。

還有一個持續交付，肯定在DevOps出現之前，你們都已經做過一些運維自動化、測試自動化這種東西。還有一些IT運營的東西，可能以前的產品會分析線上的效能，或者是研發會分析系統效能這些，去搜集這類的問題管理等等。

所以DevOps的話，並不是這幾個模組具體的產生，而是它把這幾個模組做一個比較好的整合，根據傳統的DevOps 精益管理的思想把這幾個模組很好的串通起來，這才是DevOps 整個文化理念基本的概念。

二、How does DevOps Team works？

首先，我們先看一下DevOps 團隊一般是怎麼構成的，從研發的模式來了解DevOps 的模式的話，以前我們會採用瀑布流的模式，團隊可能會分成3個團隊，一個是研發團隊，一個是QA團隊，還有一個是操作團隊。然後當這種效率其實是違反了持續交付模式裡面很多內容的，比如說手動部署、開發完成再生成部署，所以它的迭代效率會慢一點。

隨著而來，我們會在研發還有測試這一塊會提出一些敏捷開發的思想，希望能把這個過程加快一點，基於這種模式的企業一般它的團隊都是研發本身是一個合作的團隊，但是操作還是比較嚴格的，這其實違反了一個模式，就是說這裡研發是快的，但只快在研發和測試方面。

它的生產環境還是會出問題，因為它在開發完成之後才出現生產環境問題，之前一直開發的時候都沒有部署過生產環境的，所以環境不一樣可能會有一些問題出現。因此，從DevOps 來看，DevOps 希望它是一個功能團隊，希望在這個團隊裡面把開發、測試運維拉在一起互相合作，這才是一個DevOps 團隊基本的構成。

來講一下EasyOps，接下來會講一下EasyOps 的DevOps實踐是怎麼樣的，先講一下EasyOps 產品研發流程，就是需求變成一個產品之後會有一個功能的時候，它的流程是怎麼樣的，一般分成這幾個階段，先是需求和概念提出，比如說客戶提出一個功能，見簡單的，他提出一個功能說我要回滾功能，那回滾功能我們先提出這個概念會做需求討論。

然後首先會去做調研，你回滾平時是怎麼做的，大部分使用者是怎麼做的，大部分企業又是怎麼做回滾的，這裡面在調研裡其實有一個誤區在裡面，很多使用者在做需求調研的時候使用者都會說你幫我在這裡加一個什麼東西，或者是你幫我在這個頁面加一個按鈕就好了，這樣做就OK了，它的需求就搞定了，它的需求真的是這樣子嗎？其實最終很多時候做這種的需求都是失敗的。

一般正常邏輯都是這樣的，我不讓使用者指導我來做什麼，而是說我會問使用者，你為了完成這個需求，你現在是怎麼做的，你一五一十告訴我，我回答之後我會把你做的那個工作，業務流程劃出來，我會分析這個過程裡哪些是好的，哪些是壞的，哪些是有問題的，哪些是可以優化的。

然後我會去做一個流程創新，我會把使用者故事的流程進行一個創新再設計，設計出一個業務流程圖，包括這個原型需求的設計文件，然後再交給我們的研發團隊去做這次任務的編寫，然後最終是一個功能的釋出。

好的，那就是我們一個DevOps 團隊組成至少要包含這一塊的東西，DevOps 基本組成會是這樣子的，比如說第一個，我們至少有一個產品經理，而且這個產品經理負責做我們的需求的收集、分析、業務流程等等的調研，這個需求分解完之後會有需求輪崗出來，這邊的需求輪崗會交給測試和QA控制組做這個事情。

QA這邊有一個評委組出一個文出來，然後再根據需求文件去寫那些根據需求出來的知識，我們的這個使用者就看情況了，比如說這個需求需要前端支援的話，可能有UI、前端和後端，所以一個虛擬團隊的話基本組成大概會有一個7人的小團隊這樣子的。

但是大部分的情況，這不是固定的，大部分的情況下，很多產品不同，可能產品會經常穿插於各個功能特性上去，所以不是固定的，會在團隊裡去穿插，我們的QA也是，當它根據需求寫完這個測試和場景覆蓋的話，可能去幫助其他的功能團隊去做更多的測試。這些也是按照實際情況來調整的。

比如說我們的功能比較簡單，需要一個後端，需要一個前端就搞定了，有可能會出現這樣子。但是，這些角色的話是一定要存在的，它是一個單獨的團隊。這些團隊一般是按照產品線來劃分，它在組織架構上會調整。

來看一下EasyOps 迭代效率是怎麼樣的，如果是按照這樣的組成來構建內部一個團隊，功能研發團隊的話，首先我們會去產生一個功能，比如說使用者級的回滾功能。

我們同時在一個版本開發裡會有同時很多這樣的功能在開發，比如說有一個團隊正在開發回滾的功能，有一個團隊正在開發版本型別的功能，有一個團隊正在開發持續交付流水線的功能，所以它會有不同的小組一起正在進行工作，這些功能最後合併成一個上線時的一個版本，比如說這個版本里面就可能發很多內容在裡面。

我們的EasyOps 研發大概是35人左右，比如說按照7人團隊來做的話，同時能夠並行5個功能的開發。但是實際上其實很多功能都不需要那麼多人的，也是可以穿插各個功能一起做這個事情，所以平時基本上EasyOps 內部同時迭代的功能大概有10個或者是10個以上，這就是EasyOps 內部產品研發團隊的工作模式。

三、How Does Aglie Management works？

接下來我會講一下我們的產品研發團隊組成在敏捷管理這一塊是怎麼工作的，其實這個也是DevOps 最主要的內容，DevOps 裡面兩個最核心的模組一個是敏捷管理，還有一個是持續交付，大家平時聽得比較多是持續交付，很少講敏捷管理，我會簡單的講一下。

我們EasyOps 內部敏捷管理是怎麼做的？首先看一下整個產品研發的流程，我們把剛才的那個圈細化一下，首先在需求概念階段的話，是怎麼樣的？有使用者提出我要回滾，然後我們就會把這個需求提交上去，它會有一個通道說這裡顯示一個回滾的功能是需求待討論的。

我們會把這個拿出來一起討論，我們的研發會一起討論確定這個功能確實是需要做，然後把這個功能立項把它給到一個分支號，比如說f056。就我們現在已經立項做這個事情了，立項做這個事情怎麼做呢？

首先還是按照剛才所說的，在你的調研和設計階段，你必須要去做調研，你必須要知道你一個回滾的流程整個流程圖是怎麼樣的，你必須畫出來，這個流程圖出來之後會產生一些使用者操作的場景，這實際上是使用者用你的功能以後會出現一些場景，比如說回滾，它可能立即回滾，比如說他釋出完一次之後，馬上有問題了系統幫它立即回滾。

或者是另外一種場景，他選擇釋出之後，15分鐘之後發現業務上有問題，但是他本來原來剛才啟動的時候是沒有問題的。後面事後回滾的話是怎麼做這個產品的，然後多應用，比如10個應用、10個應用釋出了，現在要回滾這些應用怎麼去做，這就是使用者故事的場景。

然後根據這些使用者故事的場景我們會去設計一個原型出來，根據不同的場景設計這些原型，最終得出我們的需求文件，這個需求文件包含了我們的設計原則和業務流程圖。然後產品，研發和測試就是看到這個測試流程圖幹活的，當然也有需求討論會去討論這個需求文件。

簡單看一下業務流程圖是怎麼樣的，這裡是f063是我們的docker 開發的業務流程圖，使用者是怎麼樣在我們平臺上使用docker 的映象管理的，比如說這個有一個docker 映象管理它會有不同的業務流程管理它，不然研發沒有流程圖，沒有需求原型是很難精確理解到這個需求，最終做出來很容量變樣的，所以這塊在管理裡是非常重要的。

這是業務流程圖，這是業務原型，產品性大概做這個東西做成什麼樣子，會給一個原型出來，可能可以交付給我們的後端研發或者是前端的UI等等去參考，然後最終這個需求文件會出來，明確一下這個功能的詳情是用來做什麼的，功能描述等等，還有裡面包含很多的流程圖，還有我們的業務原型圖。

需求文件提出來進入討論階段，我們會開需求評審會，需求評審會完了之後會有特性皮膚去跟蹤，這是我們EasyOps 內部的特性皮膚，特性皮膚這個功能皮膚是正被在做的，一部分是正在做的功能，一部分是已經完成功能，另一部分是準備釋出的功能，還有一部分是已經發的那些功能，可以在歷史的版本里會找到這些功能。

這是每一個功能的專案，比如說f056持續交付流水線這個功能所包含的一些基本的描述，根據這個基本的描述我們會有專門的皮膚跟蹤這個功能的開發，比如說這裡需求已經定稿的，這是研發出來的大概的任務，這些任務會跟需求1，有標籤1，比如說這個是01、02的需求，那些研發任務上面會打標籤說這是屬於哪一個需求分解出來的研發任務，全部都在這裡。然後研發的那些比如說待辦的、開發完成的，正在QA測試的都能看到。

這個是我們的專案管理進度，就是研發任務分解完之後我們有皮膚跟蹤，分解了明確的研發任務，分解了明確測試的編寫任務。當所有的任務完成了就標誌著這個功能已經被完成了，所以我們會時刻跟蹤這個皮膚上面的那些任務完成的進度，比如說這裡有總的任務數，每天完成的趨勢，還有每個人的任務統計，防止延誤的風險，這裡還會精確到個人的分析，比如說這個人工作狀態是怎麼樣的，他每天完成的任務是怎麼樣的。

我們在分解這個任務的時候要小心，如果他是比較大的功能，我們分解任務的時候希望分解到每人每天，這樣專案經理還有研發經理就很容易判斷，他這個人掛了多少任務，他現在是不是空閒的，他還有多少的工作開發量，還有天的開發量，這個皮膚還有多少的任務沒有完成，他就看一下比如說有10個任務沒有完成，這個團隊有10個人的話，他就知道這個任務今天就可以投入使用，它是這樣的模式。

在敏捷管理裡剛才說的都是整個的需求分解、研發分解、研發分解、測試用例分解等等一些管理，敏捷管理還包括其他，比如說我們的分支管理是怎麼做的，版本管理是怎麼做的，分支管理我們沒有做很多的創新，直接用了git-flow做我們的分支管理和版本管理。

這裡面敏捷管理還有環境管理規範，我們EasyOps 的環境管理規範首先包含這幾個東西，首先我們採用分支開發模式，所以那些功能之後分支都有獨立的環境。然後我們會有固定的功能開發和伺服器，這個是QA控制組立項的時候，會分配一個獨立的環境，比如說同一個功能我就分配163給他做這個開發，還有持續交付流水線，我們就分配164給他做功能開發。

接下來是我們的產品管理。比如說2.27.0版本我們都會開一個產品釋出會，這個版本帶來哪些功能去，比如說2.27這個版本前端支援開發，應用部署支援什麼，還有什麼流程工具版本控制，流程工具的支援配置管理等等這些功能在這裡。

然後我們一目瞭然的，知道這個版本發完了什麼東西，有什麼新的特性。這是敏捷管理裡面的產品管理。其實還有很多的東西，比如說EasyOps 的部署規範，由於時間關係，有興趣的可以後面跟我聊一下。

四、Why Pipeline？How Does it work？

我們講完敏捷管理，講第二個核心模組，持續交付是怎麼做的，大家會比較熟悉一點，這裡就簡單的講一下EasyOps 是怎麼做的？

剛才出現了兩個產品研發的流程圖，那是專案管理裡面的流程圖，這一頁是持續交付的流程圖是怎麼做的，首先在研發和交付階段分成幾個模組，剛才我們拿到需求文件，開需求評審會，可能研發就會分解他的任務。

然後進行程式碼研發，在這裡少寫了一個就是測試分解測試用例的場景，所以在程式碼研發的時候同時測試用例正在編寫，有可能測試用例寫完了研發都還沒有把程式碼寫完。研發寫完了以後就可以馬上進行整合，進行版本交付的過程。

講到持續交付肯定要講流水線，我們講一下流水線，這個流水線經常會看到很多教科書寫的可靠、可重複流水線，大家知道可靠可重複是什麼意思？為什麼流水線是可靠可重複的？我來簡單解答一下，可靠是什麼意思？

可靠就是說流水線它也是一種基礎環境，你可以認為它是一種程式碼環境，它也是一種程式碼，輸入1，輸出E永遠是這樣子的不會輸錯，是不可變的。這是它的可靠性。第二個可重複是什麼意思？它永遠只幹一件事情，這個過程可以追蹤、可以審計的，從來不會做其他的事情，你讓他幹A活就A，幹B活就B。

再舉個通俗一點的例子，比如說我線上部署應用A，如果人去做這個部署，可能我給上面5個人做部署應用A，可能這5個人最終都是專家應用到部署上去，但是應用部署方式不一樣，比如說第一個人先把包上傳下來，然後解壓放到臨時目錄，然後再把檔案覆蓋過去，但是另外一個人不是這樣做的，另外一個人也是先把包上傳下來，解壓把原來目錄備份一下比較安全，然後再把這個檔案放進去，可能不同的人來做過程不一樣，但是結果有可能一樣的，有可能不一樣。

就是人去做部署的時候非常不可靠的，這就是為什麼持續交付裡面非常反感那些人做手工部署，這些手工部署不僅要理解部署文件，而且你做的事情換另外一個人來做有可能不一樣，所以這是為什麼用流水線做這個東西是可靠可重複的。

我們來簡單看一下一個需求釋出的基本工作流程是怎麼樣的，至少包含這4個階段，第一個是需求設計和研發。就是你會有不斷的研發，需求設計完之後就是本地研發，本地研發之後最常見的就是提測，提測就會進入到我們的測試環境去做功能驗證，因為很多已經做了自動化的測試，這裡測試環境更多是做什麼？

做人工性的探索測試，演示性測試，會起到一些安全性的，比如說容量的壓縮等這些測試，可能會測試環境做，當測試通過之後這個版本就可以進行版本上線，版本上線比較複雜，生產環境會按照這個測試來做，比如說滾動部署。

一般的功能流程包含這4個階段，我們認為這四個階段用一條流水線來做實在是太困難了，而且是不同的階段在幹不同的事情，所以我們認為流水線可以分成多個階段來做這個事情，真正的流水線之間是有銜接的，在敏捷管理裡面它是同一個需求就可以了。我們把流水線分成三個階段，一個是開發階段本地的，一個是開發運營的流水線，一個是測試的流水線，還有一個最終交付上線的釋出策略相關的交付流水線。

在EasyOps 內部開發流程是這樣子的，就是它關注研發本地開發，我在這個功能環境裡，比如說研發正在做回滾的功能，我在163這個伺服器上不斷的提交我的程式碼，它會自動的更新163這個東西，這裡涉及到一些我們的程式碼管理怎麼做，分支管理怎麼做，以及構建設施怎麼做，你的單元測試怎麼做的，結構測試怎麼做的，還有流水線構建的能力，就包含這些能力在裡面，不要小看這麼廣，其實包含一個一個的東西在裡面。

像我們的研發，在本地一旦提交程式碼，就會程式碼構建，構建完之後就去做打包管理，打包管理註冊我們的版本，把版本註冊上去就部署到我們的163環境，然後就跑自動化的介面測試，它就包含這幾個東西。等會會講一下為什麼這裡不是單元測試，程式碼覆蓋率，為什麼這裡內部只有一個介面測試，我會在QA環節解答一下。

然後就是測試流水線，測試流水線比較嚴格一點，跟開發流水線有什麼不一樣，其實大部分都是一樣的，但是有一個地方不一樣，就是它有一個明確的版本是二進位制的包提出來，開發不關心這個過程的，所以他匯入的包可能沒有真正錄入到我們的二進位制倉庫裡去，但是測試和運維關心的不是某一個分支，而是明確的版本。

所以這裡構建的時候，在版本管理裡面還涉及到一些版本管理，我們會通過打標籤的方式，標籤就是我們的版本號，打標籤的時候會自動觸發這個流水線，比如說給一個標籤出來，註冊成一個測試版本，在我們的二進位制倉庫裡面去，要執行一些測試的自動化的介面測試，還有自動化的UI測試等等，最後就進入了人工確認的環節，人工確認比如說有一些手工測試，有一些探索性的測試要做，做完之後我就上線，如果他不想上線就結束了，這樣的模式。

簡單看一下在構建流水線的時候本身具備什麼能力才能適應，就算公司開發自己的流水線你要注意有這些能力，比如說你要有序列的能力，有並行的能力，因為有些自動化測試可以並行調的，一定不能忽視這個環節。有序列、並行、合流、分流，有子流程，可以穿插子流程，可以放一個任務，失敗了可以繼續進行，失敗了也可以停下來。然後還有判斷，一些人工確認也是需要做的。

比如說它不是OA流程的，那種人工圈是比較簡單的應用人工暫停。還有輸入輸出共享，這個在流程設計裡非常重要的，它是跟OA流程完全不一樣的地方，就是每一個模組裡面的輸入輸出在後面的時候模組都是共享的，在構建這個流水線的時候能力非常的便利。

##五、EasyOps封閉開發

講完了流水線具體來看一下我們的封閉開發是怎麼做的？比如說把上個月持續交付的流水線，就是開發這個功能，我們是怎麼開發的？把這個例子給大家說一下。

EasyOps 開發特性的案例，比如說開發持續交付流水線的功能，這個功能去清遠做了封閉開發，在那裡我們用了兩週的時間來設計持續交付流水線，只用了5天的時間開發，7個小組3個模組，一共分解了56個研發任務。

為什麼設計這裡這麼複雜，研發週期為什麼那麼短，其實你在設計階段，剛才不斷強調敏捷管理裡面的作用，一旦需求在裡面，業務流程圖非常明確，業務原型有參考的意義，這樣研發拿到這樣的資料文件才好開發，開發的效率才會高，在簡單的測試用例才不會有偏差。

需求文件設計得好，研發的效率其實會大幅度的提升，絕對不會慢，而且開發出來的東西也不會偏離場景的意圖太遠。這個能力因為我們核心團隊人都是來自於騰訊的，騰訊內部也非常重視這個東西，騰訊的產品經理的權利是最大的，只要這個需求文件說我要做研發，基本上沒有討價還價的機會。

因為他的產品都非常的專業，會畫出非常詳細的業務流程，把使用者的使用場景一步步的列出來，比如說正常的流程是這樣子的，異常的會是什麼樣子，規劃得非常的詳細，然後研發就看就懂了，這東西就開發成這樣子。業務員也覺得很詳細，有參考的意義，而且看完之後不需要弄太多，所以他們的產品經理都是有非常高的許可權。

接下來看一下使用者場景，我們流程圖出來之後就會搞一些使用者故事出來，總結一些使用者故事出來，使用者故事就是使用者的使用場景，在這個使用場景上我們去分解我們的研發任務，比如說在持續交付的流水線有哪些的使用場景，比如說第一個建立流水線，第二個維護流水線，第三個使用流水線，使用者會有這三個基本的場景使用，在這個場景裡可能會分解出哪些的使用場景和研發任務，我們用小卡片的方式把它列出來。

這就是我們的流水線的業務流程圖，比較模糊，大家可以參考一下，這個是我們的需求流水線F056，持續交付流水線是F056，原型圖是怎麼樣的，然後就用需求文件。

這個需求文件包含了流程圖還有原型，分解完之後CTO就可以簡單看一下這個功能的研發任務有多少個，這裡有一些統計在裡面，每天他可以看一下統計，可以根據持續交付流水線開發的進度，這是我們一些專案進度的分析，交付流水線基本上就是這樣子。

接下來講一下交付流水線裡面測試是怎麼做的，其實在整個持續交付流水線裡面，測試是最重要的環節，在我們的EasyOps 平面，剛開始也想做單元測試、程式碼覆蓋率這些，後面想一些這些直接體現價值的沒有介面測試高。

因為在現代應用研發裡，比如說它是很多微服務架構，那些服務組建介面就是它最基本的功能，只要這個介面功能響應是正常的，內部大部分的邏輯都是OK的，所以大部分的團隊都非常希望寫介面測試，比如說關注小寫的單元測試，這個現階段可以補上，但是現階段馬上要完成就是我們的介面測試，保證在開發過程中每一個介面都是OK的。

六、QA、Not QC！

我們EasyOps 介面測試怎麼做的？我們的介面測試首先也是基於robolframe work封裝，這個介面測試是全自動的，據說不需要人工干預，這個研發不需要誰介面測試用例，它是怎麼做到的？

首先，它基於robolframework的封裝這裡會使用一些robolframe work，只要你按照這個規範去寫介面，這上面是一個介面，按照那個格式來寫介面註釋，把這個引數寫好，robolframe work的一些關鍵字寫好，它就能夠自動的把這東西生成出來，比如說它會生成這樣子的，兩個介面測試庫就出來了。

這樣只是一個庫，因為它是通過程式碼介面生成的，通過註釋生成的，沒有維護測試用例的資料在裡面，所以測試用例的資料是我們的研發自己維護的，比如說這個測試庫上面支援測試資料，這些測試資料也是作為程式碼的一環回到程式碼庫裡面去的。

這裡還有在開發過程裡不斷的迭代我們的程式碼，不斷的做自動化的介面測試，自動化的介面測試質量也是可以去看的，比如說現在CMDB這個專案特性介面測試用例大概有多少個？它的成功率、覆蓋率是怎麼樣的？這裡有兩個衡量介面的東西，第一個是你的覆蓋率，第二個是你的成功率，覆蓋率是什麼意思？這個專案已經覆蓋滿了沒有，介面就全部寫入那個介面測試裡去。

這是覆蓋率。另外一個是成功率，我不斷的提交我的程式碼，在每一次提交程式碼的時候他就會刷一下這個自動化測試的皮膚，把這一次提交他的覆蓋率和成功率算出來展示給大家看。這個皮膚是掛在我們公司大屏上去的，所以CTO就坐在前面每天監控看的，然後他看到哪個專案說，為什麼你這個成功率失敗這麼多？因為我們提交程式碼是用企業微信通知的，每一次都會發出來，或者看這個皮膚就知道了。

這裡簡單總結一下，我們的註釋通過我們對robolframe work自動化的生成一個測試庫，然後我們自定義我們的測試資源，測試資源就是我們的測試資料，這裡有一個規範，測試庫加我的測試資源就會形成一個測試用例，在這個邏輯裡我們的研發只需要把註釋寫好，剩下來不需要關心，結果都是自動化生成的。

為什麼說在EasyOps內部，測試是QA不是QC，這裡重點講一下，我們沒有測試組，只有質量控制組，質量控制組的工作就是需求文件出來了，現在產品讓研發和質量控制組的同學一起去開需求評審會。

需求評審會之後研發就自己分解自己的分解任務，測試去做測試用例的編寫，所以他會提前參與到設計裡，當需求文件一旦明確了，測試用例就可以開始了，完全不需要等研發了。隨著需求在研發過程中有細微調整的話，最終開發完成之後，UI用例會被重新審查一遍，已確保和需求完全吻合。

還有一個介面測試和UI測試有成本上的考慮，我可以告訴大家整個版本所有專案的任務，一個專案資源專案大概有30多個元件，跑完所有的介面測試大概需要10分鐘－15分鐘左右，這裡跑完所有的UI測試需要40多分鐘，所以一般UI測試很少跑，只能在一個地方跑，只會在什麼地方跑？

就是說你會做一個測試工程，這就是平時我們經常說的測試工程為什麼會去做，我們在本地經常跑元件介面測試，基本上一分鐘內跑完非常快，所以在本地開發的時候不斷去跑這些介面測試保證功能是OK的。

但是UI測試在打版本的時候，比如說這個版本包含了幾個特性在裡面，比如說回滾的特性，持續交付流水線的特性，還有版本型別的特性都包含在裡面了，所以會做比較嚴謹整個系統的測試。

這裡有一個QA組還要提一個規範，就是我們的研發就是維護測試用例資料，但是沒有規範，比如說一般的研發只會顯示兩個，一個是OK的，一個是失敗就搞定了。

但是質量控制會規範整個開發過程，比如說這組測試要寫的資料至少符合哪些場景，哪些場景這個介面必須要，介面用例資料都補充完，不然這個就是不通過的。我算一下，多少個介面？介面用例是多少個？一算我就知道你這個完不完整，這就是質量控制在定這個規範，要研發去遵守，這就是質量控制組平時工作的一環。

有一個工作就是這個東西，所以大家看到質量控制和測試人員不一樣的，質量控制是做規範，定規範，然後去控制整個生產過程的質量，但是測試人員只是這個產品出來我做一下校驗是可以OK而已，起碼要承擔更多的東西，之前我看到老王發一張圖，說工程圖裡面薪水最高的是哪些工程師，就是說QA人員的工資是最高的，比研發還高。

##七、總 結

最後總結一下EasyOps 的實踐，其實我們做更多的事情，現在沒有時間做，比如說我們提交之前就做靜態掃描、單元測試、程式碼覆蓋率這些，後面也是可以提升一下我們的質量，但是現在是重要不緊急。

還有一個程式碼稽核平臺，比如說回滾功能完成後，我就直接合併到上面，沒有人稽核，這個東西風險也是有的，到後面可能會有程式碼審查，當你的功能完成之後，我們有跟開發分支部的人審查一下這個程式碼是不是OK的，然後才把它合併到分支上面去，因為一定要保證它是否穩定可靠才行。

第二個是用例資料的規範，QA組會定這個規則，所有的介面測試都要去覆蓋。我們這邊也要支援docker ，可能後面的組建會容器化，就算我們建立一個環境，功能測試環境怎麼快都要10分鐘，它是一個完整獨立可以執行的環境。

如果用容器這方面可能會提高一點，但是在建立環境的需求平時不是很頻繁，10分鐘還是能接受的，因為你只是建立一下環境而已。還有降低生產維護的成本，我們現在微服務的架構上組建比較多，雖然用微服務來去做動態的變化調整，對於客戶來說還是組建太多了，後面通過容器來降低生產維護的成本。

我來總結一下DevOps 基本的理念，我認為DevOps 是一種文化的精神，它是一種組織工作的方式，也是持續不斷的進步，不是說一下子就能完成整個能力鏈條，而是慢慢在DevOps 迭代過程裡慢慢把這些能力給補上來，比如說我們的自動化UI測試，自動化的介面測試，還有流水線的接入等等這些方式，後面慢慢的補上來，剛開始也是什麼都沒有的。

以上就是我今天分享的內容，謝謝大家！