【51CTO.com原創稿件】隨著互聯網產業的飛速發展，IT 研發的工作方式也越發的靈活多變。從應用的角度來說，由原來的單服務應用，到現在的微服務應用，處理的數據量和類型也在不斷增長。
圖片來自 Pexels
從團隊的角度來說，不僅包括開發，測試人員，還引入了運維，安全，系統，網絡等各個專業的人員。
那麼在新的時代下，我們如何利用 DevOps(開發運維)的方法論指導交付過程，就顯得尤為重要了。
我們將從 DevOps 的兩個要點三個原則切入，來看看組織，團隊，流程的優秀實踐。
DevOps 的兩個要點和三原則
做任何一件事情都有其價值，做事的過程就是“把業務構想轉化為客戶價值的過程”，我們稱之為價值流。
對於研發團隊來說，也存在技術價值流。它就是通過“開發+運維”的敏捷迭代的方式為用戶提供價值。技術價值流就是第一個要點。
通過開發運維的方式，幫助業務想法觸達到客戶需求
如果把我們創造價值流的工作分成兩個階段：
- 第一個階段是設計和開發
- 第二個階段是測試和運維
技術價值流創造的兩個階段
那麼前置時間是客戶提出需求，我們創建一個工單解決這個需求，然後處理工單，直到工作完成的時間的總和。前置時間作為第二個要點是我們值得關注的。
部署工作的前置時間和處理時間
通常情況下從設計，開發，測試，運維中間需要經歷很多複雜漫長的過程。
交付的過程複雜且漫長
我們想要達到的目標是，在代碼版本控制中不斷提交小批量的代碼，每次提交都會做自動化的編譯，自動化測試，手動測試(探索測試)，然後再部署到生產環境中。
為了實現這個目標，需要儘量讓設計，開發，測試，發佈的時間縮短，給客戶提供最大程度的技術價值流。
基於上面提到的兩個要點，下面三個 DevOps 原則就是最好的選擇。
流動原則
為了縮短從開發到上線之間的時間，提高服務質量和可靠性，我們會加快開發(Dev)和運維(Ops)之間的流動。我們一起來看看需要注意哪些方面。
①使工作可見
和傳統行業相比軟件開發行業的工作可見度不高。通常只有完全做完才能看到可以使用的用戶界面，有的後臺服務甚至完成以後都看不到長什麼樣子。
但是對於不可見的東西，人們對其又難以掌控，所以我們需要對工作進行可視化。
在敏捷開發中我們會對每個階段的任務進行切割，協助項目推薦和軟件開發的完成。
開發，運維，UAT，交付全流程
同時我們要告訴團隊，只有軟件交付到用戶手中並且給用戶帶來價值了，我們的工作才算完成。
②限制每人同時持有的任務數
這種場景大家是不是經常遇到，你在開發某一個功能的時候，測試同學向你報了一個急需解決的 Bug，同時產品經理又跑過來說這個需求可能需要再改改，架構師也找你談重構的事情。
這導致一個人同時要處理很多事情，每件事情都很重要，都需要馬上完成。就好像攤大餅一樣，每個事情都做，每件事都做不好。你會不斷地被打擾，在任務之間切換，使得效率變低。
因此，需要藉助看板控制每人的任務量，讓任務保持合理的數量，從而保證質量和效率。
一人持有多個任務
③減少批量大小
我們在開發過程中經常會遇到這種情況，一個事情有四個步驟組成，我們需要完成 100 件這樣的事情。
於是，根據抽象和分工合作的原則，我們把這個事情分成 4 步，每個步驟分配給一個人來完成，這樣每個人完成每個步驟 100 次這個事情就完成了。
這個方法沒有錯，但是在做這個事情的初期，最好是把這個事情的四個步驟由一個人先完成一次，看看是否存在潛在的問題，在看看在完成過程中是否有可以總結的經驗和需要踩的坑。
這樣往復幾次，把一些問題解決以後再找其他幾個人來分步驟幫忙。這種方式在快速試錯的互聯網企業用的非常的多。
先完成閉環流程，再複製經驗
④減少交接次數
我們在完成一個事情的時候往往會和其他的團隊和人員進行大量的溝通，請求，委派，通知，協調等工作。
例如：軟件發佈過程中就需要面臨功能測試，集成測試，環境搭建，配置服務器，存儲管理，網絡等工作。如果任何事情都需要審核，協調勢必會降低工作的效率。
這裡互聯網企業的扁平化管理就可以借鑑，每個小隊包括技術，業務，管理和不同領域的人員，這樣減少了跨部門的溝通，工作效率更高。
減少交接
⑤識別和改善約束點
在軟件開發交付的過程中有很多約束，包括：人員，時間，軟件，服務器，網絡等等。
在 DevOps 中也一樣，我們需要不斷的識別這個約束，並且不斷改善這些限制條件才能推進整個開發的進度。
讓約束點之間能夠平滑過度
環境搭建：建議使用自動的環境部署，利用現在容器技術(Docker)提高整個環境的搭建速度。
代碼部署：建議讓代碼上傳，編譯，部署自動化起來。這些動作在一個軟件交付團隊每天都在不斷的上演，開發團隊的人越多這個工作更是需要做。
測試執行：這個是承接上一點的，一旦一個軟件發佈以後就需要跟進自動化的測試。
至少用自動化腳本針對核心 20% 的功能進行測試，然後再由測試人員對具體功能進行冒煙測試。
軟件隨著功能擴展，測試工作量也會隨之增大。如果不用自動化測試，依靠手動測試工作量是很大的。
解耦架構：隨著微服務的風行，現在基本都是組件式的設計，組件出現問題都做故障隔離和熔斷機制，那麼也需要針對組件進行發佈。
反饋原則
如果說流動原則說的是，從開發到運維的快速流動，那麼反饋原則就是從運維到開發快速的反饋。這兩個原則週而復始運轉，才能為客戶交付最好最快的軟件服務。
①及時發現問題
一個服務/產品的交付歷經了很多個過程，從需求分析，原型設計，架構設計，編碼，測試，發佈，集成測試，驗收測試，一直到上線。
每個階段都有工作者參與其中。任何一個問題的產生都是有原因的，即使不能阻止問題的產生，但可以第一時間發現問題，讓問題暴露出來。
例如：產品經理沒有分析透徹，到了開發的時候就會遇到需求不清的問題，這時程序員就可以提出問題，產品經理就需要對需求進行澄清。
發現問題，反饋問題，解決問題流程圖
②解決分析問題
有這樣一種情況，在開發的時候發現的問題，在需求和設計上都沒有提到。如果放任錯誤不管顯然會影響系統運行。
如果採取事不關己高高掛起的態度，那麼問題永遠無法發現，那麼出現問題我們應該如何處理。
第一，上游環節出現問題，一定不要把問題帶到下游環節。在上游環節就把問題解決掉。
上游環節出現問題
第二，暫停上游環節的工作，避免新的問題繼續產生。
發現問題及時處理
第三，建立 PDCA 環，計劃(Plan)，實施(Do)，檢查(Check)，改進(Action)避免此類問題不再發生。
建立 PDCA 機制
③源頭保證質量
什麼是源頭，相對下游來說上游就是源頭。產品經理是開發的源頭，需求質量不過關代碼就受影響。
程序員是測試人員的源頭，程序質量有問題測試就會受影響;測試人員是客戶的源頭，如果問題都被放過了，那麼就不能給客戶帶來價值。
所以，保證源頭就是保證交付的質量。對每個過程和階段做監控是我們要關注的：
- 需求階段：需求評審，需求確認，需求宣講。
- 開發階段：代碼審核，結對編程，單元測試。
- 測試階段：冒煙測試，迴歸測試，驗收測試。
- 發佈階段：自動配置，自動部署，自動檢測。
追根溯源圖
④客戶同理心
客戶分為兩種，內部客戶和外部客戶。外部客戶是通常意義的客戶，我們為客戶提供軟件交付，滿足客戶的需求，為客戶創造價值。
內部客戶就是我們的下游。產品經理把開發人員作為客戶，開發人員把測試人員作為客戶。
我們在做任何動作，發現任何問題，做任何決定的時候都要想想我們的“客戶”，是否對他們有利。我們要把自己放在客戶的角度來看問題，好多問題在當下就會被解決。
客戶在哪裡，站在客戶的角度
學習原則
學習原則是對前面兩個原則的支持，是基礎原則。不管你在工作中踩了多少坑，不管你在編碼過程中遭受多少失敗都不要忘記學習，持續的學習讓一個人變得更加強大，讓一個團隊逐漸成熟。
①建立學習型的組織結構
在服務交付的過程中，無論我們如何的小心都無法避免犯錯。大家都有背鍋的經歷。
比如某某需求，本來產品經理就沒有說清楚，程序員在實現的時候忽略了，到了交付的時候就是程序員的鍋，之後項目經理就會信誓旦旦地把開發人員批評一通。
這種場景在我早期工作的時候經常遇到。後來隨著帶的項目越來越多，發現這樣“責備”式的解決問題方式是不對的。
我們應該多從問題本身出發，找出問題的原因。總結歸納，定義好的流程和機制讓兄弟們不再犯類似的錯誤。
如果我們把組織分為三類的話，我希望我們應該是生機型(學習型)的組織。
組織類型分類
病態型：組織中的成員感到大量的恐懼和威脅(生怕做錯事情)。大家為了保全自己都不願承擔責任，甚至隱瞞真相和事實。
官僚型：規則多，流程僵化，大家自掃門前雪。
生機型(學習型)：在錯誤中不斷總結，不斷學習，不斷進步。大家積極探索，勇於承擔，樂於共享。
生機型組織是我們的目標
②日常工作制度化
這裡的制度化並不是為了官僚而給大家加入的繁文縟節，正好相反這些制度的產生都是兄弟們在工作中總結出來的經驗教訓，轉換成制度的原因是希望不要有其他的兄弟再踩這些坑。
舉個例子，早先我們做發佈的時候總是忘記發佈數據庫的腳本，導致生產環境的程序 Run 不起來。後來，我們把更新數據庫腳本作為發佈前必須做的事情寫入到發佈制度中。
再後來，作為自動化腳本寫到自動化發佈中。實際上在工作中有很多好的經驗，如果我們留心都可以建立這樣持續改進的機制，成為心照不宣的制度。實際上我們在平時編碼中有很多事情都可以好好總結。
比如：編碼規範，命名規範，標準的 MVP/MVC/MVVM 寫法，發佈流程，測試用例，測試腳本。
制度服務於流程
③局部經驗全局化
在開發/運維過程中我們經常會遇到各種各樣的事件(坑)，這些事件或是迎刃而解或者困擾我們許久。
但最終解決以後，我們希望把這些經驗放到知識庫中保存起來，這是我們共同經歷的一筆財富。
實際上一個項目做完以後，問問自己你在這個項目裡面學到了什麼，就是這些經驗的積累。
當你找下一份工作的時候，面試官問你遇到最困難的問題是什麼的時候，你就可以自豪的分享這些經歷了。
就算是再小的經驗，在放到全局的時候對其他的技術人員甚至是跨部門的技術人員都是有啟發和幫助的。
用知識庫管理經驗
④注入彈性模式
這裡說的彈性有兩個方面的意思，一個是指人員的彈性，一個是指我們維護系統的彈性。
人員的彈性，在衝刺項目的時候要有長征的韌性和搶渡大渡河的勇氣。在項目不忙的時候，也需要不斷總結，學習新知識，每個人的成長才能帶動整個團隊的成長。
項目的彈性，用壓力測試的方法，對維護的系統進行正壓力測試和負壓力測試，探查我們系統的承受極點，從而完善他。
團隊彈性和系統彈性
DevOps 組織結構
根據康威定律，軟件的架構和軟件團隊的結構是一致的，這個是康威定律對團隊和架構的解讀。
我經歷過團隊從小到大的發展，在初期人較少時，工作流程概念不強，一個人做多個角色的事情，基本沒有溝通成本，軟件的架構基本是單應用。
後來隨著開發，測試，運維人員的增加，總體需要處理的工作量也大了。為了方便管理和項目推進效率，會對人和事情進行切割，規定流程以及團隊之間的溝通方式。
架構也從原來的單應用轉變成了後來的微服務，數據庫從原來的單庫轉化為分表分庫的模式。
組織結構決定軟件架構
開發，測試，運維相互融合
在開發過程中，開發，測試，運維所屬不同的專業，在項目推進過程中各司其職。在 DevOps 的組織結構中，需要他們三者互相融合。
開發完成以後需要通過單元測試，結對編程的方式保證代碼的質量。測試需要發現/驗證 Bug，並且與運維合作完成壓力測試/性能測試。
大家會發現，現在很多大廠的一線運維人員都是來自開發團隊，甚至有很多公司都鼓勵，開發，測試人員參與運維工作。讓他們感受一下自己的工作對下游工作的影響。
開發，運維，測試相互融合
DevOps 團隊搭建
團隊成員互為依託
既然瞭解了 DevOps 的組織結構，那麼團隊需要哪些成員參與呢?
- 產品負責人：業務方面的代表，可以把他想象成客戶。
- 開發團隊：負責具體功能開發。
- QA 團隊：負責質量保障。
- 運維團隊：維護生產環境，配置，發佈。
- 信息安全團隊：負責系統和信息的安全。
當然，大家可以根據自己公司的需要在這個基礎上增加一些管理和支持職責的團隊。
對初創企業來說，如果沒有運維和信息安全的團隊，建議找開發團隊的兄弟兼任。
團隊價值流
多個團隊合作工作，存在溝通，統一認知等方面的問題。價值流圖就是為了統一大家的思想，讓每個團隊的成員都知道，在什麼階段需要做什麼事情。實際這些圖在之前的文章中也有介紹，無非是把團隊和階段對應上。
團隊價值流圖
工作在線
如果說要讓團隊站在同一個平面上面，使用高效的工具是必不可少的。例如：Confluence，石墨文檔，Jira，禪道，ProcessOn，Jenkins，Bamboo，Git，JMeter，LoadRunner。
它們可以幫助我們從設計，開發，測試，發佈各個階段提升工作效率。讓團隊保持高度統一，讓所有的工作都在線。
讓工具為團隊服務，讓工作在線
DevOps 流水線部署
團隊存在的目的是，為了客戶創造價值。那麼將軟件交付到用戶手中的過程，就好像工廠的流水線一樣，流水線的上游是原料，經過加工以後，輸出的是商品。作為 DevOps 的流水線部署，需要使這個過程自動化。
作為交付團隊每次完成代碼編寫完成，都需要提交版本庫。提交以後，版本庫會對整體的代碼進行編譯(構建/Build)，並且執行單元測試的代碼。
如果失敗，會把錯誤信息打回交付團隊，程序員在修正錯誤以後再次提交代碼。只有通過後，才發佈到測試環境，進行自動化腳本的測試。
同樣沒有通過自動化測試，依舊會打回到開發團隊，再次進行修改。這個過程週而復始，直到通過用戶驗收測試，並且發佈。
DevOps 流水線
提交階段：是從技術角度上判斷系統是可以工作的。這個階段會進行編譯，運行單元測試腳本，通常這些腳本都是程序員自己編寫的。
另外，會針對具體代碼，由經驗豐富的程序員做代碼走查，或者代碼互查。這裡可以使用 Junit 單元測試工具。
自動化驗收測試階段：是從功能和非功能角度上斷言整個系統是可以工作的，即從系統行為上看，它滿足用戶的需要並且符合客戶的需求規範。
手工測試階段：用於判斷系統是可用的，滿足了它的系統要求，試圖發現那些自動化測試未能捕獲的缺陷，這部分測試內容較為複雜，步驟較多，甚至存在多系統切換的情況。
這一階段通常包括探索性測試、集成環境上的測試以及 UAT(User Acceptance Testing，用戶驗收測試)。測試人員會根據 UAT 的用例對系統進行測試。
發佈階段：旨在將軟件交付給用戶，是直接將其應用部署到生產環境，部署之後就進入運維階段。
按照流水線部署的好處就是，控制每個階段的交付質量，逐步建立交付者的信心，通過層層篩選將問題擋在外面。
同時對於開發，測試，運維人員也是考驗。他們需要大量的協同工作，不斷地讓應用在流水線上流動，並且及時反饋給不同位置上的隊員。
在熟悉了流水線上的幾個階段以後，再來看看每個階段產生了哪些數據，以及這些數據是如何流動的。
①流程的起點是，開發人員向代碼庫提交代碼。在 Checkin 代碼之前，開發人員需要把代碼庫中相關的代碼和組件下載到本地，保證修改後的代碼在本地是可以編譯通過的。
比較規範的公司，是需要申請 Code Review，讓其他的同事走查代碼。雖然在 Checkin 到代碼庫之後，平臺會自動運行單元測試。但是建議各位，先做單元測試。
因為，一旦進入驗收階段，編譯會花費大量的時間，如果出現問題，系統會生成錯誤報告並且發給 Team Leader 或者項目組。
如果那個時候再改代碼，恐怕所有人都知道 Bug 是從你這裡出來的了。因此，還是先在本地跑一下單元測試。
其範圍包括你修改代碼的模塊，也包括其他模塊。實際上，任何對代碼的修改都有可能影響其他模塊，即使你並沒有修改其他模塊。
持續集成管理系統對這次代碼提交作出響應，從指定的代碼庫拉取代碼，並且進行編譯，運行單元測試，執行代碼分析，組裝打包。
如果單元測試都通過，並且代碼符合編碼標準，就可以打包成可執行文件，並放到一個成品庫(artifact repository)中。
當下的持續集成服務器，都提供這些功能，並讓用戶和流水線的後續階段能以簡便的方式進行。
另外，還有像 Nexus 和 Artifactory 這樣的工具可幫助管理過程產物。目前比較成熟的產品。例如 Bamboo，Jenkins 都可以通過配置代碼庫，成品庫，通過腳本命令的方式完成上述操作。
②第二個階段通常由運行時間較長的自動化驗收測試。這些測試的主要內容，是針對一些 API 和模塊的測試。
也有的項目組用來做頁面的測試，但是個人不建議做頁面的自動化，特別是在頁面設計的初期，頁面元素經常變動，自動化的腳本變化也很大，效果不是很好。
在此之後，部署流水線可能會有分支出現，這樣就可以將該構建版本獨立部署到多個不同的環境中，比如部署到用戶驗收測試環境、容量測試環境和生產環境。
也有串行的例子，比如 DEV(開發)環境，INT(集成測試)環境，MO(準生成)環境，Prod(生產)環境。
通常情況下，我們希望測試人員或運維人員可以做到自服務，即自己手工選擇需要的某個版本。
例如：可以通過 Bamboo 或者 Jenkins 工具選擇成品庫中的應用版本，然後發佈到指定的環境。
所謂的自動化部署腳本也就是一行能夠在服務器上運行的命令，執行命令完成部署工作。
測試人員應當能夠看到需要手工測試的所有構建版本，以及它們的狀態，之後單擊一個按鈕，運行相應的部署腳本將選定的構建版本部署到選定的環境上。
提交和驗收階段
總結
DevOps 模式需要遵循三個原則，快速流動，及時反饋，堅持學習。因此，DevOps 的組織結構需要開發，測試，運維緊密合作。
按照這個標準去打造團隊，讓團隊產生價值流，通過工作在線的方式，給用戶提供價值。
DevOps 的價值體現在流水線的部署方式，這裡需要合理配置提交，驗收，手工測試和發佈階段。讓應用快速流轉，讓團隊收穫及時反饋，從而穩步推進軟件交付。
簡介：十六年開發和架構經驗，曾擔任過惠普武漢交付中心技術專家，需求分析師，項目經理，後在創業公司擔任技術/產品經理。善於學習，樂於分享。目前專注於技術架構與研發管理。
閱讀更多 51CTO 的文章
