Подписки на SaaS слетели разом: что переносить к себе в первую очередь

MAATRIX

Карта не проходит, в GitHub и Slack — «account suspended», письмо от Google Workspace про «temporary restriction», и это всё в один день. Первое желание — кинуться разворачивать всё сразу, но так за первые сутки не успеть ничего, а часть сервисов на самом деле может подождать неделю или месяц без вреда для бизнеса. Ниже — план приоритизации: что действительно горит в первые часы, что можно спокойно перенести за неделю, а что вообще не стоит трогать раньше, чем через месяц.

Первый час: поймите, что именно отключилось

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

Три разных сценария требуют разных действий:

• Полная блокировка. Логин не проходит вообще, API отдаёт 403. Здесь данные и код уже недоступны на чтение — приоритет уходит на восстановление доступа (саппорт, альтернативный email, резервные коды 2FA) или на смирение с тем, что старые данные придётся поднимать из локальных копий сотрудников.
• Частичная блокировка / grace period. Логин работает, но оплата не проходит, и сервис прислал «доступ сохранится до N числа». Это лучший случай — у вас есть окно на экспорт всего важного, не тратьте его на споры с поддержкой.
• Деградация. Сервис работает нестабильно из-за гео-фильтрации (ловит капчи, режет скорость, рвёт long-polling соединения в мессенджерах). Часто чинится сменой региона выхода на сервере, а не переездом — не спешите переносить то, что на самом деле можно стабилизировать проще.

Заведите таблицу на 15 минут: сервис — статус — кто админ — где числится оплата — что уникального в нём хранится (то, чего нет больше нигде). Эта таблица и есть основа для приоритизации на следующем шаге.

Критерий приоритета: что сломает бизнес-процессы сильнее всего

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

1. Блокирует ли это чью-то работу прямо сейчас — не «неудобно», а буквально нельзя закоммитить код, нельзя выставить счёт, нельзя ответить клиенту.
2. Есть ли риск необратимой потери данных — аккаунт могут удалить через N дней простоя, экспорт станет недоступен вместе с логином.
3. Видят ли отключение клиенты напрямую — упавшая форма на сайте, недоступный саппорт-чат, не пришедшее уведомление о заказе.
4. Единая точка отказа (bus factor) — доступ к сервису есть только у одного человека, и если проблема совпала с его отпуском, это отдельный кризис поверх основного.

Сервис, который набирает 3–4 балла из этого списка — переносится в первые сутки. 1–2 балла — в течение недели. 0 баллов — можно вообще не торопиться, а иногда и не возвращать. Пример распределения по опыту нескольких таких переездов:

Первая волна (0–24 часа): код, доступы и связь любой ценой

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

Код — вытащить в первую очередь, пока есть доступ на чтение. Даже если полноценный self-hosted git ещё не поднят, зеркалируйте репозитории на любой сервер, до которого дотягиваетесь по SSH:

# на своей машине, пока GitHub/GitLab.com ещё пускает
git clone --mirror git@github.com:org/repo.git repo.git
tar czf repo-mirror-$(date +%F).tar.gz repo.git

# заливаем на сервер, который точно останется под вашим контролем
scp repo-mirror-*.tar.gz user@your-vps:/backup/git-mirrors/

Пройдитесь скриптом по списку всех репозиториев организации (через API, пока он ещё отвечает) — вручную по одному вы не успеете за окно доступа.

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

Связь — не идеальная, а любая работающая. Не тратьте первые часы на выбор идеального мессенджера. Заведите временный канал (рабочая группа в Telegram, если он у всех есть) с одной пометкой «это временно, следующий этап — свой сервер» — и переходите к следующему пункту.

Контроль над доменом и DNS. Проверьте отдельно от остального: жив ли доступ к регистратору домена и панели DNS. Если контроль над доменом утерян вместе с остальным — это отдельный, более тяжёлый инцидент, потому что через домен восстанавливается доступ ко многим другим сервисам (сброс пароля по email на этом домене, подтверждение владения). Разберитесь с ним раньше, чем с чатом.

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

Вторая волна (2–7 дней): разворачиваем рабочую инфраструктуру

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

Git и CI/CD. GitLab CE или Gitea/Forgejo поднимаются на VPS за один вечер через docker compose:

services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    hostname: git.your-domain.ru
    ports: ["443:443", "22:22"]
    volumes:
      - ./config:/etc/gitlab
      - ./logs:/var/log/gitlab
      - ./data:/var/opt/gitlab

Дальше — импорт зеркал, которые вы сняли в первой волне (git push --mirror в новый origin), и настройка GitLab CI runner на том же или соседнем сервере, чтобы деплой не зависел от внешнего CI.

Пароли — свой Vaultwarden. Лёгкий контейнер, совместимый с клиентами Bitwarden, разворачивается быстро и снимает зависимость от чужой подписки навсегда, а не только на время кризиса.

Чат и видеозвонки. Временный Telegram-канал стоит заменить на что-то с управлением доступом и историей — Mattermost или Rocket.Chat для текста, свой Jitsi для звонков. Экономика такого перехода по сравнению с подпиской разобрана отдельно: окупаемость перехода со Slack на свой сервер и цена часа конференции: Zoom против своего Jitsi — там же ориентиры по нагрузке на сервер для команды в 20–50 человек.

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

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

Третья волна (2–4 недели): то, что можно не спешить переносить

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

• Почта компании. Полноценный перенос почтового сервера — это MX-записи, SPF/DKIM/DMARC, репутация нового IP на приём писем. Торопиться вредно: письма начнут падать в спам у получателей, если сделать это на бегу. На первую неделю достаточно временного форвардинга и второго почтового ящика для критичной переписки, полноценный self-hosted сервер — отдельный проект на 1-2 недели с прогревом IP.
• CRM. Если данные клиентов уже выгружены (см. первую волну), давление снижается — можно спокойно сравнить SuiteCRM и другие варианты, а не хвататься за первое, что нашли.
• Дизайн-инструменты, аналитика, маркетинг-автоматизация. В подавляющем большинстве случаев эти сервисы можно просто приостановить на месяц без последствий для операционки — это хороший повод пересчитать, сколько вообще стоит весь SaaS-стек и что из него теперь не нужно вовсе. Разбор такой полной сметы по одному из крупных SaaS есть здесь: чем заменить Google Workspace для компании — там же видно, что часть подписок в стеке обычно оплачивалась «на всякий случай» и реально не использовалась.
• Второстепенные интеграции и вебхуки. Всё, что настраивалось между уже отключёнными сервисами, чинится последним — сначала должны появиться сами системы, между которыми есть смысл что-то связывать.

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

Чеклист по категориям сервисов

Сводная таблица для быстрой сверки — распечатайте или скопируйте в свою систему задач в момент инцидента, когда не до раздумий.

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

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