LabEx
Регистрация

Повтор неудачного шага и обработка постоянных ошибок

AWSBeginner
Практиковаться сейчас

Введение

Временная ошибка зависимости может исчезнуть, а недопустимый заказ должен остаться неудачным. Вы настроите выборочные повторные попытки и путь постоянной ошибки, затем увидите реальные попытки и сохранённые результаты.

Сначала выполните Создание многошагового процесса заказа. Эта новая VM предоставляет собственный обработчик и пустые таблицы; прежние машины, роли и выполнения не используются.

Связь с сертификацией

Эта лабораторная работа помогает на практике изучить следующие темы экзаменов.

  • Solutions Architect – Associate (SAA-C03) · Задача 2.1: Обработка ошибок рабочих процессов, ограниченные повторы и результаты сбоев.
  • Developer – Associate (DVA-C02) · Задача 1.1: Обработка ошибок рабочих процессов, ограниченные повторы и результаты сбоев.
  • DevOps Engineer – Professional (DOP-C02) · Задача 5.1: Базовая практика: Обработка ошибок рабочих процессов, ограниченные повторы и результаты сбоев.
  • Solutions Architect – Professional (SAP-C02) · Задача 2.4: Базовая практика: Обработка ошибок рабочих процессов, ограниченные повторы и результаты сбоев.

Авторизация процесса для вызова обработчика

На этом шаге проверьте предоставленный бизнес-обработчик и создайте отдельную роль выполнения для Step Functions.

Используйте AWS View рядом с Terminal, чтобы сравнивать запросы CLI с реальными ресурсами и результатами этой работы. Сохраните предоставленные эталонные данные.

Эта новая VM предоставляет функцию-обработчик и независимые таблицы заказов, диагностики и эталонов. Машины состояний или роли процесса пока нет. Обработчик принимает заказ, записывает его количество и сумму и позже может прочитать сводку. Для проверки синтетических сбоев режим flaky вызывает TransientOrderError при первой попытке до любой бизнес-записи; режим permanent вызывает InvalidOrder до записи. Диагностические попытки отделены от бизнес-заказов. Его роль выполнения Lambda уже авторизует эти отдельные операции таблиц.

Начните в каталоге проекта. Присваивания оболочки сохраняют возвращённые идентификаторы; --query выбирает поле ответа, а --output text выдаёт строку для повторного использования.

cd /home/labex/project
WORKER_NAME=labex-ev04-worker
WORKER_ARN=$(aws lambda get-function-configuration \
  --function-name labex-ev04-worker \
  --query FunctionArn \
  --output text)
aws lambda get-function-configuration \
  --function-name labex-ev04-worker \
  --query '{Name:FunctionName,Role:Role,Runtime:Runtime,Timeout:Timeout}'
aws stepfunctions list-state-machines

Обработчик использует Python3.12 и собственную роль Lambda; список машин пуст. Step Functions нужна собственная роль выполнения. Политика доверия позволяет сервису Step Functions принять эту роль; политика разрешений позволяет полученному сеансу вызвать только этот обработчик. Here-document в кавычках записывает буквальный JSON, а file:// читает его в запрос.

cat > workflow-trust.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "states.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
JSON
ROLE_ARN=$(aws iam create-role \
  --role-name labex-ev04-workflow-role \
  --assume-role-policy-document file://workflow-trust.json \
  --query Role.Arn \
  --output text)

Запишите обычный документ разрешений. Оболочка подставляет $WORKER_ARN, ограничивая это разрешение предоставленным обработчиком.

cat > workflow-invoke.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "lambda:InvokeFunction",
      "Resource": "$WORKER_ARN"
    }
  ]
}
EOF
aws iam put-role-policy \
  --role-name labex-ev04-workflow-role \
  --policy-name InvokeWorker \
  --policy-document file://workflow-invoke.json
aws iam get-role-policy --role-name labex-ev04-workflow-role --policy-name InvokeWorker

