【寫在前面】筆者曾幫助多家大型企業深入了解 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 通路生産環境确實有很大的風險。
本文作者：oneapm 工程師
來源：51cto