Сброс техстека: удалите один слой перед большими изменениями

Почему лишние слои замедляют команды

Сброс техстека часто начинается с вычитания. Большинство лишних слоёв попадают в стек по понятной причине, а потом остаются там намного дольше, чем нужно.

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

Небольшие команды чувствуют это первыми. Каждый лишний слой — это ещё одно место, где нужно читать логи, ещё один шаг деплоя, ещё один владелец и ещё один раунд «кто это поменял?». Задача, которая должна занять 20 минут, съедает полдня, потому что один инженер ждёт, пока другой подтвердит, где проблема: в приложении, в обёртке, в очереди или в инструменте между ними.

Передачи между людьми и командами бьют сильнее, чем многие ожидают. Команде из пяти человек не хватает места для бесконечных эстафет. Когда работа прыгает между backend, infra и product, темп падает. Люди теряют контекст. Небольшие баги лежат дольше, потому что никто не хочет снова и снова проходить один и тот же запрос по трём почти одинаковым путям.

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

То же самое происходит с инструментами. Две CI-системы, два трекера ошибок или два инструмента feature flags обычно означают двойную настройку и вдвое меньше ясности. Вы платите дважды, дважды обучаете новых людей и всё равно спорите, какой дашборд говорит правду. Это и есть торможение, без всяких украшений.

Фракционный CTO часто замечает это раньше, потому что такой паттерн повторяется у стартапов снова и снова. Стек выглядит занятным, но проблема проста: команда построила параллельные маршруты для одной и той же работы.

Есть несколько признаков, которые повторяются снова и снова:

• Один запрос проходит через сервисы, которые почти не добавляют бизнес-логики
• Два инструмента отправляют уведомления об одном и том же инциденте
• Старый миграционный код всё ещё работает спустя месяцы после переезда
• Инженеры спорят, где именно начался сбой

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

Где обычно прячутся дублирующие слои

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

Первое место, куда стоит смотреть, — путь запроса. У небольших команд часто появляется wrapper service, который принимает запрос, переименовывает пару полей, пересылает его в другой сервис, а потом возвращает ответ обратно. Если этот wrapper не занимается auth, caching, rate limits или реальной бизнес-логикой, он обычно просто добавляет лишнее время в каждый запрос.

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

Фоновые задачи и поток данных

Дублирующие слои прячутся и в фоновой работе. Частый пример — две очереди для одной и той же задачи. Одна очередь запускает обработку изображений, отправку писем, генерацию отчётов или очистку данных. Потом кто-то добавляет вторую очередь во время переписывания, миграции или попытки масштабирования. Теперь у команды две политики повторов, два пути dead-letter и два места, где задача может зависнуть.

Синхронизация данных — ещё один частый подозреваемый. Команды копируют одни и те же записи дважды, потому что каждому инструменту нужна своя копия, или потому что старый sync-job так и не удалили после запуска нового. Признаки появляются быстро: timestamps не совпадают, поддержка спрашивает, какая таблица правильная, а инженеры вносят патчи, чтобы обе копии оставались «достаточно близкими».

Мониторинг тоже часто дублируется

Дублирующие слои встречаются не только в product code. Они появляются и в дашбордах, и в алертах. Один алерт отслеживает ошибки приложения в logging tool, другой замечает тот же всплеск в metrics tool, а третий срабатывает из cloud provider. Команда получает три шумных сообщения об одном инциденте и начинает игнорировать их все.

Быстрая проверка обычно показывает одни и те же слабые места:

• Сервисы, которые в основном просто пересылают запросы
• Параллельные очереди с одинаковыми payload задач
• Sync-скрипты, которые пишут одни и те же данные в два места
• Дашборды, которые описывают один и тот же сбой разными словами
• API, которые в основном только переименовывают поля

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

Как выбрать первый слой для удаления

Выбирайте слой, который можно отключить, не навредив выручке, поддержке или доверию клиентов. Обычно это внутренний wrapper, дублирующая очередь, sync-job, который зеркалит данные, уже лежащие где-то ещё, или сервис, который в основном переименовывает поля и просто передаёт запрос дальше.

Избегайте слоя, который стоит на пути checkout, login, billing или чего-то, что команда не может объяснить в одном предложении. Первый шаг должен научить вас чему-то, а не отправить компанию в режим паники.

Хорошая проверка проста: если вы отключите этот слой на один час в staging, кто это заметит? Если ответ — «клиенты» или «finance», пока пропустите его. Если ответ — «только engineering, и то, возможно, не сразу», это часто лучшее место для начала.

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

Эта маленькая карта делает две полезные вещи. Она показывает, делает ли слой реальную работу, и выявляет скрытую связанность. Команды часто обнаруживают, что «временная» обёртка теперь кормит analytics, support tools и один забытый cron job.

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

Используйте короткий список перед тем, как решиться:

• У слоя низкий бизнес-риск
• Вы можете назвать каждый вход и каждый выход
• Вы знаете, кто ещё от него зависит
• Вы можете измерить успех после удаления
• Вы сможете быстро вернуть его назад, если что-то пойдёт не так