Политика имеет один точный ARN функции. Step Functions не получает разрешений DynamoDB обработчика: обработчик выполняет эти вызовы со своей отдельной ролью Lambda. Выполните проверку авторизации.

Настройка ограниченных повторных попыток и пути постоянной ошибки

На этом шаге постройте действительный процесс из двух задач с выборочным восстановлением.

Повтор временной ошибки и постоянная ошибка

Временная ошибка этого обработчика может исчезнуть при повторной попытке. Его постоянная ошибка следует через Catch к явно неудачному исходу.

ASL Retry перечисляет ошибки задачи, для которых возможны повторные попытки. ErrorEquals должен совпадать с типом ошибки функции. IntervalSeconds:1 начинает с задержки одну секунду; BackoffRate:2 умножает следующую задержку. MaxAttempts:2 допускает до двух повторных попыток после исходной. Это повторение обрабатывает только TransientOrderError, а не все возможные ошибки.

Catch выбирает другое состояние для ошибки, от которой задача не восстановилась. ResultPath записывает ошибку под failure; Next достигает явного состояния Fail. Обработка ошибки не означает успех бизнес-задания. Постоянная InvalidOrder заканчивается FAILED с OrderRejected, не изображая завершение заказа.

Here-document в кавычках записывает буквальный JSON. Существующий Choice отклоняет неположительное количество; две Tasks сохраняют заказ, затем читают сводку. Payload.$ передаёт текущие входные данные, ResultSelector сохраняет действительную полезную нагрузку функции, ResultPath сохраняет её под saved, а OutputPath возвращает реальную сводку.

cat > workflow-template.json <<'JSON'
{
  "StartAt": "CheckQuantity",
  "States": {
    "CheckQuantity": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.quantity",
          "NumericGreaterThan": 0,
          "Next": "StoreOrder"
        }
      ],
      "Default": "Rejected"
    },
    "StoreOrder": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": {
        "FunctionName": "WORKER_NAME",
        "Payload.$": "$"
      },
      "ResultSelector": {
        "result.$": "$.Payload"
      },
      "ResultPath": "$.saved",
      "Retry": [
        {
          "ErrorEquals": [
            "TransientOrderError"
          ],
          "IntervalSeconds": 1,
          "BackoffRate": 2,
          "MaxAttempts": 2
        }
      ],
      "Catch": [
        {
          "ErrorEquals": [
            "InvalidOrder"
          ],
          "Next": "Rejected",
          "ResultPath": "$.failure"
        }
      ],
      "Next": "ReadSummary"
    },
    "ReadSummary": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": {
        "FunctionName": "WORKER_NAME",
        "Payload": {
          "stage": "summary",
          "id.$": "$.saved.result.id"
        }
      },
      "OutputPath": "$.Payload",
      "End": true
    },
    "Rejected": {
      "Type": "Fail",
      "Error": "OrderRejected",
      "Cause": "Order could not be completed"
    }
  }
}
JSON
jq --arg worker "$WORKER_NAME" '.States.StoreOrder.Parameters.FunctionName=$worker | .States.ReadSummary.Parameters.FunctionName=$worker' workflow-template.json > workflow.json
MACHINE_ARN=$(aws stepfunctions create-state-machine \
  --name labex-ev04-orders \
  --type STANDARD \
  --role-arn "$ROLE_ARN" \
  --definition file://workflow.json \
  --query stateMachineArn \
  --output text)
aws stepfunctions describe-state-machine \
  --state-machine-arn "$MACHINE_ARN" \
  --query '{Name:name,Definition:definition}'

Определение содержит блоки выборочного повторения и перехвата ошибок. AWS View показывает ту же конфигурацию; выполнений или бизнес-заказов пока нет. Выполните проверку определения восстановления.

Наблюдение реальных результатов Retry, Catch и разрешений

