Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Strategie di riprova di lavoro nell'assistenza in AWS Batch
<a name="service-job-retries"></a>

Le strategie di ripetizione dei lavori di assistenza consentono AWS Batch di riprovare automaticamente i lavori di servizio non riusciti in condizioni specifiche.

I lavori di assistenza possono richiedere più tentativi per diversi motivi:
+ **Problemi temporanei di servizio**: errori interni del servizio, rallentamenti o interruzioni temporanee possono causare il fallimento dei lavori durante l'invio o l'esecuzione.
+ **Errori di inizializzazione dell'addestramento: i** problemi durante l'avvio del processo, ad esempio problemi di acquisizione delle immagini o errori di inizializzazione, possono essere risolti riprovando.

Configurando strategie di riprova appropriate, è possibile migliorare le percentuali di successo del lavoro e ridurre la necessità di interventi manuali, in particolare per carichi di lavoro di formazione di lunga durata.

**Nota**  
I job di assistenza riprovano automaticamente determinati tipi di errori, ad esempio errori di capacità insufficiente, senza consumare i tentativi di riprova configurati. La strategia di riprova consente di gestire principalmente altri tipi di errori, ad esempio errori di algoritmo o problemi di servizio.

## Configurazione delle strategie di ripetizione dei tentativi
<a name="configuring-service-job-retries"></a>

Le strategie di ripetizione dei processi di servizio sono configurate utilizzando [ServiceJobRetryStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ServiceJobRetryStrategy.html), che supporta sia il semplice numero di tentativi che la logica di ripetizione condizionale.

### Configurazione del nuovo tentativo
<a name="basic-retry-configuration"></a>

La strategia di riprova più semplice specifica il numero di tentativi di nuovo tentativo da effettuare se un job di servizio fallisce:

```
{
  "retryStrategy": {
    "attempts": 3
  }
}
```

Questa configurazione consente di ritentare il job di servizio fino a 3 volte in caso di errore.

**Importante**  
Il `attempts` valore rappresenta il numero totale di volte in cui il lavoro può essere collocato nello `RUNNABLE` stato, incluso il tentativo iniziale. Il valore 3 indica che il processo verrà tentato inizialmente una volta, quindi ritentato fino a 2 volte in caso di esito negativo.

### Riprova la configurazione con evaluateOnExit
<a name="advanced-retry-configuration"></a>

È possibile utilizzare il `evaluateOnExit` parametro per specificare le condizioni in base alle quali i lavori devono essere ritentati o lasciati fallire. Ciò è utile quando diversi tipi di errori richiedono una gestione diversa.

L'`evaluateOnExit`array può contenere fino a 5 strategie di ripetizione, ognuna delle quali specifica un'azione (`RETRY`o`EXIT`) e condizioni basate sui motivi dello stato:

```
{
  "retryStrategy": {
    "attempts": 5,
    "evaluateOnExit": [
      {
        "action": "RETRY",
        "onStatusReason": "Received status from SageMaker: InternalServerError*"
      },
      {
        "action": "EXIT",
        "onStatusReason": "Received status from SageMaker: ValidationException*"
      },
      {
        "action": "EXIT",
        "onStatusReason": "*"
      }
    ]
  }
}
```

Questa configurazione:
+ Riprova i lavori che falliscono a causa di errori interni del server SageMaker AI
+ Fallisce immediatamente i lavori che presentano eccezioni di convalida (errori del client che non verranno risolti con un nuovo tentativo)
+ Include una regola generale per uscire da qualsiasi altro tipo di errore

#### Corrispondenza del motivo dello stato
<a name="status-reason-patterns"></a>

Il `onStatusReason` parametro supporta la corrispondenza dei modelli con un massimo di 512 caratteri. I pattern possono utilizzare caratteri jolly (\$1) e corrispondere ai motivi di stato restituiti dall' SageMaker IA.

Per i lavori di assistenza, i messaggi di stato dell' SageMaker IA hanno il prefisso «Stato ricevuto da SageMaker:» per distinguerli dai messaggi AWS Batch generati. I modelli più comuni includono:
+ `Received status from SageMaker: InternalServerError*`- Rispondi agli errori interni del servizio
+ `Received status from SageMaker: ValidationException*`- Corrisponde agli errori di convalida del client
+ `Received status from SageMaker: ResourceLimitExceeded*`- Rispondi agli errori relativi al limite delle risorse
+ `*CapacityError*`- Risolvi gli errori relativi alla capacità

**Suggerimento**  
Utilizza un pattern matching specifico per gestire in modo appropriato diversi tipi di errore. Ad esempio, riprovate a commettere errori interni del server, ma non riuscite immediatamente in caso di errori di convalida che indicano problemi con i parametri del lavoro.