Управление версиями в устойчивых функциях (Функции Azure) — общедоступная предварительная версия

Управление версиями оркестрации устраняет основную проблему развертывания изменений в функциях оркестратора при сохранении детерминированной модели выполнения, требующей устойчивых функций. Без этой функции изменения в логике оркестратора или сигнатурах функций действия могут привести к сбою экземпляров оркестрации во время воспроизведения, так как они нарушают требование детерминизма, обеспечивающее надежное исполнение оркестрации. Эта встроенная функция обеспечивает автоматическую изоляцию версий с минимальной конфигурацией. Она не зависит от серверной части, поэтому она может использоваться приложениями, используюющими любой из поставщиков хранилища устойчивых функций, включая планировщик устойчивых задач.

Terminology

В этой статье используются два связанных, но отдельных термина:

• Функция Orchestrator (или просто orchestrator): ссылается на код функции, определяющий логику рабочего процесса — шаблон или схему выполнения рабочего процесса.
• Экземпляр оркестрации (или просто "оркестрация"): обозначает конкретное выполнение функции оркестратора с собственным состоянием, ID экземпляра и входными данными. Несколько экземпляров оркестрации могут выполняться одновременно из одной функции оркестратора.

Понимание этого различия имеет решающее значение для версионирования оркестрации, в котором код функции оркестратора содержит логику, учитывающую версии, а экземпляры оркестрации постоянно связаны с определенной версией при их создании.

Принцип работы

Функция управления версиями оркестрации работает по этим основным принципам:

• Связь версий: при создании экземпляра оркестрации она получает версию, которая постоянно связана с ней.

• Выполнение с учетом версии: код функции Orchestrator может изучить значение версии, связанное с текущим экземпляром оркестрации, и разветвлять выполнение соответствующим образом.

• Обратная совместимость. Рабочие, работающие под управлением более новых версий оркестратора, могут продолжать выполнять экземпляры оркестрации, созданные более старыми версиями оркестратора.

• Защита пересылки: среда выполнения автоматически запрещает рабочим, работающим с более ранними версиями оркестратора, выполнять оркестрации, запущенные более новыми версиями оркестратора.

Предпосылки

Перед использованием версионирования оркестрации убедитесь, что у вас есть необходимые версии пакетов для вашего языка программирования.

Если вы используете язык non-.NET (JavaScript, Python, PowerShell или Java) с пакетами расширений, приложение-функция должна ссылаться на пакет расширений версии 4.26.0 или более поздней версии. Настройте диапазон extensionBundle в host.json, чтобы минимальная версия была не менее 4.26.0, например:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.26.0, 5.0.0)"
    }
}

Дополнительные сведения о выборе и обновлении версий пакета см. в документации по конфигурации пакета расширений .

Базовое использование

Наиболее распространенный вариант использования для управления версиями заключается в том, что необходимо внести критические изменения в логику оркестратора, сохраняя существующие экземпляры оркестрации, работающие с исходной версией. Все, что вам нужно сделать, — обновить defaultVersion в вашем host.json и изменить код оркестратора, чтобы проверить версию оркестрации и осуществить разветвление выполнения соответствующим образом. Давайте рассмотрим необходимые действия.

Шаг 1: Конфигурация параметра defaultVersion

Чтобы настроить версию по умолчанию для оркестрации, необходимо добавить или обновить параметр defaultVersion в файле host.json в проекте Azure Functions.

{
  "extensions": {
    "durableTask": {
      "defaultVersion": "<version>"
    }
  }
}

Строка версии может соответствовать любому формату, который соответствует стратегии управления версиями:

• Многочастное версионирование: "1.0.0", "2.1.0"
• Простое нумерирование: "1", "2"
• На основе даты: "2025-01-01"
• Пользовательский формат: "v1.0-release"

После настройки defaultVersion все новые экземпляры оркестрации будут постоянно связаны с этой версией.

Правила сравнения версий

При выборе стратегии Strict или CurrentOrOlder (см. Сопоставление версий), среда выполнения сравнивает версию экземпляра оркестрации со значением defaultVersion рабочей роли, используя следующие правила:

