DevOps 文化中的合規

何時使用

如果要測量的屬性集很小、版本發布不頻繁且回應很簡單，這可能是一個簡單且容易的流程。為小規模合規流程實施此流程不需要大量資源或時間投資。它可以像建立一個 Google 表單一樣簡單，讓團隊完成並提交。通常，此類型的實施還包括手動檢閱流程，通常實施為與檢閱會議相關的正式核准。

隨著組織規模擴大，此流程可能會很快變得痛苦。由於工作量和複雜性增加，額外的規模會產生多面向的挑戰。

容量挑戰來自於組織規模擴大所推動的工作量增加。隨著組織的成長，合規流程的運作容量必須成比例地增加，以處理合規核准的額外請求。由於部署核准請求的隨機性，流向中央合規團隊的工作量變化很大，因此很難為中央團隊的快速回應調整規模。隨著組織的成長，這個問題會被放大。

隨著組織規模擴大，複雜性挑戰隨之而來，產生新的且令人興奮的故障模式，進而推動合規程序的變更。合規表單的規模和複雜性日益增加，需要開發團隊和合規團隊投入更多時間和精力才能完成程序。

當合規程序顯示出其在規模上的低效率時，可能會出現二階效應，並開始成為開發團隊能多快提供業務價值的限制因素。

團隊可以透過將部署中的變更分批處理，專注於成本效率，以便開發要發布的價值的工作佔部署這些變更到生產環境所需的總成本的顯著比例。

合規程序的領先時間也會決定批次大小，因為合規辦公室的工作容量限制了在特定時間段內可以處理的部署請求數量。在部署數量受限的情況下，增加交付給客戶的價值的唯一方法是增加批次大小。

如果合規辦公室超載（無論出於何種原因），那麼等待合規結果的團隊佇列就會增加 - 合規程序本身就是限制價值交付的瓶頸。通常，交付的壓力會壓垮合規程序，而開發團隊會積極濫用、破壞或完全迴避合規程序，導致「影子 IT」、受損的設計和架構決策，甚至偽造合規回應。

我們在商業和政府領域的組織中都見過所有這些行為。我們見過手動合規程序，在現實中需要 6-9 個月才能完成，然後才能將新服務或系統部署到生產環境。在另一位客戶中，我們能夠證明他們的程序不僅限制了組織可以交付的速度和規模，而且該程序在其應用和結果方面高度不一致。

不幸的現實是，我們的經驗表明手動合規程序是一種「安全戲劇」，導致價值交付延遲，而系統的安全性和安全性並未實質增加。我們還看到這些程序對交付程序以外的影響不成比例，影響組織結構、架構決策、網域邊界，甚至人員配置和人才保留。

何時使用

顯然，合規性測試的自動化對合規性辦公室和團隊中的開發人員來說都是一大好處。

合規性辦公室可以確信適當的合規性適用性功能正在執行，而且管線記錄可以提供記錄適用性功能執行和結果的稽核追蹤。團隊可以將注意力集中在提供業務價值，而不是透過確保管線執行所需工作來把關個別變更。

團隊中的開發人員可以更快收到有關系統版本是否符合合規性需求的回饋（至少對於已自動化為適用性功能的需求），因為管線失敗表示未符合合規性。

在同質開發環境中，每個團隊都使用相同的堆疊，建置大致相同的系統類型（例如，REST 服務等），團隊可以透過複製標準管線來實現效率提升。至少，在同質環境中分享相同的合規性適用性功能將產生規模經濟。

組織對生產環境失敗的常見回應是向部署程序新增手動驗證步驟。舉例來說，適用性功能可能會定義為「所有工作已完成且有回滾計畫」，團隊經理和安全人員必須手動驗證。這並非理想，因為它會導致一個工作佇列，而這個佇列名義上由對系統負責的角色負責，但實際上並未負責（例如，熟悉）他們核准的變更。[2] 最終結果是額外的延誤，但系統的安全性或穩定性並未具體改善。

另一個典型的反應是希望鎖定管道以保證相容性。這可能會發生在製作過程中出現一些故障時，也許可以追溯到團隊特定偏離標準管道的行為。組織將管道相容性流程的責任轉移到一個中央團隊，目的是透過同一個「黃金」管道引導每個團隊的系統發布。

我們的經驗顯示，由於團隊管道中變更的頻率很高，因此管道的中央所有權是開發過程中最大的摩擦來源之一。這種集中化導致開發整體速度變慢，因為中央團隊已成為限制團隊演進其系統的瓶頸。

第二階效應類似於手動解決方案：「影子 IT」、受損的設計和架構決策，或在未更新相容性管道的情況下部署到製作環境。

我們知道有案例是基於明確希望減慢發布速度而做出此類中央「所有權」決策。儘管不常公開說明，但組織已意識到更頻繁的發布通常會暴露其開發流程中的系統性不成熟。轉移到中央控制通常是試圖將交付品質的責任從工程和開發團隊轉移到相容性組織。

