【寫(xiě)在前面】筆者曾幫助多家大型企業(yè)深入了解 DevOps，幫助他們理解如何改善服務(wù)交付能力。這些公司大多聽(tīng)說(shuō)過(guò) DevOps，也在四處尋求一個(gè)策略來(lái)采用 DevOps 方法，從而進(jìn)一步占領(lǐng)市場(chǎng)，提升產(chǎn)品質(zhì)量。出于各種原因，并非所有人都信任 DevOps。有些人覺(jué)得 DevOps 只不過(guò)給開(kāi)發(fā)者改善產(chǎn)品提供了一個(gè)途徑而已，還有的人覺(jué)得 DevOps 是一堆悅耳的空頭支票，甚至有人認(rèn)為 DevOps 根本無(wú)法采用，因?yàn)槠渌陬I(lǐng)域所必須的自動(dòng)化工具根本不存在。

以下為原文編譯內(nèi)容。

[[150231]]

通常在企業(yè)里，運(yùn)維通常由一個(gè)集中且獨(dú)立的團(tuán)隊(duì)完成，同時(shí)他們需要支撐多個(gè)應(yīng)用程序組。如果網(wǎng)站的可用性出問(wèn)題，責(zé)任就落在運(yùn)維團(tuán)隊(duì)身上。一旦出現(xiàn)性能問(wèn)題、宕機(jī)或故障，運(yùn)維團(tuán)隊(duì)無(wú)疑是***道防線，但有時(shí)問(wèn)題升級(jí)會(huì)返回到應(yīng)用組去修復(fù) bug 或者幫助診斷問(wèn)題。

對(duì) DevOps 感興趣的企業(yè)往往實(shí)踐或采用了一個(gè)對(duì)運(yùn)維需求非常高的敏捷技術(shù)，比如建立一個(gè)測(cè)試環(huán)境，或者測(cè)試節(jié)后發(fā)布軟件到生產(chǎn)環(huán)境。持續(xù)加快的步伐給運(yùn)維團(tuán)隊(duì)施加了很大的壓力，因?yàn)榇蠖鄷r(shí)候工作集中在項(xiàng)目后期(例如，是時(shí)候發(fā)布到生產(chǎn)環(huán)境中)。迫于時(shí)間壓力或者過(guò)量工作，運(yùn)營(yíng)團(tuán)隊(duì)很難完成相對(duì)請(qǐng)求，甚至有時(shí)聽(tīng)到開(kāi)發(fā)者埋怨想親力親為。那些用戶可能想重建服務(wù)器、獲取 Shell 訪問(wèn)、安裝軟件、運(yùn)行命令和腳本、設(shè)置虛擬機(jī)、修改網(wǎng)絡(luò) ACL 和更新負(fù)載平衡器等。他們認(rèn)為有些事情還不如自己來(lái)做，從而不再需要高度集中的運(yùn)維小組。

如何讓運(yùn)維團(tuán)隊(duì)，一直負(fù)責(zé)生產(chǎn)環(huán)境運(yùn)行時(shí)的部門能擴(kuò)展其支持的環(huán)境?他們應(yīng)該如何避免成為各應(yīng)用團(tuán)隊(duì)項(xiàng)目周期尾端的瓶頸?如何讓業(yè)務(wù)更加穩(wěn)定可靠，而不是混亂、中斷或不按預(yù)期執(zhí)行?

如果你身處這種企業(yè)環(huán)境，又該如何進(jìn)入 DevOps?如果你身處高度集中的運(yùn)營(yíng)團(tuán)隊(duì)，又該解決采用 DevOps 的壓力，這里有幾個(gè)問(wèn)題需要企業(yè)團(tuán)隊(duì)謹(jǐn)慎考慮，問(wèn)題的答案則是一步步形成 DevOps 戰(zhàn)略的重要步驟。

那么，一個(gè)高度集中的運(yùn)營(yíng)團(tuán)隊(duì)如何處理必要任務(wù)，使得應(yīng)用程序可以在生產(chǎn)環(huán)境或其他環(huán)境下順利運(yùn)行?

在有些企業(yè)中，初期會(huì)創(chuàng)建一個(gè)名為「devops」的專業(yè)團(tuán)隊(duì)來(lái)解決各種「devops 問(wèn)題」，這便是良好運(yùn)營(yíng)的開(kāi)端。這個(gè)團(tuán)隊(duì)可能會(huì)負(fù)責(zé)接手開(kāi)發(fā)團(tuán)隊(duì)的應(yīng)用程序，使用自動(dòng)化工具進(jìn)行打包，進(jìn)行部署并將其轉(zhuǎn)交給 Site Reliability 團(tuán)隊(duì)。不幸的是，集中式的 devops 團(tuán)隊(duì)也可能變成「silo」 ，也要不斷接受傳統(tǒng)運(yùn)維組所面臨的「項(xiàng)目末期」交接挑戰(zhàn)。同時(shí)，隨著更多的開(kāi)發(fā)者和開(kāi)發(fā)項(xiàng)目涌入，devops 工程師和 devops 團(tuán)隊(duì)再次成為瓶頸。集中的 devops 團(tuán)隊(duì)和傳統(tǒng)的 QA 部門一樣，當(dāng)他們嘗試「添加質(zhì)量檢測(cè)」作為一個(gè)獨(dú)立過(guò)程階段時(shí)，也不得不面臨同樣的壓力。