• Пустые или нулевые версии рассматриваются как равные.
• Пустая или нулевая версия считается более ранней, чем любая определенная версия.
• Если оба варианта могут быть интерпретированы как System.Version, используется метод CompareTo.
• В противном случае выполняется сравнение строк без учета регистра.

Шаг 2: Логика функции «Orchestrator»

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

[Function("MyOrchestrator")]
public static async Task<string> RunOrchestrator(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    if (context.Version == "1.0")
    {
        // Original logic for version 1.0
        ...
    }
    else if (context.Version == "2.0")
    {
        // New logic for version 2.0
        ...
    }
    ...
}

const df = require("durable-functions");

df.app.orchestrator(function* (context) {
    if (context.df.version === "1.0") {
        // Original logic for version 1.0
        // ...
    } else if (context.df.version === "2.0") {
        // New logic for version 2.0
        // ...
    }
    // ...
});

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.FUNCTION)

@myApp.orchestration_trigger(context_name="context")
def orchestrator_function(context: df.DurableOrchestrationContext):
    if context.version == "1.0":
        # Original logic for version 1.0
        # ...
    elif context.version == "2.0":
        # New logic for version 2.0
        # ...
    # ...

param($Context)

if ($Context.Version -eq "1.0") {
    # Original logic for version 1.0
    # ...
} elseif ($Context.Version -eq "2.0") {
    # New logic for version 2.0
    # ...
}
# ...

@FunctionName("MyOrchestrator")
public String myOrchestrator(
    @DurableOrchestrationTrigger(name = "context") 
    TaskOrchestrationContext context) {
    
    String version = context.getVersion();
    if ("1.0".equals(version)) {
        // Original logic for version 1.0
        // ...
    } else if ("2.0".equals(version)) {
        // New logic for version 2.0
        // ...
    }
    // ...
}

• C#: context.Version == null или context.Version is null
• JavaScript: context.df.version == null
• Питон: context.version is None
• PowerShell: $null -eq $Context.Version
• Java: context.getVersion() == null Также обратите внимание, что указание "defaultVersion": null в host.json эквивалентно тому, чтобы не указывать его вовсе.

Что происходит после развертывания

Вот что ожидать после развертывания обновленной функции оркестратора с новой логикой версии:

• Сосуществование рабочих: рабочие, содержащие новый код функции оркестратора, начнут работу, в то время как некоторые рабочие со старым кодом все еще могут быть активными.

• Назначение версии для новых экземпляров: всем новым оркестрациям и вложенным оркестрациям, созданным новыми работниками, будет назначена версия из defaultVersion.

• Новая совместимость рабочих: новые рабочие смогут обрабатывать как только что созданные оркестрации, так и ранее существующие оркестрации, так как изменения, выполненные на шаге 2 предыдущего раздела, обеспечивают обратную совместимость с помощью логики ветвления с учетом версий.

• Старые ограничения рабочей роли: старые работники смогут обрабатывать только оркестрации с версией , равной или ниже версии, указанной в собственном defaultVersionhost.jsonкоде, так как они не должны иметь код оркестратора, совместимый с более новыми версиями. Это ограничение предотвращает ошибки выполнения и непредвиденное поведение.

Пример. Замена действия в последовательности

В этом примере показано, как заменить одно действие другим в середине последовательности, используя оркестрацию версий.

Версия 1.0

Конфигурация host.json:

{
  "extensions": {
    "durableTask": {
      "defaultVersion": "1.0"
    }
  }
}

Функция Оркестратор:

[Function("ProcessOrderOrchestrator")]
public static async Task<string> ProcessOrder(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var orderId = context.GetInput<string>();
    
    await context.CallActivityAsync("ValidateOrder", orderId);
    await context.CallActivityAsync("ProcessPayment", orderId);
    await context.CallActivityAsync("ShipOrder", orderId);
    
    return "Order processed successfully";
}

const df = require("durable-functions");

