Спросите у любого технического руководителя, где у него серверы, и ответ почти никогда не будет состоять из одного слова. Обычно это звучит так: «основное у Timeweb, но база вынесена на отдельную машину в Hetzner, там дешевле; в AWS лежит S3 и одна старая функция, которую боимся трогать; ещё есть VPS у провайдера, где хостится сайт с прошлого агентства, и физический сервер в офисе с 1С».
Это не бардак и не следствие плохого планирования. Так складывается почти всегда, и по вполне рациональным причинам.
Откуда берётся зоопарк
Первая причина — цена и характеристики. Разница в стоимости выделенных ресурсов между европейскими и российскими провайдерами доходит до кратной. Держать всё в одном месте ради красоты, переплачивая, — плохое решение.
Вторая — законодательство. Персональные данные российских граждан должны обрабатываться на территории России, а вот тестовый контур, сборочные агенты и статика такого требования не имеют. Разделение возникает естественно.
Третья — наследство. Компания покупает подрядчика или проект, вместе с ним получает инфраструктуру у чужого провайдера. Переезд стоит денег и рисков, а работает и так.
Четвёртая — доступность и санкционные риски. После нескольких лет, когда сервисы то отключали оплату, то ограничивали регистрацию, идея «всё в одном облаке» перестала выглядеть безопасной. Распределение — это осознанная страховка.
Итог: мультиоблачность в средней российской компании — это не архитектурное решение, а данность. Вопрос не в том, как от неё уйти, а в том, как с ней жить.
Что на самом деле болит
Сама по себе разница между провайдерами — не проблема. Проблема начинается там, где нужно делать одну и ту же операцию в разных местах.
Первое: не существует общей картины. Чтобы ответить на простой вопрос «сколько у нас всего серверов и что на них крутится», нужно открыть четыре панели, вспомнить четыре пароля, а часть машин вообще нигде не отображается, потому что это железо в офисе. Инвентаризация превращается в электронную таблицу, которая устаревает через месяц.
Второе: разные метрики. У каждого провайдера свой мониторинг, свои графики и свой период хранения. Сравнить нагрузку на двух машинах у разных провайдеров невозможно — они по-разному считают и по-разному рисуют. А ответить на вопрос «что происходило в четверг в 15:40 на всех серверах сразу» нельзя вообще.
Третье: разные способы что-то сделать. Перезагрузить машину в одной панели — одна кнопка, в другой — другая, для железа в офисе — вообще IPMI. Каждая операция требует помнить, где ты находишься.
Четвёртое, самое дорогое: разные счета. Расходы на инфраструктуру размазаны по четырём кабинетам в двух валютах с разными датами списания. Вопрос «сколько мы тратим на инфраструктуру в месяц» требует получаса работы бухгалтера и всё равно даёт приблизительный ответ.
И пятое: доступы. У каждой панели свой набор учётных записей, свои ключи API, свои сотрудники с правами. При увольнении человека нужно вспомнить все места, где он что-то мог.
Что унифицируется легко
Хорошая новость: базовые вещи у всех провайдеров устроены достаточно одинаково, чтобы свести их к общему знаменателю.
Инвентарь — список машин с параметрами, адресами, статусом и локацией. У всех есть API, который это отдаёт.
Метрики — процессор, память, диск, сеть. Здесь важно снимать их самому, а не тянуть из панели провайдера: только так вы получите одинаковую методику подсчёта и общую шкалу времени. Метрика, снятая агентом на самой машине, одинаково устроена что в Hetzner, что на физическом сервере в офисе.
Базовые операции — старт, стоп, перезагрузка. Есть у всех, отличается только вызов API.
Выполнение команд — по SSH это вообще не зависит от провайдера.
Затраты — сложнее, но тоже сводимо: у большинства есть API биллинга, а там, где его нет, расход считается по конфигурации машин и прайсу.
Что не унифицируется — и не надо
Здесь важно быть честным, потому что маркетинговые обещания «единой панели для всех облаков» обычно разбиваются именно об это.
Специфические управляемые сервисы каждого облака не сводятся к общему интерфейсу. Управляемая база данных с автоматическими репликами, очереди, serverless-функции, балансировщики с их правилами — у каждого провайдера это устроено принципиально по-своему. Пытаться сделать для них общую панель — значит получить худший вариант каждого.
Тонкая настройка сети — виртуальные сети, маршруты, группы безопасности — тоже отличается достаточно, чтобы абстракция протекала.
Разумная граница проходит так: общая панель берёт на себя то, что действительно одинаково — инвентарь, метрики, логи, базовые операции, доступ, расходы, инциденты. Всё специфическое остаётся в родной панели провайдера, и это нормально. Ценность не в том, чтобы никогда туда не заходить, а в том, чтобы не заходить туда по десять раз в день ради рутины.
Как выглядит рабочая схема
Практически работающая архитектура состоит из трёх частей.
Первая — подключение провайдеров по API. Токен на чтение и базовые операции, из него подтягивается список машин и их параметры. Это даёт актуальный инвентарь без ручного ведения таблицы: новая машина появляется в панели сама.
Вторая — агент или SSH-доступ на самих машинах. Это то, что даёт одинаковые метрики и логи независимо от того, где машина живёт, и позволяет работать с серверами, которых нет ни в одном облаке: физическими, в офисе, у мелких провайдеров без API.
Здесь есть развилка, о которой стоит сказать прямо. Схема с SSH-доступом от панели к серверам проще в запуске, но означает, что где-то лежит ключ, открывающий все машины. Схема с агентом сложнее в установке, но безопаснее: агент сам инициирует исходящее соединение, входящих портов открывать не нужно, а команды исполняются только те, что явно разрешены. Для инфраструктуры, где серверы разбросаны по провайдерам и часть из них смотрит в интернет, второй вариант надёжнее.
Третья часть — единое хранилище: метрики, логи, инциденты и расходы в одной базе с общей шкалой времени. Именно это превращает набор панелей в инструмент: вопрос «что происходило в четверг в 15:40» получает ответ.
Что это даёт на практике
Самый заметный эффект — исчезает класс задач «пойти посмотреть». Не нужно открывать четыре панели, чтобы понять, всё ли в порядке.
Второй — появляется история. Панели провайдеров хранят метрики неделю-две, и когда через месяц возникает вопрос «когда именно эта машина начала упираться в память», ответить нечем. Собственное хранилище решает это.
Третий — расходы становятся видимыми в одном месте и в одной валюте. Обычно первый же сводный отчёт находит машины, за которые платят и которые никто не использует: тестовый стенд с прошлого проекта, вторая копия базы, поднятая для миграции два года назад.
Четвёртый — доступ управляется централизованно. Один список людей и прав вместо четырёх.
Как это сделано в COSCIO
Провайдеры подключаются как модули: Timeweb, Hetzner, AWS, DigitalOcean, а любой сервер без поддерживаемого API добавляется как обычная машина по SSH. Внутри всё сведено к одному интерфейсу — список серверов, метрики, операции, терминал — независимо от того, где машина физически находится.
Принципиальный момент, который стоит проговорить: платформа не требует переезда. Мы исходим из того, что управляем чужой инфраструктурой такой, какая она есть. Если у клиента домены у одного регистратора, серверы у трёх провайдеров, а почта на четвёртом сервисе — работать нужно с этим, а не предлагать всё перевезти в удобное нам место. Поддержка только одного вендора — это дыра в продукте, а не повод просить клиента перестроиться.
Метрики и логи собирает собственный агент: он устанавливается на сервер, работает от непривилегированного пользователя, ходит наружу сам и не требует открывать входящие порты. Он намеренно не трогает то, что уже настроено на сервере, — конфигурацию SSH, двухфакторную аутентификацию, правила фаервола остаются вашими.
Расходы по всем подключённым провайдерам сводятся в один раздел с пересчётом в выбранную валюту. Инциденты по всем машинам живут в общей ленте.
При этом специфические сервисы каждого облака остаются в родных панелях — см. выше про честные границы. Задача единой панели не в том, чтобы заменить консоль AWS, а в том, чтобы девяносто процентов ежедневной рутины делалось в одном месте.
С чего начать
Не начинайте с переезда — начинайте с инвентаризации.
Соберите полный список машин: всё, что есть у всех провайдеров, плюс физическое железо, плюс то, что арендуют отдельные подразделения мимо ИТ. Последняя категория обычно самая интересная.
Для каждой машины запишите три вещи: кто владелец, что на ней работает, сколько она стоит в месяц. Уже на этом этапе, до внедрения любых инструментов, обычно находятся машины, которые можно выключить прямо сейчас.
Дальше подключите сбор метрик единым способом на всё — и через две недели у вас появится то, чего не было: возможность сравнивать и видеть историю. А вопрос про инструмент решится сам собой, когда станет понятно, чего именно не хватает.