DevOps的工程化

 

孫敬雲 --Worktile高級系統架構師，WTC成員

1.研發的困境

互聯網的環境

互聯網這個環境比較特別，包括如今不僅是互聯網，就算是被互聯網賦能的這些「互聯網+」的企業也在改變，用戶在發生變化，用戶構成的羣體在發生變化，羣體形成場景的變化，場景營造新需求，需求養成新用戶習慣，新用戶習慣造就一批新用戶，周而復始。咱們一直在追趕用戶，但從用戶的角度來講，他一直都指望有一個好的產品和一個穩定的服務。相信在座各位既是技術從業者也是普通的用戶，你們會發現本身老是想嘗試一些新的東西和好的東西。

 

 

軟件交付的困境

進度不可控： 咱們的研發團隊會面臨一個問題，一些傳統的行業也好，或者如今在實行Sprnit的團隊也好，你會發現研發 進度很是不可控 。你有時候感受一切都很可控，完成任務的時候前80%也以爲沒問題，必定能交付。但一旦到了後20%，測試報出海量的bug，運維問你怎麼部署？好多東西尚未定，愈來愈忙。尤爲是上線的晚上，必定要搞一個通宵才能把全部的問題解決。這種複雜的困境是技術不可控的;

流程不可靠： 咱們公司老是有各式各樣的流程發生，但你會發現這個流程走着走着老是須要有一些 關鍵角色 蹦出來，必須有一些企業大牛或團隊經理站出來講這個事情應該怎樣作，或者說今天誰誰沒來，這個流程無法往下作。

環境不穩定： 線上怎麼就出問題了？測試環境好好的，本地就沒問題，是否是由於線上沒有按照我說的作？環境這個問題在哪一個公司都會遇到。

溝通不順利：研發同窗跟運維同窗在爭論，研發同窗說上線以後跑腳本，運維跑完了上線出了問題。研發同窗就問他「你跑腳本了嗎？」他說「跑了」，「是部署前跑的仍是部署後跑的？」他說「你沒有跟我說這個。」這就是溝通不暢，這個原本是能夠避免的。

 

 

咱們須要一種工程手法，讓軟件在很短的週期內穩定部署上線。 關鍵詞是 「很短」 和 「穩定」 ，甚至一鍵部署到任何版本任何環境中，甚至這些操做都在可視化的環境進行。咱們在研發團隊中說，凡是要定目標作計劃，怎麼辦？咱們今天每一個人給本身定一個目標： 從今天開始每一個團隊一天部署三次 。你們以爲不可能，安排計劃Sprint兩天就夠嗆了，怎麼可能一天上線三次？

舉一個真實的例子

匯豐銀行在2014年的時候整年release24次，這個數字至關於 兩週有一個 release的版本，很高效。可是2018年整年release12000次，這是什麼概念？你今天一天release 幾十 次，你們以爲這不可能，開發代碼能寫完嗎？這就是一種思惟方式的轉變。

若是咱們今天說必定要達成這個目標，無論可能不可能，給我一個執行方案和參考的借鑑點。

概念的組合

咱們把這個事情分爲四個步驟：

第一步 ，自動化的流水線，這是穩定可重複使用的。
第二步 ，支持構建流水線所須要的技術平臺和工具。
第三步 ，運行這些平臺完成流水線所須要的人和角色。
第四步 ，支持可以把這些全部東西所有落地並有穩定持續改善方案的文化與規則。

2.DevOps是什麼？

DevOps在維基百科上的定義

DevOps是一種重視軟件開發人員和IT運維技術人員之間溝通合做的文化、運動或慣例，透過自動化軟件交付和架構變動的流程，來使得構建、測試、發佈軟件可以更加地快捷、頻繁和可靠。

因此前面全部的都是定語，只有最後一句最關鍵，就是 ：頻繁可靠的發佈軟件，這就是咱們的終極目標。

 

 

