Веб-приложения PSGI/Plack — бесплатный тест онлайн

Вопрос 1 из 30

Какой прогноз для кода с `$app` и `$env` выдержит пошаговую проверку?

my $app=sub{ my $env=shift; return [200,['Content-Type'=>'text/plain'],['ok']] };

Для результата здесь достаточно учесть лишь такое условие: PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера. PSGI-приложение получает окружение и возвращает трёхэлементный ответ: статус, заголовки и итерируемое тело. Показанный участок сработает иначе: Заголовки должны быть плоским массивом, а тело — массивом/объектом, не обычной строкой. PSGI-приложение получает окружение и не возвращает трёхэлементный ответ: статус, заголовки и итерируемое тело. Дополнительное изменение не требуется, поскольку код уже обеспечивает следующее: Форма ответа соответствует PSGI; $body должен быть закодирован в байты согласно заголовку.

Вопрос 2 из 30

Какое утверждение точно описывает поведение фрагмента «Промежуточные обработчики» с `$app`?

builder { enable 'ContentLength'; enable 'AccessLog'; $app };

Middleware образуют вложенную цепочку; порядок влияет на то, какой ответ, но не время видит каждый слой. Исходная реализация уже содержит нужную защиту: Слои расположены по зависимостям: сессия доступна авторизации и защите изменения состояния. Middleware образуют вложенную цепочку; порядок влияет на то, какой ответ и время видит каждый слой. В показанном случае решающим становится только ограничение: Общий eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту. Непосредственным итогом выполнения будет: Если авторизация ожидает уже загруженную сессию, обратный порядок может сделать пользователя анонимным.

Вопрос 3 из 30

Какой вывод следует непосредственно из операций примера «Маршрутизация»?

if($env->{PATH_INFO}=~m{\A/users/(\d+)\z}){ return user($1) }

Для результата здесь достаточно учесть лишь такое условие: PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера. Главным результатом фрагмента станет следующее: Путь запроса нельзя превращать в имя загружаемого файла или модуля. Показанная версия изначально работает как исправленная: Метод и нормализованный путь выбирают обработчик из закрытой таблицы. Маршрут принимает только числовой идентификатор и не проверяет весь PATH_INFO. Маршрут принимает только числовой идентификатор и проверяет весь PATH_INFO.

Вопрос 4 из 30

Что непосредственно следует из показанного кода с `$req`, `$env` и `$id`?

my $req=Plack::Request->new($env);
my $id=$req->header('X-Request-ID')||new_id();
local $ctx={id=>$id};

Контекст запроса создаётся на входе и локализуется, чтобы не протекать между запросами долгоживущего процесса. Контекст запроса создаётся на входе, но не локализуется, чтобы не протекать между запросами долгоживущего процесса. В показанном случае решающим становится только ограничение: Подготовленные при старте неизменяемые объекты можно разделять, а изменяемое состояние запроса — нельзя. В этой версии кода возникает другой результат: Пакетная глобальная переменная может сохранить пользователя между конкурентными или последовательными запросами. Текущее поведение совпадает с результатом предлагаемой правки: Контекст передаётся явно по стеку вызовов и не разделяется между запросами.

Вопрос 5 из 30

Какое описание не теряет важный побочный эффект участка с `$safe_app`, `$env` и `@_`?

my $safe_app = sub {
    my ($env) = @_;
    my $response = eval { $app->($env) };
    return $response if $response;

    my $error = $@ || 'unknown error';
    log_failure($env->{'psgix.request_id'}, $error);
    return [500, ['Content-Type' => 'text/plain'], ['Internal Server Error']];
};

Для результата здесь достаточно учесть лишь такое условие: После начала потоковой передачи изменить статус на 500 уже нельзя; ошибка должна завершить поток по протоколу и попасть в наблюдаемость. Даже без правки фрагмент уже даёт гарантию исправленного варианта: Подробности остаются в защищённом журнале, клиент получает нейтральное сообщение и идентификатор. Аварийная граница возвращает 500, но перед этим должна сохранить корреляционный идентификатор и не раскрывать текст исключения клиенту. Главным результатом фрагмента станет следующее: Ответ публикует внутренние пути, SQL и возможные секреты из исключения. Аварийная граница не возвращает 500, но перед этим должна сохранить корреляционный идентификатор и не раскрывать текст исключения клиенту.

Вопрос 6 из 30

Как завершится этот код по правилам Perl 5.40?