為了確保應(yīng)用程序可以在生產(chǎn)環(huán)境以及其他環(huán)境下正常運(yùn)行，devops 重點(diǎn)必須嵌入應(yīng)用體系結(jié)構(gòu)。這就意味著，讓?xiě)?yīng)用程序易于配置、部署和監(jiān)控均在開(kāi)發(fā)階段完成。集中的運(yùn)維團(tuán)隊(duì)必須學(xué)會(huì)開(kāi)發(fā)一個(gè)共享式軟件交付流程和工具鏈。在交付工具鏈內(nèi)部，任務(wù)可以分布在多個(gè)團(tuán)隊(duì)。集中的運(yùn)維組可以支持工具鏈，正如架構(gòu)師和服務(wù)提供者提供給應(yīng)用開(kāi)發(fā)團(tuán)隊(duì)一個(gè)基礎(chǔ)框架，而在填充所需的構(gòu)件就可以驅(qū)動(dòng)這個(gè)管道。

什么是合規(guī)策略(compliance policies)?

大多數(shù)企業(yè)都遵循一個(gè)修改策略，即預(yù)先指定誰(shuí)可以在生產(chǎn)過(guò)程中做出修改。很多時(shí)候，這一策略常常被理解為除了運(yùn)維組以外，其他人都不能發(fā)布更新。這種切換可能導(dǎo)致交付時(shí)間拖延，同時(shí)如果在傳遞過(guò)程中丟失信息，甚至可能導(dǎo)致故障發(fā)生。

這些規(guī)則都是由企業(yè)制定的，但事實(shí)上，在交付端的職員從未去認(rèn)真地去理解這些政策的語(yǔ)義，他們通常根據(jù)想象或者習(xí)慣去判斷。而隨著時(shí)間推移，工具和流程往往發(fā)酵成無(wú)效率的官僚機(jī)構(gòu)。

基于應(yīng)用或客戶類型，通常會(huì)形成不同的限制規(guī)則。當(dāng)涉及到如何縮短交付周期時(shí)，這些差異應(yīng)該納入考慮，因?yàn)樗軒椭惆l(fā)現(xiàn)究竟誰(shuí)可以做出更改，以及修改該如何進(jìn)行。

除了主動(dòng)理解規(guī)則，規(guī)則同樣需要做到快速和便捷地審校：

簡(jiǎn)單易懂的規(guī)則能清晰展現(xiàn)以下內(nèi)容：

• 誰(shuí)做出了變動(dòng)以及是否有權(quán)限
• 改變應(yīng)用在哪里
• 具體的改變內(nèi)容，這些調(diào)整是否能接受

這種查詢應(yīng)該能即時(shí)訪問(wèn)，而不是在某個(gè)事情后(比如故障發(fā)生)通過(guò)人工收集得到。當(dāng)你拿到服務(wù)器過(guò)去24小時(shí)的工作報(bào)告時(shí)，便能輕而易舉了解到環(huán)境中發(fā)生了哪些變化。

這些審計(jì)視圖應(yīng)該包含基礎(chǔ)設(shè)施和工件信息，因?yàn)椴还苁情_(kāi)發(fā)者還是運(yùn)維人員都想清楚軟件和服務(wù)器的信息，一堆不明所以的修改信息和錯(cuò)誤鏈接報(bào)告無(wú)論如何也無(wú)法組成一張全景圖。

如何開(kāi)放訪問(wèn)又不會(huì)失去控制?

通過(guò)審視軟件交付的整個(gè)過(guò)程工作流全時(shí)監(jiān)控將變得簡(jiǎn)單，在以往這個(gè)工作通常由一個(gè)獨(dú)立的團(tuán)隊(duì)完成，他們往往以往競(jìng)爭(zhēng)優(yōu)先級(jí)導(dǎo)致的上下文切換而變得沒(méi)有效率，這種情況通常在運(yùn)維團(tuán)隊(duì)發(fā)生。運(yùn)維團(tuán)隊(duì)需要平衡來(lái)源于應(yīng)用開(kāi)發(fā)團(tuán)隊(duì)的工作(例如，參與敏捷開(kāi)發(fā)沖刺)、網(wǎng)絡(luò)操作(例如，處理中斷和生產(chǎn)問(wèn)題)、企業(yè)用戶(例如，收集信息用于控制策略)。***，運(yùn)維還需負(fù)責(zé)維護(hù)或改善基礎(chǔ)設(shè)施等項(xiàng)目工作。

