DevOps 解讀

時間 2019-11-17

標籤 devops 解讀简体版

原文原文鏈接

本文爲轉載文章，非原創

DevOps

DevOps（Development和Operations的組合詞）是一種重視「軟件開發人員（Dev）」和「IT運維技術人員（Ops）」之間溝通合做的文化、運動或慣例。透過自動化「軟件交付」和「架構變動」的流程，來使得構建、測試、發佈軟件可以更加地快捷、頻繁和可靠。 DevOps是一種文化轉變，或者說是一個鼓勵更好地交流和協做（即團隊合做）以便於更快地構建可靠性更高、質量更好的軟件的運動。前端

DevOps 核心價值

文化觀念的改變 + 自動化工具 = 不斷適應快速變化的市場ios

更快速地交付, 響應市場的變化。
更多地關注業務的改進與提高。

爲何須要DevOps

VUCA 概念後端

V=Volatillity（易變性）是變化的本質和動力，也是由變化驅使和催化產生的瀏覽器
U=Uncertainty（不肯定性）缺乏預見性,缺少對意外的預期和對事情的理解和意識安全
C=Complexity（複雜性）企業爲各類力量，各類因素，各類事情所困擾。服務器
A=Ambiguity（模糊性）對現實的模糊，是誤解的根源，各類條件和因果關係的混雜。網絡

產品迭代

咱們無論是作互聯網仍是作遊戲，其實最終都是在作產品，作一款用戶喜歡的產品。喬布斯有句很是著名的名言：「消費者並不知道本身須要什麼，直到咱們拿出本身的產品，他們才發現，這是我想要的東西」。因此喬幫主可以在一開始的時候就設計好了產品最終的效果，而後按照零部件一步步迭代生產前端工程師

現實中的用戶其實一開始並不知道本身想要什麼，可是直到看到了咱們的產品，他才知道本身不想要什麼。即讓現實的產品迭代是如此曲折和反覆架構

用戶：我平時上下班都是走路，天天都要走五千米，好辛苦，有沒有辦法幫我設計個工具，解決下個人痛點。

咱們思考了下，以爲這個不是很難嘛，能夠試下，因而咱們討論 -> 設計 -> 開發 -> 測試 -> 交付給用戶了一個滑板。框架

用戶：這個滑板很差操控，能夠給我加個扶手嗎？

而後咱們按照用戶新的需求，生產了個滑板車。

用戶：滑板車得滑着走，能不能讓我能夠騎着走的。

咱們繼續改進產品，生產了個自行車。

用戶：自行車還得登着走，路程遠了也很累。

咱們又繼續優化，把它變成了電瓶車。

用戶：電瓶車卻是解決了的需求，不過就是不太安全，能再優化下產品嗎？

通過各類努力咱們最後生產出了一輛漂亮的小轎車交付給了用戶，終於讓用戶滿意了。

技術革新

在之前的系統中業務單1、邏輯簡單、用戶量少，項目團隊的規模通常在 10~30人。而如今的系統要面對不一樣用戶的定製化推薦等，互聯網鏈接着人與人、人與物、以及物與物，業務也變得愈來愈複雜，功能愈來愈多，若是整個系統耦合在一塊兒，則一定會牽一髮而動全身，致使系統維護起來至關困難。

所以IT技術架構也隨着系統的複雜化而不斷地變化革新，從早期全部服務的All In One發展到如今的微服務架構、從純手動操做到全自動化流程、從單臺物理機到雲平臺，下圖展現了IT技術革新的變化：

DevOps的指導思想

其實DevOps核心思想就是：「快速交付價值，靈活響應變化」。

高效的協做和溝通；
自動化流程和工具；
快速敏捷的開發；
持續交付和部署；
不斷學習和創新。

總體流程圖

敏捷管理：一支訓練有素的敏捷開發團隊是成功實施DevOps的關鍵。

根據康威定律：軟件團隊開發的產品是對公司組織架構的反映。

因此根據公司狀況調整組織結構是首要條件，它將直接影響到需求、設計和開發階段的效率、以及溝通的成本。

關於團隊的溝通成本的計算公式：溝通成本 = n(n-1)/2，其中n爲人數，因此溝通成本將隨着組織人員的增長而呈指數級增加。

持續交付部署：實現應用程序的自動化構建、部署、測試和發佈。

經過技術工具，把傳統的手工操做轉變爲自動化流程，這不只有利於提升產品開發、運維部署的效率，還將減小人爲因素引發的失誤和事故，提前發現問題並及時地解決問題，這樣也保證了產品的質量。