針對剛纔定義的原始闡述，從這個環形圖上的工做方式，一直在持續演進，好像看起來沒有什麼特別的，這個神奇點在哪？

 

 

若是你跟別人說你今天看了一篇分享是DevOps，或者你去搜DevOps，會發現所包含的含義和相關的含義特別多，包括 精益思想、自動化、持續集成、持續部署、價值流、三步工做法、持續交付、分級部署、敏捷思想、敏捷開發、團隊合做 。

 

 

在我看來這是你們對於美好事物的一種指望，指望DevOps能承擔更多。即便咱們今天不提DevOps這個詞，把敏捷這個詞說出來，你也會說敏捷包含這些部分，換個詞也是這樣。我認爲咱們 千萬不要陷入於這個詞的含義是什麼 ，我是想談 工程化 ，談 工程化背後美好的東西。

「持續交付」和「DevOps」

咱們挑兩個特別容易被網上的人或你們所對比的詞彙，一個是 持續交付 ，一個是 DevOps 。

 

 

持續交付也好，DevOps也好，他們的共同點是秉持交付思想，他們都崇尚精益思想，他們都喜歡自動化，他們都以快速和穩定的變動爲目標，這是兩個共同點。持續交付偏向於將不一樣的過程集中起來，而且更快更頻繁地執行這個過程。

雖然咱們對比了這兩個詞，但我但願你們不要過分陷入於概念自己，不是說我今天學的到底是DevOps仍是持續交付，這個沒有意義。咱們要把好的思想帶回項目組，帶回團隊，能不能落地是咱們的關注點，咱們不要過多對比概念。

基礎參與人

凡是涉及人的話題，必定是比較特別的，你只要不把人的範圍說清楚，這個事情就別想落地。只要你沒說這個事情讓他作，他就不會主動問你，若是你主動問你說明這我的是優秀員工。

把敏捷開發單獨四個字列出來，持續部署跟持續交付看似範圍同樣，但持續交付指的是我有交付能力，但我沒說必定要部署到線上環境。持續部署講的是如今既然已經完成了構建的流水線，那麼就從頭走到尾就結束了，這個講的是自動化。DevOps講的是什麼？範圍好像如出一轍，但 DevOps不強調每個角色應該幹什麼，而是將全部的角色聚集在一塊兒 ，有點像敏捷思想裏面的 角色互換 ，你們誰都能幹這個事情，不用指定這個事情，你們能夠角色互換一塊兒來作，因此 DevOps不強調每個人誰是誰，而是強調這些人聚集到一塊兒以後，你可以將開發編譯測試一次性完成 ，這是他們的區別點。

 

 

3.DevOps工程化

工程化這個詞不知道你們怎麼理解，你在寫代碼的時候，咱們說你的代碼結構好，你的框架設計得好，這實際上是一個工程，由於它落地。咱們今天談的DevOps工程化也指的這個含義，到如今爲止都是一些比較抽象的概念，它是一些比較好的理念，沒有具體的落地點，你沒法感覺到它真正的好。

 

 

若是你的團隊想要去實施DevOps，從個人觀點來講它由 四部分 組成。

流水線： 流水線必定要自動化，自動化的流水線必須是可靠、可重複、高效的流水線，你的流水線必定要可視化，全程可見，出了問題能夠提示你，將你的部署交付給他，完成到哪一步，完成的效果怎麼樣，咱們須要有實時反饋和實時監督。

技術平臺和工具： 這個技術平臺我列了 容器 和 集羣 ，有人可能說咱們公司也作了流水線，也作了自動化，沒有用容器作也挺好的。不知道有沒有人最近關注國際和國內比較流行的詞彙，最近我發現有兩種思惟比較大，一個是微服務，一個是雲原生。

