Деградированный режим при сбое сервиса проверки исполнителя

Деградированный режим — это сохранение частичной работоспособности системы при отказе отдельного компонента вместо полной остановки. В проверке исполнителей он означает временный статус «на верификации» для ранее проверенного партнёра, пока внешний реестр недоступен. Применяется на цифровых платформах занятости, маркетплейсах и агрегаторах услуг, где обязанность проверки партнёра закреплена 289-ФЗ с 1 октября 2026 года.

Кратко:

• Что это: инженерная практика graceful degradation, перенесённая на онбординг: проверенный исполнитель работает с урезанными полномочиями, пока запрос ждёт ответа реестра в очереди.
• Кто устанавливает правила: сам оператор платформы. 289-ФЗ не вводит статус «на верификации», основанием для временных ограничений служит договор с партнёром.
• Сколько ждать: срок проверки по ПП № 768 — 5 рабочих дней, для МСП и автозапроса в реестры — 1 календарный день, поэтому короткий сбой переживается в очереди.
• Что закрыто всегда: первый выход нового исполнителя, вывод средств, смена платёжных реквизитов, доставка товаров с возрастным ограничением.
• Цена ошибки: штрафы по ст. 14.69 КоАП РФ — до 100 тыс. руб. за незаконное ограничение доступа к кабинету и до 500 тыс. руб. за нарушение сроков рассмотрения жалобы.

Что такое деградированный режим при сбое проверки?

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

Инженеры Google в SRE Workbook формализовали измерение такого состояния. Для сервисов, отвечающих на запросы, они советуют считать долю ответов, отданных без деградации, отдельной метрикой качества, если сервис умеет изящно деградировать при перегрузке или недоступности бэкендов. Оттуда же берётся бюджет ошибок: цель доступности 99,9% оставляет 0,1% допустимой недоступности за период, и внутри этого запаса деградированные ответы предпочтительнее отказа.

Бюджет ошибок переводится в часы и показывает реальную цену процента доступности. Доступность источника данных на уровне 98% допускает примерно 14,5 часа недоступности в календарный месяц; при 99,9% запас сокращается до 43 минут. Ни одна из этих цифр не равна нулю, поэтому окно недоступности проверки наступит по расписанию поставщика данных, и платформа на его сроки не влияет.

Как часто сбоят российские сервисы проверки?

Система межведомственного электронного взаимодействия (СМЭВ) регулярно закладывает плановые окна недоступности в свой график. Платформе полезно сверяться с этим графиком заранее: тогда сбой проверки не становится неожиданностью. В опубликованных уведомлениях за август 2026 года заявлены прерывание доступности сервиса ГИС ГМП до 240 минут, смена мастер-ключей на сетях ViPNet в период с 17 августа по 2 сентября 2026 года с недоступностью до 10 минут в ночном окне и недоступность сервисов ФНС России в СМЭВ в ночь с 17 на 18 августа. Актуальный перечень публикуется в новостях СМЭВ 3.

Незапланированные сбои опаснее: их не видно заранее, и платформа узнаёт о них по факту отказа проверки. 15 апреля 2026 года банки лишились доступа к сервису проверки подлинности паспортов в СМЭВ 3 и СМЭВ 4. Отключение затронуло все кредитные организации, причина и сроки восстановления не раскрывались, и по состоянию на 16 апреля сервис оставался недоступным. Минцифры при этом сообщило банкам, что инфраструктура СМЭВ исправна, а проблема связана с управлением доступом со стороны владельца сервиса.

Ближайший пример затронул уже саму инфраструктуру связи. Вечером 18 августа 2026 года отключение электроэнергии на у зле связи ММТС-9 в Москве вывело из строя десятки сайтов и сервисов одновременно; регистратор «Рег.ру» связал недоступность ресурсов с перебоями питания на крупном узле связи, а собственную инфраструктуру из причин исключил.

Восстановление заняло больше одной ночи. 19 августа российский сегмент интернета работал в режиме ограниченной доступности: «Ростелеком» подтвердил внешнюю аварию на энергетической инфраструктуре как основную причину, жалобы поступали практически из всех федеральных округов, а в сводки перебоев наравне со стримингами и мессенджерами попадали банковские приложения и портал Госуслуг с авторизацией по ЕСИА.

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

Чем жёсткая блокировка отличается от открытого пропуска при сбое?

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

