2021-05-12 14:32:11
DevOps詳解
2020-06-16 17:17:13
最近我閱讀了很多有關DevOps的文章，其中一些非常有趣，然而一些內容也很欠考慮。貌似很多人越來越堅定地在DevOps與chef、puppet或Docker容器的熟練運用方面劃了等號。對此我有不同看法。DevOps的範疇遠遠超過puppet或Docker等工具。
這樣的看法甚至讓我感覺有些氣憤。DevOps在我看來極為重要，過去15年來，我一直在大型電腦構，主要是大型金融機構中從事工程業務。DevOps是一種非常重要的方法論，該方法將解決一些最大型問題的基本原則和實踐恰如其分地融為一體，很好地解決了此類機構的軟體開發專案中一種最令人感覺悲涼的失敗要素：開發者和運維人員之間的混亂之牆。
請不要誤會我的這種觀點，除了某些XP實踐，大部分此類大型電腦構對敏捷開發方法論的運用還有很長的路要走，同時還有很多其他原因會導致軟體開發專案的失敗或延誤。
但在我看來，混亂之牆目前依然是他們所面臨的最令人沮喪、最浪費時間、同時也相當愚蠢的問題。
與其獨自生悶氣，我覺得不如說點更實在的東西，寫一篇盡可能精準的文章，向大家介紹DevOps到底是什麼，能為我們帶來什麼。長話短說，DevOps並不是某一套工具。DevOps是一種方法論，其中包含一系列基本原則和實踐，僅此而已。而所用的工具（或者說“工具鏈”吧，畢竟用於為這些實踐提供支援的工具集有著極高的擴充套件性）只是為了對這樣的實踐提供支援。
最終來說，這些工具本身並不重要。相比兩年前，目前的DevOps工具鏈已經產生了翻天覆地的變化，可想而知，兩年後還會產生更大的差異。不過這並不重要。重要的是能夠合理地理解這些基本原則和實踐。
本文並不準備介紹某些工具鏈，甚至完全不會提到這些工具。網上討論DevOps工具鏈的文章已經太多了。我想在本文中談談最基本的原則和實踐，它們的主要目的，畢竟這些才是對我而言最重要的。
DevOps是一種方法論，歸納總結了面臨獨一無二的機遇和強有力需求的網路巨頭們，結合自身業務本質構思出全新工作方式的過程中所採用的實踐，而他們的業務需求也很直接：以史無前例的節奏對自己的系統進行演進，有時候可能還需要以天為單位對系統或業務進行擴充套件。
雖然DevOps對初創公司來說很明顯是不可或缺的，但我認為那些有著龐大的老式IT部門的大企業才是能從這些基本原則和實踐中獲得最大收益的。本文將試圖解釋得出這個結論的原因和實現方法。
本文的部分內容已發布為Slideshare演示幻燈片，可在這裡瀏覽：http://www.slideshare.net/JrmeKehrli/devops-explained-72091158
目錄
1. 簡介 1.1 管理信條 1.2 一個典型的IT組織 1.3 運維人員測挫敗感 1.4 基礎架構自動化 1.5 DevOps：僅此一次，一顆神奇的銀子彈 2. 基礎架構即程式碼 2.1 概述 2.2 DevOps工具鏈 2.3 收益 3. 持續交付 3.1 從實踐中學習 3.2 自動化 3.3 更頻繁的部署 3.4 持續交付的前提需求 3.5 零停機部署 4. 共同作業 4.1 混亂之牆 4.2 軟體開發流程 4.3 共用工具 4.4 協同工作 5. 結論
1. 簡介
DevOps所關注的不是工具本身，也不是對chef或Docker的掌握程度。DevOps是一種方法論，是一系列可以幫助開發者和運維人員在實現各自目標（Goal）的前提下，向自己的客戶或使用者交付最大化價值及最高品質成果的基本原則和實踐。
開發者和運維人員之間最大的問題在於：雖然都是企業中大型IT部門不可或缺的，但他們有著截然不同的目的（Objective）。
開發者和運維人員之間目的上的差異就叫做混亂之牆。下文會介紹這個概念的準確定義，以及為什麼我認為這種狀況很嚴峻並且很糟糕。
DevOps是一種融合了一系列基本原則和實踐的方法論（並從這些實踐中派生出了各種工具），意在幫助這些人員向著一個統一的共同目的努力：盡可能為公司提供更多價值。
令人驚奇的是，這個問題竟然有一個非常簡單的“銀子彈”：讓生產端變得敏捷起來！
而這恰恰正是DevOps所要達成的唯一目標！
但在進一步討論這一點之前，首先需要談談其他幾件事。
1.1 管理信條
IT管理這場戰爭的原動力到底是什麼？換句話說，在軟體開發專案中，管理工作首要的，以及最重要的目的是什麼？
有什麼想法嗎？
我來提供一個線索吧：在建立一家初創公司時，最重要的事情是什麼？
當然是要加快上市時間（TTM）！
上市時間（即TTM）是指一件產品從最初的構思到最終可供使用者使用或購買這一過程所需要的時間。對於產品很快會過時的行業，TTM是一個非常重要的概念。
在軟體工程方面，所採用的方法、業務，以及具體技術幾乎每年都會變化，因而TTM就成了一個非常重要的KPI（關鍵績效指標）。
TTM通常也會被叫做前置時間（Lead Time）。
第一個問題在於，（很多人認為）在開發過程中TTM和產品品質是兩個對立的屬性。在下文可以看到，改善品質（進而提高穩定性）是運維人員的目的，而開發者的目的在於降低前置時間（進而提高TTM）。
請容我來解釋一下。
IT組織或部門通常會通過兩個關鍵的KPI進行評估：軟體本身的品質，因而需要盡可能減少缺陷的數量；此外還有TTM，因而需要將業務構想（通常由業務使用者提供）變為最終成果，並以盡可能快的速度提供給使用者或客戶。
這裡的問題在於，大部分情況下這兩個截然不同的目的是由兩個不同團隊提供支援的：負責構建軟體的開發者，以及負責執行軟體的運維人員。
1.2 一個典型的IT組織
在組織內部負責管理重要IT部門的典型IT組織通常看起來是這樣的：
主要由於歷史的原因（大部分運維人員來自硬體和電信業務領域），運維人員和開發者分屬不同的組織結構分支。開發者屬於研發部門，而運維人員大部分時候屬於基礎架構部門（或專門的運維部門）。
別忘了，他們有著不同的目的：
此外作為旁注，這兩個團隊有時候會使用不同的預算來運營。開發團隊使用構建（Build）預算，運維團隊使用運營（Run）預算。不同的預算，對控制權越來越高的需求，以及企業IT成本的縮水，這些因素結合在一起會進一步放大兩個團隊各自目的的對立性。
（依本人愚見，時至今日，隨著人與人之間無時無刻隨時隨地進行的互動，以及由不同目的推動著企業和社會進行數位化轉型，IT預算方面古老的“規劃/構建/執行”框架已經不那麼合理了，不過這又是另一回事了。）
1.3 運維人員測挫敗感
接下來看看運維人員，一起看看典型的運維團隊把大部分時間都花在哪裡了：
生產團隊有將近一半（47%）的時間花在了與部署有關的工作中：
- 執行實際的部署工作，或
- 修復與部署工作有關的問題
這樣的KPI其實相當瘋狂，但實際上我們早就應該採納。實際上早在40年前，電腦科學的“原始時代”就已湧現出運維團隊，當時計算機主要運用在工業界，運維人員需要手工執行大量命令來執行自己的任務。為了履行職責，他們已經習慣于按照清單執行各種各樣的命令或手工流程。
突然有一天他們終於意識到自己“總在做著相同的事情”，然而長達四十多年的工作過程中卻幾乎沒人考慮過變革。
考慮到這一點你會發現，實在是太瘋狂了。平均來說，運維人員將近一半的時間都在處理與部署有關的任務！
為了改變這種狀況，必須考慮到兩個最關鍵的需求：
- 通過自動化部署將目前這種手工任務所需的時間減少31%。
- 通過產業化措施（類似於通過XP和敏捷實現的軟體開發產業化）將需要處理的與這些部署有關的問題減少16%。
1.4 基礎架構自動化
在這方面也有一個相當富有啟發性的統計結果：
以手工操作的數量所表示的成功部署概率。
這些統計告訴我們：
- 只需手工執行5條命令的情況下，成功部署的概率就已跌至86%。
- 如需手工執行55條命令，成功部署的概率將跌至22%。
- 如需手工執行100條命令，成功部署的概率將趨近於0（僅2%）！
成功部署意味著軟體能夠按照預期在生產環境中執行。未能成功部署意味著有東西出錯，可能需要進行必要的分析才能了解部署過程中哪裡出錯，是否需要應用某種修補程式，或需要修改某些設定。
因此讓這一切實現自動化並不惜一切代價避免手工操作似乎是個好主意，對吧？
那麼行業裡這方面的現狀是怎樣的：
（來源：IT Ops & DevOps Productivity Report 2013 - Rebellabs ）
（說實話，這個統計資訊比較老了，是2013年的結果，相信現在的結果會有所不同）
然而這也可以讓我們明確的知道，在基礎架構自動化方面我們還有多遠的路要走，並且DevOps的基本原則和實踐依然是那麼的重要。
網路巨頭們當然會通過新的方法和實踐及時滿足自己的需求，他們早已開始構建自己的工程業務，而正是他們所確立的實踐逐漸衍生出當今我們所熟悉的DevOps。
看看這些網路巨頭們在這方面目前所處的位置吧，舉幾個例子：
- Facebook有數千名開發和運維人員，成千上萬台伺服器。平均來說一位運維人員負責500台伺服器（還認為自??化是可選的嗎？）他們每天部署兩次（環式部署，Deployment ring的概念）。
- Flickr每天部署10次。
- Netflix明確針對失敗進行各種設計！他們的軟體按照設計從最底層即可容忍系統失敗，他們會在生產環境中進行全面的測試：每天通過隨機關閉虛擬機器的方式在生產環境中執行65000次失敗測試…… 並確保這種情況下一切依然可以正常工作。
他們這種做法秘密何在？
更多詳情見請繼續閱讀下一頁的精彩內容： http://www.linuxidc.com/Linux/2017-04/143080p2.htm
相關文章