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