[轉載]你所不瞭解的DevOps

DevOps開發運維訓練營

一旦創建了創新的文化，即便那些並不是科學家或者工程師的人——詩人、演員、記者——也能以團體的形式，接受科學文化的意義。他們信奉創新文化的概念。他們以促進這種文化的方式投票。他們不會反對科學，也不會反對技術。

——Neil deGrasse Tyson

在本文中，咱們討論如何快速地從更高的層面理解DevOps，介紹準備改變文化的最佳實踐。咱們將討論DevOps的目標以及從組織管理層獲得支持的方法，爲DevOps的概念打下基礎。咱們將試着從根本上介紹使應用程序生命期管理簡單、高效的DevOps實踐。

DevOps不是一種框架、工具或者技術，理解這一點很是重要。它更多的是與組織的文化有關。DevOps仍是人們在組織中使用預先定義的過程、利用自動化工具，使平常工做更加高效、手工工做更少的一種方法。

爲了理解DevOps的重要性，咱們在本文中將包含以下主題：

DevOps的必要性；

如何發展DevOps文化；

PPT（人、過程和技術）的重要性；

爲何DevOps不全和工具備關；

DevOps評估問題。

1.1　DevOps的必要性

Harriet Tubman有一段名言，能夠在http://harriettubmanbiography.com上找到：

每一個偉大的夢想都源於夢想家。永遠銘記，你擁有的力量、耐心和熱情，能夠令你摘星攬月、改變世界。

改變是生命的法則，也適用於組織機構。若是任何組織或者我的只盯着過去或者現有的模式、文化或實踐，他們就確定會錯失將來的最佳實踐。在動態的IT世界中，咱們必須遇上技術革新的步伐。

咱們能夠參考喬治•蕭伯納的名言：

不改變就不可能進步，沒法改變本身的想法，就不能改變任何東西。

如今，咱們關注的是應用程序生命期管理方法的改變。重要的是，咱們是否真的須要這種改變？咱們是否真的須要經歷改變的痛苦？

答案是確定的。

人們可能會說，這種業務或者文化的改變不能是強制性的。

贊成。

讓咱們在圖1-1的幫助下，理解現代世界中組織在應用程序生命期管理中面對的痛點。

 

圖1-1

考慮到業務中不斷變化的模式和競爭環境，改善應用程序生命期管理是當務之急。

在現代，有什麼因素可以幫助咱們改善應用程序生命期管理？

是的，雲計算改變了遊戲規則，爲許多開創性的解決方案和創新打開了大門。讓咱們來理解雲計算的真正意義，以及DevOps和自動化等術語在企業中所起的重要做用。

1.1.1　雲計算概述

從計算革命來看，雲計算是下一個合乎邏輯的步驟。從傳統數據中心和虛擬化，到混合環境、私有云、公共雲和混合雲服務，雲計算是向雲消費者按需提供多租戶或者專用計算資源（如計算、存儲和網絡）的計算類型。雲計算有多種不一樣風格，包括不一樣的雲部署模型和雲服務模型。最重要的是其訂價模型——現收現付。

雲部署模型是雲資源部署的方式。

1）私有云：私有云由防火牆後專門用於特定組織的場內雲資源組成。

2）公共雲：公共雲由可用於全部組織及我的的雲資源組成。

3）混合雲：混合雲由可用於一組有相似興趣或者相似需求類型的組織的雲資源組成。

4）社區雲：社區雲由組合兩種或者更多部署模型的雲資源組成。

雲服務模型描述了向各種客戶（我的、小型組織、大型企業）提供雲資源的方式。

雲服務模型包括：雲客戶或者最終用戶能夠訪問和控制虛擬機的純基礎設施——基礎設施即服務（IaaS）；提供運行時服務，雲服務提供者提供和管理運行應用所需的全部軟件安裝及配置的平臺——平臺即服務（PaaS）；雲服務提供者提供整個應用程序，負責基礎設施和平臺的軟件即服務（SaaS）。

近幾年涌現了許多服務模型，可是IaaS、PaaS和SaaS是基於美國國家標準與技術學會（NIST）的定義，如圖1-2所示。

雲計算有一些重要的特性，如多租戶，相似於電力或者煤氣的現收現付模式，提供更高計算、存儲和網絡資源利用率的按需自助服務和資源池化，用於根據須要自動擴展和收縮資源的快速伸縮，以及用於計費的可度量服務。

