Облачная инфраструктура на Selectel: автоматизация и IaC

Облачная инфраструктура Selectel: где ломается

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

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

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

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

Что меняется после перевода сервисов в управляемое облако

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

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

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

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

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

Варианты развёртывания: облачная инфраструктура или свои серверы

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

Между ними — гибридная схема и выделенные мощности. Гибрид оставляет данные в своём контуре, а веб-слой и обработку выносит в облако; выделенные мощности берут там, где нагрузка предсказуема и важна изоляция. Ограничения каждого режима проявляются на конкретном профиле нагрузки, поэтому смотрим на неё, а не на модность подхода.

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

Порядок работ: от аудита до передачи в эксплуатацию

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

1. Аудит инфраструктуры. Инвентаризируем, что где запущено, какие сервисы связаны между собой, где остались ручные операции и единые точки отказа. На выходе — карта текущего состояния с перечнем рисков и приоритетами.
2. Схема сети и целевой среды. Фиксируем сегментацию, правила доступа, маршрутизацию между подсетями и резервные копии. Схема согласуется до начала настройки, чтобы не переделывать окружение по ходу.
3. Описание среды как кода. Конфигурация хранится в репозитории, а не в чек-листах: окружение поднимается из описания и воспроизводится один в один — тестовое повторяет продуктивное.
4. Проверка под нагрузкой. Прогоняем сценарии на пиковом профиле, смотрим время отклика и поведение при отказе отдельного узла. Найденные узкие места устраняем до переноса, а не после.
5. Миграция сервисов. Переносим группами, начиная с некритичных, с обратным переключением на прежнюю площадку. Данные переносятся с проверкой целостности и сверкой контрольных сумм.
6. Документирование. Регламенты восстановления, схемы, инструкции для дежурной команды и порядок внесения изменений — то, по чему среда живёт без нас.
7. Передача в эксплуатацию. Отдаём доступы, проводим обучение команды, фиксируем ответственных за изменения. Дальше остаёмся на связи по плановым доработкам.

Такой порядок убирает главный риск инфраструктурных проектов — когда среда работает, но никто не понимает, как её чинить и менять.

Комплект передачи: схемы, политики доступа, регламенты

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

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

Кейс: переезд сервисов без остановки работы

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

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

Метрики до и после

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

Что делать, если часть сервисов уже на своих мощностях?

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

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

Единая точка входа убирает главную сложность гибрида: приложению не нужно знать, на какой площадке живёт его часть. На входе ставим балансировщик с проверками доступности, за ним — сервисы обеих площадок; короткий TTL в DNS переводит трафик на новую площадку за минуты. Внутренние системы и пользователи обращаются к одному адресу, поэтому перенос не требует правок на их стороне.

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

Частые технические вопросы: доступ, безопасность, откат

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

Что будет с нашими учётными записями после проекта?

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

Как устроены резервные копии и проверяется ли восстановление?

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

Какой план восстановления после сбоя?

Вся инфраструктура описана кодом в репозитории, поэтому контур воспроизводится с нуля, а не собирается руками. Есть регламент реагирования с приоритетами сервисов и порядком действий дежурного. Такой подход убирает класс отказов, где восстановление зависит от памяти конкретного инженера.

Где граница ответственности подрядчика?

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

Обсудим задачу и вернёмся с оценкой и планом

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

• Схема сервисов и связей между ними — даже набросок от руки или список без деталей лучше, чем ничего.
• Профиль нагрузки: пиковые периоды, сезонность, требования к доступности и времени восстановления.
• Сколько нужно сред (разработка, тест, продуктив) и чем они отличаются по составу.
• Ограничения: требования безопасности, внутренние нормативы, действующие договоры с поставщиками.
• Порядок выдачи доступов: кто согласует, нужна ли отдельная учётная запись для автоматизации.
• Болевые точки: где сейчас ручные операции, что чаще всего ломается, какие задачи отнимают время.
• Желаемые сроки: дата запуска и окна, в которые допустимо проводить миграцию.

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

Опишите задачу в свободной форме — вернёмся с оценкой и планом.