Правовые сроки добавляют к этой картине измеримую цену ошибки, но важно разграничить, к какому кругу лиц они применяются. Статьи 13 и 14 289-ФЗ (уведомление партнёра о блокировке личного кабинета за 3 дня, отмена незаконно применённой меры в течение 48 часов, срок рассмотрения жалобы до 15 дней) прямо регулируют отношения оператора с партнёром-продавцом и владельцем пункта выдачи заказов на маркетплейсах, то есть участниками, которых закон описывает в главе 2. Для партнёра-исполнителя услуг (курьера, водителя на гиг-платформе), чьи отношения регулирует глава 3 закона (ст. 15—17), закон не содержит отдельной нормы с аналогичными процедурными гарантиями. Поэтому применение сроков «3 дня / 48 часов / 15 дней» к сценарию курьера, это перенос по аналогии с общим смыслом закона, а не прямое требование конкретной статьи; платформе целесообразно закрепить такие же или сопоставимые гарантии в собственном договоре с исполнителем, не ссылаясь на ст. 13—14 как на прямо применимую норму.

Административная ответственность операторов посреднических цифровых платформ за нарушения 289-ФЗ введена Федеральным законом от 04.08.2026 № 295-ФЗ, дополнившим КоАП РФ статьями 14.69—14.71 (законопроект № 959258-8). Государственная Дума приняла его 21 июля 2026 года, закон подписан и опубликован, вступает в силу с 1 октября 2026 года, за исключением отдельных норм о снижении цены, действующих с 1 января 2027 года. Статья 14.69 КоАП РФ содержит 12 частей со штрафами для операторов: за необеспечение партнёру технической возможности размещения информации предусмотрен штраф от 10 тыс. до 40 тыс. рублей для должностных лиц и от 20 тыс. до 50 тыс. рублей для юридических лиц; за незаконное ограничение доступа к личному кабинету и нарушение сроков рассмотрения жалоб штраф составляет до 100 тыс. и до 500 тыс. рублей соответственно. Срок давности по этим нарушениям составляет 90 календарных дней со дня совершения правонарушения.

Таблица сравнения режимов допуска

Как работает очередь и circuit breaker при недоступности реестра?

Отказоустойчивая схема начинается с разделения двух событий. Запрос к внешнему реестру уходит моментально, а срок отсчитывается на получение ответа. Пока ответ не пришёл, у исполнителя нет ни признака «проверен», ни признака «отклонён»; ему нужен явный третий статус «на верификации». Модель данных с двумя состояниями вынуждает разработчика выбрать при сбое одно из них, и любой выбор окажется ложным.

• Автоматический предохранитель размыкает канал после серии ошибок: запросы перестают уходить в недоступный реестр и получают быстрый локальный ответ «на верификации». Классическое описание паттерна circuit breaker у Мартина Фаулера и каталог облачных паттернов Microsoft описывают полуоткрытое состояние, когда пробный запрос возвращает канал в работу после ответа реестра.
• Повторные попытки идут с экспоненциальной задержкой и случайным разбросом, чтобы после восстановления реестра платформа не создала пиковую нагрузку и не получила отказ повторно.
• Ключ идемпотентности на каждый запрос закрывает двойную тарификацию и дубли записей при повторной отправке.
• Кэш последнего успешного ответа с ограниченным сроком годности снимает часть сбоев без деградации: паспорт, подтверждённый вчера, остаётся действительным сегодня.
• Резервирование канала связи и размещения снимает зависимость от одного узла: инцидент с ММТС-9 обошёл стороной сервисы, чья инфраструктура не завязана на затронутую площадку.
• Тип отказа различается по коду ответа. Таймаут и ошибка шлюза означают сбой канала. Ответ «МВД не располагает сведениями» относится к содержательному результату проверки и деградированный режим не запускает.

Что можно разрешить исполнителю в статусе «на верификации»?

Объём временных полномочий оператор платформы определяет по цене ошибки в каждом сценарии, закрепляя решение договором с партнёром: закон не устанавливает конкретный перечень допустимых действий для промежуточного статуса. Деградированный режим применяется как операционная практика к повторной проверке исполнителя с ранее завершённой первичной идентификацией личности: паспорт сверен, лицо сопоставлено с документом, договор заключён. Первичный допуск нового исполнителя платформы в этом материале рассматривается как закрытый по внутреннему регламенту платформы до завершения проверки личности. Отдельно от этого 289-ФЗ (ст. 5 ч. 2) требует от оператора проверки сведений о партнёре, имеющем намерение заключить договор, по данным ЕГРЮЛ, ЕГРИП либо посредством идентификации в ЕСИА. Эта норма касается проверки правового статуса контрагента (юрлица, ИП, самозанятого) и прямо применяется к партнёру-продавцу и владельцу пункта выдачи заказов; для физлица-исполнителя на гиг-платформе она служит дополнительным основанием наряду с процедурой первичной идентификации личности, которую платформа выстраивает самостоятельно.