df.app.orchestrator(function* (context) {
    const orderId = context.df.getInput();
    
    yield context.df.callActivity("ValidateOrder", orderId);
    yield context.df.callActivity("ProcessPayment", orderId);
    yield context.df.callActivity("ShipOrder", orderId);
    
    return "Order processed successfully";
});

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.FUNCTION)

@myApp.orchestration_trigger(context_name="context")
def orchestrator_function(context: df.DurableOrchestrationContext):
    order_id = context.get_input()
    
    yield context.call_activity("ValidateOrder", order_id)
    yield context.call_activity("ProcessPayment", order_id)
    yield context.call_activity("ShipOrder", order_id)
    
    return "Order processed successfully"

param($Context)

$orderId = $Context.Input

Invoke-DurableActivity -FunctionName "ValidateOrder" -Input $orderId
Invoke-DurableActivity -FunctionName "ProcessPayment" -Input $orderId
Invoke-DurableActivity -FunctionName "ShipOrder" -Input $orderId

return "Order processed successfully"

@FunctionName("ProcessOrderOrchestrator")
public String processOrder(
    @DurableOrchestrationTrigger(name = "context") 
    TaskOrchestrationContext context) {
    
    String orderId = context.getInput(String.class);
    
    context.callActivity("ValidateOrder", orderId).await();
    context.callActivity("ProcessPayment", orderId).await();
    context.callActivity("ShipOrder", orderId).await();
    
    return "Order processed successfully";
}

Версия 2.0 с обработкой скидки

Конфигурация host.json:

{
  "extensions": {
    "durableTask": {
      "defaultVersion": "2.0"
    }
  }
}

Функция Оркестратор:

using DurableTask.Core.Settings;

[Function("ProcessOrderOrchestrator")]
public static async Task<string> ProcessOrder(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var orderId = context.GetInput<string>();

    await context.CallActivityAsync("ValidateOrder", orderId);

    if (VersioningSettings.CompareVersions(context.Version, "1.0") <= 0)
    {
        // Preserve original logic for existing instances
        await context.CallActivityAsync("ProcessPayment", orderId);
    }
    else // a higher version (including 2.0)
    {
        // New logic with discount processing (replaces payment processing)
        await context.CallActivityAsync("ApplyDiscount", orderId);
        await context.CallActivityAsync("ProcessPaymentWithDiscount", orderId);
    }
    
    await context.CallActivityAsync("ShipOrder", orderId);

    return "Order processed successfully";
}

const df = require("durable-functions");
import semver from 'semver';

df.app.orchestrator(function* (context) {
    const orderId = context.df.getInput();

    yield context.df.callActivity("ValidateOrder", orderId);

    if (compareVersions(context.df.version, "1.0") <= 0) {
        // Preserve original logic for existing instances
        yield context.df.callActivity("ProcessPayment", orderId);
    } else {
        // New logic with discount processing (replaces payment processing)
        yield context.df.callActivity("ApplyDiscount", orderId);
        yield context.df.callActivity("ProcessPaymentWithDiscount", orderId);
    }
    
    yield context.df.callActivity("ShipOrder", orderId);

    return "Order processed successfully";
});

function compareVersions(version1, version2) {
  // Feel free to implement your own version comparison logic
  const v1 = semver.coerce(version1);
  const v2 = semver.coerce(version2);

  if (!v1 || !v2) {
    throw new Error(`Invalid version string(s): "${version1}" vs "${version2}"`);
  }
  return semver.compare(v1, v2);
}

import azure.functions as func
import azure.durable_functions as df
from packaging import version

myApp = df.DFApp(http_auth_level=func.AuthLevel.FUNCTION)

@myApp.orchestration_trigger(context_name="context")
def orchestrator_function(context: df.DurableOrchestrationContext):
    order_id = context.get_input()

    yield context.call_activity("ValidateOrder", order_id)

    if compare_versions(context.version, "1.0") <= 0:
        # Preserve original logic for existing instances
        yield context.call_activity("ProcessPayment", order_id)
    else:
        # New logic with discount processing (replaces payment processing)
        yield context.call_activity("ApplyDiscount", order_id)
        yield context.call_activity("ProcessPaymentWithDiscount", order_id)
    
    yield context.call_activity("ShipOrder", order_id)

    return "Order processed successfully"

