精簡您的應用程式平臺，以簡化應用程式開發和基礎結構管理
改善組織平臺工程實務的一大部分是評估您的應用程式平臺。 應用程式平臺包含用來支援組織中開發、部署和應用程式管理的所有工具和服務。
簡化和標準化
基礎結構即程式代碼 （IaC） 和自動化工具可以與範本結合，以標準化基礎結構和應用程式部署。 若要減輕終端使用者的平臺細節負擔，請將選擇細分為相關的命名慣例，以抽象化平臺詳細數據，例如：
- 資源類型類別（高計算、記憶體高）
- 資源大小類別（T恤重設大小、中小型和大）
範本應該代表已使用預設組態測試的一般需求，因此開發小組可以立即開始使用提供最少的參數，而不需要檢閱選項。 不過，有時候小組需要變更已發佈範本上比可用或想要的更多選項。 例如，核准的設計可能需要支援範本預設值以外的特定組態。 在此實例作業或平臺工程小組中，可以建立一次性設定，然後決定範本是否需要將這些變更納入為預設值。
您可以使用 IaC 工具搭配漂移偵測功能來追蹤變更，這些功能可以自動補救漂移（GitOps）。 這些工具的範例包括 Terraform 和雲端原生 IaC 工具（範例、叢集 API、Crossplane、Azure 服務操作員 v2）。 在 IaC 工具漂移之外，偵測到雲端組態工具可以查詢資源設定，例如 Azure Resource Graph。 這些可以做為兩個好處：您可以監視基礎結構程序代碼以外的變更，並檢閱已變更的預設組態。 若要避免過於殭化，您也可以使用預先定義的限制在部署中實作容錯。 例如，您可以使用 Azure 原則 來限制部署可以擁有的 Kubernetes 節點數目。
自我管理或受控？
在公用雲端中，您可以選擇取用 SaaS、PaaS 或 IaaS。 若要深入瞭解 SaaS、PaaS 和 IaaS，請參閱描述雲端概念的訓練課程模組。 PaaS 服務提供簡化的開發體驗，但更規範其應用程式模型。 歸根結底，您需要評估輕鬆使用和控制之間的取捨。
在平台設計期間，評估並排定組織服務需求的優先順序。 例如，無論您是直接在 Azure Kubernetes Service （AKS） 上建置應用程式，還是透過 Azure Container Apps （ACA） 來建置應用程式，取決於您對服務的需求，以及內部容量和技能集。 Azure Functions 或 Azure App 服務 等函式樣式服務也是如此。 ACA、Azure Functions 和 App Service 可降低複雜度，而 AKS 則提供更多彈性和控制。 更實驗性的應用程式模型，例如 OSS Radius 孵化項目嘗試在兩者之間提供平衡，但通常比具有完整支援和已建立的 IaC 格式存在的雲端服務更早的成熟階段。
您規劃時所發現的問題應該可協助您評估此縮放比例的哪一端適合您。 請務必在做出決策時考慮您自己的內部現有技能集。
共用與專用資源
在您的組織中，有多個應用程式可以共用的資源，以提高使用率和成本效益。 每個共享資源都有自己的一組考慮。 例如，這些是共用 K8s 叢集的考慮，但有些會套用至其他類型的資源：
- 組織： 共用像是叢集內的資源，而不是跨組織界限，可以改善它們如何符合組織方向、需求和優先順序。
- 應用程式租用： 應用程式可以有不同的租用隔離需求;如果應用程式可以與其他應用程式共存，則必須檢閱個別應用程式安全性和法規合規性。 例如，在 Kubernetes 中，應用程式可以使用命名空間隔離。 但您也應該考慮不同環境類型的應用程式租用。 例如，最好避免將測試應用程式與相同叢集上的生產應用程式混合，以避免因設定錯誤或安全性問題而造成非預期的影響。 或者，您可以選擇先在專用 Kubernetes 叢集上進行測試和微調，以在共用叢集上部署之前追蹤這些問題。 不管怎樣，您方法中的一致性是避免混淆和錯誤的關鍵。
- 資源耗用量： 瞭解每個應用程式資源使用量、備用容量，並執行預測來估計共用是否可行。 您也應該注意所取用資源的限制（資料中心容量或訂用帳戶限制）。 目標是避免移動您的應用程式和相依性，因為共用環境中的資源限制，或在容量用完時發生即時網站事件。使用資源限制、代表性測試、監視警示和報告來識別資源耗用量，並防範耗用太多資源的應用程式。
- 優化共享組態： 共享資源，例如共用叢集需要額外的考慮和設定。 這些考慮包括交叉收費、資源配置、許可權管理、工作負載擁有權、數據共享、升級協調、工作負載放置、建立、管理和反覆運算基準設定、容量管理和工作負載放置。 共用資源有好處，但如果標準組態太嚴格，而且不會進化，則它們會變得過時。
實作治理策略
治理是使用護欄啟用自助式的關鍵部分，但以不會影響應用程式商業價值的時間的方式套用合規性規則是常見的挑戰。 治理有兩個部分：
- 初始部署合規性（開始正確）：這可以使用透過目錄提供的標準化 IaC 範本來達成， 並具有許可權管理和原則，以確保只能部署允許的資源和組態。
- 維護合規性（保持正確性）： 原則式工具可在發生資源變更時防止或發出警示。 除了核心基礎結構之外，請考慮工具也支援 K8s 等資源內的合規性，以及容器或 VM 中使用的 OS。 例如，您可能想要強制執行鎖定的操作系統設定，或安裝安全性軟體工具，例如 Windows 組策略、SELinux、AppArmor、Azure 原則 或 Kyverno。 如果開發人員只能存取 IaC 存放庫，您可以新增核准工作流程來檢閱建議的變更，並防止直接存取資源控制平面（例如 Azure）。
維護合規性需要工具才能存取、報告及處理問題。 例如，Azure 原則 可以搭配許多 Azure 服務使用，以進行稽核、報告和補救。 它也有不同的模式，例如 Audit、Deny 和 DeployIfNotExists，視您的需求而定。
雖然原則可以強制執行合規性，但它們也可以意外中斷應用程式。 因此，請考慮在大規模運作時，隨著程式代碼 （PaC） 實務的演進。 PaC 提供作為開始正確且保持正確方法的重要部分：
- 集中管理的標準
- 原則的版本控制
- 自動化測試和驗證
- 縮短推出時間
- 持續部署
PaC 可協助將潛在不良原則的爆破半徑降到最低，其功能如下：
- 儲存為程式代碼的原則定義，儲存在已檢閱和核准的存放庫中。
- 自動化以提供測試和驗證。
- 以環狀為基礎的原則和現有資源的補救逐步推出，有助於將潛在不良原則的爆炸半徑降到最低。
- 補救工作內建安全，如果超過90%的部署失敗，則控制措施，例如停止補救工作。
實作角色特定的可檢視性和記錄
若要支援應用程式和基礎結構，您需要整個堆疊的可檢視性和記錄。
每個角色的需求不同。 例如，平臺工程和作業小組需要儀錶板，才能使用適當的警示來檢閱基礎結構的健康情況和容量。 開發人員需要應用程式計量、記錄和追蹤，才能針對顯示應用程式和基礎結構健全狀況的自定義儀錶板進行疑難解答和自定義。 其中一個角色可能遇到的一個問題是，由於缺乏有用的信息，認知多載來自太多資訊或知識差距。
若要解決這些挑戰，請考慮下列事項：
- 標準：套用記錄標準，讓您更輕鬆地建立及重複使用標準化儀錶板，並透過OpenTelemetry可檢視性架構等專案簡化擷取處理。
- 許可權：使用 Grafana 之類的專案提供小組或應用層級儀錶板，為任何感興趣的人提供匯總數據，以及應用程式小組信任成員在需要時安全地存取記錄的功能。
- 保留： 保留記錄和計量的成本可能很高，而且可能會造成非預期的風險或合規性違規。 建立保留預設值，並將其發佈為開始正確指引的一部分。
- 監視資源限制： 作業小組應該能夠識別及追蹤指定資源類型的任何限制。 這些限制應納入 IaC 範本或原則，使用 Azure 原則 之類的工具。 然後，作業應主動監視使用 Grafana 之類的儀錶板，並展開無法或啟用自動化調整的共享資源。 例如，監視容量的 K8s 叢集節點數目，因為應用程式會隨著時間上線和修改。 需要警示，而且這些定義應儲存為程序代碼，以便以程序設計方式新增至資源。
- 識別密鑰容量和健康情況計量：使用 Prometheus 或 Azure Container Insights 之類的專案，監視和警示 OS 和共用資源（例如 CPU、記憶體、記憶體、記憶體），以使用計量集合。 您可以監視使用的套接字/埠、閒聊應用程式的網路頻寬耗用量，以及叢集上裝載的具狀態應用程式數目。
以最低許可權、統一安全性管理和威脅偵測的原則建置安全性
每一層都需要安全性，從程式代碼、容器、叢集和雲端/基礎結構。 以下是建議的最低安全性步驟：
- 遵循最低權限原則。
- 將 DevOps 安全性管理統一到多個管線。
- 請確定內容深入解析可識別並補救您最重要的風險。
- 在運行時間啟用跨雲端工作負載的新式威脅的偵測和回應。
為了協助解決此問題，您需要工具來評估跨工程和應用程式系統、資源和跨雲端和混合式服務運作的工具（例如，適用於雲端的 Microsoft Defender）。 除了應用程式安全性之外，請評估：
- 使用類似 Microsoft Defender 外部受攻擊面管理 （Defender EASM） 的外部攻擊面管理。
- 網路安全性服務 - 使用 Azure 網路安全性之類的網路型網路攻擊的應用程式和雲端工作負載保護。
- 智慧型安全性分析 - 使用安全性資訊和事件管理 （SIEM） 解決方案，例如 Microsoft Sentinel
- 管理、保護、可視化及管理數據資產的方式，就像Microsoft Purview 一樣 安全
- 掃描程式代碼是否有潛在的安全性弱點、偵測秘密、檢閱 GitHub 進階安全性與 Azure DevOps 的 GitHub 進階安全性等相依性的方法。
- 軟體供應鏈的管理，特別是容器的管理（例如，套用 容器安全供應鏈架構）。
許可權需求可能會因環境而異。 例如，在某些組織中，不允許個別小組存取生產資源，而且在檢閱完成之前，無法自動部署新的應用程式。 不過，開發與測試環境中可能允許自動化資源和應用程式部署和叢集存取以進行疑難解答。
管理服務、應用程式、大規模基礎結構的身分識別存取可能會很困難。 識別提供者，用來建立、維護及管理身分識別資訊。 您的方案應包含應用程式和服務的驗證服務，並可大規模與角色型訪問控制授權 （RBAC） 系統整合。 例如，您可以使用 Microsoft Entra ID，為 Azure Kubernetes Service 等 Azure 服務大規模提供驗證和授權，而不需要直接在每個個別叢集上設定許可權。
應用程式可能需要存取身分識別，才能存取記憶體等雲端資源。 您必須檢閱需求，並評估身分識別提供者如何以最安全的方式支援此功能。 例如，在 AKS 中，雲端原生應用程式可以利用與 Microsoft Entra 識別元同盟的工作負載身分識別，以允許容器化工作負載進行驗證。 這種方法可讓應用程式存取雲端資源，而不需要應用程式程式代碼內的秘密交換。
藉由識別工作負載擁有者和追蹤資源來降低成本
管理成本是平臺工程的另一部分。 若要正確管理您的應用程式平臺，您需要一種方式來識別工作負載擁有者。 您想要取得資源清查的方式，這些資源會對應至特定元數據集的擁有者。 例如，在 Azure 中，您可以使用 AKS 標籤、Azure Resource Manager 標籤，以及 Azure 部署環境中專案等概念，將資源分組在不同的層級。 若要這樣做，所選的元數據必須在部署工作負載和資源時包含強制屬性（使用類似 Azure 原則）。 這有助於成本配置、解決方案資源對應和擁有者。 請考慮執行一般報告來追蹤孤立的資源。
除了追蹤之外，您可能需要將成本指派給個別應用程式小組，以使用與成本管理系統相同的元數據，例如 Microsoft成本管理。 雖然此方法會追蹤應用程式小組所布建的資源，但不會涵蓋共用資源的成本，例如您的身分識別提供者、記錄和計量記憶體，以及網路頻寬耗用量。 針對共享資源，您可以將營運成本平均除以個別小組，或提供不一致耗用量的專用系統（例如記錄記憶體）。 某些共用資源類型或許可以提供資源耗用量的深入解析，例如 Kubernetes 具有 OpenCost 或 Kubecost 等工具，而且可以協助。
您也應該尋找成本分析工具，您可以在其中檢閱目前的支出。 例如，Azure 入口網站 有成本警示和預算警示，可在達到預設閾值時追蹤群組中的資源耗用量，並傳送通知。
決定投資時機和地點
如果您有一個以上的應用程式平臺，則決定何時和何處投資改善來解決高成本或可檢視性不佳等問題可能很棘手。 如果您開始新版， Azure 架構中心 有數個可能可供您評估的模式。 但除此之外，當您開始規劃您想要執行的動作時，以下是一些需要考慮的問題：
| 問題 | 提示 |
|---|---|
| 您要調整現有的應用程式平臺、開始全新或使用這些方法的組合嗎？ | 即使您對現在擁有的內容感到滿意，或開始新鮮，也想要思考如何適應隨著時間的變化。 立即變更很少運作。 您的應用程式平臺是移動的目標。 隨著時間的流逝，您理想的系統變更。 您想要將此想法和任何相關的移轉計劃納入您的進階設計。 |
| 如果您想要改變您目前所做的事情，您滿意哪些產品、服務或投資？ | 話說：“如果它不壞，不要修正它。不要在沒有理由的情況下改變事情。 不過，如果您有任何本土解決方案，請考慮是否是時候轉向現有的產品，以節省長期維護。 例如，如果您正在操作自己的監視解決方案，您要從您的營運小組中移除該負擔，並移轉至新的受控產品嗎？ |
| 您在哪裡看到一段時間發生的最多變更？ 這些在貴組織所有應用程式類型（或大部分）通用的領域是否有任何一項？ | 您或內部客戶不滿意的區域，而且不太可能經常變更是絕佳的起點。 從長遠來看，這些投資報酬率最大。 這也有助於您解決如何協助遷移至新的解決方案。 例如，應用程式模型通常是流暢的，但記錄分析工具往往具有較長的保質期。 您也可以將焦點放在要啟動的新專案/應用程式，同時確認方向變更具有所需的傳回。 |
| 您是否在具有最高增值的領域投資自定義解決方案？ 您強烈認為唯一的應用程式基礎結構平臺功能是競爭優勢的一部分嗎？ | 如果您識別出差距，在做自定義工作之前，請考慮哪些區域廠商最有可能投資，並將您的自定義思維放在別處。 首先，將自己視為整合者，而不是自定義應用程式基礎結構或應用程式模型提供者。 您建置的任何項目都必須維持在長期成本上相形見絀。 如果您覺得在疑似廠商長期涵蓋的領域需要自定義建置解決方案，請規劃日落或長期支援。 您的內部客戶通常會以現成的產品作為自定義產品感到高興（如果不是更多）。 |
調整現有的應用程式平台投資可能是一個好方法。 當您進行更新時，請考慮從新的應用程式開始，以在任何類型的推出之前簡化試驗想法。透過 IaC 和應用程式範本化來考慮這項變更。 投資自定義解決方案，以滿足您在高影響力、高價值領域的獨特需求。 否則，請嘗試使用現成的解決方案。 與工程系統一樣，著重於自動化布建、追蹤和部署，而不是假設一個固定路徑可協助您管理一段時間的變更。