← Все статьи
Кейсы

Кейс: 134 воркфлоу в проде и один инженер

Последние годы я веду AI-направление закрытой community-платформы (проект под NDA, поэтому без имён и деталей продукта). Стек: Directus + n8n + React, поиск на векторной базе Qdrant, пять арендаторов на одной кодовой базе, полный набор стендов - dev, stage, prod. Моя зона - AI-матчинг участников, логика агентов, схемы данных и прикладная архитектура. И примерно 134 продакшн-воркфлоу n8n, которые всё это исполняют.

Этот кейс - не про то, как построить 134 воркфлоу. Построить как раз несложно. Он про то, как один инженер держит их в проде так, чтобы система развивалась, а не осыпалась.

Где на самом деле потолок low-code

Low-code продаётся как "быстро собрал - работает". Это правда, но потолок наступает не при сборке, а при сопровождении. Сто с лишним воркфлоу невозможно держать в голове: через полгода собственная схема читается как чужая, любое изменение может задеть соседний процесс, а онбординг нового человека занимает недели.

Обычный финал такой истории - "у нас есть человек, который знает, как оно работает, не трогайте его". Это не масштабируется и делает проект заложником одной головы. Меня такой финал не устраивал, потому что эта голова - моя.

Что держит систему

Документация живёт внутри воркфлоу

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

Правило простое: заметка пишется для того, кто открыл воркфлоу впервые. На практике "тот, кто открыл впервые" - это я сам через полгода и AI-ассистент, которому нужен контекст. Расследование "почему тут так" сокращается с часа археологии по нодам до двух минут чтения.

Воркфлоу - это код в git

Изменения в воркфлоу идут через репозиторий, а не мышкой на проде. Экспорт в файлы, версии, диффы, откат - всё, к чему привыкли в обычной разработке, работает и для low-code. Когда что-то сломалось, я смотрю дифф, а не вспоминаю, "что я там вчера кликал".

Стенды и управляемый промоушен

Dev - верстак: здесь можно ломать. Stage - репетиция. Prod - только то, что прошло первые два. Идентификаторы воркфлоу и учёток на стендах выровнены, поэтому перенос изменения - это управляемая процедура, а не ручное пересобирание "по образцу".

Скучно? Да. Но именно скучные процедуры позволяют одному человеку спокойно катить изменения в систему, которой ежедневно пользуются живые люди у пяти арендаторов.

AI-ассистент как второй инженер

Рутину сопровождения я отдаю AI-агенту: инвентаризация воркфлоу, сверка стендов между собой, поиск "куда ещё ходит эта коллекция", черновики тех самых заметок "О процессе". Здесь замыкается круг: агент эффективен ровно потому, что первые три пункта дали ему читаемую систему - документацию, файлы в git, предсказуемые стенды.

Это, пожалуй, главный вывод кейса: AI-ассистент не компенсирует бардак, он умножает порядок. На хаосе он умножает хаос.

Результат

Один инженер ведёт AI-направление платформы на пять арендаторов: развитие, сопровождение и прод-инциденты - без "человека-энциклопедии" в единственном экземпляре, потому что знание о системе лежит в самой системе. Новая фича начинается с чтения заметок, а не с раскопок. Инцидент - с диффа, а не с паники.

Отдельный бонус всплыл позже: когда понадобилось передавать часть процессов коллегам, онбординг свёлся к "открой воркфлоу и прочитай заметку". Документация, написанная для себя-через-полгода, оказалась готовой документацией для кого угодно.

Что забрать себе