8 неочевидных ошибок при переходе на российский софт

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

На правах эксперта компании-интегратора, которая помогает крупному бизнесу на сложном пути импортозамещения, я хочу рассказать, с чем мы столкнулись в реальной практике, как решили проблемы и почему все не так страшно, как порой кажется. Все приведенные ниже ошибки обнаружились в тот или иной момент на этапе тестирования при переводе систем с проприетарного ПО (Windows + Microsoft SQL Server) на импортонезависимое (Astra Linux 1.7 + Postgres Pro Standard 13). Первая часть разбора посвящена ошибкам пользователей.

1. Тяжелые ненужные файлы

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

С похожей историей мы столкнулись и в рамках процесса корпоративного импортозамещения. Для проведения тестирования работы нового функционала мы выгрузили базу данных в виде файла с расширением .dt и попытались загрузить ее в импортонезависимое окружение. В этот момент на экране всплыла ошибка: «54000: нехватка памяти. Не удалось увеличить строковый буфер».

Сначала мы решили, что сама конфигурация не вмещается в отведенные размеры, и следующие несколько дней безуспешно модифицировали ресурсы: добавляли память, меняли настройки ОС и СУБД, увеличивали буферы, присоединяли внешние диски и т. д. Потом стали детально анализировать логи процесса загрузки и заметили, что в микросекунду возникновения ошибки производится запрос к конкретной таблице — InfoRg<>... Открыли таблицу — и нашли тяжеловесного виновника — запись с данными более 1 Гб. Для справки, максимальный размер данных в одном поле таблицы на Postgres Pro составляет как раз 1 Гб, в отличие от Microsoft SQL, где этот лимит равняется 2 Гб.

Очевидно, кто-то из пользователей однажды прикрепил файл прямо в СУБД. Хотя технически такая возможность у пользователя действительно есть, мы рекомендуем этого не делать: тяжелые файлы раздувают систему и порой затрудняют регламентное обслуживание.

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

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

2. Странные имена файлов

При тестировании функционала конфигурации базы данных 1С в импортонезависимом окружении возникли проблемы в работе с прикрепленными файлами, хранящимися в томах (то есть на этот раз правильно — вне самой базы). Эти файлы не открывались, возникала ошибка.

Сперва мы подумали, что дело в длине самих файлов, но в итоге выяснили, что проблема кроется в длине названий. Как выяснилось, имя файла в Astra Linux не должно превышать 100 кириллических символов. Что интересно, это ограничение стоит именно на кириллицу — файлы с длинными названиями на латинице открываются без каких-либо проблем. Эта тривиальная, на первый взгляд, ошибка отняла у разработчиков неделю рабочего времени. В итоге мы написали обработку, которая сокращает длину названий, и запустили автоматическое переименование файлов.

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

3. Незаметная точка

Казалось бы, все файлы переименованы, и на этом проблемы должны были закончиться. Но нет, часть файлов все равно не открывалась. Мы проанализировали, что между ними общего, и заметили, что все они начинаются с точки. Для Astra Linux точка в начале имени файла означает «скрытый» файл. Вот тут и начинаешь вспоминать, как в Стране невыученных уроков двоечнику Вите объясняли важность знаков препинания…

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

Как избежать подобной ошибки: не начинайте название корпоративных файлов с символа точки.

4. Вовремя не обновленный софт

В рамках тестирования мы решили сравнить работу системы в текущем и импортонезависимом окружениях с помощью встроенной подсистемы «Тест-центр», которая позволяет моделировать работу пользователей и автоматизировать многопользовательские нагрузочные испытания. Но столкнулись с тем, что в текущем окружении тесты запускались на выполнение успешно, а вот в импортонезависимом запуск тестов падал с ошибкой из-за невозможности подключить внешнюю компоненту, которая выполняет определенные действия с объектами.

Анализ прав, доступов и политик не дал никакого результата — все было настроено корректно. Мы проанализировали документацию по технологии создания внешних компонент и обратили внимание на фразу «Сборку компоненты для ОС Linux рекомендуется производить на самой старшей версии из списка поддерживаемых ОС Linux». Стали проверять и поняли, что встроенная подсистема Тест-центра была не самой новой.

