

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 任务配置的工作原理
<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>

您可以使用恒定推出速率或指数推出速率来创建推出配置。您可以使用恒定推出速率来指定每分钟可通知的最大任务目标数。

Amazon IoT 当满足各种标准和阈值时，可以使用指数级部署率来部署工作。如果失败任务数与指定的一组条件相匹配，则您可以取消任务推出。在创建任务时，使用 [https://docs.amazonaws.cn/iot/latest/apireference/API_JobExecutionsRolloutConfig.html](https://docs.amazonaws.cn/iot/latest/apireference/API_JobExecutionsRolloutConfig.html) 对象设置任务推出速率条件。在创建任务时，使用 [https://docs.amazonaws.cn/iot/latest/apireference/API_AbortConfig.html](https://docs.amazonaws.cn/iot/latest/apireference/API_AbortConfig.html) 对象设置任务中止条件。

下面的示例显示推出速率的工作原理。例如，基本速率为每分钟 50 次、增量因子为 2、通知和成功设备数量各为 1000 的任务推出，其工作方式如下：该任务将以每分钟 50 次任务执行的速率开始，并以该速率继续工作，直到 1000 个事物收到任务执行通知，或发生了 1000 次成功的任务执行。

下表说明了推出将如何通过前四个增量继续。


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| 每分钟的推出速率 | 50 | 100 | 200 | 400 | 
| 满足速率提高的通知设备数或成功的任务执行 | 1000 | 2000 | 3000 | 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>

当你使用连续任务在队列上部署远程操作时，J Amazon IoT obs 会为目标事物组中的设备推出任务执行。对于添加到动态事务组中的新设备，这些任务执行会继续推出到这些设备，甚至在创建任务之后也是如此。

推出配置只能控制在创建任务之前添加到组中的设备的推出速率。创建任务后，对于任何新设备，一旦设备加入目标组，就会立即近乎实时地创建任务执行。

### 任务计划配置
<a name="job-scheduling"></a>

您可以使用预先确定的开始时间、结束时间和结束行为，最多提前一年安排连续任务或快照任务，以确定在到达结束时间后每个任务执行将发生的情况。此外，您可以创建一个可选的定期维护时段，该时段具有灵活的频率、开始时间和持续时间，以供连续任务将任务文档推出到目标组中的所有设备。

#### 任务计划配置
<a name="jobs-scheduling-without-maintenance-window"></a>

**开始时间**

计划任务的开始时间是该任务开始向目标组中的所有设备推出任务文档的未来日期和时间。计划任务的开始时间适用于连续任务和快照任务。在最初创建计划任务时，该任务保持 `SCHEDULED` 状态。到达您选择的 `startTime` 后，任务将更新为 `IN_PROGRESS` 并开始推出任务文档。`startTime` 必须小于或等于自您创建计划任务的初始日期和时间起一年。

有关使用 API 命令或`startTime`时的语法的更多信息 Amazon CLI，请参阅[时间戳](https://docs.amazonaws.cn/cli/latest/userguide/cli-usage-parameters-types.html#parameter-type-timestamp)。

对于具有可选计划配置的任务，且该任务在定期维护时段内在采用夏令时（DST）的位置发生，从 DST 切换到标准时间和从标准时间切换到 DST 时，时间将变动一小时。

**注意**  
中显示的时区 Amazon Web Services 管理控制台 是您当前的系统时区。但是，这些时区将在系统中转换为 UTC。

**结束时间**

计划任务的结束时间是该任务停止向目标组中的任何剩余设备推出任务文档的未来日期和时间。计划任务的结束时间适用于连续任务和快照任务。在计划任务达到所选的 `endTime` 并且所有任务执行都达到最终状态后，它会将其状态从 `IN_PROGRESS` 更新为 `COMPLETED`。`endTime` 必须小于或等于自您创建计划任务的初始日期和时间起两年。介于 `startTime` 和 `endTime` 之间的最短持续时间为 30 分钟。将重试任务执行，直到任务达到 `endTime`，然后 `endBehavior` 将决定如何继续。

有关使用 API 命令或`endTime`时的语法的更多信息 Amazon CLI，请参阅[时间戳](https://docs.amazonaws.cn/cli/latest/userguide/cli-usage-parameters-types.html#parameter-type-timestamp)。

对于具有可选计划配置的任务，且该任务在定期维护时段内在采用夏令时（DST）的位置发生，从 DST 切换到标准时间和从标准时间切换到 DST 时，时间将变动一小时。

**注意**  
中显示的时区 Amazon Web Services 管理控制台 是您当前的系统时区。但是，这些时区将在系统中转换为 UTC。

**结束行为**

计划任务的结束行为决定了当任务达到所选的 `endTime` 时，任务执行和所有未完成的任务执行会发生什么情况。

以下列出了创建任务或任务模板时可以选择的结束行为：
+ `STOP_ROLLOUT`
  + `STOP_ROLLOUT` 会停止向任务的目标组中的所有剩余设备推出任务文档。此外，所有 `QUEUED` 和 `IN_PROGRESS` 任务执行都将继续，直到达到最终状态。除非选择 `CANCEL` 或 `FORCE_CANCEL`，否则这是默认结束行为。
+ `CANCEL`
  + `CANCEL` 会停止向任务的目标组中的所有剩余设备推出任务文档。此外，所有 `QUEUED` 任务执行都将被取消，而所有 `IN_PROGRESS` 任务执行都将继续，直到达到终止状态。
+ `FORCE_CANCEL`
  + `FORCE_CANCEL` 会停止向任务的目标组中的所有剩余设备推出任务文档。此外，所有 `QUEUED` 和 `IN_PROGRESS` 任务执行都将被取消。

**注意**  
必须选择 `endtime` 才能选择 `endbehavior`

**最长持续时间**

无论 `startTime` 和 `endTime` 如何，计划任务的最长持续时间都必须小于或等于两年。

下表列出了计划任务的常见持续时间场景：


| **计划任务示例编号** | **startTime** | **endTime** | **最长持续时间** | 
| --- | --- | --- | --- | 
| 1 | 在初始任务创建后立即。 | 在初始任务创建后一年。 | 一年 | 
| 2 | 在初始任务创建后一个月。 | 在初始任务创建后 13 个月。 | 一年 | 
| 3 | 在初始任务创建后一年。 | 在初始任务创建后两年。 | 一年 | 
| 4 | 在初始任务创建后立即。 | 在初始任务创建后两年。 | 两年 | 

#### 定期维护时段
<a name="jobs-scheduling-maintenance-window"></a>

维护时段是 Amazon Web Services 管理控制台 和中的调度配置`SchedulingConfig`中的`CreateJob`可选配置`CreateJobTemplate` APIs。您可以设置定期维护时段，其中包含预先确定的开始时间、持续时间和维护时段发生的频率（每天、每周或每月）。维护时段仅适用于连续任务。定期维护时段的最长持续时间为 23 小时 50 分钟。

下图显示了具有可选维护时段的各种计划任务场景的任务状态：

![显示发生某些事件后一个连续任务生命周期的示意图，状态从 SCHEDULED、IN_PROGRESS、CANCELLED 到 DELETION_IN_PROGRESS 不断转换。](http://docs.amazonaws.cn/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)
```


| **字段** | **值** | **通配符** | 
| --- | --- | --- | 
| Minutes | 0-59 | , - \* / | 
| Hours | 0-23 | , - \* / | 
| D ay-of-month | 1-31 | , - \* ? / L W | 
| Month | 1-12 或 JAN-DEC | , - \* / | 
| D ay-of-week | 1-7 或 SUN-SAT | , - \* ? L \# | 
| Year | 1970-2199 | , - \* / | 

**通配符**
+ **,**（逗号）通配符包含其他值。在“月份”字段中，JAN、FEB 和 MAR 将包含 January、February 和 March。
+ **-**（破折号）通配符用于指定范围。在“日”字段中，1-15 将包含指定月份的 1 - 15 日。
+ **\***（星号）通配符包含该字段中的所有值。在“小时”字段中，**\*** 将包含每个小时。不能在 Day-of-month和 Day-of-week字段中同时使用 **\***。如果您在一个中使用它，则必须在另一个中使用 **?** 。
+ **/**（正斜杠）通配符用于指定增量。在“分钟”字段中，您可以输入 1/10 以指定从一个小时的第一分钟开始的每个第十分钟（例如，第 11 分钟、第 21 分钟和第 31 分钟，依此类推）。
+ **?**（问号）通配符用于指定一个或另一个。在 Day-of-month字段中，你可以输入 **7**，如果你不在乎 7 号是一周中的哪一天，你可以输入**？** 在 Day-of-week野外。
+ ** 或 ** 字段中的 Day-of-monthL Day-of-week 通配符用于指定月或周的最后一天。
+ 该 Day-of-month字段中的**W**通配符指定工作日。在该 Day-of-month字段中，**3W**指定最接近该月第三天的工作日。
+  Day-of-week字段中的 **\#** 通配符指定一个月内一周中指定某一天的特定实例。例如，3\#2 指该月的第二个星期二：3 指的是星期二，因为它是每周的第三天，2 是指该月内该类型的第二天。
**注意**  
如果使用 '\#' 字符，则只能在 day-of-week字段中定义一个表达式。例如，`"3#1,6#3"` 是无效的，因为它被解释为两个表达式。

**限制**
+ 您无法在同一 cron 表达式中为 Day-of-month 和 Day-of-week 字段同时指定值。如果您在其中一个字段中指定了值（或一个 \*），则必须在另一个字段中使用 **?**。

**示例**

在为定期维护时段的 `startTime` 使用 cron 表达式时，请参阅以下示例 cron 字符串。


| **分钟** | **小时** | **日期** | **月份** | **星期几** | **年** | **意义** | 
| --- | --- | --- | --- | --- | --- | --- | 
| 0 | 10 | \* | \* | ? | \* | 每天上午的 10:00（UTC）运行 | 
| 15 | 12 | \* | \* | ? | \* | 每天在下午 12:15（UTC）运行 | 
| 0 | 18 | ? | \* | MON-FRI | \* | 每星期一到星期五的下午 6:00（UTC）运行 | 
| 0 | 8 | 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>

使用此配置可创建条件，以便设备的阈值百分比符合该条件时取消任务。例如，在以下情况，您可以使用此配置取消任务：
+ 当一定比例的设备未收到任务执行通知时，例如当您的设备不兼容 Over-The-Air (OTA) 更新时。在这种情况下，设备可以报告 `REJECTED` 状态。
+ 设备的阈值百分比报告其任务执行失败时，例如设备尝试从 Amazon S3 URL 下载任务文档时发生连接中断。在这种情况下，设备必须进行编程，才能向 Amazon IoT报告 `FAILURE` 状态。
+ 任务执行开始后，由于任务执行超时达到设备的某个阈值百分比而报告 `TIMED_OUT` 状态时。
+ 出现多次重试失败时。添加重试配置时，每次重试都可能让您的 Amazon Web Services 账户产生额外费用。在这种情况下，取消任务可以取消排队的任务执行，避免重试这些执行。有关重试配置以及其与中止配置搭配使用的更多信息，请参阅 [任务执行超时和重试配置](#job-timeout-retry)。

您可以使用 Amazon IoT 控制台或 Jobs API 设置 Amazon 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`状态。 Amazon IoT 还会发布 MQTT 通知。

**步骤计时器**  
您还可以设置仅适用于要更新的任务执行的步骤计时器。这种计时器不会对进行中计时器产生影响。您每次更新任务执行时，都可以为此步骤计时器设置新值。为事物启动下一个待处理任务执行时，您还可以创建新的步骤计时器。如果任务执行保持在 `IN_PROGRESS` 状态的时间长度超过了此步骤计时器间隔，它将失败，并切换为最终 `TIMED_OUT` 状态。

**注意**  
您可以使用 Amazon IoT 控制台或 Amazon IoT Jobs API 设置进行中的计时器。若要指定步骤计时器，请使用 API。

#### 任务超时计时器工作原理
<a name="job-timeout-timers-works"></a>

下图说明了进行中超时计时器与步骤超时计时器在 20 分钟超时期限内相互作用的方式。

![显示 20 分钟进行中计时器的时间线，嵌套步进计时器分别为 7、5 和 8 分钟。](http://docs.amazonaws.cn/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 超时。步骤计时器不能超过进行中计时器的绝对界限。

### Job 执行重试配置
<a name="job-retry-configuration"></a>

您可以在满足某组条件时使用重试配置来重试任务执行。如果任务超时或设备报告失败，就可以尝试重试。如果要因超时错误重试执行，则必须启用超时配置。

**如何使用重试配置**  
使用以下步骤重试配置：

1. 确定是否对 `FAILED`、`TIMED_OUT` 或这两种失败条件使用重试配置。对于`TIMED_OUT`状态，在报告状态后， Amazon IoT Jobs 会自动重试设备执行任务。

1. 对于 `FAILED` 状态，请检查是否可以重试任务执行失败。如果可以重试，请对设备进行编程，以便向 Amazon IoT报告 `FAILURE` 状态。以下部分介绍了有关可重试和不可重试失败的更多信息。

1. 使用前述的信息指定每种失败类型的重试次数。最多可以为单台设备的两种失败类型组合指定 10 次重试。当执行成功或达到指定的尝试次数时，重试尝试会自动停止。

1. 添加中止配置，以便在重复出现重试失败时取消任务，以避免大量重试产生额外费用。

**注意**  
当任务达到定期维护时段事件结束时，所有 `IN_PROGRESS` 任务执行都将继续执行在任务文档中确定的操作，直到它们达到最终状态。如果任务执行在维护时段之外达到最终状态 `FAILED` 或 `TIMED_OUT`，则当尝试次数未耗尽时，将在下一个时段中尝试进行重试。在下一个维护时段事件的 `startTime`，将创建一个新的任务执行并进入 `QUEUED` 状态，直到设备准备好开始为止。

**重试和中止配置**  
每次重试都会向您收取额外费用。 Amazon Web Services 账户为避免重复出现的重试失败产生额外费用，我们建议添加中止配置。有关定价的更多信息，请参阅 [Amazon IoT Device Management 定价](https://www.amazonaws.cn/iot-device-management/pricing/)。

当设备的高阈值百分比超时或报告失败时，您就可能遇到多次重试失败。在这种情况下，您可以使用中止配置取消任务，避免任何排队的任务执行或更多重试尝试。

**注意**  
符合取消任务执行的中止条件仅会取消 `QUEUED` 任务执行。系统不会尝试设备的任何排队重试。不过，当前具有 `IN_PROGRESS` 状态的任务执行不会遭到取消。

在重试失败的任务执行之前，我们还建议您检查任务执行失败是否可以重试，如下面的部分所述。

**`FAILED` 失败类型重试**  
若要重试 `FAILED` 失败类型，就必须对设备进行编程，以便向 `FAILURE` 报告失败任务执行 Amazon IoT状态。使用重试 `FAILED` 任务执行的条件来设置重试配置，并指定要执行的重试次数。当 Amazon IoT Jobs 检测到`FAILURE`状态时，它将自动尝试重试设备执行作业。任务执行成功或达到最大重试次数，重试才会停止。

您可以跟踪每次重试以及在这些设备上运行的任务。通过跟踪执行状态，您可以在达到指定的重试次数后，使用设备报告失败以及发起另一次重试。

**可重试和不可重试失败**  
任务执行失败可以是可重试或不可重试的失败。每次重试都会让您的 Amazon Web Services 账户产生费用。为避免因多次重试而产生额外费用，请先检查任务执行失败是否可以重试。可重试失败示例包括设备尝试从 Amazon S3 URL 下载任务文档时发生的连接错误。如果任务执行失败是可重试的，可对设备进行编程，以便在出现任务执行失败时报告 `FAILURE` 状态。然后，将重试配置设置为重试 `FAILED` 执行。

如果执行不可重试，为避免重试以及可能让您的账户产生额外费用，我们建议您对设备进行编程以向 Amazon IoT报告 `REJECTED` 状态。不可重试失败的示例包括：设备与接收任务更新不兼容，或执行任务时遇到内存错误。在这些情况下， Amazon IoT Jobs 不会重试任务执行，因为它只有在检测到`FAILED`或`TIMED_OUT`状态时才会重试任务执行。

在确定任务执行失败可重试后，如果重试仍然失败，请考虑检查设备日志。

**注意**  
当具有可选计划配置的任务达到其 `endTime` 时，所选的 `endBehavior` 将停止向目标组中的所有剩余设备推出任务文档，并指示如何继续剩余的任务执行。如果通过重试配置选择了这些尝试，则会重试这些尝试。

**`TIMEOUT` 失败类型重试**  
如果您在创建任务时启用超时，则 Amazon IoT 当状态从`IN_PROGRESS`变为时，任务将尝试重试设备执行任务。`TIMED_OUT`如果进行中计时器超时，或者您指定的步骤计时器处于 `IN_PROGRESS` 中然后超时，此状态可能会发生更改。任务执行成功或达到此失败类型的最大重试次数后，重试才会停止。

**持续任务和事物组成员资格更新**  
对于任务状态为 `IN_PROGRESS` 的连续任务，当事物的组成员资格更新时，重试次数将重置为零。例如，假设您指定了五次重试，并且已经执行了三次重试。如果现已从事物组中删除事物，然后该事物重新加入该组（例如动态事物组），则重试次数将重置为零。您现在可以对事物组执行五次重试，而非剩余的两次重试。此外，从事物组中删除事物将取消其他重试次数。