原文地址：
https://medium.com/@jeehad.jebeile/devops-and-segregation-of-duties-9c1a1bea022e
原文作者：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 - https://martinfowler.com/bliki/BlueGreenDeployment.html
這裏的要點是， 不要等到軟件被認爲是完美的才允許發佈。 在具有 kill-switch 機制下我們允許所有版本投入生產，因爲在需要時我們可以快速恢復服務。所以我們強調快速恢復，而不是試圖去避免（不可避免的）失敗。
譯者注：常見的帶有故障恢復效果的部署策略還有灰度發佈／金絲雀發佈，通過將更改先推廣到一小部分用戶，然後將其推廣到整個基礎架構並使其可供所有人使用。以保障整體系統穩定的情況下，儘早發現、調整問題。參考：https://martinfowler.com/bliki/CanaryRelease.html
總結一下
在軟件交付控制方面，職責分離應該是最後的手段。除非失敗可能導致生命損失，或者監管機構強制要求，否則如果你希望獲得 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 幫助您控制每一次從引入代碼變更到發佈的整個過程，從而更好地優化軟件交付的速度和質量。