Запишите правило успеха до любых изменений в коде. Хорошие правила скучные и конкретные: тот же результат для пользователя, меньше движущихся частей, меньше ошибок, на один unit деплоя меньше или на 20 минут короче каждый релиз. Размытые цели потом порождают споры.

Откат требует той же детализации. Решите, кто сможет восстановить слой, сколько это займёт, какие данные может понадобиться переиграть и какой сигнал скажет, что эксперимент пора остановить. Стартап-команды слишком часто пропускают это. Потом маленькая чистка превращается в длинную ночь.

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

Как безопасно удалить один слой

Выберите одно важное действие пользователя и проследите его от начала до конца. Подходит signup, экспорт invoice или «сохранить профиль», потому что можно увидеть весь путь целиком. Запишите каждый переход запроса: browser, API, queue, worker, cache, database. Команды часто замечают дублирующиеся сервисы только после того, как рисуют полный маршрут на одной странице.

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

Небольшая продуктовая команда может многому научиться на одном узком тесте. Допустим, checkout flow сначала отправляет данные в тонкий orchestrator service, а уже потом они доходят до payment API. Если этот сервис не добавляет бизнес-правила, антифрод-проверки или нужные вам повторы, обойдите его для одного типа запроса в staging. Если результат остаётся тем же, лишний переход, скорее всего, просто мёртвый груз.

Следите за переключением в production

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

Во время такого теста смотрите на короткий набор сигналов:

• Процент ошибок и таймауты
• Время ответа для этого действия пользователя
• Сообщения в поддержку от пользователей
• Дублирующиеся задачи, пропавшие события или некорректные записи

Числа важны, но важна и трение. Если после удаления на поддержку приходит меньше жалоб вида «оно на секунду зависло», это тоже считается. В сбросе техстека такие мелкие сигналы часто говорят больше, чем большая схема архитектуры.

Когда новый путь стабилизируется, закончите cleanup. Удалите старые конфиги, feature flags, алерты, дашборды и документы, которые описывают удалённый слой. Если оставить это позади, кто-нибудь потратит полдня, гоняясь за предупреждением от сервиса, который уже ничего не значит.

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

Простой пример из небольшой продуктовой команды

У одной небольшой SaaS-команды была схема, которая на бумаге выглядела безопасно, а в жизни — громоздко. Когда пользователь запускал фоновую задачу, приложение сначала отправляло её в свою собственную очередь. Потом worker забирал её и отправлял ту же задачу в cloud queue, где уже другой worker окончательно выполнял работу.

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

Проблема проявлялась скучно и дорого. Экспорт отчёта мог лежать в очереди приложения 40 секунд, затем попадать в cloud queue и ждать ещё раз. Если что-то ломалось, поддержке приходилось отвечать на простой вопрос неприятным ответом: «Сбой где-то в конвейере».

Команда оставила cloud queue и удалила очередь приложения.

Решение было не драматичным. Cloud queue уже умела управлять правилами повторов, visibility timeouts и масштабированием worker’ов. Очередь приложения в основном просто переносила работу с места на место, а значит команда построила лишнюю задержку для каждой задачи.

После изменения приложение стало отправлять задачи сразу в cloud queue. Один путь worker’а исчез. Один путь повторов тоже исчез. Деплой стал меньше, потому что команде больше не нужно было выкатывать и отслеживать код, который переносил задачи между очередями.

Несколько вещей быстро улучшились:

• Сбои теперь были видны в одном месте
• Логи стали понятнее без сверки двух систем
• Поддержка могла найти зависшую задачу за минуты, а не за полчаса
• Новые разработчики понимали поток уже в первый день

Самая большая победа была не в скорости, хотя задачи и правда стали двигаться быстрее. Победа была в ясности. Когда клиент говорил: «Мой импорт так и не завершился», команда смотрела в одну очередь, на одну группу worker’ов и один поток логов.

Вот почему сброс техстека часто начинается с удаления, а не с замены. Команде не нужна была новая платформа, больший worker framework или свежая схема архитектуры. Им нужно было перестать заставлять каждую задачу ждать дважды.

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

Когда лишняя очередь исчезла, команда смогла увидеть настоящие узкие места. И только тогда следующее улучшение стало очевидным.

Ошибки, которые усложняют сброс

Большинство неудачных работ по очистке проваливаются не потому, что команда выбрала не тот слой. Они проваливаются потому, что пытаются изменить слишком много сразу и потом теряют понимание, что именно сломалось.

Первая ошибка — удалять несколько слоёв за один проход. Команда убирает wrapper service, меняет очередь, правит внутренние API и чистит правила auth в одном спринте. На бумаге это звучит эффективно. На деле обычно получается туман из мелких сбоев. Когда логи шумят или растёт latency, никто не понимает, какое именно изменение виновато.

Лучший сброс — скучный специально. Уберите один слой, понаблюдайте за системой, затем переходите дальше.

Ловушка резервной копии

Вторая ошибка — держать старый путь живым слишком долго «на всякий случай». Короткое окно для отката имеет смысл. Постоянная shadow system — нет. Если оба пути работают неделями, команда теперь владеет двумя системами вместо одной, и ни одной полностью не доверяет.

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