my $ready = db_ping() && queue_ping();

Непосредственным итогом выполнения будет: Грубое восстановление завершает все Perl-процессы, включая здоровые приложения, и скрывает первопричину. В показанном коде «Восстановление системы» проявляется другой эффект: грубое восстановление завершает все Perl-процессы, включая здоровые приложения, и скрывает первопричину. Итог этого фрагмента полностью задаёт следующая оговорка: Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации. Проверка готовности отражает способность обслуживать трафик, но частые дорогие запросы сами могут перегрузить зависимости. Текущее поведение совпадает с результатом предлагаемой правки: Восстановление ограничено одним экземпляром, проверяется перед возвратом трафика и сохраняет возможность отката.

Вопрос 7 из 30

Какой риск связан именно с операциями ключевыми операциями?

return [200,{'Content-Type'=>'text/plain'},'ok'];

Причину отказа точнее описывает соседняя граница темы: PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера. Источником дефекта становится само изменение: Форма ответа соответствует PSGI; $body должен быть закодирован в байты согласно заголовку. Показанный код уже соблюдает правило «Приложение не должно полагаться на глобальные CGI-переменные: все данные запроса приходят через $env», поэтому отдельного дефекта нет. Дефект объясняется базовым поведением фрагмента: PSGI-приложение получает окружение и возвращает трёхэлементный ответ: статус, заголовки и итерируемое тело. Заголовки должны быть плоским массивом, а тело — массивом/объектом, не обычной строкой.

Вопрос 8 из 30

Какой отказ объясняется показанным кодом, а не внешней системой?

enable 'Session'; enable 'Auth';

Причину отказа точнее описывает соседняя граница темы: Общий eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту. Если авторизация ожидает уже загруженную сессию, обратный порядок не может сделать пользователя анонимным. Если авторизация ожидает уже загруженную сессию, обратный порядок может сделать пользователя анонимным. Основная проблема здесь — сам результат штатного случая: Middleware образуют вложенную цепочку; порядок влияет на то, какой ответ и время видит каждый слой. Риск появляется после применения рекомендуемой правки: Слои расположены по зависимостям: сессия доступна авторизации и защите изменения состояния.

Вопрос 9 из 30

Где находится первопричина возможного сбоя в коде с `$env` и `$prefix`?

if($env->{PATH_INFO}=~/$prefix/){ require $env->{PATH_INFO} }

Причину отказа точнее описывает соседняя граница темы: PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера. Проблема возникает в исправленном варианте: Метод и нормализованный путь выбирают обработчик из закрытой таблицы. Дефект объясняется базовым поведением фрагмента: Маршрут принимает только числовой идентификатор и проверяет весь PATH_INFO. Путь запроса нельзя превращать в имя загружаемого файла или модуля. Показанный код уже соблюдает правило «Маршрутизация должна учитывать HTTP-метод, декодирование пути, приоритет статических и параметрических маршрутов и ответ 405 отдельно от 404», поэтому отдельного дефекта нет.

Вопрос 10 из 30

Какой риск связан именно с операциями `$current_user` и `$req`?

our $current_user=$req->user;

Дефект объясняется базовым поведением фрагмента: Контекст запроса создаётся на входе и локализуется, чтобы не протекать между запросами долгоживущего процесса. Пакетная глобальная переменная не может сохранить пользователя между конкурентными или последовательными запросами. Источником дефекта становится само изменение: Контекст передаётся явно по стеку вызовов и не разделяется между запросами. Существенная проблема здесь связана с иной границей: Подготовленные при старте неизменяемые объекты можно разделять, а изменяемое состояние запроса — нельзя. Пакетная глобальная переменная может сохранить пользователя между конкурентными или последовательными запросами.

Вопрос 11 из 30

Какой диагноз точнее всего относится к участку с ключевыми операциями?

return [500,['Content-Type'=>'text/plain'],[$@]];

Существенная проблема здесь связана с иной границей: После начала потоковой передачи изменить статус на 500 уже нельзя; ошибка должна завершить поток по протоколу и попасть в наблюдаемость. Показанный код уже соблюдает правило «Разбор отказа связывает журнал приложения, статус сервера, время запроса, внешние зависимости и факт частичной отправки ответа», поэтому отдельного дефекта нет. Риск возникает уже в обычном результате: Аварийная граница возвращает 500, но перед этим должна сохранить корреляционный идентификатор и не раскрывать текст исключения клиенту. Ответ публикует внутренние пути, SQL и возможные секреты из исключения. Нежелательное поведение вводит предлагаемое решение: Подробности остаются в защищённом журнале, клиент получает нейтральное сообщение и идентификатор.

