Рубрика: ИТ

Один из достаточно часто встечающихся антипаттернов в ИТ: встраивание в бизнес-процессы чужой модифицированный продукт. Обычно такое происходит в малых, иногда средних компаниях, намного реже в крупных, но и там встречается.

Суть в следующем. Компания использует некоторое покупное или открытое ИТ-решение и всё в нём устраивает, кроме некоторого недостающего функционала. И этот функционал не обеспечивается штатными возможностями продукта, конфигурацией или расширениями к нему. Возникает естественная мысль: а давайте найдём спеца/компанию или своими силами "доработаем напильником" решение как нам надо. Часто это можно сделать за вменяемые деньги и время, компания модифицирует решение и включает в свой ключевой бизнес-процесс. И всё работает, какое-то время.

Сложности начинаются по прошествии времени. Продукт у поставщика обновляется, а наш нет. Или обновляется, но работает не как ожидалось. Или работает, но через какое-то время появляются неожиданные ошибки. Или продукт поменялся так, что модификация с сохранением функционала теперь невозможна. Фактически компания теперь имеет кастомный продукт без возможности внятной поддержки. Таким образом получаются различные необновляемые CRM/ERP/фреймоворки и сторонние библиотеки, а 1С-ники отлично знают "счастье" работы с правленной конфигурацией.

Хороший вариант решения: написать свой модуль или расширение к используемому решению. К сожалению, такое возможно не всегда, да и в этом случае расширение зависимо от основного продукта и может потерять поддержку.

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

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

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

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

В продакшене могила компилировалась из исходников на тех же CentOS серверах примерно в те же годы, т.е. начало 2010-х. На тех же серверах работает код самого проекта на php 5.4 с остальным уже сильно не новым окружением. А код заказчика развивается и хотелось бы уже мигрировать новую спецификацию языка и использовать возможности новых библиотек. Но сделать это сложно.

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

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

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

Долго запрягали, но поехали очень быстро. За половину суток скрипт обработал все файлы и доступ к ним через новый интерфейс неожиданно оказался намного быстрее. И самое главное: можно полностью избавиться от всего старого окружения.

Выводы:

1. Избегать использования библиотек, поддержка которых вероятно скоро прекратится. Заранее это не всегда можно определить, но есть косвенные признаки.
2. Писать код с продуманной архитектурой и интерфейсами, которые позволяют легко поменять хранилище (и не только его).
3. Разделять задачу на разные уровни. Конкретно здесь хранение можно почти полностью реализовать на более низком уровне без существенного потери функционала.
4. Использовать как можно более прозрачные и унифицированные инструменты.