云計(jì)算時(shí)代，你所不了解的DevOps

在本文中，我們討論如何快速地從更高的層面理解DevOps，介紹準(zhǔn)備改變文化的實(shí)踐。我們將討論DevOps的目標(biāo)以及從組織管理層得到支持的方法，為DevOps的概念打下基礎(chǔ)。我們將試著從根本上介紹使應(yīng)用程序生命期管理簡(jiǎn)單、高效的DevOps實(shí)踐。

DevOps不是一種框架、工具或者技術(shù)，理解這一點(diǎn)非常重要。它更多的是與組織的文化有關(guān)。DevOps還是人們?cè)诮M織中使用預(yù)先定義的過(guò)程、利用自動(dòng)化工具，使日常工作更加高效、手工工作更少的一種方法。

為了理解DevOps的重要性，我們?cè)诒疚闹袑缦轮黝}：

DevOps的必要性;

如何發(fā)展DevOps文化;

PPT(人、過(guò)程和技術(shù))的重要性;

為什么DevOps不全和工具有關(guān);

DevOps評(píng)估問(wèn)題。

1.1　DevOps的必要性

每個(gè)偉大的夢(mèng)想都源于夢(mèng)想家。永遠(yuǎn)銘記，你擁有的力量、耐心和熱情，可以令你摘星攬?jiān)?、改變世界?/p>