Назначьте жёсткий срок удаления. Если старый путь нужен для отката, скажите точно, сколько он проживёт, кто сможет включить его обратно и какой сигнал докажет, что его можно удалить окончательно. Без этой даты «временное» превращается в «всё ещё здесь через шесть месяцев».

Быстрые проверки перед тем, как считать работу законченной

Сброс техстека завершён не тогда, когда схема выглядит аккуратнее. Он завершён тогда, когда команда ощущает меньше торможения в обычной работе. Если люди всё ещё спрашивают: «Кто владеет этим сервисом?» или «Где проверять эту задачу?», старый хаос всё ещё рядом.

Начните с ответственности. У каждого запроса, фоновой задачи, cron task или webhook должен быть один понятный дом. Если событие всё ещё может пройти через два сервиса, которые оба преобразуют, ставят в очередь или валидируют одно и то же, дублирующий слой всё ещё жив.

Используйте короткий список и будьте к нему строги:

• У каждого запроса или задачи есть один сервис, который отвечает за логику
• Команда первым делом открывает один основной просмотр логов, когда что-то ломается
• Шагов деплоя стало меньше, а движущихся частей — меньше
• В ежемесячном счёте видно явное снижение хотя бы по одной статье
• Никто не называет старый дублирующий инструмент «временным» без даты удаления

Логи быстро говорят правду. Если инженеры всё ещё прыгают между двумя системами логов, чтобы проследить один неудачный запрос, вы просто перенесли путаницу из одного места в другое. Одно основное место для логов не означает, что все инструменты исчезнут, но первая точка входа должна быть очевидной для всей команды.

Деплои — ещё одна хорошая проверка, потому что они показывают скрытую сложность. Посчитайте реальные шаги для обычного релиза, отката и изменения конфига. Если теперь команде нужно больше environment variables, больше secrets или больше координации, чем раньше, удаление слоя сделало жизнь сложнее.

Стоимость тоже должна меняться так, чтобы это можно было объяснить без мучений. Возможно, вы убрали один сервис очереди, один wrapper API или одну лишнюю статью в мониторинге. Экономия не обязана быть огромной. Но её должно быть легко показать.

Небольшая продуктовая команда может убрать вторую систему worker’ов, которая «когда-то помогала при пиках». Через две недели поддержка должна знать, куда попадают упавшие задачи, инженеры должны выкатывать один путь worker’ов вместо двух, а finance должен увидеть, что одна строка исчезла. Если обе системы всё ещё работают «для безопасности», сброс не завершён.

Последняя проверка грубая, но рабочая: задайте трём людям один и тот же вопрос. Куда идёт этот запрос? Где вы смотрите, когда он ломается? Что мы сейчас разворачиваем? Если ответы совпадают, изменение, скорее всего, закрепилось. Если нет — продолжайте убирать лишнее.

Что делать после первого удаления

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

Начните со скучной части. Обновите архитектурную схему, заметки по деплою, support runbooks и setup docs, где ещё упоминается удалённый сервис. Если через месяц кто-то придёт и решит, что старая очередь или обёртка всё ещё существуют, cleanup не завершён.

Привычки команды так же важны, как и схемы. Если инженеры по-прежнему открывают тикеты по-старому, копируют старые шаблоны или следуют устаревшим шагам ревью, тот же лишний слой снова просачивается внутрь. Измените чек-лист code review, поправьте шаблоны и сделайте более простой путь вариантом по умолчанию.

Первый шаг должен ещё и освободить вам время. Используйте это время на следующее узкое место, а не на праздник победы. Если удаление одной обёртки экономит 20 минут на каждом деплое, потратьте эти минуты на медленный test step, шумный алерт или ручную задачу релиза, которая теперь мешает сильнее.

Несколько проверок не дадут сбросу откатиться назад:

• Удалите старые ссылки из дашбордов, алертов и CI jobs
• Уберите мёртвые конфиги, feature flags и fallback scripts
• Напишите короткую заметку о том, почему слой убрали и когда замена была бы оправдана
• Добавьте правило, которое блокирует тонкие wrapper’ы, если они не решают названную проблему

Это правило важнее, чем кажется. Тонкие wrapper’ы часто начинаются как «просто маленький helper», а потом превращаются в ещё одно место, где прячутся баги. Если wrapper не добавляет безопасность, не убирает реальное дублирование и не изолирует инструмент, который вы скоро замените, большинству команд лучше без него.

Сторонний взгляд помогает, когда следующий шаг может повлиять на uptime, облачные расходы или AI tooling. Маленькие ошибки на этом этапе могут затронуть деплои, observability, вызовы к моделям или latency. Свежий взгляд часто замечает связанность, которую команда больше не видит, потому что каждый день обходит её по привычке.

Если вам нужен такой второй взгляд, Oleg Sotnikov на oleg.is работает как Fractional CTO для стартапов и небольших компаний с фокусом на бережную архитектуру, надёжность production и AI-first команды разработки.

Закрепите более простую форму системы, а потом переходите к следующему реальному ограничению. Именно так упрощение архитектуры ПО продолжает приносить пользу, а не исчезает после одного раунда чистки.