介紹

隨著各大企業在 2024 年加速采用云計算，基礎設施即代碼 (IaC)、策略即代碼 (PaC) 和優化即代碼 (OaC) 已成為成功實現云遷移、IT 現代化和業務轉型的關鍵功能。

讓我在云計劃的背景下全面了解這些代碼功能的當前狀態。我們將研究現代云基礎設施趨勢、IaC、PaC 和 OaC 在云采用中扮演的角色、當前的工具和模式、集成方法、衡量結果、要避免的陷阱以及未來的道路。

加速云采用

云計算已成為大多數企業構建和部署應用程序的事實上的方法。超過 85% 的組織將采用多云或混合云策略。組織還發現，遷移到云可以通過技術轉型實現更深層次的業務轉型。

隨著云應用的加速，基礎設施的復雜性和規模正在達到新的高度。組織正在管理數據中心、公共云、邊緣環境和物聯網中不斷膨脹的資產庫存。這種異構性需要新的基礎設施管理策略，同時增加了與成本、合規性、可靠性和性能相關的風險。

企業面臨的云挑戰

盡管勢頭強勁，但遷移到云對許多企業來說仍然具有挑戰性。常見的陷阱包括缺乏技能、規劃不足、不了解云經濟、安全漏洞、供應商鎖定以及無法重構遺留應用程序。

組織在初始遷移后也難以快速迭代，因為隨著時間的推移，基礎設施會逐漸走向優化不佳或不合規的狀態。隨著云在企業中的使用范圍不斷擴大，這些挑戰變得越來越嚴重。

解決這些問題需要制定云采用策略，而不僅僅是一次性遷移工作。領先的團隊采用持續的實踐來優化基礎設施、管理環境和實現交付現代化，以持續滿足云目標。

IaC、PaC 和 OaC 在云成功中的作用

基礎設施自動化很早就成為大規模采用云的必要條件。隨后，嵌入策略護欄和推動持續優化的做法也變得同樣重要。

基礎設施即代碼 (IaC) 允許團隊以模板化、可共享的方式通過代碼定義整個應用程序環境。IaC 對于高效地按需部署和復制資源至關重要。

策略即代碼 (PaC) 將基礎設施配置和變更的規則嵌入到代碼中。這可以大規模、高速地管理云的使用，而緩慢、容易出錯的手動策略方法無法跟上云的步伐。

代碼優化 (OaC) 專注于將數據驅動的運營改進嵌入到基礎設施自動化流程中。指標、分析和部署之間構建良好的反饋循環可創建“自我優化”的云環境。

這些代碼功能使我們能夠快速擴展云使用量，同時保持嚴格的治理和卓越的運營。那些以緊密集成的方式利用 IaC、PaC 和 OaC 的人將獲得最高的云成功。

云環境中 IaC 的狀態

幾年前，IaC 的采用已達到主流地位，Terraform、CloudFormation 和 Ansible 等工具迅速成為行業標準。基礎設施管道和 GitOps 等成熟模式將 IaC 代碼直接集成到應用程序交付流程中。領先的云咨詢公司現在將 IaC 功能作為其產品的核心，意識到這些功能是企業級云轉型成功的關鍵。

多云和管理層影響

隨著云應用的加速，一個關鍵趨勢是企業越來越多地使用多云架構和管理層。企業經常使用跨 AWS、Azure 和 GCP 的混合環境來避免被鎖定在單一供應商。新的工具已經出現，以促進跨目標云的無縫 IaC。

流行的多云 IaC 選項包括 Terraform、Pulumi、Ansible 和其他開源工具。多云管理的主要參與者包括 HashiCorp、RedHat、VMware、Datadog 和 AHEAD。原生提供商也提供了跨云的一些可移植性。

企業通常難以通過 Terraform、CloudFormation 等直接定制云，而是通過 IaaS 實現 VMware Cloud Foundation 或 Datadog Cloud Security Platform 等管理層。這些構建了更高級別的抽象，同時實現了跨環境的統一策略和自動化。

基礎設施測試困難

雖然核心配置功能已經相當成熟，但用于驗證和測試的 IaC 工具仍然不一致。根據安全性、合規性和架構標準驗證實施仍然通常很慢且需要手動操作。

這會導致配置在大規模復雜環境中使用時，隨著時間的推移偏離所需規格的風險。致力于完善測試工具并將自動驗證檢查直接嵌入基礎設施管道的專門工作正在不斷擴大。

