[譯] DevOps VS 職責分離

原文地址：
medium.com/@jeehad.jeb…
原文做者：Jeehad Jebeile
翻譯君：CODING 戴維奧普斯

在國內很多的研發組織依然經過職責分離的方式來管理研發團隊，這種狀況下就會形成團隊之間合做效率低下、責任互相推諉等問題。咱們翻譯瞭如下這篇文章來與讀者們一塊兒探討 DevOps 與職責分離究竟該如何結合在一塊兒，從而更好地提升研發團隊的效率。

引言

如何把 DevOps 與職責分離完美地融合在一塊兒？

DevOps 和職責分離（SoD：Segregation of Duties）一般不會相提並論。DevOps 旨在消除障礙並最大限度地減小交接，而職責分離則是經過增長隔離以最大限度地下降風險。

在受到高度監管的行業（如金融、醫療保健）工做時，採用 DevOps 工做方式來運做團隊可能很是具備挑戰性。這是由於監管機構但願只有通過請求、批准以及充分測試的變動才能進入生產環境。在這些狀況下，主要的控制方式其實是職責分離。

職責分離

什麼是職責分離？

職責分離（SoD）是不止一人來完成任務的概念。在商業中，經過在一個任務中經過多我的來實現分離是一種旨在防止欺詐和錯誤的內部控制方式。
—— 維基百科

在軟件工程領域，這基本上意味着開發代碼的人或團隊沒法批准他人或者本身部署代碼。 這是爲了防止意外或惡意將未經受權的代碼發佈到生產環境中。

相比之下，DevOps 是將開發和運維兩個分離的功能合二爲一。一個團隊同時能夠開發和測試代碼，還支持部署代碼。隔離，意味着將人或者事物從主體中剝離出來，這仍然是目前常見的控制生產環境的方法之一。

在 DevOps 團隊中實行職責分離的缺點是什麼？

• SoD 會經過添加沒必要要的切換來下降團隊速度，而且可能會引入錯誤。每次發生切換時，都須要進行信息傳遞，這不只會下降速度，還可能會致使信息傳遞有誤。交接不只會影響變動的部署，還會影響生產環境中緊急事件的處理。在這種狀況下，處理事情的責任人最好是能更好地響應事件而不是負責變動的人（或團隊）。
• 職責分離代表對團隊缺少信任，這滋長了「恐懼」文化的培養。DevOps 團隊須要自主，以得到這個理念所宣揚的所有價值和速度優點。爲了實現這種自主權，團隊須要始終被信任他們正在作正確的事情。在他們作錯事的時候，依然會被要求負責並糾正錯誤。請記住，能力越大，責任就越大。
• SoD 沒法解決與共同決策有關的問題。這涉及到有人（或團隊）故意將未經受權的變動推向生產，不管他們是出於惡意仍是出於緊急狀況來企圖破壞這過程。例如，他們會說：「咱們沒有時間進行完整的迴歸測試，由於咱們須要明天發佈，你能不能立刻簽名？」。不管有多少控制措施，你都沒法擺脫這個問題。

若是你別無選擇，只能實施 SoD 該怎麼辦？

正如文章開頭中所提到的，有一些受到高度監管的行業不容許 DevOps 團隊徹底自主地工做。若是你發現本身遇到這種狀況，如下是你的團隊應該關注的一些事項。

最大限度地減小交接次數

DevOps 的主要原則之一是改進你的工做流，以便執行任務的效率是最高的。在 DevOps 中，重點一般是 SDLC（即 CI/CD），但其實最小化切換能夠應用於團隊中的大多數流程。在最開始，須要首先經過確認工做流之間的相關性來評估現有流程；隨後，你能夠經過簡化流程來得到實現目標所需的最少步驟數。肯定新的工做流後，你能夠加上自動化了。但要記住， 即便自動化很重要而且一般也是一個好主意，但自動化一個糟糕或者冗餘的流程是沒有任何意義的。因此先確認工做流，優化它，而後自動化。
譯者注：SDLC（systems development life cycle）即系統發展生命週期，也稱軟件生命週期，用於描述一個信息系統從規劃、建立、測試到最終完成部署的全過程。

自動化

自動化你的構建、測試和部署。經過自動化交付流水線，你能夠最大限度地下降人爲錯誤致使的風險。

• 持續集成： 是一種開發實踐，須要開發人員天天屢次將代碼集成到共享代碼存儲庫中。而後經過自動構建和單元測試過程驗證每一個簽入，可讓團隊儘早發現問題。
• 持續交付： 是持續集成的天然延伸：團隊確保對系統的每次更改都是可發佈的，而且咱們只需按一下按鈕便可發佈任何版本。持續交付旨在使發佈成爲一件無聊的事情，咱們能夠常常快速交付而且快速獲得用戶的反饋。
• 持續部署： 在以上環節準備好後可當即自動部署某個版本的代碼，進一步擴展了持續交付。

即便最終生產環境的部署須要由另外一我的或團隊完成，你也能夠實現持續交付，至少可讓研發組織在最快的時間內達到生產環境就緒狀態。

刪除外部依賴項

消除對外部團隊的依賴，並嘗試在團隊中保留全部審批權力。擁有外部依賴關係，例如須要特定利益相關方的批准，或者讓另外一個單獨的團隊執行部署會下降流程的速度。這並非說應該跳過或忽略這些操做，但應該可以由本團隊成員完成。再次回到 DevOps 原則， 團隊應該包括全棧或 T 型開發人員，他們能夠出如今須要執行團隊各類任務的地方。