你們知道雲原生是什麼意思嗎？你的服務不管部署在哪個雲服務的提供商上，它均可以正常去跑，這是一個基金會發起的很是好的倡議。你在百度雲上作的好好的，能夠拿到阿里雲、華爲雲去作，代碼一行都不用變。若是你的部署方式基於物理機而不是容器，未來想作雲原生就很難，雲原生必定是歷史趨勢，我建議若是想實施，你能夠提早往前多走一步，直接到容器化。使用容器有這麼幾點。一是既然使用容器必定要有標準化，你的容器是怎麼構建的，裏面包含哪些東西，須要啓動的方式是怎樣的，須要怎樣的運行，這都是須要你本身規劃跟設計的。

有了容器就要有私有鏡像倉庫，往DockerHub去推，若是被別人拿下來可能會形成代碼泄露的問題，因此咱們要搭建私有鏡像倉儲。再往下要有集羣，當前的集羣很是多，並且都很是成熟，從今年開始聊Kubernetes的人愈來愈多，由於去年它已經贏得了集羣的勝利。自從發表了1.3，如今有1.4，立刻要發佈1.5，如今愈來愈強大了，集羣這個事情越早越好，我相信有夢想的工程師都想創造出一個QPS幾十萬的服務。當這一瞬間忽然來的時候，你的服務能不能扛得住？你的基礎設施夠不夠穩定？這就形成了極大的挑戰，這時候就須要集羣幫你管理一切。
若是有集羣，要提早構想微服務怎麼搭，怎麼充分利用集羣的價值。若是用微服務也好，用集羣也好，部署管理怎麼作，每一份要怎麼布，怎麼作熔斷機制，怎麼作監控報警，怎麼作擴容，全部的這些東西都須要本身提早考慮，須要提早想清楚。

人和角色： 主要分兩類， 開發測試 和 運維 。開發跟測試放在一塊兒，由於我認爲這兩個角色按道理來講是屬於一個工種。在谷歌實際上是沒有測試這個職業的，他們都叫QA，都是質量控制幫你把控質量。在百度的時候也沒有測試的概念，QA前線大到什麼程度？開發了代碼就不讓你上線，就懷疑有問題，由於我有數據，我發現你的執行速度慢了一毫秒，你將影響咱們多少用戶？這些用戶加到一塊兒是多少小時？你能承擔起嗎？他們一說我就沒話了，承擔不起就不上了，不上了老闆找誰？由於已經答應了上線。因此開發跟測試必定要搞好關係，咱們是一塊兒的，你必定要讓我上，你讓我上了請你吃飯，咱們倆是一家人。這個是玩笑話，這兩個角色不要對立，它們是一塊兒的，要共同搭建分支策略。你們必定會聽過標準代碼分支管理，它們須要共同搭建持續集成。你提交任何一個代碼進行持續集成，保證整個代碼的質量持續穩定交付，就是須要持續集成做爲保證和前提。

文化規則： 講到團隊文化，你們可能會以爲很虛，以爲不切實際，好像離咱們很遠。

舉個例子 ，一個好的團隊文化，尤爲是DevOps團隊或敏捷團隊，必定要講角色的互換。今天你作這件事情，明天能夠作另外一件事情。咱們不是說缺了誰就不能上線，缺了誰公司就無法轉，咱們應該靈活轉變本身。如今有一個很是好的職位叫DevOps工程師，什麼都能幹，甚至DevOps工程師要強到什麼程度？他須要出來說課培訓DevOps，有時候客戶一諮詢，我解答不了，可能DevOps工程師寫着寫着代碼就去回答問題了。

說完了整個架構圖，咱們再從頭看一下 流水線的概念 。

 

 

這是DevOps和持續交付裏面標準的流水線。

程序編譯 --這個不用多說，不管開發哪一個語言，除了腳本語言以外，多數的語言都有編譯環節，原文件要編譯要編譯成另一種形態才能運行。

單元測試 --我建議你們有空都要寫單元測試，單元測試是很是好的東西，由於你寫了單元測試以後就會發現，你跟QA的關係會變得很是好，你就不必麻煩他了。