def compare_versions(version1, version2):
    # Feel free to implement your own version comparison logic
    v1 = version.parse(version1)
    v2 = version.parse(version2)

    if v1 < v2:
        return -1
    elif v1 > v2:
        return 1
    return 0

param($Context)

$orderId = $Context.Input

Invoke-DurableActivity -FunctionName "ValidateOrder" -Input $orderId

if (Compare-Version $Context.Version "1.0" -le 0) {
    # Preserve original logic for existing instances
    Invoke-DurableActivity -FunctionName "ProcessPayment" -Input $orderId
} else {
    # New logic with discount processing (replaces payment processing)
    Invoke-DurableActivity -FunctionName "ApplyDiscount" -Input $orderId
    Invoke-DurableActivity -FunctionName "ProcessPaymentWithDiscount" -Input $orderId
}

Invoke-DurableActivity -FunctionName "ShipOrder" -Input $orderId

return "Order processed successfully"

function Compare-Version([string]$version1, [string]$version2) {
    # Feel free to implement your own version comparison logic
    $v1 = [Version]$version1
    $v2 = [Version]$version2

    if ($v1 -lt $v2) { return -1 }
    elseif ($v1 -gt $v2) { return 1 }
    else { return 0 }
}

import org.apache.maven.artifact.versioning.ComparableVersion;

@FunctionName("ProcessOrderOrchestrator")
public String processOrder(
    @DurableOrchestrationTrigger(name = "taskOrchestrationContext") 
    TaskOrchestrationContext context) {
    
    String orderId = context.getInput(String.class);

    context.callActivity("ValidateOrder", orderId).await();

    if (compareVersions(context.getVersion(), "1.0") <= 0) {
        // Preserve original logic for existing instances
        context.callActivity("ProcessPayment", orderId).await();
    } else {
        // New logic with discount processing (replaces payment processing)
        context.callActivity("ApplyDiscount", orderId).await();
        context.callActivity("ProcessPaymentWithDiscount", orderId).await();
    }
    
    context.callActivity("ShipOrder", orderId).await();

    return "Order processed successfully";
}

private int compareVersions(String version1, String version2) {
    // Feel free to implement your own version comparison logic
    ComparableVersion v1 = new ComparableVersion(version1);
    ComparableVersion v2 = new ComparableVersion(version2);
    return v1.compareTo(v2);
}

Расширенное использование

Для более сложных сценариев управления версиями можно настроить другие параметры для управления соответствием и несоответствиям версии среды выполнения.

Сопоставление версий

Параметр versionMatchStrategy определяет, как среда выполнения соответствует версиям оркестрации при загрузке функций оркестратора. Он контролирует, обработку каких экземпляров оркестрации может выполнять рабочий в зависимости от совместимости с версиями.

Configuration

{
  "extensions": {
    "durableTask": {
      "defaultVersion": "<version>",
      "versionMatchStrategy": "CurrentOrOlder"
    }
  }
}

Доступные стратегии

• None (не рекомендуется): полностью игнорировать версию оркестрации. Все полученные работы обрабатываются независимо от версии. Эта стратегия эффективно отключает проверку версий и позволяет любому рабочему сотруднику обрабатывать любой экземпляр оркестрации.

• Strict: обрабатываются только задачи из оркестрации с точно такой же версией, как указано в defaultVersion в рабочем процессе host.json. Эта стратегия обеспечивает высокий уровень изоляции версий, но требует тщательной координации развертывания, чтобы избежать оставленных без управления оркестраций. Последствия несоответствия версий описаны в разделе обработки несоответствия версий .

• CurrentOrOlder (по умолчанию): обработка задач из оркестрации, чья версия меньше или равна версии, указанной defaultVersion в рабочем host.json. Эта стратегия позволяет обеспечить обратную совместимость, позволяя новым работникам обрабатывать оркестрации, запущенные более старыми версиями оркестратора, не позволяя старым работникам обрабатывать более новые оркестрации. Последствия несоответствия версий описаны в разделе обработки несоответствия версий .

