Уборка инфраструктуры после пивота без сбоев в prod

Что остаётся после пивота

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

Так происходит по обычным причинам. Команды спешат выпустить новый план, оставляют старые части на месте на всякий случай и обещают себе убрать их позже. Позже растягивается на полгода. К тому времени уже никто не помнит, почему сервис import-sync-v1 всё ещё работает, нужна ли старая очередь SQS и кто отвечает за staging-кластер с меткой temporary.

Утечка расходов начинается с малого. Одна очередь, два крошечных инстанса, пустая база данных, забытый узел Redis, preview-окружение, которое никто не открывал с весны. Каждый счёт по отдельности выглядит безобидно. Но вместе они могут каждый месяц уводить реальные деньги, особенно когда на фоне продолжают расти бэкапы, логи, snapshot’ы и сетевой трафик.

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

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

Хорошая уборка аккуратная, а не безрассудная. Цель проста: перестать платить за старый багаж дорожной карты и убедиться, что заброшенные компоненты не смогут помешать текущей работе. Удаляйте с доказательствами, а не наугад.

Начните с полного инвентаря

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

Начните с сырого списка, а не с красивой таблицы. Заберите данные из облачного аккаунта, из контейнеров или VM, из CI-runner’ов, из scheduler’а и из конфигурации приложения. Вам нужен один список, где будут все работающие сервисы, очереди, базы данных, bucket’ы, cron-задачи, воркеры, кэши и фоновые процессы.

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

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

Данные об использовании показывают, живо ли что-то или просто забыто. Проверьте объём запросов, глубину очереди, подключения к базе, логи, запуски cron-задач и историю деплоев. Сервис, который не получал трафик 45 дней и не деплоился 6 месяцев, скорее всего, не нуждается в героическом спасении. Ему нужен review на выключение.

Владение важнее, чем многим кажется. Запишите, кто может ответить на один простой вопрос: «Что сломается, если мы это выключим?» Если никто не знает, пометьте этот пункт. Бесхозные ресурсы чаще всего создают самые неприятные сюрпризы в счетах, потому что все думают, что это всё ещё нужно кому-то другому.

Первый проход делайте грубым. «Активно», «возможно устарело» и «неизвестно» — этого достаточно. Потом можно уточнить.

Простой пример делает это наглядным. Допустим, после пивота ваша компания отказалась от marketplace-функции. Тогда вы можете всё ещё найти старый search-worker, две очереди, staging-базу, object bucket с экспортами и ночную reconciliation-задачу. По отдельности ничего не выглядит драматично. Вместе это сжигает деньги и создаёт риск.

Если пропустить инвентаризацию, вы просто гадаете. А на догадках команды и продолжают платить за дорожную карту, которую уже давно выбросили.

Решите, что оставить, что приостановить, что заархивировать, а что удалить

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

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

Память здесь плохой советчик. Старые заметки по проекту часто описывают планы, которые так и не вышли, а члены команды обычно переоценивают, насколько сервис всё ещё важен. Используйте свежие факты. Смотрите на трафик за последние 30–90 дней, запуск задач, чтение базы, ошибки, деплои и биллинг. Если очередь не обрабатывала реальную работу два месяца, это говорит больше, чем документ по roadmap за прошлый год.

Разделяйте клиентские системы и внутренние инструменты как можно раньше. Фоновый воркер, связанный с логином, биллингом или данными клиентов, должен пройти гораздо более строгую проверку перед тем, как его можно будет остановить или убрать. Заброшенное demo-окружение, старое QA-приложение или отчёт, который никто не читает, гораздо быстрее уходят в pause или archive.

Хорошо работает простое правило: сначала защищайте всё, что влияет на живых пользователей, а всё остальное проверяйте жёстче.

Записывайте причину каждого решения. Коротко. Одной строки достаточно: «оставить до миграции последнего enterprise-клиента», «заархивировать, потому что finance могут понадобиться логи для аудита» или «удалить, потому что нет трафика, нет владельца и есть дубликат сервиса». Такая пометка спасёт от повторения того же спора в следующем месяце.

Если не уверены, не прыгайте сразу к delete. Сначала приостановите, понаблюдайте за жалобами, а потом убирайте полностью. Этот дополнительный шаг предотвращает множество простоев.

Удаляйте старые очереди по шагам

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