集成 IaC 測試

盡管 DevSecOps 集成取得了一些進展，但在許多 IaC 項目中，測試代碼質量和基礎設施結果仍然脫節。領先的團隊現在將測試自動化和斷言推向上游代碼存儲庫，并在部署前后針對云資源進行下游測試。

HashiCorp Sentinel、InSpec、Terraform Compliance 和 Amazon Inspector 代表了嵌入式 IaC 和云測試方面的進步。Checkov 提供針對安全配置錯誤的基礎設施掃描。新興模式包括“基礎設施單元測試”和適用于 IaC 源代碼的 CI/CD 樣式管道。

基礎設施漂移檢測

相關的挑戰是，隨著變化的積累，基礎設施會隨著時間的推移偏離所需的配置基線。像 AWS Config Rules 這樣的原生工具可以檢測 AWS 資源的偏差，通常用于 PaC 實施。對于多云/混合環境，Dome9 Continuous Compliance 等工具會根據 CIS Benchmarks 等策略框架評估配置。NetApp 和其他公司提供跨資產的代理來檢測細粒度的狀態變化。

協調聲明式 DSL 與命令式 DSL

IaC 語言使用聲明式（Terraform、CloudFormation）或命令式 DSL（Ansible、Docker、Puppet）。每種方法在抽象能力和排序需求方面各有優缺點。集成挑戰圍繞狀態管理和排序組合使用而存在。

HashiCorp Terraform Cloud 和 RedHat Ansible Automation Platform 代表了領先的商業解決方案，可在 IaC 工具中提供集成的工作流程。開源選項（如 Terraform 的 null 配置程序或 Ansible 調用 Terraform 模塊）可在技術之間提供更輕量的橋梁。

云安全和合規性的 PaC 現狀

將策略直接嵌入到基礎設施自動化流程中已成為以企業規模和速度準確管理云使用情況的唯一方法。單個云提供商的策略累積問題也需要跨環境分析的工具來消除差距或沖突。

主要的云原生 PaC 解決方案

AWS、Azure 和 GCP 現在具有強大的本機 PaC 功能，可用于管理安全性、訪問、成本和合規性。AWS 提供用于評估的 Config 和用于實施的 Guardrails。Azure 通過 Azure Sentinel 提供帶有合規性儀表板的 Blueprint 和 Policy。GCP 包括 Org Policy 管理和用于最小特權實施的 Access Context Manager。

多云 PaC 可降低風險

第三方策略工具覆蓋在原生選項之上，以集中控制和查看各種云變體。例如，Rebar Enforce 可應用自動化策略護欄，管理任何環境的成本、安全性和運營約束。Fugue 和 Blue Hexagon 等其他解決方案專注于降低跨多個平臺的云安全風險。Lacework 等威脅檢測工具可在復雜的混合環境中提供對漏洞和錯誤配置的統一查看。

使用 PaC 實現合規自動化

內置審計數據收集、持續合規性監控和自動證據收集功能也已顯著成熟。例如，CloudTruth 和 LogicHub 等工具可自動驗證 SOC2、ISO 27001、PCI DSS 和 HIPAA 等標準的控制。集中式合規性解決方案可減少使用分散的本機工具時遇到的審計疲勞。

將 PaC 集成到策略生命周期中

盡管工具不斷創新，但許多組織仍然面臨政策無序擴張、申請豁免流程效率低下以及問題補救緩慢等問題。要應對這些挑戰，需要 PaC 工具與上游生命周期階段（包括通常通過 ITSM 平臺協調的申請、批準和補救工作流）之間實現更大程度的集成。

例如，ServiceNow 的 Safeguard 為整個策略生命周期覆蓋了流程自動化。其他 ITSM 供應商提供成熟的云治理模塊，包括 BMC Helix 和 Cherwell。ShiftLeft 提供 GitHub 集成，用于將安全策略門直接嵌入開發人員工作流程，以便在交付管道中盡早調整 PaC 執行點。

云環境中代碼優化的現狀

掌握成本效率、性能、可擴展性、可靠性和其他結果指標需要根據應用模式和業務變量對云基礎設施進行微調。事實證明，臨時修改或依賴狹隘的 AI/ML 優化是不夠的，尤其是在環境規模擴大和變得更加復雜的情況下。

