Azure 自動化中的程序自動化，可讓您建立和管理 PowerShell、PowerShell 工作流程和圖形化 Runbook。 如需詳細資訊，請參閱 Azure 自動化 Runbook。
自動化會根據在 Runbook 中定義的邏輯來執行 Runbook。 如果 Runbook 中斷，則會從頭重新啟動。 前提是 Runbook 必須撰寫成發生暫時性問題時可重新啟動。
在 Azure 自動化中啟動 Runbook 時會建立作業，此為 Runbook 的單一執行個體。 每個作業會連線到您的 Azure 訂用帳戶，以存取 Azure 資源。 資料中心內的資源必須開放給公用雲端存取，作業才能存取這些資源。
在 Runbook 執行期間，Azure 自動化會指派背景工作角色來執行每個作業。 雖然背景工作是由多個 Azure 帳戶共用，來自不同自動化帳戶的工作會彼此隔離。 您無法控制由哪個背景工作角色來處理作業要求。
當您在 Azure 入口網站中檢視 Runbook 清單時，可看到已針對每個 Runbook 啟動的每個作業的狀態。 Azure 自動化最多儲存 30 天的作業記錄。
下圖顯示 PowerShell Runbook、PowerShell 工作流程 Runbook 和圖形化 Runbook 的 Runbook 作業生命週期。
附註
如需檢視或刪除個人資料的詳細資訊，請參閱 GDPR 的一般資料主體要求、GDPR 的 Azure 資料主體要求或 GDPR 的 Windows 資料主體要求，視您的所在區域和需求而定。 如需 GDPR 的詳細資訊，請參閱 Microsoft 信任中心的 GDPR 區段和服務信任入口網站的 GDPR 區段。
Runbook 執行環境
Azure 自動化中的 Runbook 可以在 Azure 沙箱或混合式 Runbook 背景工作角色上執行。
如果 Runbook 設計為對 Azure 中的資源進行驗證和執行，則會在 Azure 沙箱中執行。 在沙箱中的 Runbook 執行期間，Azure 自動化會指派背景工作角色來執行每個作業。 雖然背景工作是由多個 Azure 帳戶共用，來自不同自動化帳戶的工作會彼此隔離。 使用相同沙箱的作業均受限於該沙箱的資源限制。 Azure 沙箱環境不支援互動式作業。
您也可以使用混合式 Runbook 背景工作角色，直接在裝載角色的電腦上執行 Runbook，以及針對環境中的本機資源執行 Runbook。 Azure 自動化會儲存並管理 Runbook，然後將 Runbook 傳遞至一或多個指派的電腦。
在 Azure 儲存體、Azure Key Vault 或 Azure SQL 上啟用 Azure 防火牆，這會封鎖從 Azure 自動化 Runbook 存取這些服務。 即使啟用防火牆例外以允許受信任 Microsoft 服務時，存取也會遭到封鎖，因為自動化不是受信任服務清單的一部分。 啟用防火牆後，只能使用混合式 Runbook 背景工作角色和虛擬網路服務端點來進行存取。
下表列出一些 Runbook 執行工作，並列出針對各 Runbook 建議的執行環境。
| 任務 | 建議 | 注意 |
|---|---|---|
| 與 Azure 資源整合 | Azure 沙箱 | 裝載於 Azure 中，驗證比較簡單。 如果您在 Azure VM 上使用混合式 Runbook 背景工作角色，您可以搭配受控識別使用 Runbook 驗證。 |
| 獲得最佳效能來管理 Azure 資源 | Azure 沙箱 | 指令碼在相同環境中執行，延遲較少。 |
| 將營運成本最小化 | Azure 沙箱 | 沒有任何計算額外負荷，也不需要 VM。 |
| 執行長時間執行的指令碼 | 混合式 Runbook 背景工作角色 | Azure 沙箱有資源限制。 |
| 與本機服務互動 | 混合式 Runbook 背景工作角色 | 直接存取主機電腦，或其他雲端環境或內部部署環境中的資源。 |
| 需要協力廠商軟體和可執行檔 | 混合式 Runbook 背景工作角色 | 您負責管理作業系統且可以安裝軟體。 |
| 使用 Runbook 監視檔案或資料夾 | 混合式 Runbook 背景工作角色 | 在混合式 Runbook 背景工作角色上使用監看員工作。 |
| 執行耗用大量資源的指令碼 | 混合式 Runbook 背景工作角色 | Azure 沙箱有資源限制。 |
| 使用具有特定需求的模組 | 混合式 Runbook 背景工作角色 | 一些範例包括： WinSCP - winscp.exe IIS 管理的相依性 - 啟用或管理 IIS 的相依性 |
| 使用安裝程式來安裝模組 | 混合式 Runbook 背景工作角色 | 沙箱的模組必須支援複製。 |
| 使用需要 .NET Framework 4.7.2 以外版本的 Runbook 或模組 | 混合式 Runbook 背景工作角色 | Azure 沙箱支援 .NET Framework 4.7.2，不支援升級至不同版本。 |
| 執行需要提高權限的指令碼 | 混合式 Runbook 背景工作角色 | 沙箱不允許提高權限。 使用混合式 Runbook 背景工作角色時，您可以關閉 UAC，並使用 Invoke-Command 來執行需要提高權限的命令。 |
沙箱中的暫存儲存體
如果您需要建立暫存檔作為 Runbook 邏輯的一部分，可以針對於 Azure 中執行的 Runbook 在 Azure 沙箱中使用 Temp 資料夾 (也就是 $env:TEMP)。 唯一限制是您無法使用超過 1 GB 的磁碟空間，這是每個沙箱的配額。 使用 PowerShell 工作流程時，此案例可能會導致問題，因為 PowerShell 工作流程會使用檢查點，而且指令碼可能會在不同的沙箱中重試。
透過混合式沙箱，您可以根據混合式 Runbook 背景工作角色上的儲存體可用性來使用 C:\temp。 不過，根據 Azure VM 建議，您不應該在 Windows 或 Linux 上使用暫存磁碟來保存需要保存的資料。
資源
您的 Runbook 必須包含邏輯來處理資源，例如 VM、網路和網路上的資源。 資源繫結至 Azure 訂用帳戶，而 Runbook 需要適當的認證才能存取任何資源。 關於在 Runbook 中處理資源的範例，請參閱處理資源。
安全性
Azure 自動化使用適用於雲端的 Microsoft Defender 來確保資源的安全性，並偵測 Linux 系統是否遭到入侵。 無論資源是否在 Azure 中，所有工作負載都受到保護。 請參閱 Azure 自動化中的驗證簡介。
適用於雲端的 Defender 會限制哪些使用者可在 VM 上執行任何指令碼 (已簽署或未簽署)。 如果您是對 VM 具有 root 存取權的使用者，則必須以數位簽章來明確設定機器或關閉機器。 否則，只有在建立自動化帳戶並啟用適當功能之後，您才能執行指令碼來套用作業系統更新。
訂用帳戶
Azure 訂用帳戶是您為了使用一或多個雲端式服務，而與 Microsoft 簽訂的合約，需要付費。 如果您使用的認證可以存取多個訂用帳戶，則可以在相同的自動化帳戶中管理多個訂用帳戶。
認證
不論是在 Azure 或協力廠商系統上，Runbook 都需要適當的認證，才能存取任何資源。 這些認證儲存在 Azure 自動化、Key Vault 等。
Azure 監視器
Azure 自動化可以使用 Azure 監視器 來監視其機器作業。
Runbook 權限
Runbook 需要有權限來透過認證向 Azure 進行驗證。 請參閱 Azure 自動化驗證概觀。
模組
Azure 自動化包含下列 PowerShell 模組：
- Orchestrator.AssetManagement.Cmdlets - 包含數個內部 Cmdlet，只有當您在 Azure 沙箱環境或 Windows 混合式 Runbook 背景工作角色上執行 Runbook 時，才可以使用這些內部 Cmdlet。 這些 Cmdlet 的設計目的是代替 Azure PowerShell Cmdlet，用來與自動化帳戶資源互動。
- Az.Automation - 建議的 PowerShell 模組，可與取代 AzureRM 自動化模組的 Azure 自動化互動。 當您建立自動化帳戶且需要手動匯入時，不會自動包含 Az.Automation 模組。
- AzureRM.Automation - 當您建立自動化帳戶時，預設會安裝。
此外，您也可以根據 Runbook 和 DSC 設定所需的 Cmdlet 來安裝模組。 關於 Runbook 和 DSC 設定可用的模組，如需詳細資訊，請參閱在 Azure 自動化中管理模組。
憑證
Azure 自動化使用憑證向 Azure 進行驗證，或將憑證新增至 Azure 或協力廠商資源。 憑證都妥善儲存，供 Runbook 和 DSC 設定來存取。
您的 Runbook 可以使用自我簽署憑證，這種憑證不是由憑證授權單位 (CA) 簽署。 請參閱建立新的憑證。
工作
Azure 自動化支援一個從相同自動化帳戶來執行作業的環境。 單一 Runbook 一次可以執行許多工作。 同時執行的作業越多，越常會分派到相同的沙箱。 最多 10 個作業可以在沙箱中執行。 當沙箱中沒有作業執行時，該沙箱會被刪除；因此，它不應該用來儲存檔案。
相同沙箱流程中執行的作業可能影響彼此。 例如執行 Disconnect-AzAccount Cmdlet。 執行此 Cmdlet 會中斷連接共用沙箱流程中的每個 Runbook 作業。 如需有關解決此情況的範例，請參閱防止同時作業。
附註
如果 PowerShell 作業是從 Azure 沙箱中執行的 Runbook 啟動，可能無法以完整的 PowerShell 語言模式執行。
工作狀態
下表描述作業可能的狀態。 您可以在 Azure 入口網站中，檢視所有 Runbook 作業的狀態摘要，或深入了解特定 Runbook 作業的詳細資料。 您也可以設定與 Log Analytics 工作區的整合，以轉送 Runbook 作業狀態和作業串流。 如需與 Azure 監視器記錄整合的詳細資訊，請參閱將作業狀態和作業串流從自動化轉送到 Azure 監視器記錄。 如需在 Runbook 中處理狀態的範例，另請參閱取得作業狀態。
| 狀態 | 描述 |
|---|---|
| 啟用中 | 作業正在啟動。 |
| Completed | 工作已成功完成。 |
| 失敗 | 無法編譯圖形化 Runbook 或 PowerShell 工作流程 Runbook。 PowerShell Runbook 無法啟動，或作業發生例外狀況。 請參閱 Azure 自動化 Runbook 類型。 |
| 處理失敗，正在等候資源 | 工作失敗，因為其達到 公平共用 的三次上限，且每次從相同的檢查點或啟動 Runbook 開始。 |
| 已排入佇列 | 作業正在等候自動化背景工作角色上的資源變成可用，如此才能啟動作業。 |
| 繼續中 | 工作暫停後，系統正在繼續工作。 |
| 執行中 | 工作正在執行。 |
| 執行中，正在等候資源 | 作業已卸載，因為已達到公平共用限制。 工作會很快地從其上一個檢查點繼續。 |
| 啟動中 | 此作業已指派給背景工作角色，並且系統正在進行啟動。 |
| 已停止 | 工作完成之前已由使用者停止。 |
| 停止中 | 系統正在停止作業。 |
| 暫止 | 只適用於圖形化 Runbook 和 PowerShell 工作流程 Runbook。 工作已由使用者、系統或 Runbook 中的命令暫停。 如果 Runbook 沒有檢查點，則會從頭開始。 如果它有檢查點，則可重新啟動並從其最後一個檢查點繼續。 只有在發生例外狀況時，系統才會暫止 Runbook。 根據預設，ErrorActionPreference 會設定為 Continue，表示作業在發生錯誤時繼續執行。 如果此喜好設定變數設定為 Stop，則作業在發生錯誤時會暫止。 |
| Suspending | 只適用於圖形化 Runbook 和 PowerShell 工作流程 Runbook。 因使用者要求，系統正在嘗試暫停工作。 Runbook 必須達到其下一個檢查點才能暫停。 如果已通過最後一個檢查點，則在暫止之前就會完成。 |
| 新增 | 作業最近已提交，但尚未啟動。 |
附註
若發生基礎設施故障，該工作會在內部重試最多三次。
活動記錄
在 Azure 自動化中執行 Runbook 時會將詳細資料寫入自動化帳戶的活動記錄中。 如需使用此記錄的詳細資訊，請參閱從活動記錄取出詳細資料。
例外狀況
本節說明在 Runbook 中處理例外狀況或間歇問題的一些方法。 例如 WebSocket 例外狀況。 正確處理例外狀況可防止因為暫時性網路失敗而造成 Runbook 失敗。
ErrorActionPreference
ErrorActionPreference 變數決定 PowerShell 如何回應非終止錯誤。 終止錯誤一律會終止，不受 ErrorActionPreference 所影響。
當 Runbook 使用 ErrorActionPreference 時，平常的非終止錯誤 (例如來自 Get-ChildItem Cmdlet 的 PathNotFound) 會阻止 Runbook 完成。 下列範例示範 ErrorActionPreference 的用法。 當指令碼停止時，最後的 Write-Output 命令永遠不會執行。
$ErrorActionPreference = 'Stop'
Get-ChildItem -path nofile.txt
Write-Output "This message will not show"
Try Catch Finally
Try Catch Finally 用於 PowerShell 指令碼中來處理終止錯誤。 指令碼可以使用此機制來攔截特定例外狀況或一般例外狀況。
catch 陳述式應該用來追蹤或嘗試處理錯誤。 下列範例嘗試下載不存在的檔案。 此範例會攔截 System.Net.WebException 例外狀況，並傳回其他任何例外狀況的最後一個值。
try
{
$wc = new-object System.Net.WebClient
$wc.DownloadFile("http://www.contoso.com/MyDoc.doc")
}
catch [System.Net.WebException]
{
"Unable to download MyDoc.doc from http://www.contoso.com."
}
catch
{
"An error occurred that could not be resolved."
}
Throw
Throw 可以用來產生終止錯誤。 在 Runbook 中定義您自己的邏輯時，這項機制很有用。 如果指令碼符合準則而應該停止，則可以使用 throw 陳述式來停止。 下列範例使用此陳述式來顯示必要的函式參數。
function Get-ContosoFiles
{
param ($path = $(throw "The Path parameter is required."))
Get-ChildItem -Path $path\*.txt -recurse
}
Errors
您的 Runbook 必須處理錯誤。 Azure 自動化支援兩種 PowerShell 錯誤：終止和非終止。
終止錯誤發生時會停止 Runbook 執行。 Runbook 會以作業狀態 Failed 停止。
非終止錯誤即使發生，仍允許指令碼繼續。 例如，當 Runbook 在 Get-ChildItem Cmdlet 中使用不存在的路徑時，就會發生非終止錯誤。 PowerShell 發現路徑不存在，則會擲回錯誤，並繼續下一步資料夾。 此情況下的錯誤不會將 Runbook 作業狀態設為 Failed，作業甚至可能完成。 若要強制 Runbook 在非終止錯誤時停止，您可以在 Cmdlet 上使用 ErrorAction Stop。
呼叫流程
在 Azure 沙箱中執行的 Runbook 不支援呼叫流程，例如可執行檔 (.exe 檔案) 或子流程。 這是因為 Azure 沙箱是容器中執行的共用流程，可能無法存取所有基礎 API。 如果需要協力廠商軟體或呼叫子流程，您應該在 混合式 Runbook 背景工作角色上執行 Runbook。
裝置和應用程式特性
Azure 沙箱中的 Runbook 作業無法存取任何裝置或應用程式特性。 Windows 上最常用來查詢效能計量的 API 是 WMI，記憶體和 CPU 使用量就是其中一些常用的計量。
Webhooks（網路鉤子）
外部服務 (例如 Azure DevOps Services 和 GitHub) 可以在 Azure 自動化中啟動 Runbook。 為了以這種方式啟動，服務需要透過單一 HTTP 要求來使用 Webhook。 使用 Webhook 時，Runbook 不需要實作完整的 Azure 自動化功能就能啟動。
共用資源
為了讓雲端的所有 Runbook 共用資源，Azure 採用所謂的「公平共用」概念。 基於公平共用，Azure 會暫時卸載或停止已執行超過三小時的任何作業。 PowerShell Runbook 和 Python Runbook 的作業會停止且不會重新啟動，而作業狀態會變成 Stopped。
對於長時間執行的 Azure 自動化工作，建議使用混合式 Runbook 背景工作角色。 混合式 Runbook 背景工作角色並未受限於公平共用，而且未限制 Runbook 執行時間長度。 其他作業限制會套用至 Azure 沙箱和混合式 Runbook 背景工作角色。 雖然混合式 Runbook 背景工作角色不受限於 3 小時的公平共用限制，但您應該以發生非預期的本機基礎結構問題時，也能夠重新啟動的背景工作角色，作為您開發 Runbook 執行的環境。
另一個選項是使用子 Runbook 將 Runbook 最佳化。 例如，您的 Runbook 可能在數個資源上重複執行同一個函式，例如，在數個資料庫上執行資料庫作業。 您可以將此函式移至子 Runbook，然後讓您的 Runbook 使用 Start-AzAutomationRunbook 來呼叫此函式。 子 Runbook 會個別的流程中平行執行。
使用子 Runbook 可縮短父 Runbook 完成所需的總時間。 如果您的 Runbook 在子系完成後，仍然還有其他作業，則可以使用 Get-AzAutomationJob Cmdlet 來檢查子 Runbook 的作業狀態。
後續步驟
- 若要開始使用 PowerShell Runbook，請參閱教學課程：建立 PowerShell Runbook。
- 若要使用 Runbook，請參閱在 Azure 自動化中管理 Runbook。
- 如需 PowerShell 的詳細資料，請參閱 PowerShell 文件。
- 如需 PowerShell Cmdlet 參考，請參閱 Az.Automation。