改變是生命的法則，也適用于組織機(jī)構(gòu)。如果任何組織或者個(gè)人只盯著過(guò)去或者現(xiàn)有的模式、文化或?qū)嵺`，他們就肯定會(huì)錯(cuò)失未來(lái)的好實(shí)踐。在動(dòng)態(tài)的IT世界中，我們必須趕上技術(shù)革新的步伐。

我們可以參考喬治•蕭伯納的名言：

不改變就不可能進(jìn)步，無(wú)法改變自己的想法，就不能改變?nèi)魏螙|西。

現(xiàn)在，我們關(guān)注的是應(yīng)用程序生命期管理方法的改變。重要的是，我們是否真的需要這種改變?我們是否真的需要經(jīng)歷改變的痛苦?

答案是肯定的。

人們可能會(huì)說(shuō)，這種業(yè)務(wù)或者文化的改變不能是強(qiáng)制性的。

同意。

讓我們?cè)趫D1-1的幫助下，理解現(xiàn)代世界中組織在應(yīng)用程序生命期管理中面對(duì)的痛點(diǎn)。

圖1-1

考慮到業(yè)務(wù)中不斷變化的模式和競(jìng)爭(zhēng)環(huán)境，改善應(yīng)用程序生命期管理是當(dāng)務(wù)之急。

在現(xiàn)代，有什么因素能夠幫助我們改善應(yīng)用程序生命期管理?

是的，云計(jì)算改變了游戲規(guī)則，為許多開(kāi)創(chuàng)性的解決方案和創(chuàng)新打開(kāi)了大門(mén)。讓我們來(lái)理解云計(jì)算的真正意義，以及DevOps和自動(dòng)化等術(shù)語(yǔ)在企業(yè)中所起的重要作用。

1.1.1　云計(jì)算概述

從計(jì)算革命來(lái)看，云計(jì)算是下一個(gè)合乎邏輯的步驟。從傳統(tǒng)數(shù)據(jù)中心和虛擬化，到混合環(huán)境、私有云、公共云和混合云服務(wù)，云計(jì)算是向云消費(fèi)者按需提供多租戶(hù)或者專(zhuān)用計(jì)算資源(如計(jì)算、存儲(chǔ)和網(wǎng)絡(luò))的計(jì)算類(lèi)型。云計(jì)算有多種不同風(fēng)格，包括不同的云部署模型和云服務(wù)模型。最重要的是其定價(jià)模型——現(xiàn)收現(xiàn)付。

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

1)私有云：私有云由防火墻后專(zhuān)門(mén)用于特定組織的場(chǎng)內(nèi)云資源組成。

2)公共云：公共云由可用于所有組織及個(gè)人的云資源組成。

3)混合云：混合云由可用于一組有類(lèi)似興趣或者類(lèi)似需求類(lèi)型的組織的云資源組成。

4)社區(qū)云：社區(qū)云由組合兩種或者更多部署模型的云資源組成。

云服務(wù)模型描述了向各類(lèi)客戶(hù)(個(gè)人、小型組織、大型企業(yè))提供云資源的方式。

云服務(wù)模型包括：云客戶(hù)或者最終用戶(hù)可以訪問(wèn)和控制虛擬機(jī)的純基礎(chǔ)設(shè)施——基礎(chǔ)設(shè)施即服務(wù)(IaaS);提供運(yùn)行時(shí)服務(wù)，云服務(wù)提供者提供和管理運(yùn)行應(yīng)用所需的所有軟件安裝及配置的平臺(tái)——平臺(tái)即服務(wù)(PaaS);云服務(wù)提供者提供整個(gè)應(yīng)用程序，負(fù)責(zé)基礎(chǔ)設(shè)施和平臺(tái)的軟件即服務(wù)(SaaS)。

近幾年涌現(xiàn)了許多服務(wù)模型，但是IaaS、PaaS和SaaS是基于美國(guó)國(guó)家標(biāo)準(zhǔn)與技術(shù)學(xué)會(huì)(NIST)的定義，如圖1-2所示。

云計(jì)算有一些重要的特性，如多租戶(hù)，類(lèi)似于電力或者煤氣的現(xiàn)收現(xiàn)付模式，提供更高計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源利用率的按需自助服務(wù)和資源池化，用于根據(jù)需要自動(dòng)擴(kuò)展和收縮資源的快速伸縮，以及用于計(jì)費(fèi)的可度量服務(wù)。

多年以來(lái)，不同云部署模型的使用根據(jù)用例而改變。最初，公共云用于非關(guān)鍵應(yīng)用，而私有云用于關(guān)注安全性的關(guān)鍵應(yīng)用?；旌显坪凸苍频氖褂秒S著時(shí)間的推移以及對(duì)云服務(wù)提供商所提供服務(wù)的經(jīng)驗(yàn)及信心而發(fā)展。同樣地，不同云服務(wù)模型的使用也根據(jù)用例和靈活性而有所不同。IaaS在早期最受歡迎，但是PaaS則憑借其成熟度和自動(dòng)伸縮、支持多語(yǔ)言和支持端到端應(yīng)用程序生命期管理工具的易用性而后來(lái)居上。

圖1-2

1.1.2　DevOps概述

DevOps與發(fā)展開(kāi)發(fā)和IT運(yùn)營(yíng)團(tuán)隊(duì)之間的協(xié)作，以比現(xiàn)有方式更高效地管理應(yīng)用程序生命期的組織文化、過(guò)程和技術(shù)有關(guān)(見(jiàn)圖1-3)。我們?cè)诠ぷ髦型鶅A向于根據(jù)模式，從類(lèi)似的問(wèn)題或者挑戰(zhàn)中找出可重用解決方案。

圖1-3

多年之后，成功與失敗的試驗(yàn)、好實(shí)踐、自動(dòng)化腳本、配置管理工具和方法論已經(jīng)成為DevOps文化中不可分割的一部分。

DevOps有助于定義設(shè)計(jì)方法、開(kāi)發(fā)方法、測(cè)試方法、安裝方法、環(huán)境管理方法、配置管理方法、應(yīng)用部署方法、反饋收集方法、代碼改善方法和創(chuàng)新方法。

下面是開(kāi)展DevOps實(shí)踐的一些明顯好處。

DevOps是一系列創(chuàng)新，以高效的方法將開(kāi)發(fā)與運(yùn)營(yíng)團(tuán)隊(duì)整合在一起，這些方法包括持續(xù)構(gòu)建集成、持續(xù)測(cè)試、云資源配給、持續(xù)交付、持續(xù)部署、持續(xù)監(jiān)控、持續(xù)反饋、持續(xù)改善和持續(xù)創(chuàng)新，按照敏捷方法論的要求，更快地交付應(yīng)用程序。文化的發(fā)展不是一夜之間就能完成的，需要很長(zhǎng)的時(shí)間。但是，對(duì)于DevOps究竟是什么仍存在概念上的混淆，人們往往將單獨(dú)的持續(xù)集成或者配置管理實(shí)踐當(dāng)成DevOps實(shí)踐，這就像盲人摸象，每個(gè)人都將觸摸到的一部分當(dāng)成大象的整體，如圖1-4所示。

圖1-4

但是，DevOps涉及的不僅是開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)。在現(xiàn)有文化的發(fā)展中，涉及測(cè)試團(tuán)隊(duì)、業(yè)務(wù)分析人員、構(gòu)建工程師、自動(dòng)化團(tuán)隊(duì)、云團(tuán)隊(duì)和許多其他利益相關(guān)方。

DevOps和組織文化沒(méi)有太大區(qū)別，它們有共同的價(jià)值和行為特征，需要調(diào)整心態(tài)和過(guò)程，與新的技術(shù)和工具相匹配。

開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)面臨的挑戰(zhàn)

正因?yàn)楝F(xiàn)實(shí)中的一些挑戰(zhàn)，使DevOps呈向上的趨勢(shì)，并成為所有信息技術(shù)相關(guān)討論中的熱門(mén)話(huà)題。

開(kāi)發(fā)團(tuán)隊(duì)面臨的挑戰(zhàn)

開(kāi)發(fā)人員渴望采用新技術(shù)和新方法解決問(wèn)題。但是，他們面對(duì)許多挑戰(zhàn)。

競(jìng)爭(zhēng)激烈的市場(chǎng)造成了按時(shí)交付的壓力。

他們不得不負(fù)責(zé)生產(chǎn)就緒代碼管理和新功能的實(shí)現(xiàn)。

發(fā)行周期往往很長(zhǎng)，因此，開(kāi)發(fā)團(tuán)隊(duì)必須在應(yīng)用部署最終進(jìn)行之前做出假設(shè)。在這種情況下，修復(fù)在模擬環(huán)境或者生產(chǎn)環(huán)境中部署期間發(fā)生的問(wèn)題需要花費(fèi)更多的時(shí)間。

運(yùn)營(yíng)團(tuán)隊(duì)面臨的挑戰(zhàn)

運(yùn)營(yíng)團(tuán)隊(duì)對(duì)資源變化、新技術(shù)或新方法的使用總是小心翼翼，因?yàn)樗麄冃枰€(wěn)定性。但是，他們也面對(duì)許多挑戰(zhàn)。

資源爭(zhēng)用：難以處理日益增長(zhǎng)的資源需求。

重新設(shè)計(jì)或者調(diào)整：這是在生產(chǎn)環(huán)境中運(yùn)行應(yīng)用程序的需要。

診斷和改正：他們應(yīng)該在應(yīng)用程序部署與外界隔絕的情況下診斷和改正問(wèn)題。

IT團(tuán)隊(duì)面臨的挑戰(zhàn)

IT團(tuán)隊(duì)向各個(gè)團(tuán)隊(duì)提供運(yùn)營(yíng)所需的資源。

基礎(chǔ)設(shè)施配給：提供基礎(chǔ)設(shè)施和具備合適安裝軟件包的運(yùn)行時(shí)環(huán)境。

配置管理：根據(jù)工具或者技術(shù)的可供更新，升級(jí)現(xiàn)有基礎(chǔ)設(shè)施或者軟件包。

考慮到開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)面對(duì)的所有挑戰(zhàn)，我們應(yīng)該如何改善現(xiàn)有過(guò)程、利用自動(dòng)化工具提高過(guò)程的效率、改變?nèi)藗兊乃季S方式?在下一小節(jié)，我們將了解如何在組織中發(fā)展DevOps文化，改善效率和效能。

1.2　如何發(fā)展DevOps文化

低效的估算、進(jìn)入市場(chǎng)的時(shí)間過(guò)長(zhǎng)以及其他問(wèn)題導(dǎo)致了瀑布模型的改變，產(chǎn)生了敏捷模型。文化的演變不是有固定時(shí)限或者一夜之間可以完成的過(guò)程，它可能是一個(gè)步進(jìn)式的分階段過(guò)程，可以在不依賴(lài)其他階段的情況下完成。

我們可以在不使用云配給的情況下實(shí)現(xiàn)持續(xù)集成，可以在不實(shí)現(xiàn)配置管理的情況下實(shí)現(xiàn)云配給。我們也可以在沒(méi)有任何DevOps實(shí)踐的情況下實(shí)現(xiàn)持續(xù)測(cè)試。圖1-5所示是實(shí)現(xiàn)DevOps實(shí)踐的不同階段。

圖1-5

1.2.1　敏捷開(kāi)發(fā)

敏捷開(kāi)發(fā)或基于敏捷的方法論對(duì)應(yīng)用程序構(gòu)建很有用，這種方法將權(quán)力下放，鼓勵(lì)互動(dòng)，重視可工作軟件、客戶(hù)協(xié)作——利用反饋改善后續(xù)步驟——并以高效的方式響應(yīng)變化。

敏捷開(kāi)發(fā)最吸引人的好處之一是在短時(shí)間內(nèi)(敏捷術(shù)語(yǔ)中叫作“沖刺”)持續(xù)交付。這樣，應(yīng)用開(kāi)發(fā)的敏捷方法、技術(shù)上的改進(jìn)、破壞性創(chuàng)新和方法在開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)之間造成了一條鴻溝。

1.2.2　DevOps

DevOps試圖通過(guò)發(fā)展開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)之間的伙伴關(guān)系，彌合這條鴻溝。DevOps活動(dòng)強(qiáng)調(diào)軟件開(kāi)發(fā)人員和IT運(yùn)營(yíng)部門(mén)之間的溝通、協(xié)作和整合。

DevOps促進(jìn)協(xié)作，通過(guò)自動(dòng)化和編排改善過(guò)程為協(xié)作提供方便。換言之，DevOps本質(zhì)上將敏捷活動(dòng)的持續(xù)開(kāi)發(fā)目標(biāo)擴(kuò)展到持續(xù)集成和發(fā)行。DevOps是利用云解決方案的優(yōu)勢(shì)，將敏捷實(shí)踐與過(guò)程組合起來(lái)。敏捷開(kāi)發(fā)和測(cè)試方法幫助我們實(shí)現(xiàn)應(yīng)用程序的持續(xù)集成、開(kāi)發(fā)、構(gòu)建、部署、測(cè)試和發(fā)行目標(biāo)。

構(gòu)建自動(dòng)化

自動(dòng)化構(gòu)建運(yùn)用Gradle、Apache Ant和Apache Maven等構(gòu)建自動(dòng)化工具，幫助我們創(chuàng)建應(yīng)用程序構(gòu)建。

自動(dòng)化構(gòu)建過(guò)程包括將源代碼編譯成類(lèi)文件或者二進(jìn)制文件、提供第三方庫(kù)文件引用、提供配置文件路徑、將類(lèi)文件或者二進(jìn)制文件打包成包文件、執(zhí)行自動(dòng)化測(cè)試用例、在本地或遠(yuǎn)程機(jī)器上部署包文件和減少包文件創(chuàng)建中的手工作業(yè)等活動(dòng)。

持續(xù)集成

簡(jiǎn)言之，持續(xù)集成(CI)是一種軟件工程實(shí)踐，在這種方法中，開(kāi)發(fā)人員的每次簽入(Check-in)都使用如下任一種方法驗(yàn)證。

“拉”機(jī)制：在計(jì)劃的時(shí)間點(diǎn)執(zhí)行自動(dòng)化構(gòu)建。

“推”機(jī)制：在存儲(chǔ)庫(kù)中保存更改時(shí)執(zhí)行自動(dòng)化構(gòu)建。

這一步之后，對(duì)源代碼庫(kù)中最新的更改執(zhí)行一次單元測(cè)試。持續(xù)集成是一種流行的DevOps方法，要求開(kāi)發(fā)人員將代碼每天數(shù)次整合為Git和SVN等代碼庫(kù)，以驗(yàn)證代碼的完整性。

然后，自動(dòng)化構(gòu)建驗(yàn)證每次簽入，使團(tuán)隊(duì)可以及早發(fā)現(xiàn)問(wèn)題。

CI(甚至CD)是公司同步DevOps存檔的基線。在組織中如果沒(méi)有很好地實(shí)施CI和CD，就無(wú)法實(shí)施DevOps。

云配給

在本章前面，我們已經(jīng)介紹了云計(jì)算的基本知識(shí)。云配給為架構(gòu)即代碼(Infrastructure as Code ，IAC)敞開(kāi)了大門(mén)，使整個(gè)過(guò)程變得極其高效，因?yàn)槲覀冊(cè)诤艽蟮某潭壬蠈⑸婕叭斯じ深A(yù)的過(guò)程自動(dòng)化了。

現(xiàn)收現(xiàn)付的計(jì)費(fèi)模式使所需的資源更加容易承受，不僅對(duì)大型組織，對(duì)中小規(guī)模組織和個(gè)人也是如此。

云配給有助于改進(jìn)和創(chuàng)新，因?yàn)橐郧暗馁Y源約束從成本和維護(hù)的角度阻礙了組織的進(jìn)一步發(fā)展。一旦我們?cè)诨A(chǔ)設(shè)施資源上擁有了敏捷性，就可以考慮自動(dòng)化運(yùn)行應(yīng)用程序所需軟件包的安裝和配置。

配置管理

配置管理(CM)系統(tǒng)中的更改，更具體地說(shuō)，就是服務(wù)器運(yùn)行時(shí)環(huán)境。我們可以使用市場(chǎng)上的許多工具實(shí)現(xiàn)配置管理。流行工具包括Chef、Puppet、Ansible、Salt等。

讓我們來(lái)考慮一個(gè)需要管理多個(gè)同類(lèi)配置服務(wù)器的例子。

例如，我們需要在每個(gè)服務(wù)器上安裝Tomcat。如果需要改變所有服務(wù)器上的端口、更新某些軟件包或者為某些用戶(hù)提供權(quán)限，該怎么辦?這種情形下的任何修改都是人工的，也就是一種容易出錯(cuò)的過(guò)程。因?yàn)樗蟹?wù)器都使用相同的配置，可以利用自動(dòng)化手段。

持續(xù)交付

持續(xù)交付和持續(xù)部署是可以互換使用的術(shù)語(yǔ)。但是，兩者之間還是有一些小的差別。

持續(xù)交付是在任何環(huán)境中以自動(dòng)化方式部署一個(gè)應(yīng)用程序并提供持續(xù)反饋以改善其質(zhì)量的過(guò)程。持續(xù)交付和持續(xù)部署中的自動(dòng)化方法不會(huì)改變。但是批準(zhǔn)過(guò)程和其他小細(xì)節(jié)可能改變。

持續(xù)測(cè)試和部署

持續(xù)測(cè)試是端到端應(yīng)用程序生命期管理過(guò)程中很重要的階段，包括功能測(cè)試、性能測(cè)試、安全性測(cè)試等。

Selenium、Appium、Apache JMeter和許多其他工具都可以用于相同的目的。另一方面，持續(xù)部署是部署應(yīng)用程序，包含對(duì)生產(chǎn)環(huán)境的最新更改。

持續(xù)監(jiān)控

持續(xù)監(jiān)控是端到端交付流水線的骨干，開(kāi)源監(jiān)控工具就像冰淇淋勺的頭部。

如圖1-6所示，在幾乎每個(gè)階段都設(shè)置監(jiān)控，獲得所有過(guò)程的透明度是十分可取的做法。這還能夠幫助我們快速檢修故障。監(jiān)控應(yīng)該在深思熟慮的計(jì)劃下執(zhí)行。

圖1-6描述了持續(xù)方法的全部過(guò)程。

我們必須理解，這是一種分階段的方法，不一定要一次性完成各個(gè)階段的自動(dòng)化工作。每次選擇一種DevOps實(shí)踐、實(shí)施并理解其好處，然后再實(shí)施另一個(gè)，這是更有效的做法。

這樣，我們可以安全地評(píng)估組織文化改變帶來(lái)的改善，消除應(yīng)用程序生命期管理中的手工勞動(dòng)。

圖1-6

1.3　PPT——人、過(guò)程和技術(shù)——的重要性

PPT在任何組織中都是一個(gè)重要的詞。等等!我們說(shuō)的可不是PowerPoint演示。這里，我們關(guān)注的是人、過(guò)程和工具/技術(shù)。讓我們來(lái)了解一下，為什么這些因素在改變?nèi)魏谓M織的文化時(shí)很重要。

1.3.1　人

引用Jack Cranfield的名言：

不管周?chē)l(fā)生什么，成功的人總是積極地看待人生。他們著眼于過(guò)去的成功而不是過(guò)去的失敗，聚焦于使他們更接近目標(biāo)的下一步行動(dòng)，而不是生活中令他們分心的其他事務(wù)。

為什么說(shuō)人很重要?這是一個(gè)有趣的問(wèn)題。如果我們想要用一句話(huà)來(lái)回答，那就是：因?yàn)槲覀冊(cè)噲D改變文化。

那么又如何?

人是任何文化的重要組成部分，只有人能夠驅(qū)動(dòng)文化的改變，或者改變自己以適應(yīng)新過(guò)程、定義新過(guò)程、學(xué)習(xí)新工具或者技術(shù)。

讓我們用變革方程式來(lái)理解。

按照維基百科的說(shuō)法，David Gleicher在20世紀(jì)60年代初創(chuàng)造了變革方程式。Kathie Dannemiller在1980年對(duì)方程式進(jìn)行了完善。這個(gè)方程式提供了一個(gè)模型，以評(píng)估影響組織變革倡議成功概率的相對(duì)優(yōu)勢(shì)。

Gleicher(原始)版本為：C= (ABD) >X，其中C=變革，A=對(duì)現(xiàn)狀的不滿(mǎn)意度，B=希望得到的明確狀態(tài)，D=達(dá)到理想狀態(tài)的實(shí)際步驟，X=變革的代價(jià)。

Dannemiller的版本：D×V×F>R，其中D、V和F必須存在，組織變革才能進(jìn)行：D=對(duì)現(xiàn)狀的不滿(mǎn)意度，V=對(duì)可能目標(biāo)的愿景，F(xiàn)=可用于實(shí)現(xiàn)愿景的前幾個(gè)具體步驟。如果這3個(gè)因素的乘積大于R(阻力)，那么變革就是可能成功的。

本質(zhì)上說(shuō)，這個(gè)公式表示，必須有對(duì)現(xiàn)有事務(wù)或者過(guò)程的不滿(mǎn)，對(duì)新趨勢(shì)、技術(shù)和市場(chǎng)方案創(chuàng)新的愿景，以及實(shí)現(xiàn)愿景所采取的具體步驟。

關(guān)于變革方程式的更多細(xì)節(jié)，可以訪問(wèn)維基百科網(wǎng)頁(yè)：https://en.wikipedia.org/wiki/Formula_for_change#cite_note-myth-1

作為經(jīng)驗(yàn)分享，我認(rèn)為培訓(xùn)人員適應(yīng)新的文化非常重要，這是一場(chǎng)需要耐心的博弈。我們不能在一夜之間改變?nèi)藗兊乃季S方式，在改變文化之前首先需要理解。

在行業(yè)中往往能看到，文化的改變從DevOps知識(shí)或者DevOps工程師開(kāi)始，但是在理想狀況下，這些不應(yīng)該是“舶來(lái)品”，而應(yīng)該逐步改變現(xiàn)有環(huán)境，并在其中訓(xùn)練人員，以控制阻力。我們不需要一個(gè)專(zhuān)門(mén)的DevOps團(tuán)隊(duì)，需要的是開(kāi)發(fā)人員、測(cè)試團(tuán)隊(duì)、自動(dòng)化實(shí)現(xiàn)人員和云或基礎(chǔ)設(shè)施團(tuán)隊(duì)之間的更多溝通和協(xié)作。

讓所有人都理解彼此的痛點(diǎn)是必不可少的步驟。在我工作過(guò)的機(jī)構(gòu)里，我們習(xí)慣于有一個(gè)卓越中心(COE)來(lái)管理新技術(shù)、創(chuàng)新或者文化。作為自動(dòng)化實(shí)現(xiàn)者和DevOps團(tuán)隊(duì)的一員，我們只應(yīng)該擔(dān)當(dāng)促進(jìn)者的角色，而不是與世隔絕的“豎井”中的一員。

1.3.2　過(guò)程

Tom Peters曾有一段名言：

幾乎所有質(zhì)量改進(jìn)都來(lái)源于對(duì)設(shè)計(jì)、制造…布局、過(guò)程和規(guī)程的簡(jiǎn)化。

在處理文化的發(fā)展時(shí)，質(zhì)量極其重要。我們需要過(guò)程和策略，以正確的方式完成工作，并標(biāo)準(zhǔn)化各個(gè)項(xiàng)目，使操作的順序、約束、規(guī)則等都有完備的定義，以便對(duì)成功與否進(jìn)行度量。

我們需要為以下任務(wù)建立過(guò)程。

敏捷規(guī)劃。

資源規(guī)劃和配給。

配置管理。

對(duì)云資源和自動(dòng)化中使用的其他工具的基于角色訪問(wèn)控制。

編程語(yǔ)言的靜態(tài)代碼分析規(guī)則。

測(cè)試方法論與工具。

發(fā)行管理。

這些過(guò)程對(duì)于度量DevOps文化發(fā)展的成功也很重要。

1.3.3　技術(shù)

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

技術(shù)并不重要，重要的是你對(duì)人們有信心，他們都很好、很聰明，如果給他們工具，他們就能做了不起的事。

科技幫助人和組織產(chǎn)生創(chuàng)意、完成創(chuàng)新，同時(shí)改變文化。沒(méi)有科技，在日常例行的自動(dòng)化操作中，就很難實(shí)現(xiàn)速度和效率。云計(jì)算、配置管理工具和構(gòu)建流水線在資源配給、安裝運(yùn)行時(shí)環(huán)境和編排中很有用處。它們從根本上提高了應(yīng)用程序生命期管理中不同方面工作的速度。

1.4　為什么說(shuō)DevOps不全和工具有關(guān)

是的，工具什么都不是，在任何組織的文化變革中，它們都不是重要的因素。原因很簡(jiǎn)單。不管我們使用哪一種技術(shù)，都必須實(shí)施持續(xù)集成、云配給、配置管理、持續(xù)交付、持續(xù)部署、持續(xù)監(jiān)控等。

按照類(lèi)別，可以使用不同的工具集，但是所有工具執(zhí)行的都是類(lèi)似的操作。工具執(zhí)行某個(gè)操作的方式可能不同，但結(jié)果是相同的。表1-1所示是按照分類(lèi)列出的一些工具。

表1-1

讓我們來(lái)看看在不同運(yùn)營(yíng)工作的不同階段使用的不同工具。這可能根據(jù)不同組織中的環(huán)境數(shù)量或者DevOps實(shí)踐數(shù)量而變化，如圖1-7所示。

圖1-7

如果我們需要根據(jù)不同的DevOps好實(shí)踐分類(lèi)工具，可以將其分類(lèi)為開(kāi)源和商業(yè)。表1-2所示為一些例子。

表1-2

1.5　DevOps評(píng)估問(wèn)題

DevOps是一種文化，我們對(duì)此已經(jīng)很了解。但是，在實(shí)施自動(dòng)化、制定過(guò)程和發(fā)展文化之前，我們必須理解組織文化的現(xiàn)狀，以及是否有必要引入新過(guò)程或者自動(dòng)化工具。

我們必須非常清楚，我們需要的是使現(xiàn)有文化變得更加高效，而不是輸入文化。

創(chuàng)建需要提出的問(wèn)題類(lèi)別，并根據(jù)具體應(yīng)用得出答案。

下面是幾個(gè)問(wèn)題的例子。

1.你是否遵循敏捷原則?

2.你是否使用源代碼庫(kù)?

3.你是否使用靜態(tài)代碼分析工具?

4.你是否使用構(gòu)建自動(dòng)化工具?

5.你使用場(chǎng)內(nèi)基礎(chǔ)設(shè)施還是基于云的基礎(chǔ)設(shè)施?

6.你使用配置管理工具、安裝應(yīng)用程序軟件包的腳本還是運(yùn)行時(shí)環(huán)境?

7.你是否使用自動(dòng)化腳本在生產(chǎn)和非生產(chǎn)環(huán)境中部署應(yīng)用程序?

8.你是否使用應(yīng)用程序生命期管理的編排工具或者腳本?

9.你是否使用功能測(cè)試、負(fù)載測(cè)試、安全性測(cè)試和移動(dòng)測(cè)試的自動(dòng)化工具?

10.你是否使用應(yīng)用程序和基礎(chǔ)設(shè)施監(jiān)控工具?

一旦問(wèn)題就緒，就準(zhǔn)備答案，并根據(jù)上述問(wèn)題的每個(gè)答案確定等級(jí)。

保證框架的靈活性，即使我們改變?nèi)魏晤?lèi)別中的一個(gè)問(wèn)題，也能夠自動(dòng)地管理。

評(píng)出等級(jí)之后，在框架中引入不同的條件和智能，捕捉答案并計(jì)算總體等級(jí)。

創(chuàng)建各個(gè)分類(lèi)的最終等級(jí)，根據(jù)最終等級(jí)創(chuàng)建不同類(lèi)型的圖表，使其更容易理解。在這里，需要注意的是，組織在應(yīng)用程序生命期管理各領(lǐng)域中的專(zhuān)業(yè)能力。這將為評(píng)估框架提供一個(gè)新的維度，以增加智能，使其更為高效。

1.6　小結(jié)

在本文中，我們?cè)O(shè)定了本書(shū)要實(shí)現(xiàn)的許多目標(biāo)。我們介紹了持續(xù)集成、云環(huán)境中的資源配給、配置管理、持續(xù)交付、持續(xù)部署和持續(xù)監(jiān)控。

設(shè)計(jì)目標(biāo)是將愿景清晰化的第一步。

我們已經(jīng)看到，云計(jì)算是如何改變過(guò)去對(duì)創(chuàng)新的認(rèn)知方法，它現(xiàn)在已經(jīng)變成了切實(shí)可行的方案。我們還簡(jiǎn)要介紹了DevOps的必要性和各種不同的DevOps實(shí)踐。人、過(guò)程和技術(shù)在改變組織現(xiàn)有文化的過(guò)程中也很重要。我們?cè)噲D指出它們的重要性。工具很重要，但不能止步于此;可以利用任何工具集，改變文化并不需要特定的工具集。我們也簡(jiǎn)要地討論了DevOps的評(píng)估框架，它將幫助你沿著文化變革的道路前進(jìn)。