優化即代碼的出現

這一現實推動了 OaC 框架的出現，這些框架旨在以可衡量、可測試的方式將運營改進嵌入到基礎設施自動化流程中。主要示例包括 AWS Well Architected Framework，它指導團隊根據最佳實踐迭代改進云架構。

Cloudwaste 和 CloudZero 提供專門的優化器，可根據利用率和支出數據進行實時調整。Gremlin 和 Chaos Native 通過模擬災難進行基礎設施測試，構建彈性架構。在 Datadog、New Relic 和 Dynatrace 等工具中，云平臺、應用程序、分析和自動化工作流程之間的核心重要運營反饋循環正在迅速成熟。

采用 OaC 實現成本和可持續性目標

云計算成本的飆升使得 OaC 對于避免浪費、合理使用和實現可持續發展至關重要。IDC 預測，到 2022 年，企業將浪費 33% 的云計算支出。調整預留計劃、使用模式、資源分配和技術債務都是控制費用的必要條件。云優化必須在降低成本與保持性能、安全性和可靠性目標之間取得平衡。

將 OaC 集成到政策護欄中

領先的團隊現在使用 PaC 護欄包裹 OaC 工具，以便在仍然管理環境的同時安全地優化云資源使用。例如，策略可以規定自動擴展模式，而優化器則根據需求信號和利用率目標不斷調整這些閾值。成本策略可以設定一般界限，同時為優化器提供適當大小使用量的自由度。

這有助于避免一些常見的陷阱，即狹隘的優化過度導致性能、架構或安全問題。優化器識別改進，而策略即代碼在定義的約束內實施更改。儀表、分析和自動化之間構建良好的反饋循環可確保安全的持續優化進程。

集成 IaC、PaC 和 OaC 的架構方法

精明的云架構師現在認識到將 IaC、PaC 和 OaC 工作結合到集成工作流中而不是采用分散的方法至關重要。緊密連接這些實踐可在整個云生命周期中釋放復合效益。

基礎設施狀態管理

管理所需狀態配置和歷史狀態的強大系統是 IaC/PaC 集成的基礎。所需狀態來自 IaC 模板，而歷史狀態則反映用于評估偏差的部署現實。狀態存儲庫提供真相來源，支持下游自動化。

基礎設施管道模式：基礎設施交付管道大量借鑒了軟件 CI/CD 學科。存儲庫中的源代碼經過構建、測試和部署階段，這些階段代表：規劃 > 創建 > 驗證階段。金絲雀部署和推廣流程為部署后的基礎設施變更提供治理。

GitOps 用于聲明式基礎設施：?GitOps 擴展了管道，實現了 Git 中所需的基礎設施狀態與平臺上部署的實際狀態之間的持續協調循環。自動化控制器（例如 Flux）不斷檢測和協調偏差，使環境回到版本化基線。好處包括改進恢復、減少錯誤/未經授權的更改以及環境狀態的儀表板。

基礎設施借貸庫：經過批準的架構模板和共享服務精心構建的目錄支持在大型組織中擴展 IaC，同時防止基礎設施蔓延或重復。它們提供符合控制的模塊化、經過實戰檢驗的藍圖，可作為開發團隊實施新方案的構建塊。AWS Service Catalog、Terraform Modules 和 Azure Blueprints 就是這種方法的典型代表。

自我優化資源池：基礎設施資源共享池（Kubernetes 集群、數據存儲、無服務器等）可以自動配置和動態擴展，以供啟用的服務使用。這些下一代“云原生”資源結構嵌入了數據驅動的分配，針對運行時的利用率和成本效率進行了優化。團隊只需根據池 API 進行集成，而無需調整基礎設施的大小。

策略和控制集成點：基礎設施策略控制適用于各個級別的流程。基礎技術控制直接嵌入跨環境的基礎基礎設施（IAM、VPC 設計等）。訪問和更改控制層位于管理工具之上（Terraform Cloud 上的 RBAC、Azure Blueprints）。更高級別的護欄可以通過控制臺 UI 或 API 上的可擴展平面進行連接。

OaC 嵌入式指標驅動調整：優化工具嵌入到核心自動化流程中時效果最佳，而不是保持孤立或偶發調整。策略控制為優化活動授予允許的邊界。遙測數據管道進入分析和決策引擎，以確定在定義的護欄內啟用的調整操作以完成反饋循環。

衡量成果