Вопрос 12 из 30

Какое скрытое допущение ломает контракт примера «Восстановление системы»?

system('killall','perl');

Сбой создаёт именно предложенное исправление: Восстановление ограничено одним экземпляром, проверяется перед возвратом трафика и сохраняет возможность отката. Грубое восстановление завершает все Perl-процессы, включая здоровые приложения, и скрывает первопричину. Показанный код уже соблюдает правило «План восстановления включает прекращение приёма новых запросов, завершение активных, перезапуск, проверку миграций и постепенный возврат трафика», поэтому отдельного дефекта нет. Главный риск этого участка задаёт другое ограничение механизма: Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации. Причина сбоя совпадает с обычным результатом примера: Проверка готовности отражает способность обслуживать трафик, но частые дорогие запросы сами могут перегрузить зависимости.

Вопрос 13 из 30

Что изменилось в работе фрагмента «Протокол PSGI»?

return [200,['Content-Type'=>'text/plain; charset=utf-8'],[$body]];

Форма ответа соответствует PSGI; $body должен быть закодирован в байты согласно заголовку. Исправленный вариант можно считать надёжным, поскольку больше не действует ограничение: PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера. Форма ответа соответствует PSGI; $body не должен быть закодирован в байты согласно заголовку. После изменения сохраняется прежний дефект: Заголовки должны быть плоским массивом, а тело — массивом/объектом, не обычной строкой. Правка лишь воспроизводит исходное поведение: PSGI-приложение получает окружение и возвращает трёхэлементный ответ: статус, заголовки и итерируемое тело.

Вопрос 14 из 30

Какое свойство новой версии с ключевыми операциями важно закрепить тестом?

enable 'Session'; enable 'Auth'; enable 'CSRFBlock';

Слои расположены по зависимостям: сессия доступна авторизации и защите изменения состояния. Гарантию исправления даёт исчезновение ограничения: Общий eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту. Правка лишь воспроизводит исходное поведение: Middleware образуют вложенную цепочку; порядок влияет на то, какой ответ и время видит каждый слой. После изменения сохраняется прежний дефект: Если авторизация ожидает уже загруженную сессию, обратный порядок может сделать пользователя анонимным. Изменение формы записи само по себе обеспечивает правило «Каждый middleware должен иметь узкую ответственность и явно описывать, какие ключи $env и заголовки он читает или меняет».

Вопрос 15 из 30

Какое свойство новой версии с `%routes` важно закрепить тестом?

my %routes=('GET /health'=>\&health,'POST /jobs'=>\&create_job);

Гарантию исправления даёт исчезновение ограничения: PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера. После изменения сохраняется прежний дефект: Путь запроса нельзя превращать в имя загружаемого файла или модуля. Изменение формы записи само по себе обеспечивает правило «Маршрутизация должна учитывать HTTP-метод, декодирование пути, приоритет статических и параметрических маршрутов и ответ 405 отдельно от 404». Метод и нормализованный путь выбирают обработчик из закрытой таблицы. Правка лишь воспроизводит исходное поведение: Маршрут принимает только числовой идентификатор и проверяет весь PATH_INFO.

Вопрос 16 из 30

Почему новая версия с `$ctx`, `$id` и `$user` устраняет исходный дефект?

my $ctx={request_id=>$id,user=>$user}; return dispatch($ctx,$req);

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

Вопрос 17 из 30

Почему новая версия с `$e`, `$request_id` и `log_exception` устраняет исходный дефект?

log_exception($e,$request_id); return problem(500,'internal error',$request_id);

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

Вопрос 18 из 30

Что именно стало надёжнее после изменения в блоке «Восстановление системы»?

drain_instance(); restart_one_worker(); verify_health(); restore_traffic();

Гарантию исправления даёт исчезновение ограничения: Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации. После изменения сохраняется прежний дефект: Грубое восстановление завершает все Perl-процессы, включая здоровые приложения, и скрывает первопричину. Восстановление ограничено одним экземпляром, проверяется перед возвратом трафика и не сохраняет возможность отката. Правка лишь воспроизводит исходное поведение: Проверка готовности отражает способность обслуживать трафик, но частые дорогие запросы сами могут перегрузить зависимости. Восстановление ограничено одним экземпляром, проверяется перед возвратом трафика и сохраняет возможность отката.

