企業運營對 DevOps 的「傲慢與偏見」

摘要：出於各類緣由，並不是全部人都信任 DevOps 。有些人以爲 DevOps 只不過給開發者改善產品提供了一個途徑而已，還有的人以爲 DevOps 是一堆悅耳的空頭支票，甚至有人認爲 DevOps 根本沒法採用。

【編者按】近日，Alex Honor 在 Dev2ops 上撰文闡述了當下企業對 DevOps 所存在的偏見，並就形成這些問題的緣由分享了企業該如何向 DevOps 模式切換，本文系 OneAPM 工程師編譯整理。

筆者曾幫助多家大型企業深刻了解 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 訪問生產環境確實有很大的風險。

原文連接：http://dev2ops.org/2014/06/adopting-devops-in-enterprise-operations/

本文系 | 31a86d24833cfae285650a96be0588874 | 工程師編譯整理。想閱讀更多技術文章，請訪問 OneAPM 官方博客。