隨著云采用達到主流規模，團隊面臨的壓力也越來越大，他們需要在成本效率、風險降低、DevOps 加速和基礎設施穩定性結果方面展示切實的投資回報。如果執行得當，集成的 IaC/PaC/OaC 實踐將為可衡量的轉型奠定基礎，關鍵的客觀和主觀結果指標如下：

風險管理與合規

• 減少威脅面
• 暴露于錯誤配置
• 審計績效
• 遵守標準
• 例外率

成本管理

• 優化云成本
• 自動化帶來的節省
• 預留容量利用率
• 跨環境的可見性

卓越運營

• 事件響應
• 失敗率
• 利用率和爭用
• 備份和恢復性能

生產率

• 部署速度
• 開發人員體驗
• 錯誤率
• 員工效率

每個結果領域都包含定量和定性 KPI，涵蓋從業務標準到技術指標的一系列內容。整體儀表板使權衡和進展清晰可見，從而實現持續改進。

需要避免的陷阱

云的成功在很大程度上取決于選擇正確的遷移策略，但許多人因技術規劃不善或缺乏組織對遷移后卓越運營的承諾而失敗。以下是破壞云工作的最常見錯誤：

• 追求無需更改應用程序的“提升和轉變”計劃
• 未能解決技術債務和遺留限制
• 缺乏優化持續成本的決心
• 自動化技能和人員不足
• 自動化孤島仍處于斷開狀態
• 手動、被動的云管理方法
• 對實際云利用率的了解有限
• 合規實踐存在問題，審計失敗
• 不強制要求云原生架構原則

IaC/PaC/OaC 和云計算的下一步是什么

展望未來，云基礎設施自動化將成為成熟組織的規則而非例外。隨著規模、速度和連接性（物聯網、邊緣等）的復雜性不斷增加，對云自動化和智能進行基本運營的依賴將很快成為開展業務的成本。

國家爆炸式增長和政策債務
政策覆蓋范圍、連通性和復雜性將使傳統治理方法達到臨界點，需要從根本上采用新方法。分散的工具和流程將過渡到統一的系統，以在整個企業堆棧中擴展云策略自動化。

安全性、合規性和成本測試的左移、
安全性和合規性實踐將繼續在部署之前盡早應用于開發流程。代碼存儲庫、管道和云中的嵌入式保護措施將成為標準。資源優化將深入到代碼，并根據使用情況信號調整從功能性能到基礎設施開銷的一切。

NoOps 和 GitOps 成為默認模式
NoOps 模式將消除剩余的手動更改流程，因為組織將云連接到直接更新基礎設施的 MLOps 管道。GitOps 將提供統一的記錄系統并繼續自動化進程。這些將使速度大大加快，同時具有更高的穩定性和監督性。

決策智能和高級分析：云和基礎設施分析將越來越多地關注決策支持、預測指導和規范行動，而不僅僅是監控和閾值警報。集成將加強監控、分析和自動化引擎之間的雙向循環，從而實現更高級別的自主環境。

云技能的轉變：隨著云原生模式的接管，云技術專業知識將成為必需技能。關鍵技能將轉向業務轉型、客戶關注、決策能力、分析能力、自動化和創造性解決問題的能力，而這些都是 AI/ML 無法比擬的。

業務驅動因素加速技術變革
雖然技術變革傳統上側重于 IT 目標，但云的發展將更直接地圍繞核心業務目標和成果。業務線領導者必須倡導以客戶和數據戰略為基礎的現代化，并將 IT 與更大的組織使命完全結合起來。

隨著云基礎設施自動化面臨規模不斷擴大的復雜性，未來的道路必將發生大規模技術變革。團隊如何有效地利用和發展 IaC/PaC/OaC 實踐，很可能決定哪些組織能在未來動蕩的環境中茁壯成長。

結論

基礎設施即代碼、策略即代碼和優化即代碼是現代云采用策略的支柱，可實現云環境的成功遷移、持續管理和持續改進。將這些功能與交付管道、策略生命周期和強大的測量系統相結合，可實現轉型業務成果。

2024 年的云工程仍然充滿希望，但規模、風險和復雜性也在不斷增加。隨著世界經濟迅速進入數字商業模式，云計算既是前景，也是危險。掌握云自動化、治理和創新相互交織的實踐的組織是在未來動蕩中蓬勃發展的關鍵。