隨著時間推移而產生的摩擦程度難以低估。管道存在的主要原因是提供軟體開發流程中的中央工具。當它被挪用，然後受到正交目標控制時，開發人員的疑慮往往會根據管道團隊（通常是 DevOps 團隊）的人員配置、組織、激勵和營運方式而降低優先順序。

何時使用

對於需求符合建構模組功能的團隊來說，這是一個很棒的解決方案。「黃金映像檔」代表業務或技術功能，否則團隊必須實作這些功能，而且這些映像檔已經通過相容性要求。例如，仰賴黃金 PostgreSQL 映像檔表示團隊不需要思考如何設定備份/還原、資料庫調整、部署、記錄或運作考量。所有這些活動都已作為通過相容性的 PostgreSQL 建構模組的一部分完成。

假設有成熟的建構模組集合、同質的開發環境和變異性低的業務需求，這可以透過避免許多開發團隊重複工作來提供效率提升。

當這些基本假設和限制遭到破壞時，與組件組合策略相關的摩擦就會出現。任何需要超出現有「黃金映像」範圍之外功能的產品開發，也需要開發團隊為其系統的這些「非黃金」組件經歷相同的繁重合規程序。有些團隊可能會認為這樣做會帶來相當大的時程風險，這可能會對系統的架構和設計造成不當的影響。

此外，這是一個滑坡；在滑坡的底部，組織並不會更好，因為每個團隊都在為自己的特殊情況解決方案管理合規性。有人可能會爭辯說，使用合規映像作為自訂的基礎，會將合規工作限制在增量變更上。然而，由於這些共用的「基準」映像，跨團隊的耦合會增加。合規的單位仍然是整個映像，因此隨著時間推移，合規的邊際成本可能比人們想像的要大。

當管道集中時，將責任轉移給中央團隊以提供合規映像，具有與上述完全相同的特徵。

由於組件組合解決方案顯示其在規模上的低效率，它也開始成為開發團隊可以提供業務價值的速度限制因素。二階效應與手動和基於管道的解決方案類似：「影子 IT」、受損的設計和架構決策，或部署到未通過合規要求的生產組件。

我們觀察到，根據組織的規模，遵循此模式的系統中存在不同的行為。在小規模或實施此模式的早期階段，很容易找到具有相似需求的團隊，在這些團隊中，依賴合規構建模組的經濟效益顯而易見，並可為團隊提供加速。然而，超過某個規模後，所提供的解決方案的需求就會出現分歧，導致團隊無法依賴合規構建模組時，摩擦的來源會變得熟悉。

注意：我們故意迴避合規性是否實際上可以針對一組合規容器映像進行組合分配的問題。假設這是真的，它可能只對具有零自訂能力的確切容器映像成立，這反過來又可能將解決方案空間限制到無法提供實際效用的程度。我們鼓勵您仔細思考在組合合規性的範圍內，相對於您的使用案例，可以實現哪些類型的可組態性。

何時使用

此解決方案有助於將先前所述解決方案中存在的瓶頸降至最低。與上述解決方案相比，它本質上更為複雜，因此可能僅限於組織規模會產生此方法能夠解決的瓶頸類型的環境。

透過區分合規性的考量，我們可以達成避免與集中管理合規性方法相關的摩擦所需的鬆散耦合。團隊可以選擇採用集中提供的管道控制組，同時仍然能夠有效率地自行管理團隊可能有的任何獨特需求。

如果合規性限制經常變更，組織可以有效率地確定對現有系統的影響，減少規劃工作並簡化實作流程。由於應用量測測試收集證據的流程並未變更，因此政策即程式碼原則可保護團隊免於額外的作業。

由於合規性流程的所有輸入都基於資料和組態，稽核流程會大幅簡化。在任何特定時間點，都可以透過查詢 SoR 來取得證據組和驗證流程的結果。

如上所述，由於考量區分，此解決方案會稍微複雜一些。然而，複雜性適當地存在於合規性辦公室中，而不是委派給組織中的每個開發團隊。

必須明確解決流程中的信任問題，作為 SoR 和相關機密金鑰管理的一部分，而這必須由合規性辦公室管理。雖然在新的量測測試的核准流程中存在熟悉的瓶頸，但這些瓶頸的範圍較為有限，因為個別工作項目（例如，就量測測試的適當性達成協議）顯著較小，而且不會顯著阻礙團隊進行開發。

仍然有「影子 IT」或部署到尚未通過合規性需求的生產元件的風險。然而，受損的設計和架構決策的風險會大幅降低。

我們已為多個客戶實作此模式多年。對於一個大型企業組織，我們實作了一個自訂的准入控制器，以確保符合部署需求、安全性及證書，使用提供已掃描 CVE 的容器的受信任容器登錄，並驗證適當文件的存（或建立）在。在另一個組織中，我們實作了類似的功能，除了整合一個政策即程式碼解決方案，在部署前對 Kubernetes 組態執行 CIS Benchmark 測試。