IT服務管理：可持續的、高可用的IT服務是保障業務正常的關鍵要素，它與業務是一個總體。

IT服務管理（ITSM）直接影響產品運營的整個生命週期，傳統的IT服務管理（像ITIL）在生產中作的很是好了，可是它對於DevOps來講又顯得過於繁瑣，因此有必要爲DevOps建立一個只關注業務持續性的ITMS，它只須要不多的必要資源來爲相應的業務提供服務，ITMS更多地從業務角度考慮了。

注：白話解釋下什麼是IT服務管理（ITSM），它是傳統的「IT管理」轉向爲「IT服務」爲主的一種模式，前者可能更關注具體服務器管理、網絡管理和系統軟件安裝部署等工做；然後者更關注流程的規範化、標準化，明肯定義各個流程的目標和範圍、成本和效益、運營步驟、關鍵成功因素和績效指標、有關人員的責權利，以及各個流程之間的關係等，好比創建線上事故解決流程、服務配置管理流程等；而光有流程還不夠，由於流程主要是IT服務提供方內部使用的，客戶對他們並不感興趣，因此還需將這些流程按需打包成特定的IT服務，而後提供給客戶使用，好比在雲平臺上購買一臺虛擬雲主機同樣。

精益管理：創建一個流水線式的IT服務鏈，打通開發與運維的鴻溝，實現開發運維一體化的敏捷模式。

精益生產主要來源於豐田生產方式 (TPS)的生產哲學，它以下降浪費、提高總體客戶價值而聞名，它主要利用優化自動化流程來提升生產率、下降浪費。因此精益生產的精髓是即時制（JIT）和自動化（Jidoka）。

JIT（Just In time）：JIT用一句話描述就是消耗最少的必要資源，以正確的數量，生產和運送正確的零件。在這種模式下工做，能夠最大程度上下降庫存，防止過早或者過分生產。大多數公司更傾向用庫存來避免潛在的停線風險，而豐田卻反其道而行之。經過減小庫存「逼迫」對生產中產生的問題作及時且有效的反應。固然JIT這一模式對解決問題的能力是至關大的考驗，在能力不足的狀況下，會有至關大的斷線風險。

Jidoka（Build in quality）：自動化，在豐田TPS系統裏，特地給「動」字加上了「人」字旁變成了「働」，換句話說，TPS/精益生產渴望生產的過程控制能像「人」同樣智能，在第一時間就異常狀況下自動關閉。這種自動停機功能能夠防止壞件流入下游，防止機器在錯誤的生產狀態下形成損壞，也可讓人更好的在當前錯誤狀態下進行故障分析。當設備可以作到自動分析故障時，就能夠將監管機器的「人」真正解放出來，作到對人力成本的節省。

精益軟件開發是精益生產和實踐在軟件開發領域的應用。精益管理貫穿於整個DevOps階段，它鼓勵主動發現問題，不斷的優化流程，從而達到持續交付、快速反饋、下降風險和保障質量的目的。

消除浪費
加強學習
儘可能延遲決定
儘快發佈
下放權力
嵌入質量
全局優化

實施DevOps的具體方法

目前大多數IT互聯網公司廣泛的分層結構，它們通常分爲七大部門：產品策劃、設計美術、前端工程師、後端工程師、測試工程師、運維&DBA和市場運營等。各部門之間自然的造成了溝通障礙牆，相互之間主要以郵件和會議的形式溝通，效率低下、需求變動困難、很難快速響應市場變化和持續交付高品質的產品。

創建快速敏捷團隊

Scrum Master 架構

實現自動化的流程

完整DevOps的Pipeline

提交：工程師將代碼在本地測試後，提交到版本控制系統，如 Git代碼倉庫中。
構建：持續整合系統（如Jenkins CI），在檢測到版本控制系統更新時，便自動從Git代碼倉庫里拉取最新的代碼，進行編譯、構建。
單元測試：Jenkins完成編譯構建後，會自動執行指定的單元測試代碼。
部署到測試環境：在完成單元測試後，Jenkins能夠將應用程序部署到與生產環境相近的測試環境中進行測試
預生產環境測試：在預生產測試環境裏，能夠進行一些最後的自動化測試，例如使用Appium自動化測試工具進行測試，以及與實際狀況相似的一些測試可由開發人員或客戶人員手動進行測試。
部署到生產環境：經過全部測試後，即可以使用灰度更新將最新的版本部署到實際生產環境裏。