Обработка несоответствия версий

Параметр versionFailureStrategy определяет, что происходит, если версия экземпляра оркестрации не соответствует текущей defaultVersion.

Configuration:

{
  "extensions": {
    "durableTask": {
      "defaultVersion": "<version>",
      "versionFailureStrategy": "Reject"
    }
  }
}

Доступные стратегии:

• Reject (по умолчанию): не нужно обрабатывать оркестрацию. Экземпляр оркестрации остается в текущем состоянии и может быть повторно запущен позже, когда совместимый рабочий станет доступным. Эта стратегия является самым безопасным вариантом, так как она сохраняет состояние оркестрации.

• Fail: сбой оркестрации. Эта стратегия немедленно завершает экземпляр оркестрации с состоянием сбоя, которое может быть уместно в сценариях, когда несоответствия версий указывают на серьезные проблемы с развертыванием.

Запуск новых оркестраций и вложенных оркестраций с определенными версиями

По умолчанию все новые экземпляры оркестрации создаются с текущим defaultVersion значением, указанным в host.json конфигурации. Однако у вас могут быть сценарии, в которых необходимо создать оркестрации с определенной версией, даже если она отличается от текущей версии по умолчанию.

Когда следует использовать определенные версии:

• Постепенная миграция: вы хотите продолжать создавать оркестрации с более старой версией даже после развертывания более новой версии.
• Сценарии тестирования. Необходимо проверить поведение конкретной версии в рабочей среде.
• Ситуации отката: необходимо временно вернуться к созданию экземпляров с предыдущей версией.
• Рабочие процессы для конкретной версии: для различных бизнес-процессов требуются разные версии оркестрации.

Вы можете переопределить версию по умолчанию, предоставив определенное значение версии при создании новых экземпляров оркестрации с помощью API клиента оркестрации. Это позволяет детально управлять тем, какую версию использует каждый новый экземпляр оркестрации.

[Function("HttpStart")]
public static async Task<HttpResponseData> HttpStart(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req,
    [DurableClient] DurableTaskClient client,
    FunctionContext executionContext)
{
    var options = new StartOrchestrationOptions
    {
        Version = "1.0"
    };
    
    string instanceId = await client.ScheduleNewOrchestrationInstanceAsync("ProcessOrderOrchestrator", orderId, options);

    // ...
}

@FunctionName("HttpStart")
public HttpResponseMessage httpStart(
    @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
    HttpRequestMessage<Optional<String>> request,
    @DurableClientInput(name = "durableContext") 
    DurableClientContext durableContext,
    final ExecutionContext context) {
    
    DurableTaskClient client = durableContext.getClient();

    NewOrchestrationInstanceOptions options = new NewOrchestrationInstanceOptions().setVersion("1.0");

    String instanceId = client.scheduleNewOrchestrationInstance("ProcessOrderOrchestrator", orderId, options);

    // ...
}

Вы также можете запускать подоркестрации с использованием определённых версий через функцию оркестратора.

[Function("MainOrchestrator")]
public static async Task<string> RunMainOrchestrator(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var subOptions = new SubOrchestratorOptions
    {
        Version = "1.0"
    };
    
    var result = await context.CallSubOrchestratorAsync<string>("ProcessPaymentOrchestrator", orderId, subOptions);
    
    // ...
}

@FunctionName("MainOrchestrator")
public String runMainOrchestrator(
    @DurableOrchestrationTrigger(name = "taskOrchestrationContext") 
    TaskOrchestrationContext context) {

    NewSubOrchestrationInstanceOptions subOptions = new NewSubOrchestrationInstanceOptions().setVersion("1.0");

    String result = context.callSubOrchestrator("ProcessPaymentOrchestrator", orderId, String.class, subOptions).await();
    
    // ...
}

Удаление устаревших путей кода

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

Когда безопасно удалять устаревший код:

