使用 無伺服器技術 將雲端上的工作流程和重複性工作自動化，可以大幅提升組織的 DevOps 小組生產力。 無伺服器模型最適合符合 事件驅動方法 的自動化案例。
架構
案例
本文說明兩個主要雲端自動化案例：
成本中心標記：此實作 會追蹤每個 Azure 資源的成本中心。 Azure 原則 服務 會 以預設成本中心識別碼標記群組中的所有新資源 。 Azure 事件方格會監視資源建立事件，然後呼叫 Azure 函式 。 函式會與 Microsoft Entra ID 互動，並驗證新資源的成本中心識別碼。 如果不同，它會更新標記，並將電子郵件傳送給資源擁有者。 為了簡單起見，會模擬 Microsoft Entra ID 的 REST 查詢。 Microsoft Entra ID 也可以使用 Microsoft Graph PowerShell 模組 或適用于 Python 的 Microsoft 驗證程式庫 （MSAL） 進行整合 。
節流回應 ：此範例會監視 Azure Cosmos DB 資料庫以進行節流。 當對 Azure Cosmos DB 的資料存取要求超過 要求單位 （或 RU） 中的容量時，就會觸發 Azure 監視器警示 。 Azure 監視器動作群組 已設定為呼叫自動化函式以回應這些警示。 函式會將 RU 調整為較高的值、增加容量，進而停止警示。
注意
這些解決方案並不是完成這些工作的唯一解決方案，並說明無伺服器技術如何回應環境訊號（事件）並影響環境變更。 在實用的情況下，透過自訂解決方案使用平臺原生解決方案。 例如，Azure Cosmos DB 原生支援 自動調整輸送量 作為節流回應案例的原生替代方案。
第一個案例的參考實作可在 GitHub 上 取得。
這些無伺服器雲端自動化案例中的函式通常會以 PowerShell 和 Python 撰寫，這是系統自動化中使用的兩種最常見指令碼語言。 它們會使用 Azure CLI 中的 Azure Functions Core Tools 進行部署。 或者，您可以使用 Az.Functions PowerShell Cmdlet 來部署和管理 Azure Functions 。
工作流程
事件型自動化案例最適合使用 Azure Functions 來實作。 它們會遵循下列常見模式：
回應資源 上的事件。 這些是 Azure 資源或資源群組建立、刪除、變更等事件的回應。 此模式會使用 事件方格 來觸發這類事件的函式。 成本中心標記案例是此模式的範例。 其他常見案例包括：
- 授與 DevOps 小組對新建立之資源群組的存取權，
- 刪除資源時將通知傳送至 DevOps，以及
- 回應 Azure 虛擬機器 （VM） 等資源的維護事件。
排程的工作。 這些通常是使用 計時器觸發函 式執行的維護工作。 此模式的範例包括：
- 在夜間停止資源，並從早上開始，
- 定期讀取 Blob 儲存體內容，並轉換成 Azure Cosmos DB 檔，
- 定期掃描不再使用中的資源，並加以移除，以及
- 自動備份。
處理 Azure 警示 。 此模式使用輕鬆整合 Azure 監視器警示和動作群組與 Azure Functions。 函式通常會採取補救動作，以回應源自應用程式和基礎結構的計量、記錄分析和警示。 節流回應案例是此模式的範例。 其他常見案例如下：
- 當SQL 資料庫達到大小上限時截斷資料表，
- 在 VM 中錯誤停止時重新開機服務，以及
- 如果函式失敗，則傳送通知。
使用外部系統 進行協調。 此模式可讓您使用 Logic Apps 與外部系統整合，以協調工作流程。 Logic Apps 連接器 可以輕鬆地與數個協力廠商服務整合，以及 Microsoft 365 等Microsoft 服務。 Azure Functions 可用於實際自動化。 成本中心標記案例示範此模式。 其他常見案例包括：
- 監視 IT 程式，例如變更要求或核准，以及
- 自動化工作完成時傳送電子郵件通知。
公開為 Web 攔截 或 API 。 使用 Azure Functions 的自動化工作可以整合至協力廠商應用程式，甚至是命令列工具，方法是使用 HTTP 觸發程式 將函式公開為 Web 攔截/API。 PowerShell 和 Python 都提供多個驗證方法，以保護對函式的外部存取。 自動化會在回應應用程式特定的外來事件時發生，例如，與 Power Apps 或 GitHub 整合。 常見情況包括：
- 觸發失敗服務的自動化，以及
- 將使用者上線至組織的資源。
建立 ChatOps 介面 。 此模式可讓客戶建立聊天式操作介面，並執行與人類共同作業的開發和作業函式和命令。 這可以與 Azure Bot Framework 整合，並使用 Microsoft Teams 或 Slack 命令進行部署、監視、常見問題等等。 ChatOps 介面會建立一個即時系統來管理生產事件，每個步驟都會自動記錄在聊天上。 如需詳細資訊，請參閱 ChatOps 如何協助您改善 DevOps。
混合式自動化 。 此模式會 使用Azure App 服務混合式連線， 在您的本機電腦上安裝軟體元件。 此元件可讓您安全地存取該電腦上的資源。 目前可以使用 PowerShell 函式來管理混合式環境 的能力 。 常見情況包括：
- 管理內部部署機器，以及
- 透過跳躍伺服器 管理防火牆後方的其他系統（例如內部部署 SQL Server ）。
元件
架構包含下列元件：
Azure Functions。 Azure Functions 在此架構中提供事件驅動、無伺服器計算功能。 函式會在事件或警示觸發時執行自動化工作。 在兩個案例中，會使用 HTTP 要求叫用函式。 程式碼複雜度應該最小化，方法是開發無 狀態和 等冪的 函 式。
多個等冪函式的執行會建立相同的結果。 為了維持等冪性，節流案例中的函式調整會保持簡單。 在真實世界的自動化中，請務必適當地相應增加或減少。 閱讀將 Azure Functions 的效能和可靠性優化，以取得撰寫函式時的最佳做法。
Azure Logic Apps。 Logic Apps 可用來執行更簡單的工作，使用內建連接器輕鬆實 作 。 這些工作的範圍可以從電子郵件通知到與外部管理應用程式整合。 若要瞭解如何搭配協力廠商應用程式使用 Logic Apps，請閱讀 Azure 中的基本企業整合。
Logic Apps 不提供 任何程式碼或 低程式碼 視覺化設計工具，而且可能單獨用於某些自動化案例。 閱讀 Azure Functions 與 Logic Apps 之間的這項比較，以查看哪些服務符合您的案例。
事件方格 。 事件方格內建支援來自其他 Azure 服務的事件，以及自訂事件（也稱為 自訂主題 ）。 使用事件方格的內建機制，可以輕鬆地將資源建立之類的作業事件傳播至自動化函式。
事件方格使用發佈-訂閱模型 簡化事件型自動化 ，允許透過 HTTPS 傳遞事件的可靠自動化。
Azure 監視器。 Azure 監視器警示可以監視重大情況，並使用 Azure 監視器動作群組採取更正動作。 這些動作群組可以輕鬆地與 Azure Functions 整合。 這很適合用來監看並修正基礎結構中的任何錯誤狀況，例如資料庫節流。
自動化動作 。 這個廣泛的區塊代表函式可以與其互動的其他服務，以提供自動化功能。 例如，用於標記驗證的 Microsoft Entra 識別碼，如第一個案例所示，或要布建的資料庫，如第二個案例所示。
考量
這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 。
復原
Azure Functions
處理 HTTP 逾時
若要避免較長自動化工作的 HTTP 逾時，請將此事件排入服務匯流排 佇列，並在另一個 函式中處理實際的自動化。 節流回應自動化案例說明此模式，即使實際的 Azure Cosmos DB RU 布建速度很快。
Durable Functions 會維護調用之間的狀態，可提供上述方法的替代方案。 Durable Functions 僅支援 特定語言 。
記錄失敗
最佳做法是，函式應該記錄執行自動化工作時的任何失敗。 這可讓您正確針對錯誤狀況進行疑難排解。 Azure Functions 原生支援將 Application Insights 整合為遙測系統。
並行
確認自動化函式的並行需求。 並行會藉由在 file host.json 中 設定變數 maxConcurrentRequests 來限制。 此設定會限制在函式應用程式中執行的並行函式實例數目。 由於每個實例都會耗用 CPU 和記憶體，因此必須針對需要大量 CPU 的作業調整此值。 如果函式呼叫似乎太慢或無法完成，請 maxConcurrentRequests 降低 。 如需詳細資訊，請參閱設定主機行為以更好地處理並行 一節 。
等冪
請確定您的自動化函式具有等冪性。 Azure 監視器和事件方格都可能會發出警示或事件，指出您的訂閱事件 已解決 、 引發 、 進行 中等等、正在布建您的資源 、 成功 建立等等，或甚至因為設定錯誤而傳送錯誤的警示。 請確定您的函式只會在相關的警示和事件上運作，並忽略所有其他事件，讓 false 或設定錯誤的事件不會造成不必要的結果。 如需詳細資訊，請參閱 為相同的輸入 設計 Azure Functions。
Event Grid
如果您的工作流程使用事件方格，請檢查您的案例是否會產生大量的事件，足以堵塞方格。 請參閱 事件方格訊息傳遞，然後重試 以瞭解在未認可傳遞時如何處理事件，並據以修改邏輯。 成本中心工作流程不會實作對此的額外檢查，因為它只會監看資源群組中的資源建立事件。 監視整個訂用帳戶中建立的資源，可能會產生較多的事件，需要更有彈性的處理。
Azure 監視器
如果產生足夠大量的警示，且自動化會更新 Azure 資源， 可能會達到 Azure Resource Manager 的節流限制。 這可能會對該訂用帳戶中的其餘基礎結構造成負面影響。 藉由限制 Azure 監視器所產生的警示頻率 來 避免這種情況。 您也可以限制針對特定錯誤所產生的警示。 如需詳細資訊， 請參閱 Azure 監視器警示 的檔。
安全性
安全性可提供針對蓄意攻擊和濫用寶貴資料和系統的保證。 如需詳細資訊，請參閱 安全性要素 概觀。
控制對函式的存取
藉由設定授權層級 來限制對 HTTP 觸發函式的 存取。 透過 匿名 驗證，函式可以輕鬆地透過 URL 存取，例如 http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME> 。 函 式層級驗證可以藉由要求 URL 中的函式金鑰來模糊化 HTTP 端點。 此層級是在 file function.json 中設定：
{
"bindings": [
{
"authLevel": "function",
"type": "httpTrigger",
"direction": "in",
"name": "Request",
"methods": [
"get",
"post"
]
},
{
"type": "http",
"direction": "out",
"name": "Response"
}
]
}
針對生產環境，可能需要其他策略來保護函式。 在這些案例中，函式會由其他 Azure 服務在 Azure 平臺內執行，且不會公開至網際網路。 函式授權有時就足以讓以 Web 攔截方式存取的函式。
請考慮在函式驗證之上新增安全性層級，例如，
- 使用用戶端憑證進行驗證，或
- 藉由 啟用 App Service 驗證 ，確定呼叫者是 或 可存取裝載函式的目錄。
函式層級驗證是使用 Azure Functions 的 Azure 監視器 動作群組唯一可用的選項。
如果需要從協力廠商應用程式或服務呼叫函式，建議使用API 管理 層來提供其 存取權。 此層應強制執行驗證。 API 管理具有 與 Azure Functions 整合的耗用量層 ，這可讓您只在 API 執行時才付費。 如需詳細資訊，請參閱 使用 OpenAPI 建立和公開函式。
如果呼叫服務支援服務端點或私人連結，可以考慮下列成本值選項：
- 使用專用的 App Service 方案，您可以在其中鎖定虛擬網路中的函式，以限制其存取權。 這在取用型無伺服器模型中是不可能的。
- 使用 Azure Functions 進階版方案 ，其中包含函式應用程式要使用的專用虛擬網路。
若要比較這些選項之間的定價和功能，請閱讀 Azure Functions 調整和裝載 。
控制函式可以存取的內容
Azure 資源的 受控識別是 Microsoft Entra 功能，可簡化函式如何驗證及存取其他 Azure 資源和服務。 程式碼不需要管理驗證認證，因為它是由 Microsoft Entra ID 所管理。
受控身分識別有兩種：
系統指派的受控識別 ：這些會建立為 Azure 資源的一部分，而且無法在多個資源之間共用。 刪除資源時，這些會遭到刪除。 針對牽涉到單一 Azure 資源或需要獨立身分識別的案例，請使用這些專案。 這兩種案例都使用系統指派的身分識別，因為它們只會更新單一資源。 只有受控識別才能更新另一個資源。 例如，函式可以讀取沒有受控識別的資源標籤。 請參閱 這些指示 ，將系統指派的身分識別新增至您的函式。
使用者指派的受控識別 ：這些會建立為獨立的 Azure 資源。 這些可以跨多個資源分享，而且不再需要時必須明確刪除。 請閱讀 這些指示 ，瞭解如何將使用者指派的身分識別新增至您的函式。 針對下列案例，請使用下列專案：
- 需要存取多個可以共用單一身分識別的資源，或
- 需要預先授權才能在布建期間保護資源，或
- 擁有經常回收的資源，而許可權必須一致。
將身分識別指派給 Azure 函式之後，請使用 Azure 角色型存取控制 （Azure RBAC） 將角色指派給 Azure 函式，以存取資源。 例如，若要更新資源， 必須將參與者 角色指派給函式的身分識別。
成本最佳化
成本優化是考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化要素 概觀。
使用 Azure 定價計算機 來預估成本。 以下是降低成本的一些考慮。
Azure Logic 應用程式
邏輯應用程式具有隨用隨付定價模式。 每次邏輯應用程式執行時，觸發程式、動作和連接器執行都會計量。 所有成功和不成功的動作，包括觸發程式，都會被視為執行。
邏輯應用程式也有固定定價模式。 如果您需要執行與 Azure 虛擬網路中受保護資源通訊的邏輯應用程式，您可以在 Integration Service Environment （ISE） 中 建立它們。
如需詳細資訊，請參閱 Azure Logic Apps 的定價模型。
在此架構中，邏輯應用程式會用於成本中心標記案例，以協調工作流程。
內建連接器可用來連線到 Azure Functions，並在自動化工作完成時傳送電子郵件通知。 函式會使用 HTTP 觸發程式公開為 Web 攔截/API。 只有在發生 HTTPS 要求時，才會觸發邏輯應用程式。 相較于函式持續輪詢和檢查特定準則的設計，這是符合成本效益的方式。 每個輪詢要求都會計量為動作。
如需詳細資訊，請參閱 Logic Apps 定價 。
Azure Functions
Azure Functions 提供 下列三個定價方案 。
使用情況方案。 這是最符合成本效益、無伺服器方案，您只需支付函式執行的時間。 根據此計畫，函式一次最多可以執行 10 分鐘。
進階方案。 請考慮針對自動化案例使用 Azure Functions 進階版方案 ，以符合其他需求，例如專用虛擬網路、較長的執行持續時間等等。 這些函式最多可以執行一小時，而且應該選擇較長的自動化工作，例如執行備份、資料庫索引或產生報告。
App Service 方案 。 使用 混合式連線Azure App 服務 的混合式自動化案例需要使用 App Service 方案。 在此方案下建立的函式可以無限期執行，類似于 Web 應用程式。
在這些自動化案例中，Azure Functions 會用於更新 Microsoft Entra ID 中的標籤，或藉由將 RU 相應增加為較高的值來變更 Azure Cosmos DB 設定等工作。 取 用方案 適用于此使用案例，因為這些工作是互動式的，而且不會長時間執行。
Azure Cosmos DB
Azure Cosmos DB 會按小時計費，以取得布建的輸送量和已取用的儲存體。 布建的輸送量以每秒要求單位（RU/秒）表示，這可用於一般資料庫作業，例如插入、讀取。 儲存體會針對儲存資料和索引所使用的每個 GB 計費。 如需詳細資訊，請參閱 Azure Cosmos DB 定價模型 。
在此架構中，當對 Azure Cosmos DB 的資料存取要求超過要求單位 （或 RU） 中的容量時，Azure 監視器會觸發警示。 為了回應這些警示，Azure 監視器動作群組會設定為呼叫自動化函式。 函式會將 RU 調整為較高的值。 這有助於降低成本，因為您只需要支付每小時工作負載所需的資源費用。
若要快速估計您的工作負載，請使用 Azure Cosmos DB 容量計算機 。
如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 中的 成本一節。
部署考量
對於管理應用程式行為的重要自動化工作流程，必須使用有效率的 DevOps 管線來達成零停機時間部署。 如需詳細資訊，請參閱 無伺服器後端部署 。
如果自動化涵蓋多個應用程式，請將自動化所需的資源保留在個別的資源群組 中 。 如果自動化涵蓋單一應用程式，則可以在自動化與應用程式資源之間共用單一資源群組。
如果工作流程牽涉到許多自動化函式，請將函式分組到單一函式應用程式中的一個案例。 如需詳細資訊，請參閱 管理函式應用程式 。
當您部署應用程式時，您必須監視它。 請考慮使用 Application Insights 來讓開發人員監視效能並偵測問題。
如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 中的 DevOps 一節。
Azure 資源的命令式動作
在這兩種案例中，最終結果是透過直接 Azure Resource Manager 互動變更 Azure 資源狀態。 雖然這是預期的結果，但如果已修改的資源原本是以宣告方式部署，例如 Bicep 或 Terraform 範本，請考慮對您的環境造成的影響。 除非這些變更複寫回您的來源範本，否則這些範本的下一個使用方式可能會復原此自動化所做的變更。 請考慮將命令式變更混合至透過範本定期部署的 Azure 資源的影響。
部署此案例
若要部署成本中心案例，請參閱 GitHub 上的部署步驟。