Приложение собрано с помощью ИИ, работает, сотрудники пользуются - но автор ушёл, исходников нет, а чинить некому. Разбираем, с чего начинается приём такого решения на сопровождение и что делать в первую очередь.
Прийти к интегратору с фразой «мы сами собрали, но что-то пошло не так» - обычная история. Чаще всего звучит примерно так: «работает медленно», «с другими модулями не приживается», «функции работают почти как надо» или «стоимость владения не радует». Само по себе это не провал - прототип сделал своё дело. Вопрос в том, как довести его до решения, которое переживёт смену сотрудников и следующую доработку.
Если вы только начинаете знакомство с платформой, почитайте что такое Битрикс24 VibeCode - это даст контекст для дальнейшего разговора.
Пока автор решения рядом - всё держится. Он помнит, почему сделал именно так, какой ключ использовал, что закомментировал «временно» три месяца назад. Проблема проявляется на второй-третьей доработке.
Каждое приложение, собранное через диалог с ИИ, получается уникальным. Это не плохо само по себе, но создаёт конкретную инженерную проблему: общих решений нет, правка одной функции задевает остальные непредсказуемым образом. Вендор платформы сам публично признавал: поддерживать такие решения сложно именно потому, что у каждого клиента своя уникальная сборка.
Добавьте сюда скорость: живой кейс из практики партнёров - приложение, собранное через платформу, отвечало по 30-40 секунд на нажатие. После переписки на прямой REST-запрос время отклика сократилось до 2-3 секунд. Это не значит, что платформа плохая, - она молодая и активно оптимизируется. Но это значит, что архитектурные решения, принятые «в процессе разговора с ИИ», бывают неоптимальными и их стоит пересмотреть.
Три потери случаются почти всегда:
Контекст. Никто не знает, почему сделано именно так. Комментариев в коде нет, ТЗ не было, история осталась в чате с ИИ на личном ноутбуке.
Доступы и ключи. Приложение ходит в портал по API-ключу, который создал и знал только автор. Если ключ не задокументирован - найти его уже нельзя, придётся создавать новый и обновлять во всём, что к нему привязано.
Исходники. Если разработка шла в локальном окружении и на сервер заливался только результат - исходников может не быть вообще. Платформа страхует частично: исходники сохраняются при каждом деплое, а для сервера можно включить резервное копирование всего диска. Но это надо было включить заранее и хотя бы раз проверить восстановлением.
Прежде чем что-то чинить, нужно понять, что именно есть. Приём любого навайбкоженного приложения начинается с семи вопросов:
Ответы на эти вопросы дают полную картину и позволяют расставить приоритеты.
Приложение проходит путь от запроса пользователя до данных портала через несколько слоёв:
flowchart LR
USER[Пользователь] --> APP[Приложение на сервере]
APP --> VIBE[Платформа VibeCode]
VIBE --> B24[Портал Битрикс24]
B24 --> DATA[(CRM, задачи,\nсмарт-процессы)]
APP --> OWNDB[(Своя БД\nприложения)]
Если данные оседают в собственной базе приложения, а не в штатных сущностях Битрикс24, это и есть главная архитектурная проблема - она видна уже на этапе инвентаризации.
Порядок работ важен: сначала обратимость, потом безопасность, потом производительность, и только затем - новые функции.
Без этого любая следующая правка - риск потерять всё. Проверяем, включено ли резервное копирование на сервере платформы. Если нет - включаем и тестируем восстановление. Фиксируем исходники в репозитории, а не в папке на сервере.
Проверяем скоупы API-ключа. Часто бывает, что приложение для чтения аналитики работает на ключе с правами на запись - это избыточно и небезопасно. Принцип простой: ключ «только на аналитику продаж, только чтение» не создаст сделку и не изменит данные случайно. Подробнее о том, как это устроено в платформе, читайте в материале про безопасность вайбкодинга в Битрикс24.
Все ключи документируем: кто создал, какие права, где используется, кто владелец. Это занимает полчаса, но спасает при смене сотрудника.
Оцениваем, как приложение обращается к API. Частые проблемы: запросы в цикле вместо пакетных вызовов, отсутствие кеширования при повторных чтениях одних и тех же данных, синхронные вызовы там, где допустима асинхронная обработка. Если приложение тормозит - сначала смотрим сюда, а не в железо.
Это отдельный и частый случай. Данные лежат внутри приложения, а не в штатных сущностях Битрикс24. Из-за этого не работают штатные отчёты, аналитика, роботы и триггеры не видят эти данные, воронки строятся вручную. Перенос хранения в портал - сделки, смарт-процессы, пользовательские поля - обычно даёт больше практической пользы, чем любая новая функция. Это трудоёмкая работа, но она переводит приложение из категории «отдельная система» в категорию «часть портала».
Только после того, как решены вопросы 1-4. Новые функции на нестабильном фундаменте накапливают технический долг.
Цель - чтобы через год, при смене сотрудника или подрядчика, следующий человек не начинал всё заново. Для этого нужны четыре вещи:
Описанная архитектура. Один документ: что делает приложение, какие сущности портала использует, где хранит данные, какой ключ использует и с какими правами. Не нужно 40 страниц - достаточно одной страницы с ответами на вопросы из раздела инвентаризации. Как составить такой документ, помогает понять структура ТЗ на доработку Битрикс24.
Зафиксированные доступы. Ключи, их права и владельцы - в корпоративном хранилище, не в личном мессенджере.
Включённые и проверенные бэкапы. Бэкап, который ни разу не восстанавливали, - это не бэкап.
Понятный владелец на стороне компании. Конкретный человек, который знает, что приложение существует, зачем оно и к кому обращаться при проблемах. Без этого любое решение снова становится бесхозным через несколько месяцев.
Если вы узнали в этом описании свою ситуацию - начните с инвентаризации. Пройдитесь по семи вопросам из соответствующего раздела и честно ответьте на каждый. Это займёт несколько часов, но даст понимание реального объёма работы.
Если на часть вопросов нет ответа - это и есть первоочередные риски.
Для приложений, развёрнутых на платформе VibeCode, часть информации можно восстановить из реестра деплоев и истории исходников - при условии, что деплой делался через платформу, а не вручную. Подробнее о том, как устроены серверы и деплой, читайте в материале про Black Hole-серверы и Галактики Битрикс24.
Если после инвентаризации стало понятно, что нужна помощь - напишите на sales@acp-24.ru или позвоните +7 495 414-48-49. АС Проект - платиновый партнёр Битрикс24 - поможет разобраться с тем, что есть, и довести решение до состояния, которое можно поддерживать. Подробнее о форматах технической поддержки - на странице технической поддержки Битрикс24.
Оставьте заявку - мы свяжемся с вами и проконсультируем.
Эксперт АС Проект свяжется в течение 60 минут.