На этом шаге запустите временную ошибку, постоянную ошибку и запрещённый вызов.

Первая попытка flaky обработчика обновляет диагностический счётчик попыток и вызывает ошибку до записи заказа. Следующая попытка может завершиться успешно. Ограниченный цикл оболочки читает статус выполнения каждые две секунды, пока оно не перестанет работать; $(...) захватывает вывод, а break выходит из цикла. Если после цикла выполнение остаётся RUNNING, проверьте его перед продолжением.

RETRY_ARN=$(aws stepfunctions start-execution \
  --state-machine-arn "$MACHINE_ARN" \
  --name retry-order \
  --input '{"id":"retry-order","quantity":2,"mode":"flaky"}' \
  --query executionArn \
  --output text)
for attempt in $(seq 1 60); do
  STATUS=$(aws stepfunctions describe-execution \
    --execution-arn "$RETRY_ARN" \
    --query status \
    --output text)
  if test "$STATUS" != RUNNING; then break; fi
  sleep 2
done
aws stepfunctions describe-execution \
  --execution-arn "$RETRY_ARN" \
  --query '{Status:status,Output:output}'
aws stepfunctions get-execution-history \
  --execution-arn "$RETRY_ARN" \
  --query 'events[?type==`TaskFailed` || type==`TaskSucceeded`].{Type:type,Error:taskFailedEventDetails.error}'
aws dynamodb get-item \
  --table-name labex-ev04-orders \
  --key '{"id":{"S":"retry-order"}}' \
  --query Item
aws dynamodb get-item \
  --table-name labex-ev04-attempts \
  --key '{"id":{"S":"retry-order"}}' \
  --query Item

Итоговый статус — SUCCEEDED с завершённой сводкой 2/600. История имеет один TaskFailed с TransientOrderError, затем два события TaskSucceeded: успешное сохранение и чтение сводки. Заказ в сервисе имеет количество 2 и сумму 600, а диагностическое число попыток равно 2. Повторная попытка и бизнес-запись — разные счётчики.

Теперь используйте режим постоянной ошибки обработчика:

PERMANENT_ARN=$(aws stepfunctions start-execution \
  --state-machine-arn "$MACHINE_ARN" \
  --name permanent-order \
  --input '{"id":"permanent-order","quantity":2,"mode":"permanent"}' \
  --query executionArn \
  --output text)
for attempt in $(seq 1 30); do
  STATUS=$(aws stepfunctions describe-execution \
    --execution-arn "$PERMANENT_ARN" \
    --query status \
    --output text)
  if test "$STATUS" != RUNNING; then break; fi
  sleep 2
done
aws stepfunctions describe-execution \
  --execution-arn "$PERMANENT_ARN" \
  --query '{Status:status,Error:error}'
aws stepfunctions get-execution-history \
  --execution-arn "$PERMANENT_ARN" \
  --query 'events[?type==`TaskFailed` || type==`FailStateEntered`].{Type:type,Error:taskFailedEventDetails.error,State:stateEnteredEventDetails.name}'
aws dynamodb get-item \
  --table-name labex-ev04-orders \
  --key '{"id":{"S":"permanent-order"}}' \
  --query Item

Один реальный вызов обработчика завершается InvalidOrder; Catch достигает Rejected, а выполнение заканчивается FAILED с OrderRejected. Повторение временной ошибки не совпадает с этой постоянной ошибкой. Бизнес-записи permanent-order нет.

Наконец удалите только разрешение вызова процесса. Ваш оператор может запускать выполнения, но роль процесса не может вызвать обработчик:

aws iam delete-role-policy --role-name labex-ev04-workflow-role --policy-name InvokeWorker
DENIED_ARN=$(aws stepfunctions start-execution \
  --state-machine-arn "$MACHINE_ARN" \
  --name denied-order \
  --input '{"id":"denied-order","quantity":2,"mode":"flaky"}' \
  --query executionArn \
  --output text)