Относитесь к очередям особенно аккуратно, потому что один пропущенный publisher или worker может сломать живой поток. Начните с полной схемы вокруг каждой очереди. Вам нужно понимать, кто отправляет сообщения, кто их читает, какие правила повторов ещё работают и есть ли dead-letter queue для ошибок. Если пропустить эту схему, вы будете удалять наугад.

Безопасный процесс прост. Найдите название очереди в коде приложения, в коде воркеров, в scheduled-задачах и в файлах деплоя. Посмотрите все места, которые всё ещё отправляют сообщения, а не только сервис, который создал очередь первым. Затем проверьте runtime-данные. Объём сообщений, число повторов, возраст самого старого сообщения и активность dead-letter queue показывают, действительно ли очередь простаивает или тихо ломается.

После этого сначала поставьте на паузу самого безопасного consumer’а. Выберите воркер, который занимается некритичной работой, а потом какое-то время смотрите логи, алерты и обращения в поддержку. Перед тем как удалять что-либо, остановите новые записи. Если producer’ы всё ещё отправляют сообщения, backlog продолжает расти, и тест ничего не доказывает.

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

Когда вы остановите producer’ов, слейте backlog намеренно. Обработайте сообщения, если они ещё важны, заархивируйте их, если нужен след, или удаляйте только после того, как убедитесь, что бизнесу эти данные больше не нужны. Dead-letter queue требует такого же внимания, потому что там часто лежит единственное доказательство сломанного пути.

Удаляйте очередь последней, а не первой. Уберите из кода настройки очереди, переменные окружения, Terraform или другие deploy-конфиги, мониторинг и дашборды. Если оставить конфигурацию, кто-то сможет воссоздать очередь при следующем деплое и снова запустить биллинг, который вы хотели остановить.

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

Останавливайте устаревшие сервисы и неиспользуемые окружения

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

Начните с одного прямого вопроса: делает ли этот сервис сейчас что-то реальное? Проверьте живой трафик, scheduled-задачи, активность webhook’ов и ошибки. Сервис может выглядеть пустым днём и всё равно запускать ночную синхронизацию в 2 часа ночи.

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

Перед удалением сохраните то, что может понадобиться позже. Заархивируйте свежие логи, конфиги деплоя, теги образов контейнеров, ID snapshot’ов базы и любые заметки о том, зачем этот сервис вообще существовал. Сейчас на это уйдёт час, а позже это может спасти долгий вечер, когда кто-то спросит: «А зачем у нас вообще был этот воркер?»

Чистое выключение обычно идёт в одном и том же порядке. Сначала остановите входящий трафик и запланированную работу. Потом подождите и убедитесь, что сервис действительно молчит. Затем заархивируйте логи, конфиги и snapshot’ы. После этого удалите сервис и потом — связанные ресурсы. И ещё несколько дней смотрите на биллинг.

Последний шаг ловит больше хвостов, чем люди ожидают. Самого приложения уже нет, а всё дополнительное осталось: load balancer’ы, зарезервированные IP, хранилища, NAT gateway, старые snapshot’ы и secrets, которые месяцами лежат в менеджере.

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

Один частый пример — стартап, который после пивота к B2B убирает marketplace-функцию. Фронтенд-маршрут исчезает, но search-worker для matching, Redis-кэш, staging-база и два preview-окружения остаются онлайн. Никто не замечает этого, пока не приходит ежемесячный счёт. Удалить приложение помогает немного. Удалить всю цепочку — вот где и начинается настоящая уборка расходов.

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

Простой пример уборки

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

Три лишних компонента продолжали работать. Один воркер всё ещё опрашивал очередь задач по выплатам продавцам. Небольшой инстанс Redis всё ещё хранил retry-данные для marketplace-событий. Два staging-приложения — одно для потока покупателей, другое для кабинета продавца — всё ещё пересобирались на каждый merge, хотя ими никто не пользовался.

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

Они искали в кодовой базе старые названия очередей, хост Redis и URL staging-приложений. Смотрели логи и метрики за семь дней, чтобы понять, приходят ли ещё задачи и работают ли воркеры по-настоящему. Проверяли cron-задачи, webhook’и и CI-pipeline’ы, чтобы не пропустить ничего, что могло бы разбудить эти сервисы. Ещё они спросили у support и product, не зависит ли от старых staging-приложений какой-нибудь внутренний процесс.

Проверки показали ясную картину. В очередь выплат не приходило новых сообщений уже несколько недель. Воркер просыпался, ничего не находил и продолжал списывать время вычислений. Redis по-прежнему хранил данные, но только потому, что у старых ключей не было срока жизни. У staging-приложений не было входов и тестового трафика, кроме одного забытого health check.