消除這些外部關係的主要緣由是，與團隊以外的人員相比，與團隊中的人員溝統統常更容易。另外，團隊中的人員知道發生了什麼以及須要作什麼，無需上下文的解釋。這兩個好處都將會提升團隊的速度。

若是您沒法刪除依賴關係，請查看是否能夠考慮將相關人員添加到你的團隊中。 例如，若是你須要公司業務利益相關方在部署以前批准你的發佈，看看你是否可讓你的產品負責人（即 PO）來表明業務方執行此功能。這樣的話 SoD 依然存在（由於 PO 一般不直接參與特性的開發）而且團隊再也不依賴於團隊以外的人。

實施安全網比控制重要

維持高水平的風險規避：最大限度地減小交接並實現快速交付的最佳方法之一是實施安全網，而不是控制。這是什麼意思呢？

在馬戲團中，當空中飛人藝術家表演他們的雜技表演時，他們一般會經過安全網來進行防禦。另外一種方法是將他們連到安全帶上，但這顯然會限制他們的運動。另外一方面，安全網容許他們儘量流暢高效地運動，並確保若是出現問題而且碰巧掉落，他們可以安全地落入網中並避免受到嚴重傷害。

別誤會個人意思，在時間和地點上確定須要控制。例如，在航班起飛前進行例行檢查，而且在每次起飛以前都要強制檢查，由於在這種狀況下咱們不能承受任何重大事故，失敗的結果將是毀滅性的。不只是由於物質成本高（飛機並不便宜），更重要的是，生命是無價的。

對於構建軟件的人來講，在大多數狀況下，若是軟件失敗，人們並不會所以失去生命。所以，在這些狀況下失敗是容許的， 只要你能夠「安全地」失敗，快速恢復並從失敗中吸收教訓，以便不會再重複這樣的失敗。

在軟件開發方面， 安全網包括對生產環境的質量系統監控。 這容許團隊瞭解系統的當前狀態以及在用戶作出響應以前處理突發事故或者避免事故產生。在發生重大事故時，可以經過快速回滾來恢復服務，例如 藍/綠部署是另外一種能夠應用的安全網。

藍/綠部署

這種技術是一種衆所周知（但利用不足）的雲模式，用於最大限度地減小發布的停機時間，並在出現問題時提供快速回滾方式（即安全網）。

Martin Fowler（敏捷宣言的最初共同創造者之一）解釋以下：

自動化部署的挑戰之一是切換自己：將軟件從測試的最後階段帶到生產環境當中。你一般須要快速執行此操做以最大限度地減小停機時間。藍/綠部署經過確保你擁有兩個儘量相同的生產環境來實現此目的。在任什麼時候候，其中一個，例如藍色指的是生產環境。在準備軟件的新版本時，您將在綠色環境中進行最後的測試階段。一旦軟件在綠色環境中工做，您就切換路由，以便全部傳入的請求都進入綠色環境，同時藍色環境處於空閒狀態。

藍/綠部署還爲你提供了快速回滾方式，若是出現任何問題，您能夠將路由切換回藍色環境。

—— Martin Fowler - martinfowler.com/bliki/BlueG…

這裏的要點是， 不要等到軟件被認爲是完美的才容許發佈。 在具備 kill-switch 機制下咱們容許全部版本投入生產，由於在須要時咱們能夠快速恢復服務。因此咱們強調快速恢復，而不是試圖去避免（不可避免的）失敗。

譯者注：常見的帶有故障恢復效果的部署策略還有灰度發佈／金絲雀發佈，經過將更改先推廣到一小部分用戶，而後將其推廣到整個基礎架構並使其可供全部人使用。以保障總體系統穩定的狀況下，儘早發現、調整問題。參考：martinfowler.com/bliki/Canar…

總結一下

在軟件交付控制方面，職責分離應該是最後的手段。除非失敗可能致使生命損失，或者監管機構強制要求，不然若是你但願得到 DevOps 原則和實踐的最大好處，則應避免職責分離。話雖如此，若是你被迫在團隊中使用 SoD，那麼實現如下技術將容許你成功實現 DevOps ，即便不是完美地實現 DevOps。

• 最大限度地減小交接次數：經過最小化步驟數和所需人員來優化你的工做流。
• 自動化：自動化一切，但必須得在你確認好自動化的內容以後。請記住，持續集成、持續交付和持續部署，這些都是你良師益友。
• 刪除外部依賴項：與團隊中的人合做更容易，所以請刪除或儘可能減小外部依賴項。
• 安全網控制：故障恢復，而不是試圖徹底避免故障。

譯後記

做者在文中很是強調自動化的實踐，而且強調了，若是須要進行嚴格的權責分離（這是許多中國團隊面臨的實際問題），更加須要依賴於自動化，以減小效率的損耗。這與 CODING 的理念不謀而合。咱們也認爲自動化能幫助研發組織解放研發效能。

CODING 的持續集成和製品庫幫助你輕鬆搞定自動化流水線，實現軟件的快速交付。CODING 持續集成（CCI）全面兼容 Jenkins 的持續集成服務，支持 Java、Python、Node.js 等全部主流語言編譯環境，而且支持 Docker 鏡像的構建。只要幾步配置，就能夠開啓 Git 代碼倉庫的持續集成。構建產物還可經過 CODING 製品庫進行統一管理。目前 CODING 支持 Docker Image、Maven/Jar、Kubernetes Helm、Node.js NPM 包等常見軟件包類型。

CODING 幫助您控制每一次從引入代碼變動到發佈的整個過程，從而更好地優化軟件交付的速度和質量。