多年以來，不一樣雲部署模型的使用根據用例而改變。最初，公共雲用於非關鍵應用，而私有云用於關注安全性的關鍵應用。混合雲和公共雲的使用隨着時間的推移以及對雲服務提供商所提供服務的經驗及信心而發展。一樣地，不一樣雲服務模型的使用也根據用例和靈活性而有所不一樣。IaaS在早期最受歡迎，可是PaaS則憑藉其成熟度和自動伸縮、支持多語言和支持端到端應用程序生命期管理工具的易用性然後來居上。

 

 

圖1-2

1.1.2　DevOps概述

DevOps與發展開發和IT運營團隊之間的協做，以比現有方式更高效地管理應用程序生命期的組織文化、過程和技術有關（見圖1-3）。咱們在工做中每每傾向於根據模式，從相似的問題或者挑戰中找出可重用解決方案。

 

 

圖1-3

多年以後，成功與失敗的試驗、最佳實踐、自動化腳本、配置管理工具和方法論已經成爲DevOps文化中不可分割的一部分。

DevOps有助於定義設計方法、開發方法、測試方法、安裝方法、環境管理方法、配置管理方法、應用部署方法、反饋收集方法、代碼改善方法和創新方法。

下面是開展DevOps實踐的一些明顯好處。

DevOps是一系列創新，以高效的方法將開發與運營團隊整合在一塊兒，這些方法包括持續構建集成、持續測試、雲資源配給、持續交付、持續部署、持續監控、持續反饋、持續改善和持續創新，按照敏捷方法論的要求，更快地交付應用程序。文化的發展不是一晚上之間就能完成的，須要很長的時間。可是，對於DevOps到底是什麼仍存在概念上的混淆，人們每每將單獨的持續集成或者配置管理實踐當成DevOps實踐，這就像盲人摸象，每一個人都將觸摸到的一部分當成大象的總體，如圖1-4所示。

 

 

圖1-4

可是，DevOps涉及的不只是開發和運營團隊。在現有文化的發展中，涉及測試團隊、業務分析人員、構建工程師、自動化團隊、雲團隊和許多其餘利益相關方。

DevOps和組織文化沒有太大區別，它們有共同的價值和行爲特徵，須要調整心態和過程，與新的技術和工具相匹配。

開發和運營團隊面臨的挑戰

正由於現實中的一些挑戰，使DevOps呈向上的趨勢，併成爲全部信息技術相關討論中的熱門話題。

開發團隊面臨的挑戰

開發人員渴望採用新技術和新方法解決問題。可是，他們面對許多挑戰。

競爭激烈的市場形成了按時交付的壓力。

他們不得不負責生產就緒代碼管理和新功能的實現。

發行週期每每很長，所以，開發團隊必須在應用部署最終進行以前作出假設。在這種狀況下，修復在模擬環境或者生產環境中部署期間發生的問題須要花費更多的時間。

運營團隊面臨的挑戰

運營團隊對資源變化、新技術或新方法的使用老是當心翼翼，由於他們須要穩定性。可是，他們也面對許多挑戰。

資源爭用：難以處理日益增加的資源需求。

從新設計或者調整：這是在生產環境中運行應用程序的須要。

診斷和改正：他們應該在應用程序部署與外界隔絕的狀況下診斷和改正問題。

IT團隊面臨的挑戰

IT團隊向各個團隊提供運營所需的資源。

基礎設施配給：提供基礎設施和具有合適安裝軟件包的運行時環境。

配置管理：根據工具或者技術的可供更新，升級現有基礎設施或者軟件包。

考慮到開發和運營團隊面對的全部挑戰，咱們應該如何改善現有過程、利用自動化工具提升過程的效率、改變人們的思惟方式？在下一小節，咱們將瞭解如何在組織中發展DevOps文化，改善效率和效能。

1.2　如何發展DevOps文化

低效的估算、進入市場的時間過長以及其餘問題致使了瀑布模型的改變，產生了敏捷模型。文化的演變不是有固定時限或者一晚上之間能夠完成的過程，它多是一個步進式的分階段過程，能夠在不依賴其餘階段的狀況下完成。

咱們能夠在不使用雲配給的狀況下實現持續集成，能夠在不實現配置管理的狀況下實現雲配給。咱們也能夠在沒有任何DevOps實踐的狀況下實現持續測試。圖1-5所示是實現DevOps實踐的不一樣階段。

 

圖1-5

1.2.1　敏捷開發

敏捷開發或基於敏捷的方法論對應用程序構建頗有用，這種方法將權力下放，鼓勵互動，重視可工做軟件、客戶協做——利用反饋改善後續步驟——並以高效的方式響應變化。

敏捷開發最吸引人的好處之一是在短期內（敏捷術語中叫做「衝刺」）持續交付。這樣，應用開發的敏捷方法、技術上的改進、破壞性創新和方法在開發和運營團隊之間形成了一條鴻溝。

