一文弄懂什麼是DevOps，媽媽語氣講解
devops是什麼
devops概念提出
單體架構+瀑布模式
分散式架構+敏捷開發模式
微服務架構+DEVOPS
devops深度理解
devops實現相關工具
devops平臺搭建工具
devops是什麼
❝
DevOps維基百科定義
DevOps（Development和Operations的組合詞）是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟體交付”和“架構變更”的流程，來使得構建、測試、釋出軟體能夠更加地快捷、頻繁和可靠。
❞
這裡先給出維基百科的定義，沒指望你一下子看懂，先有個概念瞭解一下。
devops概念提出
單體架構+瀑布模式
以電商系統為例，單體應用架構為 LNMP，這個時候只有 DEV 沒有 OPS，DEV 就是全棧，就跟我們上大學玩的 demo 一樣，專案開發好，找臺伺服器安裝好環境，把 jar 包 scp 到遠端伺服器，放上去開啟服務就可以。
這個時候服務監控也簡單，服務出了問題，直接去線上看一下執行日誌，為了解放雙手監控服務，開發者會寫一些指令碼分析日誌，伺服器少，部署簡單，通常開發就可以完成運維的工作，不需要專門的運維來做部署，所以開發模式很簡答，直接按照瀑布流方式開發就可。
分散式架構+敏捷開發模式
隨著業務體量發展越來越大，一臺機器扛不住，那麼就加機器，單機變多機，業務架構也開始加入了 nginx，cdn，快取等通用基礎服務，業務變多肯定會招人，就涉及到多人協同開發，多人多機器模式。
多人協同開發問題：
先說說多人協同開發問題，人員一多，為了更好的分工，大多會將專案進行拆分，每個人負責專注於一部分，有點包乾到戶的感覺，敏捷開發的核心理念就是
既然我們無法充分了解使用者的真實需求是怎樣的，將一個大的目標不斷拆解，把它變成一個個可交付的小目標，然後透過不斷迭代，以小步快跑的方式持續開發。
。另外，一個專案是很大的，為了保證專案質量，測試環節不可減少，為了加快速度增大開發效率，QA的工作最好是和開發同步交替進行的，
需要將測試環節從後面注入到整個開發環節當中，每次可交付的都是一個可用的功能集合，對開發交付的內容進行持續驗證
。這樣開發產品的可控性也更強，遇到了sb甲方的時候，階段性的讓他檢驗一下專案成果，防止畫雞成鴨。
多機器問題：
再說說多機器問題，之前機器很少架構簡單的時候，開發就可以幹運維的活，就算加了幾臺伺服器，那也是指令碼將 JAR 包同時釋出到這些機器上，好像也挺簡單，但是會有兩個人同時上線部署被覆蓋的問題，所以大家在上線之前可能會去群裡吆喝一聲，”我要上線了，大家先別上線哈“，可想而知這樣效率也很低下。
公司業務一大，像大公司的動不動就是幾千臺伺服器，就需要專門的運維介入了，一方面是因為開發分工每個人都專注於自己的事情，不會那麼用心進行維護，另一方面是運維的學習成本確實變高了，開發人質量參差不齊，伺服器要是每個人都可以上估計領導每天晚上都要做噩夢。
但是這個時候也不是 DEVOPS，而是 DEV+OPS，這時 Ops 的主要職責就是：硬體維護、網路裝置維護、DBA 、基礎服務維護、資料監控等，運維們擅長寫各種部署，監控指令碼，減少機械的重複工作，開發模式變成了敏捷開發模式。
開發和運維角色的天生對立問題：
加入運維，就要協調人員配合，運維的宿命就是維穩，他們是很討厭變動的；開發的天職確是不斷地推程式碼上線，進行程式碼變動，更替迭代，這兩個工種天生就是對立的。
很多大公司有那種，開發人員想要上線，需要提交各種審批，層層簽字畫押，多少人的上線激情被一句冷冰冰的‘還沒到視窗釋出期’給潑的透心涼。所以，敏捷開發解決了協同開發和多機器部署開發問題，但是沒有解決內部人員的矛盾，留著這個矛盾在公司，開發和運維隨時都可能約‘生死架’。
微服務架構+DEVOPS
❝
wiki定義微服務：
微服務（英語：Microservices）是一種軟體架構風格，它是以專注於單一責任與功能的小型功能區塊 （Small Building Blocks） 為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關 （Language-Independent/Language agnostic）的API集相互通訊。
❞
上面是我摘自wiki對微服務的定義，注意幾個關鍵詞：軟體架構風格，小型功能區塊，模組化，語言無關。
第一，公司發展到BAT這種體量，會招很多人，JAVA，PHP，GO 技術棧都會有，需要協調技術棧；第二，專案到後期往往會變得很大，全部都兌到一個專案裡，最直接的後果就是專案變得很大，上線專案啟動時間變長，一個BUG可能導致整個業務全線崩潰，最終的後果就是專案變得越來越難以維護，加一個改一個東西幾乎搞不動，而且還越來越難重構，牽一髮而動全身。
所以，
拆分解耦是最終的出路，將專案拆成一個個小的服務單獨部署
，以電商專案為例如圖，將整個專案拆分為使用者服務，商品服務，訂單服務，積分服務……每個服務單獨部署，之間透過互相呼叫的方式來互動，而且可以將一些基礎服務例如上傳圖片，傳送簡訊等很多服務都需要的基礎東西，抽象到一個單獨的服務，也就是前些年鼓吹的很厲害的‘中臺服務’。
拆分部署催生出DEVOPS
再看看這種架構下的開發模式DEVOPS，運維需要做的上線工作，主要就是將程式碼部署到對應的機器裡面，微服務有那麼多的服務，每個大點的公司幾百個服務不算多，而且還可能隨時搞一個服務出來，如果還按照原始的指令碼部署方式，可能最後連是哪個指令碼都找不到。而且，如果每個服務上線都需要運維來同意，開發也太卑微了，估計要天天求著運維同意釋出，運維也會煩不勝煩。
那麼為何不能再遠端部署一些機器，專門用來管理程式碼，進行上線工作，由運維事先把上線的規則都給定義好了，開發只要按照他的規則都訪問這臺伺服器進行各自的程式碼合成和釋出，自己上線呢，能用程式碼自動完成的事情就絕不要手動解決，這是每個開發人員都在想的東西。
運維需要做的事情，慢慢的都沉澱到了各個平臺上面
，例如監控，有專門的監控元件和視覺化，基礎服務例如伺服器，CDN，負載均衡等基礎服務可以外包到雲服務廠商，日誌也有專門的日誌工具，鏈路追蹤也有專門的元件和視覺化，還有閘道器等，漸漸的，只要這些都配置好了，開發也可以做運維的部分工作，畢竟開發才是最瞭解程式碼的人，哪裡出了問題看看監控日誌，可以最快速度定位到問題，於是DEVOPS開發模式誕生了，開發也是運維。
devops深度理解
我們知道，一個軟體從零開始到最終交付，大概包括以下幾個階段：產品規劃、開發編碼、構建、QA測試、釋出、部署和維護。
最初大家說到DEVOPS，都是指的‘開發運維一體化’，如下圖：
現在大家說的 DevOps 已經是擴大到“端到端”的概念了，如下圖：
DevOps 的三大支柱之中，即人（People）、流程（Process）和平臺（Platform）。即
DevOps = 人 + 流程 + 平臺
人 + 流程 = 文化
流程 + 平臺 = 工具
平臺 + 人 = 賦能
devops實現相關工具
人自然不用多說，開發前後中涉及到的所有人，流程前期是產品出原型，UI出設計，然後前後端程式碼開發，QA測試，最終部署上線，下圖是部分流程圖：
這裡重點來看看devops平臺搭建工具，工具很多，元件很多，百家爭鳴，這裡我列舉的大多數是我公司用的，也是大部分公司都在用的。
devops平臺搭建工具
專案管理（PM）
：jira。運營可以上去提問題，可以看到各個問題的完整的工作流，待解決未解決等；
程式碼管理
：gitlab。jenkins或者K8S都可以整合gitlab，進行程式碼管理，上線，回滾等；
持續整合CI（Continuous Integration）
：gitlab ci。開發人員提交了新程式碼之後，立刻進行構建、（單元）測試。根據測試結果，我們可以確定新程式碼和原有程式碼能否正確地整合在一起。
持續交付CD（Continuous Delivery）
：gitlab cd。完成單元測試後，可以把程式碼部署到連線資料庫的 Staging 環境中更多的測試。如果程式碼沒有問題，可以繼續手動部署到生產環境中。
映象倉庫
：VMware Harbor，私服nexus。
容器
：Docker。
編排
：K8S。
服務治理
：Consul。
指令碼語言
：Python。
日誌管理
：Cat+Sentry，還有種常用的是ELK。
系統監控
：Prometheus。
負載均衡
：Nginx。
閘道器
：Kong，zuul。
鏈路追蹤
：Zipkin。
產品和UI圖
：藍湖。
公司內部文件
：Confluence。
報警
：推送到工作群。
有了這一套完整的流程工具，整個開發流程涉及到人員都可以無阻礙的進行協調工作了，開發每天到公司，先看看jira，看看線上日誌，出了問題看看監控日誌，運營同學反饋問題不著急的去JIRA，著急的群裡吆喝，產品和UI的圖直接藍湖看，運維關注監控著大盤，改革春風開滿地，網際網路人民真高興~
這一篇有點姍姍來遲的意味，之前一直陷入了迷茫不知道該寫什麼，於是低調的修煉，有了這一篇，有問題歡迎指正，關注我的公眾號’阿甘的碼路‘，即可聯絡到我，很開心你能看到這裡，共同努力，共同進步。