Стоит пояснить, что подсистема «Тест-центр» является кроссплатформенной, то есть хорошо работает как с Windows, так и с Linux. Однако если в Windows-среде не имеет особого значения, на какой системе была скомпилирована компонента, то вот для Linux важно, чтобы все компилировалось на самой актуальной системе. После обновления подсистемы на актуальную версию проблема с запуском тестов в импортонезависимом окружении была решена.

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

5. Разные регистры букв

После перевода системы в импортонезависимое окружение мы захотели посмотреть, как с нашей базой данных будет работать весьма популярная у корпоративных заказчиков BI-система (QlikView). Первое, с чем мы столкнулись, — это чувствительность к регистру в скриптах при обращении к таблицам и полям. С этой проблемой мы быстро справились, и все заработало — данные стали загружаться и трансформироваться.

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

Мы долго бились, пока не обнаружили, что данная BI-система чувствительна к регистру символов ID объектов и для нее «91bf0050560118ed11ec5f348a440a01» и «91BF0050560118ED11EC5F348A440A01» — это разные сущности. Это не было бы проблемой, если бы при загрузке в Postgres Pro идентификаторы объектов во всех справочниках и документах не были автоматически преобразованы из верхнего регистра (стандарт Microsoft SQL) в нижний. В результате BI-система не могла «склеить» данные по идентификаторам и просто не видела связи между старой и новой информацией. Мы поправили регистры — и еще одна проблема оказалась решена.

6. «Целое вне диапазона»

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

Мы настроили аналогичный набор прав в Windows-среде, и при выполнении той же операции получили теперь уже понятную формулировку: «У пользователя недостаточно прав на исполнение операции над базой данных». Стало ясно: для данного воображаемого пользователя в системе стоят ограничения доступа на уровне записей (RLS), и «пользователь» (наш консультант) пробует работать с таблицами, на которые у него нет прав. Корректная настройка профилей/групп доступа пользователя в базе с импортонезависимым окружением быстро решила проблему.

7. Некорректная обработка исключений

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

Когда мы начали тестировать эту функцию в Linux, то заметили, что команда «ВызватьИсключение» отрабатывается некорректно. При срабатывании команды происходит зависание фонового задания, что приводит к невозможности входа в конфигуратор базы данных системы. Пришлось переписывать часть кода, чтобы исключить запуск команды «ВызватьИсключение» в рамках работы фонового задания, и только после этого проблема была решена.

8. NULL

Еще одну интересную особенность поведения платформы в работе с разными СУБД мы заметили при сортировке в запросах по полям со значением NULL, которое символизирует отсутствие данных. В Microsoft SQL все такие поля автоматически отправляются в конец таблицы, а в Postgres Pro они по умолчанию вылетают на самый верх. В нашем случае речь шла о таблице, из которой извлекались задачи в очередь на выполнение — они должны были ранжироваться по убыванию приоритета (число), и первая задача с наивысшим приоритетом шла в обработку. В Postgres Pro этой сверхважной задачей стал… NULL.

Чтобы исправить проблему, нам пришлось вычистить значения NULL из результатов с помощью конструкции ЕСТЬNULL. Таким образом мы унифицировали работу системы и получили корректный результат вне зависимости от используемой СУБД. Все подобные поля стали улетать вниз не только в Microsoft SQL, но и в Postgres Pro.

* * *

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

Это, впрочем, не значит, что ошибок нельзя избежать. Чтобы не потратить дни, а то и недели, на выявление багов в платформе, достаточно обратиться к опытному интегратору, который знаком со всеми возможными ошибками и понимает, как их быстро исправить. Фраза «Целое вне диапазона» не поставит грамотного подрядчика в тупик — он знает, что эта ошибка в формулировке уже задокументирована и попадается при работе с платформой последние три года. А обработка для переименования файлов уже есть у него в запасе, и он может моментально запустить ее при столкновении с файлами, которые наотрез отказываются открываться.

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