1.2.2　DevOps

DevOps試圖經過發展開發和運營團隊之間的夥伴關係，彌合這條鴻溝。DevOps活動強調軟件開發人員和IT運營部門之間的溝通、協做和整合。

DevOps促進協做，經過自動化和編排改善過程爲協做提供方便。換言之，DevOps本質上將敏捷活動的持續開發目標擴展到持續集成和發行。DevOps是利用雲解決方案的優點，將敏捷實踐與過程組合起來。敏捷開發和測試方法幫助咱們實現應用程序的持續集成、開發、構建、部署、測試和發行目標。

構建自動化

自動化構建運用Gradle、Apache Ant和Apache Maven等構建自動化工具，幫助咱們建立應用程序構建。

自動化構建過程包括將源代碼編譯成類文件或者二進制文件、提供第三方庫文件引用、提供配置文件路徑、將類文件或者二進制文件打包成包文件、執行自動化測試用例、在本地或遠程機器上部署包文件和減小包文件建立中的手工做業等活動。

持續集成

簡言之，持續集成（CI）是一種軟件工程實踐，在這種方法中，開發人員的每次簽入（Check-in）都使用以下任一種方法驗證。

「拉」機制：在計劃的時間點執行自動化構建。

「推」機制：在存儲庫中保存更改時執行自動化構建。

這一步以後，對源代碼庫中最新的更改執行一次單元測試。持續集成是一種流行的DevOps方法，要求開發人員將代碼天天數次整合爲Git和SVN等代碼庫，以驗證代碼的完整性。

而後，自動化構建驗證每次簽入，使團隊能夠及早發現問題。

CI（甚至CD）是公司同步DevOps存檔的基線。在組織中若是沒有很好地實施CI和CD，就沒法實施DevOps。

雲配給

在本章前面，咱們已經介紹了雲計算的基本知識。雲配給爲架構即代碼（Infrastructure as Code ，IAC）敞開了大門，使整個過程變得極其高效，由於咱們在很大的程度上將涉及人工干預的過程自動化了。

現收現付的計費模式使所需的資源更加容易承受，不只對大型組織，對中小規模組織和我的也是如此。

雲配給有助於改進和創新，由於之前的資源約束從成本和維護的角度阻礙了組織的進一步發展。一旦咱們在基礎設施資源上擁有了敏捷性，就能夠考慮自動化運行應用程序所需軟件包的安裝和配置。

配置管理

配置管理（CM）系統中的更改，更具體地說，就是服務器運行時環境。咱們可使用市場上的許多工具實現配置管理。流行工具包括Chef、Puppet、Ansible、Salt等。

讓咱們來考慮一個須要管理多個同類配置服務器的例子。

例如，咱們須要在每一個服務器上安裝Tomcat。若是須要改變全部服務器上的端口、更新某些軟件包或者爲某些用戶提供權限，該怎麼辦？這種情形下的任何修改都是人工的，也就是一種容易出錯的過程。由於全部服務器都使用相同的配置，能夠利用自動化手段。

持續交付

持續交付和持續部署是能夠互換使用的術語。可是，二者之間仍是有一些小的差異。

持續交付是在任何環境中以自動化方式部署一個應用程序並提供持續反饋以改善其質量的過程。持續交付和持續部署中的自動化方法不會改變。可是批准過程和其餘小細節可能改變。

持續測試和部署

持續測試是端到端應用程序生命期管理過程當中很重要的階段，包括功能測試、性能測試、安全性測試等。

Selenium、Appium、Apache JMeter和許多其餘工具均可以用於相同的目的。另外一方面，持續部署是部署應用程序，包含對生產環境的最新更改。

持續監控

持續監控是端到端交付流水線的骨幹，開源監控工具就像冰淇淋勺的頭部。

如圖1-6所示，在幾乎每一個階段都設置監控，得到全部過程的透明度是十分可取的作法。這還可以幫助咱們快速檢修故障。監控應該在深思熟慮的計劃下執行。

圖1-6描述了持續方法的所有過程。

咱們必須理解，這是一種分階段的方法，不必定要一次性完成各個階段的自動化工做。每次選擇一種DevOps實踐、實施並理解其好處，而後再實施另外一個，這是更有效的作法。

這樣，咱們能夠安全地評估組織文化改變帶來的改善，消除應用程序生命期管理中的手工勞動。

 

圖1-6

1.3　PPT——人、過程和技術——的重要性

PPT在任何組織中都是一個重要的詞。等等！咱們說的可不是PowerPoint演示。這裏，咱們關注的是人、過程和工具/技術。讓咱們來了解一下，爲何這些因素在改變任何組織的文化時很重要。

