雲計算時代，你所不了解的 DevOps
2019-11-21 13:56
狂師
閱讀(773)
評論(2)
編輯
收藏
舉報
在本文中，我們讨論如何快速地從更高的層面了解DevOps，介紹準備改變文化的最佳實踐。我們将讨論DevOps的目标以及從組織管理層得到支援的方法，為DevOps的概念打下基礎。我們将試着從根本上介紹使應用程式生命期管理簡單、高效的DevOps實踐。
DevOps不是一種架構、工具或者技術，了解這一點非常重要。它更多的是與組織的文化有關。DevOps還是人們在組織中使用預先定義的過程、利用自動化工具，使日常工作更加高效、手工工作更少的一種方法。
為了了解DevOps的重要性，我們在本文中将包含如下主題：
DevOps的必要性；
如何發展DevOps文化；
PPT（人、過程和技術）的重要性；
為什麼DevOps不全和工具有關；
DevOps評估問題。
1.1 DevOps的必要性
每個偉大的夢想都源于夢想家。永遠銘記，你擁有的力量、耐心和熱情，可以令你摘星攬月、改變世界。
改變是生命的法則，也适用于組織機構。如果任何組織或者個人隻盯着過去或者現有的模式、文化或實踐，他們就肯定會錯失未來的最佳實踐。在動态的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 小結
在本文中，我們設定了本書要實作的許多目标。我們介紹了持續內建、雲環境中的資源配給、配置管理、持續傳遞、持續部署和持續監控。
設計目标是将願景清晰化的第一步。
我們已經看到，雲計算是如何改變過去對創新的認知方法，它現在已經變成了切實可行的方案。我們還簡要介紹了DevOps的必要性和各種不同的DevOps實踐。人、過程和技術在改變組織現有文化的過程中也很重要。我們試圖指出它們的重要性。工具很重要，但不能止步于此；可以利用任何工具集，改變文化并不需要特定的工具集。我們也簡要地讨論了DevOps的評估架構，它将幫助你沿着文化變革的道路前進。
如果您覺得不錯，請别忘了轉發、分享、點贊讓更多的人去學習， 您的舉手之勞，就是對小編最好的支援，非常感謝！
- 分類 移動網際網路
- 标簽 DevOps
