«Облако» давно стало привычной частью IT-лексикона. Разработчик выбирает в панели провайдера процессор, память и диск, через несколько минут получает виртуальную машину — и может решить, что физическая инфраструктура больше не имеет значения.
Однако за каждым облачным сервисом по-прежнему стоят реальные процессоры, накопители, сетевое оборудование и дата-центры. Меняется не наличие инфраструктуры, а способ доступа к ней: компания арендует необходимые ресурсы вместо того, чтобы покупать и обслуживать собственные серверы.
IT-инженер Никита Кузнецов считает, что главная опасность возникает тогда, когда удобная абстракция полностью скрывает устройство системы.
«Пока сервис открывается, никого не волнует, чей это шкаф и сколько в нём полок. Волнует, когда полка ломается, а ключ от шкафа оказывается у другого человека».
Виртуальная машина не равна отдельному компьютеру
Для пользователя виртуальный сервер выглядит почти как полноценная физическая машина: у него есть процессорные ядра, память, диск, операционная система и сетевой адрес. Но фактически он остаётся частью физического хоста.
Гипервизор распределяет ресурсы одного сервера между несколькими виртуальными машинами. Это позволяет клиенту оплачивать только необходимую мощность, а провайдеру — эффективнее использовать оборудование.
В обычной работе разница незаметна. Но во время сбоя выясняется, где физически расположены данные, какие ограничения действуют на платформе и что именно изменилось в среде выполнения.
Иногда приложение не менялось вовсе — менялись физический хост, настройки платформы или условия работы провайдера. Поэтому поиск причины только в последнем обновлении кода может завести команду в тупик.
Почему виртуальные серверы начинают множиться
Физическое оборудование нельзя создать одним кликом: его нужно купить, доставить, установить и подключить. Виртуальная машина появляется за несколько минут.
Так возникают временные серверы для тестов, копии production-среды, машины для экспериментов и отдельные экземпляры для интеграций. Через несколько месяцев часть из них продолжает работать только потому, что никто не отвечает за их удаление.
В инфраструктуре появляется «зоопарк» с названиями вроде test-new, stage-old и prod-copy. Если команда не может быстро объяснить, зачем существует конкретная машина, кто отвечает за неё и когда её следует отключить, проблема уже есть.
Виртуальный сервер легко забыть: он не занимает места в офисе и напоминает о себе лишь строкой в счёте провайдера.
Облако не отменяет инфраструктурные риски
Облачные решения позволяют быстро получать ресурсы, масштабировать проекты и распределять их между регионами. Но вместе с мощностями компания принимает правила провайдера: квоты, тарифы, ограничения, API, биллинг и требования к доступности.
По словам Кузнецова:
«Облако не находится в облаке. Оно находится в чужом здании, на чужих дисках, по чужим правилам и с вашей картой на подписке».
В облачной среде по-прежнему нужно понимать, что произойдёт при недоступности региона, насколько проект зависит от конкретных сервисов и можно ли восстановить его в другом месте.
Та же логика относится к расходам. Неиспользуемая виртуальная машина, забытый диск, резервная копия или избыточная конфигурация продолжают тарифицироваться.
«Облако выгодно тем, кто считает. Оно опасно тем, кто путает кнопку “создать” с тем, что система стала бессмертной».
Несколько серверов не всегда означают большую надёжность
Добавление второго или третьего сервера помогает только тогда, когда архитектура умеет работать с несколькими экземплярами.
Нужно заранее определить, куда направляются запросы, как балансировщик обнаруживает сбой, где хранится состояние пользователя, что происходит с локальными файлами и одинаковые ли версии приложения работают на всех машинах.
Если один сервер использует старую версию программы, другой не видит нужный файл, а фоновые задачи запускаются одновременно, масштабирование создаёт новые точки отказа вместо повышения устойчивости.
Поэтому Кузнецов предлагает оценивать масштабирование не количеством машин, а способностью системы согласованно использовать их.
Один симптом может скрывать разные аварии
Фраза «сайт тормозит» не объясняет причину сбоя. За ней могут стоять переполненный диск, нехватка оперативной памяти или чрезмерная нагрузка на процессор.
Если заканчивается место, приложение перестаёт нормально записывать данные. При нехватке памяти система начинает использовать swap или завершает процессы. При высокой загрузке процессора запросы обрабатываются медленно, даже если диск и память ещё доступны.
Увеличение тарифа не всегда помогает. Дополнительная память не освободит заполненный диск, а новый сервер не устранит утечку памяти, если ошибка переедет туда вместе с приложением.
Зелёный индикатор не гарантирует доступность сервиса
Мониторинг может показывать, что сервер включён, процесс работает и проверочный endpoint отвечает. При этом база данных может быть слишком медленной, очередь задач — постоянно расти, а важный пользовательский сценарий — завершаться ошибкой.
Поэтому необходимо контролировать не только состояние машины, но и использование ресурсов, задержки, ошибки, очереди, зависимости и реальные пользовательские операции.
Если команда узнаёт о проблеме только после жалобы клиента, мониторинг фиксирует уже последствия аварии.
Контейнер не отменяет сервер
Контейнеризация помогает сделать окружение приложения более воспроизводимым. Вместе с кодом можно зафиксировать библиотеки, зависимости, переменные окружения и структуру файлов.
Но контейнер не создаёт новые вычислительные ресурсы. Под ним остаются операционная система, виртуальная или физическая машина, процессор, память, накопитель и сеть.
Контейнер не остановит утечку памяти, не сделает диск бесконечным и не снизит нагрузку на процессор. Кроме того, необходимо управлять образами, версиями, ограничениями ресурсов и старыми экземплярами.
Надёжность начинается за пределами интерфейса
Физический сервер — конкретная машина. Виртуальный сервер — программно выделенная часть физической инфраструктуры. Облако — способ получать эти ресурсы у внешнего провайдера. Контейнер — упаковка приложения и его окружения.
Ни одна из этих технологий сама по себе не делает систему устойчивой. Команда должна понимать, где находятся данные, какие ресурсы ограничены, кто отвечает за инфраструктуру и как быстро можно восстановить сервис после сбоя.
«Инфраструктура начинается не с панели и не со слова “облако”. Она начинается с вопроса: что у нас настоящее, что арендованное и какая смерть будет первой».
Чем проще становится кнопка «создать», тем важнее не путать простоту интерфейса с простотой самой системы. За облачным регионом остаются дата-центры, за контейнером — операционная система и сервер, а за зелёными индикаторами — реальные диски, процессоры, память, сеть и ограничения провайдера.
