Четыре версии ЕИС одновременно: как проверять рабочий маршрут после hotfix

Вечером 24 июля четыре публичных маршрута Единой информационной системы в сфере закупок отдавали четыре разных build-маркера. Главная страница показывала сборку от 8 июля, поиск закупок — hotfix от 22 июля, реестр контрактов — версию от 17 июля, поиск планов-графиков — от 3 июля.

Это наблюдение не позволяет объявить ЕИС неисправной. У модулей могут быть самостоятельные циклы поставки, отдельные кэши или другая техническая схема, которую публичные страницы не раскрывают. Но оно опровергает удобное допущение: если открылась главная, значит весь нужный процесс работает на одной версии и готов к юридически значимому действию.

08.07 Главная hotfix/16.2.2.55

22.07 Поиск закупок hotfix/16.2.3.125

17.07 Реестр контрактов hotfix/16.2.3.77

03.07 Планы-графики hotfix/16.2.1.47

Источник: Публичные страницы ЕИС, проверка Ферман Радар 24 июля 2026 года около 20:15 МСК

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

Что говорит номер версии — и чего не говорит

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

Сам по себе маркер не является сертификатом качества. Из строки hotfix/16.2.3.125 нельзя установить, какой дефект исправляли, какие сценарии проверили и какие регрессии исключили. В исследованных открытых источниках содержательного changelog именно для этой сборки не найдено. Поэтому утверждение «после обновления исправили поиск» было бы выдумкой, даже если номер версии свежий.

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

Маршрутная приёмка вместо проверки главной

Первый шаг — описать критические маршруты глаголами. Не «ЕИС работает», а «специалист находит извещение по номеру, открывает актуальную редакцию документа, подписывает заявку и получает подтверждение отправки». Чем точнее цепочка, тем меньше спор о том, что считать успехом.

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

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

Четвёртый шаг — сохранить минимальный протокол: роль пользователя, рабочее место, браузер и криптопровайдер, URL, время по Москве, build-маркер, входные параметры, ожидаемый и фактический результат. Такой журнал занимает несколько строк, но позволяет воспроизвести ситуацию. Без него сообщение «ЕИС не работала» почти невозможно отделить от ошибки фильтра, просроченного сертификата или неверной последовательности действий.

Контроль	Что фиксировать	Признак успеха	Что ещё не доказано
Доступ к маршруту	URL, время, роль, build	Нужный раздел открылся	Работает ли отправка
Чтение данных	Номер извещения, фильтры, редакция	Найдена ожидаемая запись	Актуален ли локальный файл
Юридически значимое действие	Хэш файла, сертификат, время	Получена квитанция или статус	Завершились ли последующие проверки
Публичное отражение	Реестровый номер, время ожидания	Запись доступна в нужном реестре	Нет ли содержательной ошибки в данных

Резерв времени важнее уверенности в интерфейсе

Техническая приёмка не спасает заявку, отправленную в последние минуты. Даже исправный маршрут зависит от локальной сети, браузера, сертификата, криптопровайдера, размера файла и времени обработки. Любой из этих элементов способен съесть остаток срока без системного сбоя на стороне ЕИС.

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

Заказчику нужен такой же запас перед размещением изменения, протокола или сведений о контракте. Если операция проходит через контроль, согласование или обмен с другой системой, приёмка заканчивается не в момент отправки, а после появления ожидаемого статуса на последнем звене.

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

Что собирать при технической проблеме

Федеральное казначейство указывает, что ГИС «Независимый регистратор» предназначена для фиксации действий участников в ЕИС и на электронных площадках, событий информационного взаимодействия, видеофиксации и мониторинга доступности. Это важный слой доказательств, но не автоматическое признание любой жалобы обоснованной.

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

Обращение в поддержку должно описывать воспроизводимый сценарий: что делали, под какой ролью, на каком шаге получили отклонение и какой результат ожидали. Фраза «ничего не работает» не помогает ни восстановлению, ни последующему правовому анализу.

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

От технического факта к юридическому выводу

Постановление Правительства № 60 задаёт нормативный контур функционирования ЕИС и электронного документооборота. Но конкретное последствие сбоя зависит от действия, срока, применимой процедуры и доказательств. Технический специалист может подтвердить последовательность событий; вывод о восстановлении срока, допустимости документа или нарушении делает уполномоченный орган либо суд в конкретных обстоятельствах.

Поэтому полезно разделить досье инцидента на три части. Первая — факт: что наблюдалось и чем подтверждено. Вторая — влияние: какое действие не завершилось и какой срок оказался под риском. Третья — правовая позиция: какая норма применяется и чего просит сторона. Смешение этих частей рождает слабые заявления вроде «номер версии доказывает вину системы».

Граница вывода

Подтверждённый факт на 24 июля — разные build-маркеры четырёх публичных маршрутов ЕИС. Свежий маркер поиска закупок датирован 22 июля. Не подтверждены состав этого hotfix, причина различий между модулями и наличие связанного с ними сбоя.

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