集成測試 --每一塊獨立的東西測試沒問題，放到一塊兒以後測能不能正常工做？

性能測試 --你今天上的東西對於咱們如今已經有的東西性能是有提高仍是有損耗？

日誌測試 --不少東西表現沒問題，但日誌中老是報奇怪的錯誤，有些人意識好，可能會打各類各樣的debug。若是你有了日誌分析這一步，必定會發現潛在地方有潛在的漏洞，也許到了線上會變動成嚴重的問題，這個東西在寫單元測試的時候可能考慮不到，咱們須要這幾步來保證持續集成的正確性。到這爲止是持續集成的核心。

鏡像 --將如今全部的東西放到一塊兒，打成最終的鏡像，把鏡像上傳到雲端，專業術語叫製品庫。

預發佈、驗收、部署上線 --驗收是預發佈環境作迴歸測試，沒有問題就能夠直接上線，這個地方能夠手動也能夠自動，咱們只講流水線不講到底指持續部署仍是持續交付。

實戰入門

演示時用到的技術若是你們沒有接觸過也不要緊，一步一步來就行了。

 

 

Gitlab、Docker、Kubernetes、Helm、Harbor、Jenkins這些都是比較標準的，只是入門，咱們只是增強這個意識。

 

 

首先咱們要進行代碼分支規範。主幹分支切開發分支，完成以後向開發分支提代碼，這時候會觸發持續集成，驗證向分支提交代碼是否安全是否對，剛纔的東西跑沒跑過，跑過要加入代碼質量跟代碼的review，沒有問題往下走，開發分支結束，咱們把東西提交到我的分支上，把代碼部署到某一個環境，假如說是測試環境。

 

 

這是持續部署的簡單示意圖

Github發起通知Jenkins Job1，Job1告訴Job2，在Job2中上傳鏡像，把鏡像傳到Helm裏，經過Kubernetes部署到Pod節點中，完成部署。咱們把Job2打開，Job2被觸發。爲何我剛纔把Job1跟Job2分開？由於對應的不同。Job1對應項目代碼，Job2對應部署代碼，咱們如今把它們解耦分開，如今Job2能夠複用，能夠構建很是多的項目。

 

 

在構建的時候須要製做鏡像、上傳鏡像、部署鏡像，每一步均可以用腳本語言實現，經過Jenkins、file串聯起來，入門的時候作好這塊就能夠了。

這套流水線能不能用在不一樣的環境上？能夠，要作環境的配置管理，須要你在集羣裏面作一些操做，在Kubernetes的文件裏說明這裏面須要部署多少的資源，須要使用多少東西。Chart文件能夠幫你輔助，把不一樣的環境區分開。

 

 

講完了工具講文化，實施以後進一步落地DevOps怎麼辦？資源管理必不可少，分紅幾步： 監控報警、行爲規範、經常使用腳本、操做指南 。每一步都很重要，怎麼去監控？監控要注意哪些事項？怎麼定義行爲規範？腳本很重要，腳本越多越好，能自動化不要手動，多寫一些文檔，供別人使用，新人文檔也好，甚至是操做指南，或者線上文檔怎麼布，用文檔記錄下來總沒有壞處。

 

 

相信一小時以後，你可能就已經忘記我說的是什麼了，不要緊我不在乎，但你必定要記住這張圖。

 

 

若是你的團隊想實施DevOps，四個因素必定要有：

自動化流水線
技術平臺和工具
人和角色
文化和規則 。

這四個一個都不能缺，缺一個都不能叫DevOps團隊，只能叫感受還不錯的團隊 。

總結

沒有最好的實踐，只有最合適的實踐，每一個公司落地的方案都不盡相同。但願你們在不斷探索更好的過程當中，找到本身團隊適合的DevOps解決方案。

認真能夠把一件事作對，用心能夠把一件事作好。

文章來源：Worktile敏捷博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。