企業(yè)運營對 DevOps 的 “傲慢與偏見”
【寫在前面】筆者曾幫助多家大型企業(yè)深入了解 DevOps，幫助他們理解如何改善服務(wù)交付能力。這些公司大多聽說過 DevOps，也在四處尋求一個策略來采用 DevOps 方法，從而進一步占領(lǐng)市場，提升產(chǎn)品質(zhì)量。出于各種原因，并非所有人都信任 DevOps。有些人覺得 DevOps 只不過給開發(fā)者改善產(chǎn)品提供了一個途徑而已，還有的人覺得 DevOps 是一堆悅耳的空頭支票，甚至有人認(rèn)為 DevOps 根本無法采用，因為其所在領(lǐng)域所必須的自動化工具根本不存在。
以下為原文編譯內(nèi)容。
通常在企業(yè)里，運維通常由一個集中且獨立的團隊完成，同時他們需要支撐多個應(yīng)用程序組。如果網(wǎng)站的可用性出問題，責(zé)任就落在運維團隊身上。一旦出現(xiàn)性能問題、宕機或故障，運維團隊無疑是***道防線，但有時問題升級會返回到應(yīng)用組去修復(fù) bug 或者幫助診斷問題。
對 DevOps 感興趣的企業(yè)往往實踐或采用了一個對運維需求非常高的敏捷技術(shù)，比如建立一個測試環(huán)境，或者測試節(jié)后發(fā)布軟件到生產(chǎn)環(huán)境。持續(xù)加快的步伐給運維團隊施加了很大的壓力，因為大多時候工作集中在項目后期(例如，是時候發(fā)布到生產(chǎn)環(huán)境中)。迫于時間壓力或者過量工作，運營團隊很難完成相對請求，甚至有時聽到開發(fā)者埋怨想親力親為。那些用戶可能想重建服務(wù)器、獲取 Shell 訪問、安裝軟件、運行命令和腳本、設(shè)置虛擬機、修改網(wǎng)絡(luò) ACL 和更新負(fù)載平衡器等。他們認(rèn)為有些事情還不如自己來做，從而不再需要高度集中的運維小組。
如何讓運維團隊，一直負(fù)責(zé)生產(chǎn)環(huán)境運行時的部門能擴展其支持的環(huán)境?他們應(yīng)該如何避免成為各應(yīng)用團隊項目周期尾端的瓶頸?如何讓業(yè)務(wù)更加穩(wěn)定可靠，而不是混亂、中斷或不按預(yù)期執(zhí)行?
如果你身處這種企業(yè)環(huán)境，又該如何進入 DevOps?如果你身處高度集中的運營團隊，又該解決采用 DevOps 的壓力，這里有幾個問題需要企業(yè)團隊謹(jǐn)慎考慮，問題的答案則是一步步形成 DevOps 戰(zhàn)略的重要步驟。
那么，一個高度集中的運營團隊如何處理必要任務(wù)，使得應(yīng)用程序可以在生產(chǎn)環(huán)境或其他環(huán)境下順利運行?
在有些企業(yè)中，初期會創(chuàng)建一個名為「devops」的專業(yè)團隊來解決各種「devops 問題」，這便是良好運營的開端。這個團隊可能會負(fù)責(zé)接手開發(fā)團隊的應(yīng)用程序，使用自動化工具進行打包，進行部署并將其轉(zhuǎn)交給 Site Reliability 團隊。不幸的是，集中式的 devops 團隊也可能變成「silo」 ，也要不斷接受傳統(tǒng)運維組所面臨的「項目末期」交接挑戰(zhàn)。同時，隨著更多的開發(fā)者和開發(fā)項目涌入，devops 工程師和 devops 團隊再次成為瓶頸。集中的 devops 團隊和傳統(tǒng)的 QA 部門一樣，當(dāng)他們嘗試「添加質(zhì)量檢測」作為一個獨立過程階段時，也不得不面臨同樣的壓力。
為了確保應(yīng)用程序可以在生產(chǎn)環(huán)境以及其他環(huán)境下正常運行，devops 重點必須嵌入應(yīng)用體系結(jié)構(gòu)。這就意味著，讓應(yīng)用程序易于配置、部署和監(jiān)控均在開發(fā)階段完成。集中的運維團隊必須學(xué)會開發(fā)一個共享式軟件交付流程和工具鏈。在交付工具鏈內(nèi)部，任務(wù)可以分布在多個團隊。集中的運維組可以支持工具鏈，正如架構(gòu)師和服務(wù)提供者提供給應(yīng)用開發(fā)團隊一個基礎(chǔ)框架，而在填充所需的構(gòu)件就可以驅(qū)動這個管道。
什么是合規(guī)策略(compliance policies)?
大多數(shù)企業(yè)都遵循一個修改策略，即預(yù)先指定誰可以在生產(chǎn)過程中做出修改。很多時候，這一策略常常被理解為除了運維組以外，其他人都不能發(fā)布更新。這種切換可能導(dǎo)致交付時間拖延，同時如果在傳遞過程中丟失信息，甚至可能導(dǎo)致故障發(fā)生。
這些規(guī)則都是由企業(yè)制定的，但事實上，在交付端的職員從未去認(rèn)真地去理解這些政策的語義，他們通常根據(jù)想象或者習(xí)慣去判斷。而隨著時間推移，工具和流程往往發(fā)酵成無效率的官僚機構(gòu)。
基于應(yīng)用或客戶類型，通常會形成不同的限制規(guī)則。當(dāng)涉及到如何縮短交付周期時，這些差異應(yīng)該納入考慮，因為它能幫助你發(fā)現(xiàn)究竟誰可以做出更改，以及修改該如何進行。
除了主動理解規(guī)則，規(guī)則同樣需要做到快速和便捷地審校：
簡單易懂的規(guī)則能清晰展現(xiàn)以下內(nèi)容：
- 誰做出了變動以及是否有權(quán)限
- 改變應(yīng)用在哪里
- 具體的改變內(nèi)容，這些調(diào)整是否能接受
這種查詢應(yīng)該能即時訪問，而不是在某個事情后(比如故障發(fā)生)通過人工收集得到。當(dāng)你拿到服務(wù)器過去24小時的工作報告時，便能輕而易舉了解到環(huán)境中發(fā)生了哪些變化。
這些審計視圖應(yīng)該包含基礎(chǔ)設(shè)施和工件信息，因為不管是開發(fā)者還是運維人員都想清楚軟件和服務(wù)器的信息，一堆不明所以的修改信息和錯誤鏈接報告無論如何也無法組成一張全景圖。
如何開放訪問又不會失去控制?
通過審視軟件交付的整個過程工作流全時監(jiān)控將變得簡單，在以往這個工作通常由一個獨立的團隊完成，他們往往以往競爭優(yōu)先級導(dǎo)致的上下文切換而變得沒有效率，這種情況通常在運維團隊發(fā)生。運維團隊需要平衡來源于應(yīng)用開發(fā)團隊的工作(例如，參與敏捷開發(fā)沖刺)、網(wǎng)絡(luò)操作(例如，處理中斷和生產(chǎn)問題)、企業(yè)用戶(例如，收集信息用于控制策略)。***，運維還需負(fù)責(zé)維護或改善基礎(chǔ)設(shè)施等項目工作。
為了釋放這個流程的瓶頸，企業(yè)必須發(fā)掘應(yīng)該如何重新分配工作，或者建立一個自服務(wù)流程。因為部署、配置和監(jiān)控都是需要設(shè)計到應(yīng)用中的運維問題，一次需要將之一定程度地傳遞給開發(fā)人員。聚焦這一系列動作，運維團隊需要維護一組基本的自動化模塊，給開發(fā)人員相應(yīng)方法來參與。創(chuàng)建一個開發(fā)環(huán)境和工具允許開發(fā)人員在自己的沙箱中將所需的改變整合到這個框架中。通過自助服務(wù)界面讓開發(fā)人員可以便捷地創(chuàng)建托管環(huán)境，打開 VMs 或者容器，允許他們測試運維管理代碼。
給運維管理框架構(gòu)建合規(guī)的審計日志，便能跟蹤到哪些資源被創(chuàng)建和使用。一旦資源發(fā)生沖突，這些日志將會有非常大的幫助，并讓你了解到哪里需要更多的沙箱或者哪些更細(xì)粒度的配置需要定義。
欲速則不達，速度越快反而導(dǎo)致質(zhì)量下降?
對于企業(yè)來說，不斷提升創(chuàng)新速度才能保持競爭力，所以速度至關(guān)重要。因此這里需要更快的軟件交付速度，也正是采用 DevOps 做法的主要動機。
許多 DevOps 成功案例都在展示其一天能部署多少次，10還是1000。但是在現(xiàn)實世界中，這些指標(biāo)簡可以稱得上是神話。有些企業(yè)盡量一個月實現(xiàn)一次部署，還有些企業(yè)一個主要版本更新需要按年計算，而發(fā)布給用戶更需要30天的時間。這三十天的滯后時間，同時生產(chǎn)環(huán)境處于不一致的狀態(tài)，所有人都難以應(yīng)付生產(chǎn)中出現(xiàn)的問題?！甘切掳姹具€是舊版本造成了這個尚未確定的問題?」操作無法加快的一個主要原因是無法確定問題究竟是發(fā)生在改變期間或改變后。
當(dāng)改動導(dǎo)致問題，可能導(dǎo)致以下結(jié)果：
- 添加更多控制過程(審批門檻更多，改動窗口更小)
- 改變批次變大(更多的工作塞到給定的變化窗口)
- 增加「緊急修正」(高優(yōu)先級功能得到快速跟蹤，才能避免正常的變化流程)
- 因為批系統(tǒng)和非正常軟件發(fā)布流程，應(yīng)用程序快速更新將帶來很大壓力
鑒于以上后果，加快改變速度的想法顯得不切實際，因為它確實可能誘發(fā)更多的問題。
問題是企業(yè)該如何快速給系統(tǒng)做更新?首先，指定更新過程中的安全策略非常重要。快速轉(zhuǎn)變意味著能安全地快速改變。下面是一些常見策略：
小批量
大批量改變所帶來的工作量需要耗費大量的人力和時間。
解決辦法是利用這種策略：變化越少越容易實現(xiàn)，完成后也便于檢查。
預(yù)演
這里有一個很好的諺語，「Don’t practice until you get it right. Practice until you can’t get it wrong」。當(dāng)然，你不能在生產(chǎn)環(huán)境中實踐這個途徑。將更新應(yīng)用到生產(chǎn)環(huán)境之前，你應(yīng)該在非生產(chǎn)環(huán)境下進行多次實驗。不要依賴于運氣，要抱著必然存在故障的理念。
可核查的流程階段
不管是新建立的一個網(wǎng)站或者是現(xiàn)有應(yīng)用程序需要更新，請確保已經(jīng)為先決條件做好了足夠的檢查。也就是說，如果你要部署一個應(yīng)用，在這之前你就要準(zhǔn)備好腳本測試，來證實你的外部或環(huán)境依賴性。如果你正在構(gòu)建一個網(wǎng)站，在安裝操作平臺之前，保證你已經(jīng)確認(rèn)好硬件和網(wǎng)絡(luò)環(huán)境。在流程階段邊界構(gòu)建這種自動化測試，對于防止問題遺漏是一個巨大的安全保障。你可以使用這些驗證檢查來決定「stop the line」。
流程規(guī)則
是什么導(dǎo)致了環(huán)境中布滿了特殊定制的服務(wù)器和網(wǎng)絡(luò)?缺少規(guī)則。如果企業(yè)無法統(tǒng)一管理變動，每個人都會按自己的方式行事。那如何對流程進行管控?搜尋所有不同的版本。如果流程在兩個版本中不同，那么就意味著這里存在一個 variation。流程 variation 意味著流程失控。有兩個簡單的度量可用于了解你對流程控制的程度：交貨時間和報廢率。交貨時間代表改變所需的時間。廢品率是返工頻率。預(yù)演和可核查的流程可以通過降低廢品率和穩(wěn)定交貨時間幫助獲得控制過程。流程管控的***好處是提高可預(yù)測變化的能力。業(yè)務(wù)依賴于這種可預(yù)測性?？深A(yù)測性的業(yè)務(wù)可以提前規(guī)劃移動速度的快慢。
更多途徑進入運維管理環(huán)境?
每個人都更好地了解生產(chǎn)中各部分是如何執(zhí)行的，可以幫助企業(yè)設(shè)計更好的系統(tǒng)來支持業(yè)務(wù)。如果開發(fā)人員或測試人員都難以發(fā)現(xiàn)服務(wù)運行的問題，只會耽擱有利于用戶操作的改進。讓任何人都能容易地了解到應(yīng)用版本在主機是如何部署的，以及主機配置和應(yīng)用程序的性能。
有時數(shù)據(jù)隱私規(guī)則使得數(shù)據(jù)訪問并不那么直接。一些日志包含客戶數(shù)據(jù)和規(guī)則可能限制有限的用戶訪問。不要說「沒有」或手動地去收集和清洗，這里需要存在一個自動化的自服務(wù)，從而讓開發(fā)者或?qū)徲嬋藛T可以自己獲取。
生產(chǎn)環(huán)境的可見性對于開發(fā)人員來說是至關(guān)重要的，從而他們可以建立一個類似的環(huán)境。模擬聲場環(huán)境建模開發(fā)和測試環(huán)境是減少變數(shù)并讓一切都在控制中的有效手段。
這是否意味著允許開發(fā)者進行 Shell訪問?
這個問題是傳統(tǒng)企業(yè)運營團隊的弊病。通常這個問題是另一個問題的征兆。為什么一個開發(fā)者要 Shell 訪問運維支持的環(huán)境?在開發(fā)或早期的測試環(huán)境下，開發(fā)人員可能需要Shell訪問來實驗開發(fā)部署和配置代碼。這的確是申請 Shell 訪問的一個合理理由。
這是臨時或生產(chǎn)環(huán)境中 Shell 訪問的請求嗎?Shell 訪問請求可能是即席改變方法的一個標(biāo)志，從而改變一個環(huán)境的穩(wěn)定性。因此，對改變方法進行自動化封裝非常重要。
歸根結(jié)底，Shell 訪問生產(chǎn)環(huán)境確實有很大的風(fēng)險。