為了釋放這個(gè)流程的瓶頸，企業(yè)必須發(fā)掘應(yīng)該如何重新分配工作，或者建立一個(gè)自服務(wù)流程。因?yàn)椴渴稹⑴渲煤捅O(jiān)控都是需要設(shè)計(jì)到應(yīng)用中的運(yùn)維問(wèn)題，一次需要將之一定程度地傳遞給開(kāi)發(fā)人員。聚焦這一系列動(dòng)作，運(yùn)維團(tuán)隊(duì)需要維護(hù)一組基本的自動(dòng)化模塊，給開(kāi)發(fā)人員相應(yīng)方法來(lái)參與。創(chuàng)建一個(gè)開(kāi)發(fā)環(huán)境和工具允許開(kāi)發(fā)人員在自己的沙箱中將所需的改變整合到這個(gè)框架中。通過(guò)自助服務(wù)界面讓開(kāi)發(fā)人員可以便捷地創(chuàng)建托管環(huán)境，打開(kāi) VMs 或者容器，允許他們測(cè)試運(yùn)維管理代碼。

給運(yùn)維管理框架構(gòu)建合規(guī)的審計(jì)日志，便能跟蹤到哪些資源被創(chuàng)建和使用。一旦資源發(fā)生沖突，這些日志將會(huì)有非常大的幫助，并讓你了解到哪里需要更多的沙箱或者哪些更細(xì)粒度的配置需要定義。

欲速則不達(dá)，速度越快反而導(dǎo)致質(zhì)量下降?

對(duì)于企業(yè)來(lái)說(shuō)，不斷提升創(chuàng)新速度才能保持競(jìng)爭(zhēng)力，所以速度至關(guān)重要。因此這里需要更快的軟件交付速度，也正是采用 DevOps 做法的主要?jiǎng)訖C(jī)。

許多 DevOps 成功案例都在展示其一天能部署多少次，10還是1000。但是在現(xiàn)實(shí)世界中，這些指標(biāo)簡(jiǎn)可以稱得上是神話。有些企業(yè)盡量一個(gè)月實(shí)現(xiàn)一次部署，還有些企業(yè)一個(gè)主要版本更新需要按年計(jì)算，而發(fā)布給用戶更需要30天的時(shí)間。這三十天的滯后時(shí)間，同時(shí)生產(chǎn)環(huán)境處于不一致的狀態(tài)，所有人都難以應(yīng)付生產(chǎn)中出現(xiàn)的問(wèn)題。「是新版本還是舊版本造成了這個(gè)尚未確定的問(wèn)題?」操作無(wú)法加快的一個(gè)主要原因是無(wú)法確定問(wèn)題究竟是發(fā)生在改變期間或改變后。

當(dāng)改動(dòng)導(dǎo)致問(wèn)題，可能導(dǎo)致以下結(jié)果：

• 添加更多控制過(guò)程(審批門檻更多，改動(dòng)窗口更小)
• 改變批次變大(更多的工作塞到給定的變化窗口)
• 增加「緊急修正」(高優(yōu)先級(jí)功能得到快速跟蹤，才能避免正常的變化流程)
• 因?yàn)榕到y(tǒng)和非正常軟件發(fā)布流程，應(yīng)用程序快速更新將帶來(lái)很大壓力

鑒于以上后果，加快改變速度的想法顯得不切實(shí)際，因?yàn)樗_實(shí)可能誘發(fā)更多的問(wèn)題。

問(wèn)題是企業(yè)該如何快速給系統(tǒng)做更新?首先，指定更新過(guò)程中的安全策略非常重要。快速轉(zhuǎn)變意味著能安全地快速改變。下面是一些常見(jiàn)策略：

小批量

大批量改變所帶來(lái)的工作量需要耗費(fèi)大量的人力和時(shí)間。

解決辦法是利用這種策略：變化越少越容易實(shí)現(xiàn)，完成后也便于檢查。

預(yù)演

這里有一個(gè)很好的諺語(yǔ)，「Don’t practice until you get it right. Practice until you can’t get it wrong」。當(dāng)然，你不能在生產(chǎn)環(huán)境中實(shí)踐這個(gè)途徑。將更新應(yīng)用到生產(chǎn)環(huán)境之前，你應(yīng)該在非生產(chǎn)環(huán)境下進(jìn)行多次實(shí)驗(yàn)。不要依賴于運(yùn)氣，要抱著必然存在故障的理念。

可核查的流程階段

