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

Добавлено

Удалено или заменено

• Вечером 24 июля четыре публичных маршрута Единой информационной системы в сфере закупок отдавали четыре разных build-маркера. Главная страница показывала сборку от 8 июля, поиск закупок — hotfix от 22 июля, реестр контрактов — версию от 17 июля, поиск планов-графиков — от 3 июля.
• Это наблюдение не позволяет объявить ЕИС неисправной. У модулей могут быть самостоятельные циклы поставки, отдельные кэши или другая техническая схема, которую публичные страницы не раскрывают. Но оно опровергает удобное допущение: если открылась главная, значит весь нужный процесс работает на одной версии и готов к юридически значимому действию.
• Источник: Публичные страницы ЕИС, проверка Ферман Радар 24 июля 2026 года около 20:15 МСК
• Практический вывод касается поставщика, заказчика и контрактной службы одинаково: проверять нужно не сайт вообще, а точный рабочий маршрут. Для поставщика это может быть поиск извещения, открытие документов, подготовка файла, подпись, отправка и получение подтверждения. Для заказчика — формирование изменения, контроль, размещение и появление записи в публичном контуре. Каждый переход может обслуживаться другим модулем.
• Что говорит номер версии — и чего не говорит
• Build-маркер полезен как координата. Он связывает наблюдение со сборкой, маршрутом и временем. Если вчера фильтр отдавал один набор закупок, а сегодня другой, номер версии помогает отделить изменение системы от изменения данных или параметров запроса.
• Сам по себе маркер не является сертификатом качества. Из строки hotfix/16.2.3.125 нельзя установить, какой дефект исправляли, какие сценарии проверили и какие регрессии исключили. В исследованных открытых источниках содержательного changelog именно для этой сборки не найдено. Поэтому утверждение «после обновления исправили поиск» было бы выдумкой, даже если номер версии свежий.
• Не следует делать и обратный вывод: разные номера в подвале не доказывают рассинхронизацию данных или ошибку развёртывания. Они показывают только то, что публичные маршруты идентифицируют себя по-разному. Причину может подтвердить оператор системы, а не внешний наблюдатель.
• Версия — это улика, не вердикт
• Фиксируйте build-маркер рядом с ошибкой или успешным результатом, но не подменяйте им проверку операции. Для решения важны входные данные, точное время, маршрут и то, появилась ли юридически значимая запись.
• Маршрутная приёмка вместо проверки главной
• Первый шаг — описать критические маршруты глаголами. Не «ЕИС работает», а «специалист находит извещение по номеру, открывает актуальную редакцию документа, подписывает заявку и получает подтверждение отправки». Чем точнее цепочка, тем меньше спор о том, что считать успехом.
• Второй шаг — выбрать контрольную операцию. Она должна быть максимально похожа на предстоящую, но не создавать ложную публикацию и не нарушать процедуру. Для публичного поиска достаточно сохранённого запроса с известным результатом. В личном кабинете используют предусмотренный системой черновик, тест подписи или другой штатный безопасный сценарий. Если тестовая операция сама меняет юридическое состояние, её проводят только по внутреннему регламенту и с полномочием.
• Третий шаг — заранее определить ожидаемый выход. Нажатая кнопка не равна завершённой операции. Подтверждением может быть регистрационный номер, квитанция, новый статус, запись в реестре или совпадающая контрольная сумма загруженного файла. Команда должна знать, где этот результат появляется и сколько обычно занимает обработка.
• Четвёртый шаг — сохранить минимальный протокол: роль пользователя, рабочее место, браузер и криптопровайдер, URL, время по Москве, build-маркер, входные параметры, ожидаемый и фактический результат. Такой журнал занимает несколько строк, но позволяет воспроизвести ситуацию. Без него сообщение «ЕИС не работала» почти невозможно отделить от ошибки фильтра, просроченного сертификата или неверной последовательности действий.
• Резерв времени важнее уверенности в интерфейсе
• Техническая приёмка не спасает заявку, отправленную в последние минуты. Даже исправный маршрут зависит от локальной сети, браузера, сертификата, криптопровайдера, размера файла и времени обработки. Любой из этих элементов способен съесть остаток срока без системного сбоя на стороне ЕИС.
• Для поставщика разумный контрольный срок — внутренний, более ранний, чем официальный дедлайн. Его величина зависит от цены ошибки и сложности пакета, поэтому универсального числа нет. Но принцип проверяем: после внутреннего срока команда не продолжает бесконечно улучшать формулировки, а переходит к подписанию, отправке и контролю результата.
• Заказчику нужен такой же запас перед размещением изменения, протокола или сведений о контракте. Если операция проходит через контроль, согласование или обмен с другой системой, приёмка заканчивается не в момент отправки, а после появления ожидаемого статуса на последнем звене.
• Руководителю полезна матрица из трёх колонок: маршрут, владелец, крайнее безопасное время. Технический специалист отвечает за воспроизводимость среды, закупщик — за правильность действия и данных, руководитель — за решение не тянуть до официальной границы.
• Что собирать при технической проблеме
• Федеральное казначейство указывает, что ГИС «Независимый регистратор» предназначена для фиксации действий участников в ЕИС и на электронных площадках, событий информационного взаимодействия, видеофиксации и мониторинга доступности. Это важный слой доказательств, но не автоматическое признание любой жалобы обоснованной.
• Локальная хронология всё равно нужна. Зафиксируйте точное время каждой попытки, адрес раздела, номер закупки или контракта, параметры операции, текст сообщения, build-маркер и состояние сертификата. Снимок экрана должен показывать контекст, а не только красную плашку. Если система сформировала идентификатор обращения или квитанцию, сохраните оригинал.
• Обращение в поддержку должно описывать воспроизводимый сценарий: что делали, под какой ролью, на каком шаге получили отклонение и какой результат ожидали. Фраза «ничего не работает» не помогает ни восстановлению, ни последующему правовому анализу.
• Не стоит публиковать в общий чат закрытые документы, персональные данные, секреты электронной подписи или полный снимок личного кабинета. Доказательства собирают в утверждённом контуре доступа. Для внешнего запроса оставляют только необходимый минимум.
• От технического факта к юридическому выводу
• Постановление Правительства № 60 задаёт нормативный контур функционирования ЕИС и электронного документооборота. Но конкретное последствие сбоя зависит от действия, срока, применимой процедуры и доказательств. Технический специалист может подтвердить последовательность событий; вывод о восстановлении срока, допустимости документа или нарушении делает уполномоченный орган либо суд в конкретных обстоятельствах.
• Поэтому полезно разделить досье инцидента на три части. Первая — факт: что наблюдалось и чем подтверждено. Вторая — влияние: какое действие не завершилось и какой срок оказался под риском. Третья — правовая позиция: какая норма применяется и чего просит сторона. Смешение этих частей рождает слабые заявления вроде «номер версии доказывает вину системы».
• Граница вывода
• Подтверждённый факт на 24 июля — разные build-маркеры четырёх публичных маршрутов ЕИС. Свежий маркер поиска закупок датирован 22 июля. Не подтверждены состав этого hotfix, причина различий между модулями и наличие связанного с ними сбоя.
• Собственный вывод Radar не зависит от технического объяснения: модульная цифровая система требует маршрутной приёмки. Главная страница показывает доступность главной страницы. Готовность закупочного процесса подтверждает только сквозная проверка точной цепочки, ожидаемый результат на её конце и сохранённое доказательство того, что увидел пользователь.