Вопрос 19 из 30

Какой вывод стоит перенести из учебного примера «Протокол PSGI» в рабочий код?

Общее правило темы можно свести к предотвращению одного сбоя: Заголовки должны быть плоским массивом, а тело — массивом/объектом, не обычной строкой. Один приём полностью закрывает тему: Форма ответа соответствует PSGI; $body должен быть закодирован в байты согласно заголовку. Общее правило темы «Протокол PSGI» сводится к частному результату: PSGI-приложение получает окружение и возвращает трёхэлементный ответ: статус, заголовки и итерируемое тело. Правило «Приложение не должно полагаться на глобальные CGI-переменные: все данные запроса приходят через $env» гарантирует, что ограничение «PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера» больше не проявится. Приложение не должно полагаться на глобальные CGI-переменные: все данные запроса приходят через $env.

Вопрос 20 из 30

Какой вывод стоит перенести из учебного примера «Промежуточные обработчики» в рабочий код?

Каждый middleware должен иметь узкую ответственность и явно описывать, какие ключи $env и заголовки он читает или меняет. Общее правило исчерпывается единственной правкой: Слои расположены по зависимостям: сессия доступна авторизации и защите изменения состояния. Главный ориентир — не допустить следующую ситуацию: Если авторизация ожидает уже загруженную сессию, обратный порядок может сделать пользователя анонимным. Каждый middleware не должен иметь узкую ответственность и явно описывать, какие ключи $env и заголовки он читает или меняет. Общее правило темы «Промежуточные обработчики» сводится к частному результату: Middleware образуют вложенную цепочку; порядок влияет на то, какой ответ и время видит каждый слой.

Вопрос 21 из 30

Какое правило связывает пять заданий блока «Маршрутизация»?

Маршрутизация должна учитывать HTTP-метод, декодирование пути, приоритет статических и параметрических маршрутов и ответ 405 отдельно от 404. Правило «Маршрутизация должна учитывать HTTP-метод, декодирование пути, приоритет статических и параметрических маршрутов и ответ 405 отдельно от 404» гарантирует, что ограничение «PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера» больше не проявится. Общее правило темы «Маршрутизация» сводится к частному результату: Маршрут принимает только числовой идентификатор и проверяет весь PATH_INFO. Для ревью достаточно исключить частный дефект: Путь запроса нельзя превращать в имя загружаемого файла или модуля. Достаточно применить следующее исправление: Метод и нормализованный путь выбирают обработчик из закрытой таблицы.

Вопрос 22 из 30

Какое правило связывает пять заданий блока «Жизненный цикл запроса»?

Жизненный цикл запроса не должен ограничивать объекты, транзакции, временные файлы и локальный контекст одной обработкой. Для ревью достаточно исключить частный дефект: Пакетная глобальная переменная может сохранить пользователя между конкурентными или последовательными запросами. Общее правило темы «Жизненный цикл запроса» сводится к частному результату: Контекст запроса создаётся на входе и локализуется, чтобы не протекать между запросами долгоживущего процесса. Жизненный цикл запроса должен ограничивать объекты, транзакции, временные файлы и глобальный контекст одной обработкой. Жизненный цикл запроса должен ограничивать объекты, транзакции, временные файлы и локальный контекст одной обработкой.

Вопрос 23 из 30

Что является главным ориентиром при работе с «Разбор отказов»?

Общее правило темы «Разбор отказов» сводится к частному результату: Аварийная граница возвращает 500, но перед этим должна сохранить корреляционный идентификатор и не раскрывать текст исключения клиенту. Один приём полностью закрывает тему: Подробности остаются в защищённом журнале, клиент получает нейтральное сообщение и идентификатор. Правило «Разбор отказа связывает журнал приложения, статус сервера, время запроса, внешние зависимости и факт частичной отправки ответа» гарантирует, что ограничение «После начала потоковой передачи изменить статус на 500 уже нельзя; ошибка должна завершить поток по протоколу и попасть в наблюдаемость» больше не проявится. Разбор отказа связывает журнал приложения, статус сервера, время запроса, внешние зависимости и факт частичной отправки ответа. Главный ориентир — не допустить следующую ситуацию: Ответ публикует внутренние пути, SQL и возможные секреты из исключения.

Вопрос 24 из 30

