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

Меня зовут Илья Лебедкин, я CEO компании «Аддамант». Мы специализируемся на разработке ИТ решений для среднего и крупного бизнеса в РФ. За годы работы стало очевидно, что с каждым новым клиентом и проектом снова и снова всплывает одна и та же боль.

ИТ-ландшафт наших заказчиков представляет собой конгломерат разрозненных решений. Вместо единой экосистемы мы видим множество независимых систем, функционал которых зачастую пересекается, а данные дублируются: сайт на одной версии Битрикса, рядом второй сайт на другой, личный кабинет на готовом SaaS по подписке, склад и учет в 1С, заявки в amoCRM, а где-то в углу — своя старая кастомная система, которую десять лет назад написал подрядчик, давно уехавший в закат. И над всем этим — три-четыре разные команды на поддержке. Это приводит к путанице в учете и снижает прозрачность бизнес-процессов

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

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

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

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

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

Архитектура предлагает классический и давно известный путь. Одна мультисайтовая платформа под единой админкой (1С-Битрикс, например, это умеет из коробки). Один движок на все сайты, общие модули свои и встроенные, а не набор чужих подписок. Никакого откровения тут нет.

Откровение — в порядке действий. Сначала мы вообще не лезем в сложное, а приводим в чувство то, что уже работает: обновляем платформы до актуальных версий, закрываем дыры, чистим код. Работа рутинная и малозаметная, но тащить новое на хлипкий фундамент — гиблое дело.

А потом по одному прицепляем к этому ядру тяжелые части: старую кастомную систему, которую надо перенести, не растеряв данные, и ее интеграции, которые надо переподключить. Здесь главная сложность — интеграции, у которых нет тестового контура. Проверить такую можно только на бою. Поэтому мы их не переключаем пачкой и на удачу: только по одной и с кнопкой отката под рукой. То, что нельзя прогнать заранее, обязано иметь путь назад.

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

Тут принято заканчивать оптимистичным выводом: собирайте все в одно, и будет вам счастье. Не будет. Объединение — не всегда правильный ход, и нормальный инженер должен уметь сказать «не трогаем».

Я не возьмусь сводить системы, если они живут разной жизнью. У двух продуктов свои дорожные карты и свой темп? Объединишь — и релизы свяжутся в один поезд, который едет со скоростью самого медленного вагона. За системами стоят разные команды? Единая платформа быстро станет общей очередью, где все ждут друг друга. Объединение создает одну жирную точку отказа там, где раньше падение одного сервиса не роняло остальные? Это не упрощение, а новый риск. Одну из систем и так скоро гасят? Глупо платить за переезд того, что вот-вот похоронят. И самое приземленное: если объединение обойдется дороже, чем вы сэкономите на подписках за несколько лет, оно просто не окупится.

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

Когда объединение действительно нужно и сделано аккуратно, на выходе получается одна платформа вместо россыпи систем. Общая админка, свои модули, никаких ежемесячных платежей чужим сервисам, обновленная и защищенная основа и одна команда на все. Но главное даже не деньги. Знание о системе перестает зависеть от конкретного подрядчика. А это и есть управляемость — ради нее все и затевается.

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

А у вас как с этим? Свели все системы в одну или живете с россыпью сервисов и подписок? Делитесь в комментариях, особенно если есть история, где объединение вышло боком. Такие кейсы ценнее любой теории, и я с удовольствием на них отвечу.

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