

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 任務組態的運作方式
<a name="jobs-configurations-details"></a>

在部署任務時使用推展和中止組態，在任務執行時則使用逾時和重試組態。下列各節說明有關這些組態運作方式的詳細資訊。

**Topics**
+ [任務推展、排程和中止組態](#job-rollout-abort-scheduling)
+ [任務執行逾時和重試組態](#job-timeout-retry)

## 任務推展、排程和中止組態
<a name="job-rollout-abort-scheduling"></a>

您可以使用任務推展、排程和中止組態，來定義接收任務文件的裝置數量、排程任務推展，以及決定取消任務的條件。

### 任務推展組態
<a name="job-rollout-configuration"></a>

您可以指定何時通知目標有一項待執行的任務。您亦可建立一個分階段推展的任務，來管理更新、重新啟動以及其他操作。若要指定通知目標的方式，請使用任務推展率。

#### 任務推展率
<a name="job-rollout-using"></a>

您可以使用恆定推展率或指數推展率來建立推展組態。若要指定每分鐘通知任務目標的數量上限，請使用恆定推展率。

AWS IoT 當符合各種條件和閾值時，任務可以使用指數推展率進行部署。如果失敗任務數量與您指定的一組條件相符，則可取消任務推展。您可以使用 [https://docs.aws.amazon.com/iot/latest/apireference/API_JobExecutionsRolloutConfig.html](https://docs.aws.amazon.com/iot/latest/apireference/API_JobExecutionsRolloutConfig.html) 物件，在建立任務時設定任務推展率條件。您還可以使用 [https://docs.aws.amazon.com/iot/latest/apireference/API_AbortConfig.html](https://docs.aws.amazon.com/iot/latest/apireference/API_AbortConfig.html) 物件在建立任務時設定任務中止條件。

下列範例說明推展率的運作方式。例如，基本速率為每分鐘 50 個、增量因數為 2、已通知和成功裝置的數量各為 1000 的任務推展率，將依以下方式運作：任務將以每分鐘 50 個任務執行的速率開始，並以該速率繼續，直到 1000 個物件均收到任務執行通知或發生 1000 次成功的任務執行。

下表說明推展如何在前四個增量中繼續進行。


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
|  每分鐘推展率  |  50  |  100  |  200  |  400  | 
|  滿足速率提高的已通知裝置或成功執行任務的數量  |  1,000  |  2,000  |  3,000  |  4,000  | 

**注意**  
如果最大並行任務限制為 500 個任務 (`isConcurrent = True`)，則所有作用中的任務將保持狀態 `IN-PROGRESS` 且不會推展任何新的任務執行作業，直到並行任務數量達到 499 以下 (`isConcurrent = False)`。此原則適用於連續任務和快照任務。  
如果 `isConcurrent = True`,表示此任務目前正在將任務執行推展到目標群組中的所有裝置。如果 `isConcurrent = False`，任務已完成將所有任務執行推展至目標群組中的所有裝置。它會在目標群組中的所有裝置一旦達到終端狀態或目標群組的臨界值百分比後，就會更新其狀態 (如果您選取了任務中止組態)。`isConcurrent = True` 與 `isConcurrent = False` 的任務層級狀態皆為 `IN_PROGRESS`。  
如需作用中任務與並行任務限制的詳細資訊，請參閱 [作用中和並行任務限制](job-limits.md#job-limits-active-concurrent)。

#### 使用動態物件群組進行連續任務的任務推展率
<a name="job-rollout-dynamic-groups"></a>

當您使用連續任務在機群上推展遠端操作時， AWS IoT Jobs 會推展目標物件群組中裝置的任務執行。對於新增至動態物件群組中的新裝置，這些任務執行會繼續推展到那些裝置，即使建立了任務之後也是如此。

建立任務之前，推展組態只能控制加入群組之裝置的推展率。建立任務後，對於任何新裝置，只要裝置加入目標群組，就會以近乎即時的速度建立任務執行。

### 任務排程組態
<a name="job-scheduling"></a>

您可以使用預定的開始時間、結束時間以及各項任務執行作業達到結束時間後所應發生的結束行為，藉此預先排定最多 1 年以後的連續或快照任務。此外，您還可以為連續任務建立具有彈性頻率、開始時間和持續時間的選用週期性維護時段，以便將任務文件推展到目標群組中的所有裝置。

#### 任務排程組態
<a name="jobs-scheduling-without-maintenance-window"></a>

**開始時間**

排程任務的開始時間是任務開始向目標群組中所有裝置推展任務文件的未來日期和時間。排程任務的開始時間會套用至連續任務和快照任務。最初建立排程任務時，它會維持為 `SCHEDULED` 的狀態。到達您選取的 `startTime` 後，它會更新為 `IN_PROGRESS` 並開始任務文件推展。`startTime` 必須少於或等於從您建立排程任務初始日期和時間起算的一年。

如需使用 API 命令或 `startTime`時 語法的詳細資訊 AWS CLI，請參閱[時間戳記](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-types.html#parameter-type-timestamp)。

對於在遵守日光節約時間 (DST) 的位置中的週期性維護時段期間進行選用排程組態的任務，從 DST 切換到標準時間以及從標準時間切換到 DST 時，時間會變動一小時。

**注意**  
中顯示的時區 AWS 管理主控台 是您目前的系統時區。但是，這些時區將在系統中轉換為 UTC。

**結束時間**

排程任務的結束時間是任務停止向目標群組中所有裝置推展任務文件的未來日期和時間。排程任務的結束時間會套用至連續任務和快照任務。在排程任務達到選取的 `endTime` 且所有任務執行都達到了終端狀態之後，它會將其狀態從 `IN_PROGRESS` 更新為 `COMPLETED`。`endTime` 必須少於或等於從您建立排程任務初始日期和時間起算的二年。`startTime` 與 `endTime` 之間的最短持續時間為 30 分鐘。繼續嘗試任務執行重試，直到任務達到 `endTime` 為止，然後 `endBehavior` 將指示如何繼續進行。

如需使用 API 命令或 `endTime`時 語法的詳細資訊 AWS CLI，請參閱[時間戳記](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-types.html#parameter-type-timestamp)。

對於在遵守日光節約時間 (DST) 的位置中的週期性維護時段期間進行選用排程組態的任務，從 DST 切換到標準時間以及從標準時間切換到 DST 時，時間會變動一小時。

**注意**  
中顯示的時區 AWS 管理主控台 是您目前的系統時區。但是，這些時區將在系統中轉換為 UTC。

**結束行為**

排程任務的結束行為會決定任務到達選定的 `endTime` 時，該任務和所有未完成的任務執行項目應有的狀態。

以下列出建立任務或任務範本時可供選取的結束行為：
+ `STOP_ROLLOUT`
  + `STOP_ROLLOUT` 會停止將任務文件推展至任務目標群組中的所有剩餘裝置。此外，所有 `QUEUED` 和 `IN_PROGRESS` 任務執行都會繼續進行，直到達到終端狀態為止。除非您選取 `CANCEL` 或 `FORCE_CANCEL`，否則這是預設的結束行為。
+ `CANCEL`
  + `CANCEL` 會停止將任務文件推展至任務目標群組中的所有剩餘裝置。此外，所有 `QUEUED` 任務執行項目都會取消，而所有 `IN_PROGRESS` 任務執行項目會繼續進行，直到達到終端狀態為止。
+ `FORCE_CANCEL`
  + `FORCE_CANCEL` 會停止將任務文件推展至任務目標群組中的所有剩餘裝置。此外，所有 `QUEUED` 和 `IN_PROGRESS` 任務執行項目都會取消。

**注意**  
若要選取 `endbehavior`，您必須選取 `endtime`

**最長持續期間**

不論 `startTime` 和 `endTime` 為何，排程任務的最長持續時間都必須小於或等於兩年。

下表列出排程任務持續時間的常見情境：


| **排程任務範例編號** | **startTime** | **endTime** | **最長持續期間** | 
| --- | --- | --- | --- | 
|  1  |  在初始任務建立後立即執行。  |  初始任務建立一年後。  |  一年  | 
|  2  |  初始任務建立後一個月。  |  初始建立任務後的 13 個月。  |  一年  | 
|  3  |  初始任務建立一年後。  |  初始任務建立兩年後。  |  一年  | 
|  4  |  在初始任務建立後立即執行。  |  初始任務建立兩年後。  |  兩年  | 

#### 週期性維護時段
<a name="jobs-scheduling-maintenance-window"></a>

維護時段是 排程組態內的選用組態， AWS 管理主控台 以及 `CreateJob`和 `CreateJobTemplate` APIs`SchedulingConfig`內的選用組態。您可以使用預先決定的開始時間、持續時間和頻率 (每日、每週或每月) 來設定週期性維護時段。維護時段僅適用於連續任務。週期性維護時段的最長持續時間為 23 小時 50 分鐘。

下圖說明具有選用維護時段之各種排程任務情境的任務狀態：

![\[圖表顯示持續任務的生命週期，在特定事件上進行 SCHEDULED、IN_PROGRESS、CANCELLED 和 DELETION_IN_PROGRESS 狀態。\]](http://docs.aws.amazon.com/zh_tw/iot/latest/developerguide/images/job-states-diagram-scheduled-maintenance-window.png)


如需任務狀態的詳細資訊，請參閱 [任務和任務執行狀態](iot-jobs-lifecycle.md)。

**注意**  
如果任務在維護時段到達 `endTime`，它將從 `IN_PROGRESS` 更新為 `COMPLETED`。此外，任何剩餘的任務執行都會遵循任務的 `endBehavior`。

**Cron 表達式**

對於在維護時段期間以自訂頻率推出任務文件的排定任務，自訂頻率會使用 cron 表達式輸入。Cron 表達式有六個必要欄位，以空格隔開。

**語法**

```
cron(fields)
```


| **欄位** | **Values (數值)** | **萬用字元** | 
| --- | --- | --- | 
|  分鐘  |  0-59  |  , - \$1 /  | 
|  小時  |  0-23  |  , - \$1 /  | 
|  月中的日  |  1-31  |  , - \$1 ? / L W  | 
|  月  |  1-12 或 JAN-DEC  |  , - \$1 /  | 
|  週中的日  |  1-7 或 SUN-SAT  |  , - \$1 ? L \$1  | 
|  年  |  1970-2199  |  , - \$1 /  | 

**萬用字元**
+ **,** (逗號) 萬用字元包含額外的值。在 Month (月) 欄位，JAN、FEB、MAR 包括 January (一月)、February (二月) 與 March (三月)。
+ **-** (破折號) 萬用字元用於指定範圍。在 Day (日) 欄位，1-15 包含指定月份的 1 至 15 號。
+ **\$1** (星號) 包含欄位中所有的值。在 Hours (小時) 欄位，**\$1** 包含每個小時。您無法在月中的特定一天和週中的特定一天兩個欄位同時使用 **\$1**。若您在其中一個欄位使用它，您必須在另一個欄位使用 **?**。
+ **/** (斜線) 萬用字元用於指定增量。在 Minutes (分鐘) 欄位，您可以輸入 1/10 指定每十分鐘的間隔，從小時的第一分鐘開始 (例如第 11、第 21、第 31 分鐘等)。
+ **?** (問號) 萬用字元用於表示不限定任何一個。在當月幾號欄位中，您可以輸入 **7**，且如果您不在意當月的 7 號是星期幾，就可以在星期幾欄位中輸入 **?**​。
+ **L** 萬用字元在 Day-of-month (月中的日) 或 Day-of-week (週中的日) 欄位可指定月份或週的最後一天。
+ **W** 萬用字元在 Day-of-month (月中的日) 欄位可指定工作日。在 Day-of-month (月中的日) 欄位，**3W** 指定的是月份中最接近第三個工作日的日子。
+ **\$1** 萬用字元在 Day-of-week (週中的日) 欄位可指定某個月中某週特定日子的特定執行個體。例如，3\$12 代表則該月的第二個星期二：3 是指星期二，因為它是每週的第三天，2 指的是一個月內該類型的第二天。
**注意**  
如果您使用 '\$1' 字元，則只能在星期幾欄位中定義一個表達式。例如：`"3#1,6#3"` 無效，因為它被轉譯為兩個表達式。

**限制**
+ 您無法在同一個 cron 表達式中指定 Day-of-month (月中的日) 和 Day-of-week (週中的日) 欄位。如果您在其中一個欄位指定了一值 (或 \$1)，則必須在另一個欄位中使用**?**​。

**範例**

針對週期性維護時段的 `startTime` 使用 cron 表達式時，請參閱下列範例 cron 字串。


| **分鐘** | **小時** | **月中的日** | **月** | **週中的日** | **年** | **意義** | 
| --- | --- | --- | --- | --- | --- | --- | 
| 0 | 10 | \$1 | \$1 | ? | \$1 |  在每天上午 10:00 (UTC) 執行  | 
| 15 | 12 | \$1 | \$1 | ? | \$1 |  在每天下午 12:15 (UTC) 執行  | 
| 0 | 18 | ? | \$1 | MON-FRI | \$1 |  在每週一至週五下午 6:00 (UTC) 執行  | 
| 0 | 8 | 1 | \$1 | ? | \$1 |  在每個月第一天上午 8:00 (UTC) 執行  | 

#### 週期性維護時段持續時間結束邏輯
<a name="jobs-scheduling-maintenance-window-end-behavoir"></a>

當維護時段期間的任務推展到達目前維護時段結束時，將會發生下列動作：
+ 任務將停止向目標群組中的所有剩餘裝置推展任務文件。它將在下一個維護時段的 `startTime` 繼續。
+ 狀態為 `QUEUED` 的所有工作執行都會保留在 `QUEUED` 中，直到下一個維護時段的 `startTime` 發生為止。在下一個時段中，它們可以在裝置準備好開始執行任務文件中指定的操作時切換至 `IN_PROGRESS`。
+ 所有 `IN_PROGRESS` 狀態為的任務執行都會繼續執行任務文件中指定的動作，直到達到結束狀態為止。`JobExecutionsRetryConfig` 中指定的任何重試嘗試都會在下一個維護時段的 `startTime` 開始進行。

### 任務中止組態
<a name="job-abort-using"></a>

達到閾值百分比的裝置滿足該條件時，即可使用此組態來建立取消任務的條件。例如，在以下情況下，您可以使用此組態來取消任務：
+ 在有達到閾值百分比的裝置未接收到任務執行通知時，例如您的裝置與空中 (OTA) 更新不相容時。在這種情況下，您的裝置可報告 `REJECTED` 狀態。
+ 在有達到閾值百分比的裝置報告其任務執行失敗時，例如當您的裝置在嘗試從 Amazon S3 URL 下載任務文件時發生連線中斷時。在這種情況下，您的裝置必須以程式設計方式向 AWS IoT報告 `FAILURE` 狀態。
+ 在任務執行開始後有達到閾值百分比的裝置任務執行逾時，因此報告 `TIMED_OUT` 狀態時。
+ 出現多次重試失敗時。新增重試組態時，每次重試嘗試均會對您的 AWS 帳戶產生額外費用。在這種情況下，取消任務可以取消已排入佇列的任務執行，並避免這些執行的重試嘗試。如需重試組態以及將其與中止組態一起使用的詳細資訊，請參閱 [任務執行逾時和重試組態](#job-timeout-retry)。

您可以使用 AWS IoT 主控台或 任務 API 來設定 AWS IoT 任務中止條件。

## 任務執行逾時和重試組態
<a name="job-timeout-retry"></a>

當任務執行的進行時間超過設定的持續時間時，使用任務執行逾時組態向您傳送 [任務通知](jobs-comm-notifications.md)。使用任務執行重試組態在任務失敗或逾時時重試執行。

### 任務執行逾時組態
<a name="job-timeout-configuration"></a>

使用任務執行逾時組態，當任務執行長時間非預期卡在 `IN_PROGRESS` 狀態時即通知您。當任務為 `IN_PROGRESS` 時，您可以監控任務執行的進度。

#### 任務逾時的計時器
<a name="job-timeout-timers"></a>

計時器有兩種類型：進行中計時器和步驟計時器。

**進行中計時器**  
建立任務或任務範本時，您可為進行中計時器指定一個介於 1 分鐘到 7 天之間的值。您可以更新此計時器的值，直到任務執行開始。計時器啟動後即無法更新，計時器值會套用於任務的所有任務執行。每當任務執行保持在 `IN_PROGRESS` 狀態超過此間隔時，任務執行就會失敗並切換到終端機`TIMED_OUT`狀態。 AWS IoT 也會發佈 MQTT 通知。

**步驟計時器**  
您還可以設定僅適用於要更新的任務執行的步驟計時器。此計時器對進行中計時器沒有任何影響。每次更新任務執行時，您可以為步驟計時器設定新值。在啟動物件的下一個待處理任務執行時，您也可以建立新的步驟計時器。如果任務執行維持在 `IN_PROGRESS` 狀態的時間超過步驟計時器隔時，任務執行就會失敗，並切換到終止的 `TIMED_OUT` 狀態。

**注意**  
您可以使用 AWS IoT 主控台或 AWS IoT 任務 API 來設定進行中計時器。若要指定步驟計時器，請使用 API。

#### 計時器如何處理任務逾時
<a name="job-timeout-timers-works"></a>

下圖說明在 20 分鐘逾時時間內進行中逾時和步驟逾時相互互動方式。

![\[時間軸顯示 20 分鐘的進行中計時器，巢狀步驟計時器為 7、5 和 8 分鐘。\]](http://docs.aws.amazon.com/zh_tw/iot/latest/developerguide/images/timeout-diagram.png)


以下顯示不同步驟：

1. 

**12：00**  
建立新任務，並在建立任務時啟動 20 分鐘的進行中計時器。進行中計時器開始執行，且任務執行切換為 `IN_PROGRESS` 狀態。

1. 

**12:05 PM**  
建立一個值為 7 分鐘的新步驟計時器。任務執行現在將在 12:12 PM 逾時。

1. 

**12:10 PM**  
建立一個值為 5 分鐘的新步驟計時器。當建立新步驟計時器時，會捨棄前一個步驟計時器，且任務執行現在將會在 12:15 PM 逾時。

1. 

**12:13 PM**  
建立一個值為 9 分鐘的新步驟計時器。捨棄前一個步驟計時器，且任務執行現在將在 12:20 PM 逾時，因為進行中計時器會在 12:20 PM 逾時。步驟計時器無法超過進行中計時器的絕對界限。

### 任務執行重試組態
<a name="job-retry-configuration"></a>

當滿足某一組條件時，您可以使用重試組態來重試任務執行。當任務逾時或裝置失敗時，可以嘗試重試。若要因逾時失敗而重試執行，必須啟用逾時組態。

**如何使用重試組態**  
使用下列步驟重試組態：

1. 確定是否針對 `FAILED`、`TIMED_OUT` 或兩者的失敗條件使用重試組態。針對 `TIMED_OUT` 狀態，報告狀態之後， AWS IoT Jobs 會自動重試裝置的任務執行。

1. 若為 `FAILED` 狀態，請檢查您的任務執行失敗是否可以重試。如果裝置可重試，請將您的裝置以程式設計方式向 AWS IoT報告 `FAILURE` 狀態。以下部分介紹了有關可重試和不可重試失敗的詳細資訊。

1. 使用上述資訊來指定要用於每種失敗類型的重試次數。針對單一裝置，您可為兩種失敗類型組合指定最多 10 次重試。當執行成功或達到指定的嘗試次數時，重試嘗試即會自動停止。

1. 新增中止組態以在重複重試失敗的情況下取消任務，進而避免在發生大量重試嘗試時產生額外費用。

**注意**  
當任務到達週期性維護時段結束時，所有 `IN_PROGRESS` 任務執行會繼續執行任務文件中識別的動作，直到達到結束狀態為止。如果任務執行在維護時段之外到達 `FAILED` 或 `TIMED_OUT` 的終端狀態，若重試次數未用完，則會在下一個維護時段進行重試。在下一次維護時段的 `startTime` 時，會建立新的任務執行，並進入 `QUEUED` 狀態，直到裝置準備好開始為止。

**重試和中止組態**  
每次重試嘗試都會對您的 產生額外費用 AWS 帳戶。為避免重複重試失敗而產生額外費用，我們建議新增中止組態。如需定價的詳細資訊，請參閱 [AWS IoT Device Management 定價](https://aws.amazon.com/iot-device-management/pricing/)。

在裝置的高閾值百分比逾時或報告失敗時，您可能會遇到多次重試失敗。在這種情況下，您可以使用中止組態來取消任務，並避免任何已排入佇列的任務執行或進一步重試嘗試。

**注意**  
當滿足取消任務執行的中止條件時，僅會取消 `QUEUED` 任務。將不會嘗試對裝置進行任何佇列重試。但是，系統不會取消目前處於 `IN_PROGRESS` 狀態的任務執行。

在重試失敗的任務執行之前，我們亦建議您檢查任務執行失敗是否可重試，如下段所述。

**重試失敗類型 `FAILED`**  
若要嘗試重試失敗類型 `FAILED`，則裝置必須以程式設計方式向 AWS IoT報告任務執行失敗的 `FAILURE` 狀態。使用重試 `FAILED` 任務執行的條件來設定重試組態，並指定要執行的重試次數。當 AWS IoT 任務偵測到`FAILURE`狀態時，它會自動嘗試重試裝置的任務執行。重試將繼續進行，直到任務執行成功或達到最大重試次數。

您可以追蹤每次重試作業的嘗試情形，以及在這些裝置上執行的任務。透過追蹤執行狀態，在嘗試指定的重試次數後，您可以使用裝置報告失敗並啟動另一次重試嘗試。

**可重試和不可重試的失敗**  
您的任務執行失敗可能是可重試或不可重試的失敗。每次重試嘗試都會對您的 AWS 帳戶產生費用。為避免多次重試嘗試產生額外費用，請先考慮檢查任務執行失敗是否可重試。可重試失敗的範例包括在嘗試從 Amazon S3 URL 下載任務文件時您的裝置所遇到的連線錯誤。如果您的任務執行失敗可重試，請使用程式將您的裝置設計為若任務執行失敗，則報告 `FAILURE`。然後，設定重試組態以重試 `FAILED` 執行。

如果執行無法重試，則若要避免重試和可能會對您的帳戶產生額外費用，我們建議使用程式將裝置設計為向 AWS IoT報告 `REJECTED` 狀態。不可重試失敗的範例包括：裝置與接收任務更新不相容，或者在執行任務時遇到記憶體錯誤。在這些情況下， AWS IoT Jobs 不會重試任務執行，因為它只會在偵測到 `FAILED`或 `TIMED_OUT` 狀態時重試任務執行。

確定可重試任務執行失敗後，如果重試嘗試仍失敗，請考慮檢查裝置日誌。

**注意**  
在具有選用排程組態的任務達到其 `endTime` 時，選取的 `endBehavior` 會停止將任務文件推展至目標群組中所有剩餘的裝置，並指定如何繼續其餘的任務執行。如果透過重試組態選取，則會重試嘗試。

**重試失敗類型 `TIMEOUT`**  
如果您在建立任務時啟用逾時，則當狀態從 變更為 `IN_PROGRESS` 時， AWS IoT 任務會嘗試重試裝置的任務執行`TIMED_OUT`。當進行中計時器逾時，或者您指定的步驟計時器為 `IN_PROGRESS` 然後逾時，即可能會發生此狀態變更。重試會繼續進行，直到任務執行成功或達到此失敗類型的重試次數上限。

**連續的任務和物件群組成員資格更新**  
對於任務狀態為 `IN_PROGRESS` 的連續任務，則當物件的群組成員資格更新時，重試嘗試次數將重設為零。例如，假定您指定了五次重試嘗試，並且已執行了三次重試。如果現已從物件群組中移除物件，然後重新連結群組 (例如動態物件群組)，重試嘗試次數將重設為零。現在，您可以對物件群組執行五次重試嘗試，而不是剩餘的兩次嘗試。此外，當物件從物件群組中移除時，系統將取消其他重試嘗試。