• Все экземпляры оркестрации с использованием старой версии завершены (выполнено успешно, не удалось или было завершено)
• Новые экземпляры оркестрации не будут созданы по старой версии
• Вы проверили с помощью мониторинга или запроса, что ни один экземпляр не работает на устаревшей версии.
• Достаточное время прошло с момента последнего развертывания старой версии (учитывая требования к непрерывности бизнес-процессов).

Рекомендации по удалению:

• Отслеживайте активные экземпляры: используйте API управления устойчивыми функциями для запроса экземпляров с использованием определенных версий.
• Задайте политики хранения. Определите, сколько времени планируется поддерживать обратную совместимость для каждой версии.
• Удаляйте постепенно: попробуйте удалить одну версию за раз, а не несколько версий одновременно.
• Удаление документов: сохраняйте четкие записи о том, когда были удалены версии и почему.

Лучшие практики

Управление версиями

• Используйте многокомпонентное управление версиями: применяйте согласованную схему управления версиями, например major.minor.patch.
• Критические изменения в документе: четко документируйте, какие изменения требуют новой версии.
• Управление жизненным циклом версии: определите время удаления устаревших участков кода.

Организация кода

• Отдельная логика версий: используйте четкое разветвление или разделенные методы для разных версий.
• Сохранение детерминизма: не изменяйте существующую логику версии после развертывания. Если изменения абсолютно необходимы (например, критически важные исправления ошибок), убедитесь, что они поддерживают детерминированное поведение и не изменяют последовательность операций, иначе можно ожидать, что более новые версии оркестратора могут завершиться ошибкой при обработке старых оркестраций.
• Тщательно протестируйте все пути версий, особенно во время переходов.

Мониторинг и наблюдаемость

• Информация о версии: включите версию в логирование для упрощения отладки.
• Мониторинг распространения версий: отслеживайте, какие версии активно выполняются.
• Настройка оповещений: мониторинг любых ошибок, связанных с версиями.

Troubleshooting

Общие проблемы

• Проблема: Экземпляры оркестрации, созданные с версией 1.0, вызывают сбой после развертывания версии 2.0

  • Решение. Убедитесь, что путь кода версии 1.0 в оркестраторе остается точно таким же. Любые изменения последовательности выполнения могут нарушить детерминированное воспроизведение.

• Проблема. Рабочие, работающие под управлением более старых версий оркестратора, не могут выполнять новые оркестрации

  • Решение. Это ожидаемое поведение. Среда выполнения намеренно запрещает старым работникам выполнять оркестрации с более новыми версиями для обеспечения безопасности. Убедитесь, что все работники обновляются до последней версии оркестратора и defaultVersion их параметры host.json обновляются соответствующим образом. Это поведение можно изменить при необходимости с помощью расширенных параметров конфигурации (дополнительные сведения см. в разделе "Дополнительное использование ").

• Проблема: сведения о версии недоступны в оркестраторе (context.Version или context.getVersion() имеет значение NULL, независимо от defaultVersion параметра)

  • Решение: Проверьте раздел Предварительные требования, чтобы убедиться, что среда соответствует всем требованиям для версионирования оркестрации.

• Проблема. Оркестрации более новой версии делают очень медленный прогресс или полностью застряли

  • Решение. Проблема может иметь различные первопричины:
    1. Недостаточно новых работников: убедитесь, что достаточное количество работников с равной или более высокой версией defaultVersion развертываются и активны для обработки новых оркестраций.
    2. Вмешательство старых работников в маршрутизацию оркестрации: старые работники могут мешать работе механизма маршрутизации оркестрации, что затрудняет новым работникам получение оркестраций для обработки. Это может быть особенно заметно при использовании определенных поставщиков хранилища (службы хранилища Azure или MSSQL). Как правило, платформа Функций Azure гарантирует, что старые работники удаляются вскоре после развертывания, поэтому любая задержка, как правило, не является значительной. Однако если вы используете конфигурацию, которая позволяет управлять жизненным циклом старых процессов, убедитесь, что старые процессы в конечном итоге отключаются. Кроме того, рекомендуется использовать планировщик устойчивых задач, так как он предоставляет улучшенный механизм маршрутизации, который менее подвержен этой проблеме.

Дальнейшие шаги