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