不管是新建立的一個(gè)網(wǎng)站或者是現(xiàn)有應(yīng)用程序需要更新，請(qǐng)確保已經(jīng)為先決條件做好了足夠的檢查。也就是說(shuō)，如果你要部署一個(gè)應(yīng)用，在這之前你就要準(zhǔn)備好腳本測(cè)試，來(lái)證實(shí)你的外部或環(huán)境依賴性。如果你正在構(gòu)建一個(gè)網(wǎng)站，在安裝操作平臺(tái)之前，保證你已經(jīng)確認(rèn)好硬件和網(wǎng)絡(luò)環(huán)境。在流程階段邊界構(gòu)建這種自動(dòng)化測(cè)試，對(duì)于防止問(wèn)題遺漏是一個(gè)巨大的安全保障。你可以使用這些驗(yàn)證檢查來(lái)決定「stop the line」。

流程規(guī)則

是什么導(dǎo)致了環(huán)境中布滿了特殊定制的服務(wù)器和網(wǎng)絡(luò)?缺少規(guī)則。如果企業(yè)無(wú)法統(tǒng)一管理變動(dòng)，每個(gè)人都會(huì)按自己的方式行事。那如何對(duì)流程進(jìn)行管控?搜尋所有不同的版本。如果流程在兩個(gè)版本中不同，那么就意味著這里存在一個(gè) variation。流程 variation 意味著流程失控。有兩個(gè)簡(jiǎn)單的度量可用于了解你對(duì)流程控制的程度：交貨時(shí)間和報(bào)廢率。交貨時(shí)間代表改變所需的時(shí)間。廢品率是返工頻率。預(yù)演和可核查的流程可以通過(guò)降低廢品率和穩(wěn)定交貨時(shí)間幫助獲得控制過(guò)程。流程管控的***好處是提高可預(yù)測(cè)變化的能力。業(yè)務(wù)依賴于這種可預(yù)測(cè)性。可預(yù)測(cè)性的業(yè)務(wù)可以提前規(guī)劃移動(dòng)速度的快慢。

更多途徑進(jìn)入運(yùn)維管理環(huán)境?

每個(gè)人都更好地了解生產(chǎn)中各部分是如何執(zhí)行的，可以幫助企業(yè)設(shè)計(jì)更好的系統(tǒng)來(lái)支持業(yè)務(wù)。如果開(kāi)發(fā)人員或測(cè)試人員都難以發(fā)現(xiàn)服務(wù)運(yùn)行的問(wèn)題，只會(huì)耽擱有利于用戶操作的改進(jìn)。讓任何人都能容易地了解到應(yīng)用版本在主機(jī)是如何部署的，以及主機(jī)配置和應(yīng)用程序的性能。

有時(shí)數(shù)據(jù)隱私規(guī)則使得數(shù)據(jù)訪問(wèn)并不那么直接。一些日志包含客戶數(shù)據(jù)和規(guī)則可能限制有限的用戶訪問(wèn)。不要說(shuō)「沒(méi)有」或手動(dòng)地去收集和清洗，這里需要存在一個(gè)自動(dòng)化的自服務(wù)，從而讓開(kāi)發(fā)者或?qū)徲?jì)人員可以自己獲取。

生產(chǎn)環(huán)境的可見(jiàn)性對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)是至關(guān)重要的，從而他們可以建立一個(gè)類似的環(huán)境。模擬聲場(chǎng)環(huán)境建模開(kāi)發(fā)和測(cè)試環(huán)境是減少變數(shù)并讓一切都在控制中的有效手段。

這是否意味著允許開(kāi)發(fā)者進(jìn)行 Shell訪問(wèn)?

這個(gè)問(wèn)題是傳統(tǒng)企業(yè)運(yùn)營(yíng)團(tuán)隊(duì)的弊病。通常這個(gè)問(wèn)題是另一個(gè)問(wèn)題的征兆。為什么一個(gè)開(kāi)發(fā)者要 Shell 訪問(wèn)運(yùn)維支持的環(huán)境?在開(kāi)發(fā)或早期的測(cè)試環(huán)境下，開(kāi)發(fā)人員可能需要Shell訪問(wèn)來(lái)實(shí)驗(yàn)開(kāi)發(fā)部署和配置代碼。這的確是申請(qǐng) Shell 訪問(wèn)的一個(gè)合理理由。

這是臨時(shí)或生產(chǎn)環(huán)境中 Shell 訪問(wèn)的請(qǐng)求嗎?Shell 訪問(wèn)請(qǐng)求可能是即席改變方法的一個(gè)標(biāo)志，從而改變一個(gè)環(huán)境的穩(wěn)定性。因此，對(duì)改變方法進(jìn)行自動(dòng)化封裝非常重要。

歸根結(jié)底，Shell 訪問(wèn)生產(chǎn)環(huán)境確實(shí)有很大的風(fēng)險(xiǎn)。

原文鏈接：http://news.oneapm.com/objections-to-devops/