1.3.1　人

引用Jack Cranfield的名言：

無論周圍發生什麼，成功的人老是積極地看待人生。他們着眼於過去的成功而不是過去的失敗，聚焦於使他們更接近目標的下一步行動，而不是生活中令他們分心的其餘事務。

爲何說人很重要？這是一個有趣的問題。若是咱們想要用一句話來回答，那就是：由於咱們試圖改變文化。

那麼又如何？

人是任何文化的重要組成部分，只有人可以驅動文化的改變，或者改變本身以適應新過程、定義新過程、學習新工具或者技術。

讓咱們用變革方程式來理解。

按照維基百科的說法，David Gleicher在20世紀60年代初創造了變革方程式。Kathie Dannemiller在1980年對方程式進行了完善。這個方程式提供了一個模型，以評估影響組織變革倡議成功機率的相對優點。

Gleicher（原始）版本爲：C= (ABD) >X，其中C=變革，A=對現狀的不滿意度，B=但願獲得的明確狀態，D=達到理想狀態的實際步驟，X=變革的代價。

Dannemiller的版本：D×V×F>R，其中D、V和F必須存在，組織變革才能進行：D=對現狀的不滿意度，V=對可能目標的願景，F=可用於實現願景的前幾個具體步驟。若是這3個因素的乘積大於R（阻力），那麼變革就是可能成功的。

本質上說，這個公式表示，必須有對現有事務或者過程的不滿，對新趨勢、技術和市場方案創新的願景，以及實現願景所採起的具體步驟。

關於變革方程式的更多細節，能夠訪問維基百科網頁：https://en.wikipedia.org/wiki/Formula_for_change#cite_note-myth-1

做爲經驗分享，我認爲培訓人員適應新的文化很是重要，這是一場須要耐心的博弈。咱們不能在一晚上之間改變人們的思惟方式，在改變文化以前首先須要理解。

在行業中每每能看到，文化的改變從DevOps知識或者DevOps工程師開始，可是在理想情況下，這些不該該是「舶來品」，而應該逐步改變現有環境，並在其中訓練人員，以控制阻力。咱們不須要一個專門的DevOps團隊，須要的是開發人員、測試團隊、自動化實現人員和雲或基礎設施團隊之間的更多溝通和協做。

讓全部人都理解彼此的痛點是必不可少的步驟。在我工做過的機構裏，咱們習慣於有一個卓越中心（COE）來管理新技術、創新或者文化。做爲自動化實現者和DevOps團隊的一員，咱們只應該擔當促進者的角色，而不是與世隔絕的「豎井」中的一員。

1.3.2　過程

Tom Peters曾有一段名言：

幾乎全部質量改進都來源於對設計、製造…佈局、過程和規程的簡化。

在處理文化的發展時，質量極其重要。咱們須要過程和策略，以正確的方式完成工做，並標準化各個項目，使操做的順序、約束、規則等都有完備的定義，以便對成功與否進行度量。

咱們須要爲如下任務創建過程。

敏捷規劃。

資源規劃和配給。

配置管理。

對雲資源和自動化中使用的其餘工具的基於角色訪問控制。

編程語言的靜態代碼分析規則。

測試方法論與工具。

發行管理。

這些過程對於度量DevOps文化發展的成功也很重要。

1.3.3　技術

史蒂夫•喬布斯有以下的名言：

技術並不重要，重要的是你對人們有信心，他們都很好、很聰明，若是給他們工具，他們就能作了不得的事。

科技幫助人和組織產生創意、完成創新，同時改變文化。沒有科技，在平常例行的自動化操做中，就很難實現速度和效率。雲計算、配置管理工具和構建流水線在資源配給、安裝運行時環境和編排中頗有用處。它們從根本上提升了應用程序生命期管理中不一樣方面工做的速度。

1.4　爲何說DevOps不全和工具備關

是的，工具什麼都不是，在任何組織的文化變革中，它們都不是重要的因素。緣由很簡單。無論咱們使用哪種技術，都必須實施持續集成、雲配給、配置管理、持續交付、持續部署、持續監控等。

按照類別，可使用不一樣的工具集，可是全部工具執行的都是相似的操做。工具執行某個操做的方式可能不一樣，但結果是相同的。表1-1所示是按照分類列出的一些工具。

 

 

表1-1

讓咱們來看看在不一樣運營工做的不一樣階段使用的不一樣工具。這可能根據不一樣組織中的環境數量或者DevOps實踐數量而變化，如圖1-7所示。

 

圖1-7