Команда убирала всё по порядку. Сначала отключила воркер и понаблюдала за ошибками. Затем сделала snapshot Redis, выключила его и оставила snapshot на короткое окно безопасности. В конце убрала оба staging-приложения из CI, DNS и хостинга, чтобы они не вернулись при следующем деплое.

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

Ошибки, которые приводят к простоям или неожиданным счетам

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

Частая ошибка — удалить очередь, не отследив всех producer’ов. Один воркер может уже исчезнуть, но scheduled-задача, background-task или старая версия приложения всё ещё могут отправлять сообщения в эту очередь. Очередь кажется тихой, пока не приходит волна повторных попыток или не просыпается отложенная задача. Потом перестают двигаться заказы, не отправляются письма или исчезают обновления для клиентов.

Названия помогают меньше, чем людям кажется. Сервис с именем legacy-worker может всё ещё обрабатывать один важный крайний случай. Теги часто ещё хуже. Команды переименовывают продукты, копируют окружения и месяцами не убирают лишнее, поэтому метки перестают совпадать с реальностью. Если доверять названиям и тегам без проверки трафика, логов и свежих деплоев, можно удалить не то, причём с большой уверенностью.

Скрытые зависимости вызывают множество простоев. Старый сервис всё ещё может получать вызовы через DNS-записи, webhook’и, cron-задачи или callbacks от сторонних систем. Именно здесь маленькие системы бьют больнее всего. Забытая ночная синхронизация в 2 часа ночи может вернуть к жизни сервис, который все уже считали умершим. Одна устаревшая DNS-запись может продолжать отправлять пользователей на сервер, который вы собирались выключить ещё на прошлой неделе.

Общие ресурсы — ещё одна ловушка. Реплика базы данных, инстанс Redis, object bucket или monitoring agent могут выглядеть привязанными к одному заброшенному проекту, но другой команде они всё ещё нужны. Это часто происходит в стартапах после пивота, потому что люди работают быстро и переиспользуют то, что уже есть. Перед удалением общего ресурса спрашивайте, кто владеет им сейчас, а не кто его создал.

Бэкапы и snapshot’ы создают другой тип счёта. Команды часто оставляют всё, потому что удалять бэкапы страшно. Через полгода они платят за volumes, snapshot’ы и machine images, которые никто не собирается восстанавливать. Если вы оставляете snapshot, сразу назначайте дату ревью. Если к этой дате никто не может объяснить, зачем он ещё нужен, удаляйте.

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

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

Короткая проверка перед удалением

Удалить не то поначалу редко бывает драматично. Чаще это всплывает на следующий день, когда перестаёт обновляться отчёт, начинает падать webhook или месячный счёт остаётся странно высоким, потому что исчезла только половина старого стека.

Быстрая проверка перед удалением экономит массу переделок. Убедитесь, что инвентарь полный, и рядом с каждым пунктом указан один владелец. Если у старой очереди, воркера, базы данных или staging-приложения нет владельца, никто не сможет сказать, всё ещё ли это нужно. Совместное владение обычно уже само по себе тревожный знак.

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

Сохраните то, что может понадобиться позже. Экспортируйте конфиги, сохраните копию схемы базы, запишите названия очередей и заархивируйте логи или snapshot’ы, если они важны для support, аудита или отката. Не нужно держать всё живым, чтобы сохранить историю.

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

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

Ещё помогает удалять волнами, а не всё сразу. Уберите одну группу очередей, один старый сервис или одно non-production-окружение, а потом подождите достаточно долго, чтобы увидеть ошибки, обращения в поддержку или изменения в биллинге. Небольшая пауза кажется медленной, но она гораздо дешевле, чем восстанавливать то, что вы убрали слишком быстро.

Если счёт не падает после запланированных удалений, считайте, что что-то ещё работает. Проверьте бэкапы, простаивающие базы данных, бесхозные volumes, старые DNS-targets и забытые CI-runner’ы. Такие остатки встречаются часто, и они накапливаются.

Что делать дальше

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

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

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

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

Держите заметки о пивоте рядом с изменениями инфраструктуры. Когда меняется направление продукта, записывайте, какие части вы закрыли, какие данные сохранили, какие задачи остановили и какие алерты убрали. Храните эти заметки там же, где команда ведёт инфраструктурные задачи. Если roadmap снова изменится, вам не придётся гадать, почему старый воркер или staging-стек всё ещё существует.

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

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