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