若是咱們須要根據不一樣的DevOps最佳實踐分類工具，能夠將其分類爲開源和商業。表1-2所示爲一些例子。

 

 

表1-2

1.5　DevOps評估問題

DevOps是一種文化，咱們對此已經很瞭解。可是，在實施自動化、制定過程和發展文化以前，咱們必須理解組織文化的現狀，以及是否有必要引入新過程或者自動化工具。

咱們必須很是清楚，咱們須要的是使現有文化變得更加高效，而不是輸入文化。在本書的篇幅中可能很難容納一整個評估框架，可是咱們將盡力提供一些問題和提示，並以此爲基礎，建立一個評估框架就會更容易。

建立須要提出的問題類別，並根據具體應用得出答案。

下面是幾個問題的例子。

1．你是否遵循敏捷原則？

2．你是否使用源代碼庫？

3．你是否使用靜態代碼分析工具？

4．你是否使用構建自動化工具？

5．你使用場內基礎設施仍是基於雲的基礎設施？

6．你使用配置管理工具、安裝應用程序軟件包的腳本仍是運行時環境？

7．你是否使用自動化腳本在生產和非生產環境中部署應用程序？

8．你是否使用應用程序生命期管理的編排工具或者腳本？

9．你是否使用功能測試、負載測試、安全性測試和移動測試的自動化工具?

10．你是否使用應用程序和基礎設施監控工具？

一旦問題就緒，就準備答案，並根據上述問題的每一個答案肯定等級。

保證框架的靈活性，即便咱們改變任何類別中的一個問題，也可以自動地管理。

評出等級以後，在框架中引入不一樣的條件和智能，捕捉答案並計算整體等級。

建立各個分類的最終等級，根據最終等級建立不一樣類型的圖表，使其更容易理解。在這裏，須要注意的是，組織在應用程序生命期管理各領域中的專業能力。這將爲評估框架提供一個新的維度，以增長智能，使其更爲高效。

1.6　小結

在本文中，咱們設定了本書要實現的許多目標。咱們介紹了持續集成、雲環境中的資源配給、配置管理、持續交付、持續部署和持續監控。

設計目標是將願景清晰化的第一步。

——Tony Robbins

咱們已經看到，雲計算是如何改變過去對創新的認知方法，它如今已經變成了切實可行的方案。咱們還簡要介紹了DevOps的必要性和各類不一樣的DevOps實踐。人、過程和技術在改變組織現有文化的過程當中也很重要。咱們試圖指出它們的重要性。工具很重要，但不能止步於此；能夠利用任何工具集，改變文化並不須要特定的工具集。咱們也簡要地討論了DevOps的評估框架，它將幫助你沿着文化變革的道路前進。

信念，就是在你尚未看到整個樓梯的時候走出第一步。

——馬丁•路德•金

在下一章中，咱們將邁出本次旅程的第一步——持續集成。咱們將使用Jenkins和Microsoft Visual Studio Team Services實施持續集成，驗證如何用不一樣的工具實施CI，而又無須面臨重大的挑戰。

本文僅用於學習和交流目的，不表明異步社區觀點。非商業轉載請註明做譯者、出處，並保留本文的原始連接。

本文摘自：《DevOps開發運維訓練營》

 

 

簡明實用的DevOps參考圖書 

輕鬆部署DevOps的自學指南 

本書按照「天天1章，總計8天」的訓練營模式提供了一些實用的學習模塊，你須要完成天天的所學任務，並以此來培養DevOps文化。 

第1天以DevOps基礎概念爲主。第2天關注的是持續集成。第3天的重點是Docker容器以及建立一個Tomcat容器。第4天則是在AWS和Microsoft Azure中建立和配置用來部署應用程序的環境，其中會用到基礎設施即服務（IaaS）以及開源的配置管理工具Chef。第5天是持續交付，其重點是應用程序的自動部署，並使用VSTS配置持續交付。第6天則是學習自動化測試的概念。第7天是使用各類方法來實現應用程序生命期管理的自動化，其中還會涉及如何在Jenkins和VSTS中建立流水線，這樣當成功實現持續集成以後，能當即開啓持續交付並部署應用程序。第8天關注的是安全和監控問題。 

做者簡介 

Mitesh Soni是一位熱心的學習者，在IT 行業已有10 年的經驗。他擁有SCJP、SCWCD、VCP、IBM Urbancode 認證，是IBM Bluemix 認證專家。他熱愛DevOps 和雲計算，對Java 編程也有興趣，以爲設計模式十分迷人。他相信「一圖勝千言」。 

延伸推薦

做者：人郵異步社區 連接：https://www.jianshu.com/p/47764f50d8d9 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。