Аудит подписок: как найти платежи-призраки в инфраструктуре

MAATRIX

Раз в квартал стоит открыть выписку по корпоративной карте и честно спросить себя: а этим сервисом кто-нибудь ещё пользуется? В большинстве команд ответ на треть строчек — «не знаю» или «кажется, нет». Это и есть платежи-призраки: подписки и облачные ресурсы, которые продолжают списываться месяц за месяцем просто потому, что их никто не отменил. Ниже — рабочая методика, как их найти и закрыть, без лишней драмы и без риска сломать что-то нужное.

Почему призраки заводятся сами собой

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

Механизм всегда один: у платежа есть создатель, но нет владельца. Создатель завёл подписку под свою задачу и переключился на следующую. Владельца, который обязан раз в квартал ответить на вопрос «оно нам ещё надо», никто не назначил. Автопродление тем временем работает исправно — это единственная часть системы, которая точно не забывает о себе.

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

Шаг 1. Соберите полный список всех регулярных платежей за год

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

Источники, которые нужно поднять:

• Выписка по корпоративной карте за 12 месяцев — банк почти всегда даёт выгрузку в CSV или Excel за произвольный период.
• Выписки по личным картам сотрудников, если в компании принято сначала платить лично, а потом компенсировать — такие подписки чаще всего и оказываются призраками, потому что о них знает только один человек.
• История платежей в PayPal, Stripe Billing (если вы сами через него что-то оплачиваете) и в криптокошельках, если часть сервисов оплачивается стейблкоинами.
• Панели самих провайдеров — у облачных платформ, реестраторов доменов и SaaS-сервисов обычно есть раздел billing с историей и датой следующего списания.

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

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

Полезная деталь: в выписке многие подписки называются криптично — не «Zoom Pro», а какой-нибудь ZM*ZOOM.US 888-799.... На сведение таких строк с реальными сервисами уходит заметная часть времени первого прохода. Не пытайтесь сделать это идеально с первого раза — соберите то, что распознаётся, отметьте непонятные строки отдельным цветом и вернитесь к ним после того, как разберётесь с очевидным.

Шаг 2. Проверьте по каждому платежу — используется ли сервис сейчас

Это не «нужен ли он в целом», а конкретный факт: заходил ли туда кто-то за последние недели и есть ли там активность.

Что проверять по каждой строке из таблицы:

• Дата последнего входа. У большинства SaaS-сервисов в настройках аккаунта или в разделе для администратора есть лог последних сессий пользователей. Если последний вход был несколько месяцев назад — это уже сильный сигнал.
• Количество активных пользователей против количества оплаченных мест. Если вы платите за 10 мест, а логинится 3 человека, вопрос не «отменять или нет», а «зачем 10».
• Есть ли у сервиса живые данные, которые никуда не выгружены. Иногда инструмент formально не используется для работы, но там лежит архив, на который есть ссылки из документации. Такую подписку нельзя резать одним днём — сначала выгрузка, потом отмена.
• Кто в компании назовёт причину, зачем это нужно, без паузы дольше пяти секунд. Грубый, но рабочий фильтр: если на прямой вопрос в общем чате никто не отвечает в течение дня — это уже кандидат в список на пересмотр.

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

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

Шаг 3. Для облачных ресурсов проверяйте загрузку, а не факт существования

Отдельная и более коварная категория — не подписки на SaaS, а сами облачные ресурсы: серверы, диски, статические IP, снапшоты, балансировщики. Здесь мало спросить «используется ли сервер» — сервер отвечает на пинг всегда, даже если на нём давно ничего не работает.

Правильный вопрос — не «существует ли ресурс», а «есть ли на нём реальная нагрузка».

Что стоит смотреть по каждому серверу и облачному ресурсу:

• Загрузку CPU и сети за последние недели в панели провайдера или через top/htop и vnstat прямо на сервере. Сервер, у которого CPU почти всегда около нуля, а по сети проходят только системные пакеты и cron-проверки — верный кандидат.
• Активные сетевые соединения. Команда ss -tulnp покажет, какие порты вообще слушаются, а who и last — заходил ли кто-то по SSH за последний месяц.
• Возраст последнего деплоя или обновления кода. Если в директории проекта дата последнего изменения файлов — полгода назад, а рядом крутится сервис-затычка на другом сервере, который эти файлы заменил, старый сервер, скорее всего, просто забыли выключить.
• Диски и снапшоты без привязки к работающей машине. Такие ресурсы отдельно тарифицируются почти у всех провайдеров, но не отображаются на первом экране панели — их нужно смотреть в разделе storage/volumes отдельно.
• Статические IP-адреса, отвязанные от серверов. У части провайдеров неиспользуемый зарезервированный IP тарифицируется дороже, чем привязанный к работающей машине — это классический тихий призрак.

Простой чек-лист для одного сервера — если на три вопроса подряд ответ «нет», это кандидат на снос:

1. Есть ли за последний месяц заметная загрузка CPU выше фонового шума?
2. Заходил ли кто-то по SSH или в панель управления за последние недели?
3. Есть ли действующий домен или интеграция, которая реально обращается к этому серверу?

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

Шаг 4. Составьте список кандидатов и проведите отмену поэтапно

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

Разделите кандидатов на три группы:

• Отменить сразу. Явные дубли, тестовые окружения без единого признака активности за месяцы, доступы уволенных сотрудников без переданных прав. Здесь долгих согласований не нужно.
• Сначала выгрузить данные, потом отменить. Сервисы, где формально никто не работает, но есть архив или история переписки, которые могут понадобиться. Выгрузка занимает час, а отмена без неё может стоить данных, которые уже не вернуть.
• Требует решения владельца процесса. Подписки, по которым нет однозначного ответа — например, инструмент используется одним человеком раз в месяц для отчётности перед инвесторами. Здесь решение принимает не тот, кто проводит аудит, а тот, кто отвечает за процесс.

Для каждой отмены — короткий протокол:

1. Написать в общий чат команды: «отменяем такой-то сервис такого-то числа, если он кому-то нужен — напишите до этой даты».
2. Дождаться дедлайна (обычно достаточно недели).
3. Экспортировать данные, если они есть.
4. Отменить подписку или удалить ресурс, зафиксировать дату и сумму экономии в той же таблице.
5. Проверить через один платёжный цикл, что списание действительно прекратилось — иногда отмена в интерфейсе не останавливает уже выставленный счёт за текущий период.

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

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

Где чаще всего прячутся призраки

После нескольких проходов аудита в разных командах закономерность становится видна — призраки почти всегда живут в одних и тех же местах.

Забытые тестовые и staging-окружения. Их поднимают под конкретную задачу — проверить гипотезу, показать демо клиенту, прогнать нагрузочный тест. Задача закрывается, а окружение остаётся, потому что «вдруг ещё пригодится». Отдельная опасность таких серверов — на них часто оставляют более слабую защиту, чем на проде, и в сумме с CPU и трафиком это ещё и тихий риск безопасности, а не только статья расходов.

Старые интеграции после смены основного инструмента. Переехали с одной CRM на другую, с одного хостинга почты на другой, с одного облака на другое — но старую учётную запись не закрыли, потому что «там могут быть письма» или «вдруг откатимся назад». Через полгода откатываться уже некому и незачем, а счёт идёт.

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

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

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

Если в какой-то момент выяснится, что весь смысл платной подписки на внешний сервис — это одна-две функции, которые проще держать на собственном сервере, стоит сразу прикинуть цифры по методике из статьи про экономику своей Jira против облачной подписки — принцип расчёта там универсальный, а не привязан к конкретному инструменту. Общий обзор того, что вообще имеет смысл держать у себя, а что выгоднее оставить на подписке, есть в материале про экономику self-hosted.

Частые вопросы