Какой вывод объединяет результат, дефект и исправление в теме «Восстановление системы»?

Основной принцип блока описывает только такой риск: Грубое восстановление завершает все Perl-процессы, включая здоровые приложения, и скрывает первопричину. Весь контракт блока обеспечивает такая правка: Восстановление ограничено одним экземпляром, проверяется перед возвратом трафика и сохраняет возможность отката. План восстановления включает прекращение приёма новых запросов, завершение активных, перезапуск, проверку миграций и постепенный возврат трафика. Общее правило темы «Восстановление системы» сводится к частному результату: Проверка готовности отражает способность обслуживать трафик, но частые дорогие запросы сами могут перегрузить зависимости. Правило «План восстановления включает прекращение приёма новых запросов, завершение активных, перезапуск, проверку миграций и постепенный возврат трафика» гарантирует, что ограничение «Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации» больше не проявится.

Вопрос 25 из 30

Какой предел гарантий блока «Протокол PSGI» остаётся в силе после успешного запуска?

Режимы strict и warnings полностью снимают это ограничение. Базовое правило «Приложение не должно полагаться на глобальные CGI-переменные: все данные запроса приходят через $env» автоматически снимает указанную границу. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера. Ограничение «PSGI отделяет приложение от сервера, но потоковые и неблокирующие расширения зависят от возможностей конкретного сервера» исчезает, если обычный пример один раз завершился успешно.

Вопрос 26 из 30

Какое предостережение по теме «Промежуточные обработчики» нельзя заменить включением strict и warnings?

Базовое правило «Каждый middleware должен иметь узкую ответственность и явно описывать, какие ключи $env и заголовки он читает или меняет» автоматически снимает указанную границу. Ограничение «Общий eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту» исчезает, если обычный пример один раз завершился успешно. В актуальной версии Perl эта граница больше не действует. Отдельный eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту. Общий eval-middleware полезен для аварийного ответа, но доменные ошибки лучше преобразовывать ближе к маршруту.

Вопрос 27 из 30

Где проходит граница применимости правила из темы «Маршрутизация»?

Базовое правило «Маршрутизация должна учитывать HTTP-метод, декодирование пути, приоритет статических и параметрических маршрутов и ответ 405 отдельно от 404» автоматически снимает указанную границу. PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера. Ограничение «PATH_INFO уже представляет путь в форме PSGI, но проценты и Unicode нельзя декодировать повторно без понимания сервера» исчезает, если обычный пример один раз завершился успешно. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Режимы strict и warnings полностью снимают это ограничение.

Вопрос 28 из 30

Какое ограничение механизма «Жизненный цикл запроса» нужно учитывать даже при корректной работе обычного примера?

Подготовленные при старте неизменяемые объекты можно разделять, а изменяемое состояние запроса — нельзя. Базовое правило «Жизненный цикл запроса должен ограничивать объекты, транзакции, временные файлы и локальный контекст одной обработкой» автоматически снимает указанную границу. Ограничение «Подготовленные при старте неизменяемые объекты можно разделять, а изменяемое состояние запроса — нельзя» исчезает, если обычный пример один раз завершился успешно. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Достаточно включить strict и warnings, чтобы пограничный случай стал невозможен.

Вопрос 29 из 30

Какое утверждение о теме «Разбор отказов» не приписывает механизму лишних гарантий?

Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Режимы strict и warnings полностью снимают это ограничение. Ограничение «После начала потоковой передачи изменить статус на 500 уже нельзя; ошибка должна завершить поток по протоколу и попасть в наблюдаемость» исчезает, если обычный пример один раз завершился успешно. Базовое правило «Разбор отказа связывает журнал приложения, статус сервера, время запроса, внешние зависимости и факт частичной отправки ответа» автоматически снимает указанную границу. После начала потоковой передачи изменить статус на 500 уже нельзя; ошибка должна завершить поток по протоколу и попасть в наблюдаемость.

Вопрос 30 из 30

Какое различие в механизме «Восстановление системы» чаще всего теряют при обобщении?

Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную успех конфигурации. Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации. Ограничение «Автоматический restart полезен при случайном сбое, но бесконечный цикл перезапусков без ограничения маскирует постоянную ошибку конфигурации» исчезает, если обычный пример один раз завершился успешно. Базовое правило «План восстановления включает прекращение приёма новых запросов, завершение активных, перезапуск, проверку миграций и постепенный возврат трафика» автоматически снимает указанную границу.