for attempt in $(seq 1 30); do
  STATUS=$(aws stepfunctions describe-execution \
    --execution-arn "$DENIED_ARN" \
    --query status \
    --output text)
  if test "$STATUS" != RUNNING; then break; fi
  sleep 2
done
aws stepfunctions describe-execution \
  --execution-arn "$DENIED_ARN" \
  --query '{Status:status,Error:error}'
aws dynamodb get-item \
  --table-name labex-ev04-orders \
  --key '{"id":{"S":"denied-order"}}' \
  --query Item
aws iam put-role-policy \
  --role-name labex-ev04-workflow-role \
  --policy-name InvokeWorker \
  --policy-document file://workflow-invoke.json

Это выполнение с отказом в доступе завершается ошибкой без вызова обработчика или создания диагностических и бизнес-данных. Повторение указанной ошибки приложения не исправляет отсутствие авторизации. Нужное разрешение восстановлено. AWS View показывает успешную сводку повторной попытки и две ошибки рядом с единственным заказом.

Пример ниже показывает реальную сводку повторной попытки, постоянную ошибку и запрещённое выполнение рядом с сохранённым заказом.

AWS View показывает реальный успех повторной попытки и постоянную ошибку

Выполните проверку реального восстановления.

Удаление ресурсов процесса и синтетических результатов

На этом шаге удалите завершённую машину, роль процесса, заказ и журналы, сохранив предоставленные ресурсы.

Все три выполнения завершены. Удаление машины исключает её из списка активных машин. Удалите политику роли упражнения перед удалением роли, затем удалите синтетический заказ и группу журналов обработчика, созданную вашим выполнением.

aws stepfunctions delete-state-machine --state-machine-arn "$MACHINE_ARN"
aws iam delete-role-policy --role-name labex-ev04-workflow-role --policy-name InvokeWorker
aws iam delete-role --role-name labex-ev04-workflow-role
aws dynamodb delete-item --table-name labex-ev04-orders --key '{"id":{"S":"retry-order"}}'
aws dynamodb delete-item \
  --table-name labex-ev04-attempts \
  --key '{"id":{"S":"retry-order"}}'
aws logs delete-log-group --log-group-name /aws/lambda/labex-ev04-worker

Прочитайте успешные перечни, чтобы доказать оставшиеся ресурсы:

aws stepfunctions list-state-machines
aws iam list-roles --query 'Roles[].RoleName'
aws dynamodb scan --table-name labex-ev04-orders --query Items
aws logs describe-log-groups --query logGroups
aws dynamodb scan --table-name labex-ev04-reference --query Items

Активных машин, заказов или групп журналов нет. Остаётся только предоставленная роль обработчика, а эталонная запись неизменна. Сохраните предоставленные обработчик и таблицы: ответственность за их подготовку отличается от ваших созданных ресурсов процесса. Ошибки сети или аутентификации никогда не доказывают удаление.

Удалите обычные файлы, созданные в этой работе:

rm -f workflow-trust.json workflow-invoke.json workflow-template.json workflow.json

AWS View показывает пустые списки машин, выполнений и заказов и сохранённый эталон. Выполните проверку очистки перед завершением VM.

Резюме

Вы настроили ограниченные повторные попытки для конкретной временной ошибки и Catch с явным постоянным отказом. История сервиса и действительные заказы различили попытки и бизнес-записи; отказ в разрешении не создал выполнения обработчика или бизнес-эффекта. Вы удалили ресурсы и результаты процесса упражнения, сохранив предоставленные ресурсы.

Следующая работа обрабатывает ошибку после бизнес-записи, когда повторная попытка может повторить её эффект.

Связанные AWS Курсы
Основы AWS для начинающих

Основы AWS для начинающих

aws
AWS S3 для начинающих

AWS S3 для начинающих

aws
AWS IAM для начинающих

AWS IAM для начинающих

aws