Таблица допустимых и закрытых действий в статусе «на верификации»

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

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

Обработка персональных данных при таком допуске остаётся под 152-ФЗ. Оператор обязан принимать меры по уточнению неполных и неточных данных. Отдельно статья 21 152-ФЗ описывает иной, но смежный механизм: при обращении субъекта персональных данных или по запросу уполномоченного органа, выявившего неточность сведений, оператор блокирует такие данные на период проверки точности, если блокирование не нарушает права субъекта и третьих лиц, а после подтверждения неточности уточняет данные в течение 7 рабочих дней и снимает блокирование. Этот механизм запускается по обращению субъекта данных или регулятора, а не по самостоятельному решению оператора о временном допуске исполнителя при сбое внешнего сервиса проверки. По аналогии он всё же показывает: закон в принципе допускает временное состояние данных «на проверке» с ограниченным сроком, и статус «на верификации» логично строить по тому же принципу, как отдельное состояние записи с отметкой времени, даже без прямой нормы именно для этого сценария.

Отказ заявителю по причине молчания реестра создаёт лишний спор с предсказуемым исходом. По ПП № 768 стандартный срок проверки составляет 5 рабочих дней, для субъектов МСП и при автоматическом запросе в цифровые сервисы: 1 календарный день, для иностранной организации без представительства в РФ: до 15 рабочих дней; уведомление заявителя о решении уходит в течение 1 рабочего дня. Отказ оформляется электронным документом с усиленной квалифицированной электронной подписью и требует указания основания, при этом заявитель вправе пройти повторную проверку без ограничения числа попыток.

Как проходит досверка после восстановления сервиса проверки?

1. Очередь отложенных запросов формируется по приоритету. Первыми уходят запросы исполнителей, у которых лимит временного допуска истекает раньше.
2. Лимит временного допуска оператор платформы устанавливает сам и переносит в договор с партнёром: ст. 5 ч. 4 289-ФЗ требует прописать требования к партнёру, исчерпывающий перечень мер ответственности и порядок обжалования решений оператора. Принцип расчёта прост: срок покрывает разбор очереди после восстановления канала и не продлевается автоматически.
3. Накопленные заявки закрываются пакетной проверкой, без поштучных запросов от операторов поддержки.
4. Отрицательный результат отзывает допуск: задания закрываются, выплата удерживается до выяснения, исполнитель получает основание и право на повторную проверку.
5. Событие заносится в журнал: идентификатор запроса, время, статус, объём выданных полномочий и сотрудник, принявший решение. Оператор обязан обеспечить партнёру доступ к действующей и утратившим силу редакциям договора не менее 3 лет с момента утраты силы соответствующей версии (ст. 5 ч. 5 289-ФЗ).
6. Повторяющиеся сбои одного источника попадают в отчёт о доступности: по нему платформа пересматривает лимиты допуска, состав кэшируемых проверок и целевые метрики качества ответов.

Как IDX обеспечивает отказоустойчивость проверки на практике?

IDX работает как оператор обработки персональных данных по поручению клиента и не определяет дополнительных целей обработки. Комплексная проверка паспорта возвращает пять состояний:

1. «Верифицирована связка ФИО-дата рождения-номер паспорта, паспорт действителен»;
2. «Связка [ФИО-Номер паспорта] подтверждена, номер паспорта верифицирован; паспорт действителен, в дате рождения возможны опечатки»;
3. «Связка [Фамилия-Имя-Номер паспорта] подтверждена, номер паспорта верифицирован, паспорт действителен»;
4. «Сведения о паспорте не были найдены»;
5. «Паспорт недействителен».

Четвёртый ответ означает отсутствие сведений в источниках и направляет заявку на другой маршрут проверки.

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

Режимы Web и API позволяют разбирать накопленную очередь пакетом и выдерживать нагрузки от единичных запросов до миллионов в месяц.