Откуда не ждали: неочевидные ошибки, которые возникают при переходе на российское ПО

Руководитель практики ИТ и сервисов ALP Group Валерий Лямо рассказывает, на каких, казалось бы, мелочах спотыкаются большие импортонезависимые системы и как избежать подобных ошибок.

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

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

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

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

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

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

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

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

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

2. Безумные имена файлов.

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

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

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

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

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

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

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

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

4. Вовремя не обновленное ПО.

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

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

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

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

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

В общем, как вы уже наверняка заметили, Windows и Microsoft SQL прощают львиную долю ошибок, на которых Linux и Postgres Pro всегда спотыкаются. Поэтому очень важно с самого начала выстраивать единые стандарты работы с корпоративным учетом, которым должны следовать все сотрудники компании.

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