Экономика

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

Слово «облако» настолько прочно вошло в IT-лексикон, что постепенно стало создавать ложное ощущение: будто современному цифровому продукту физический компьютер уже почти не нужен. Разработчик открывает панель провайдера, выбирает процессор, память и диск, через несколько минут получает виртуальную машину — и железо словно исчезает из уравнения.

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

IT-инженер Никита Кузнецов считает эту разницу принципиальной. По его словам, проблемы начинаются не тогда, когда бизнес использует облако или виртуальные серверы, а когда удобная абстракция постепенно подменяет понимание того, что находится под ней. 

«Пока сервис открывается, никого не волнует, чей это шкаф и сколько в нём полок. Волнует, когда полка ломается, а ключ от шкафа оказывается у другого человека».

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

Виртуальный сервер не становится отдельным компьютером 

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

С физическим сервером всё относительно понятно. Это конкретная машина с определённым процессором, объёмом оперативной памяти, накопителями и сетевыми интерфейсами. У неё есть предел производительности, она занимает место в стойке, потребляет электричество и может физически выйти из строя. 

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

Но физически отдельной машиной она от этого не становится. 

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

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

«Виртуальный сервер — это не маленький компьютер. Это договор: вам обещают кусок чужого компьютера и делают вид, будто кусок целый». 

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

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

При этом исходный код приложения может вообще не измениться. 

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

Почему виртуальные машины незаметно размножаются

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

Это одно из главных преимуществ облачной инфраструктуры и одновременно источник довольно типичной проблемы. 

Тестовый сервер создают на несколько дней. Затем появляется отдельная машина для интеграции. Потом кому-то требуется временная копия production-среды. 

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

Появляется инфраструктурный «зоопарк», где названия вроде test, test-new, stage-old или prod-copy уже мало кому что объясняют. 

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

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

Облако — это не отсутствие инфраструктуры, а другой способ ею пользоваться 

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

Но удобство не отменяет зависимости. 

«Облако не находится в облаке. Оно находится в чужом здании, на чужих дисках, по чужим правилам и с вашей картой на подписке». 

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

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

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

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

«Облако выгодно тем, кто считает. Оно опасно тем, кто путает кнопку "создать” с тем, что система стала бессмертной». 

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

Почему три сервера не обязательно надёжнее одного 

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

Одна из наиболее обманчивых идей масштабирования выглядит очень логично: если одному серверу тяжело, нужно добавить второй, а затем третий. 

Иногда именно это и требуется. Но увеличение количества машин решает проблему только тогда, когда сама система умеет работать с несколькими экземплярами. 

«Масштаб без порядка хуже тесноты. В тесноте хотя бы ясно, кого винить. В трёх машинах без хозяина виноваты все и никто». 

Как только серверов становится несколько, возникают новые вопросы. Куда направлять входящие запросы? Как балансировщик определяет, что один из экземпляров перестал отвечать нормально? Где хранится состояние пользователя? Можно ли отправить следующий запрос на другую машину? Что происходит с локальными файлами? Одинаковая ли версия приложения развернута на всех экземплярах? 

Если эти вопросы не решены заранее, дополнительный сервер способен не повысить надёжность, а создать новые варианты отказа. 

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

Снаружи пользователь видит лишь нестабильный сервис: одна страница открылась, следующая нет, после обновления всё снова заработало. 

Внутри системы проблема намного сложнее — разные экземпляры перестали вести себя как единое целое.

Поэтому Кузнецов предлагает считать масштабирование не количеством серверов, а способностью архитектуры согласованно использовать эти серверы. Новая машина имеет смысл только тогда, когда заранее понятно, какую работу она получает и как система поведёт себя при её появлении или исчезновении. 

Один и тот же зависший сайт может означать совершенно разные аварии 

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

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

«Пользователь видит одну крутилку. Инженер обязан видеть три разные могилы. Иначе вы начнёте докупать память там, где кончился диск». 

Представим три простых сценария. 

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

Во втором заканчивается оперативная память. Система начинает активнее использовать swap, резко теряет производительность или операционная система завершает процессы, которым больше невозможно выделить необходимый объём памяти.

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

Для человека перед экраном результат действительно почти одинаков: приложение не работает нормально.

Для инженера это три разных аварии и три разных способа лечения. 

Именно поэтому простое увеличение тарифа далеко не всегда решает проблему. Дополнительная память не освободит заполненный диск. Более мощный процессор не исправит бесконтрольный рост логов. Новый сервер не устранит утечку памяти, если та же ошибка автоматически переедет на него вместе с приложением. 

Сначала необходимо понять характер отказа. Только после этого имеет смысл увеличивать ресурсы. 

Зелёный статус сервера ещё ничего не гарантирует 

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

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

Сервер включён. Процесс существует. Проверочный endpoint отвечает. Формально всё зелёное. 

При этом база может отвечать настолько медленно, что нормальная работа невозможна. Диск может быть почти заполнен. Очередь задач — расти быстрее, чем обрабатываться. Отдельный критический пользовательский сценарий — завершаться ошибкой. 

Поэтому мониторинг инфраструктуры не должен ограничиваться вопросом «сервер жив или нет». 

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

Если команда узнаёт о проблеме только после жалобы клиента, мониторинг фактически зафиксировал не начало аварии, а её последствия. 

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

Контейнер решает одну проблему, но не отменяет сервер  

Никита Кузнецов — о контейнерах и инфраструктуре, которая всё равно остаётся под программным слоем.

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

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

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

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

«Контейнер не делает программу умнее. Он делает её переезд менее враньём. Вы упаковываете не код. Вы упаковываете условия, в которых код согласен жить». 

Это действительно серьёзное преимущество. Но контейнер не создаёт вычислительные ресурсы из воздуха.

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

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

Более того, контейнеры тоже требуют управления. 

Нужно понимать, какие образы используются, где они хранятся, какие версии запущены, какие ограничения ресурсов установлены и что происходит со старыми экземплярами после обновления. 

Контейнер делает среду приложения более воспроизводимой. Он не отменяет инфраструктуру, на которой эта среда существует. 

Надёжность начинается с понимания того, что находится под интерфейсом 

Если убрать терминологию, картина оказывается довольно приземлённой. 

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

Ни одна из этих технологий сама по себе не делает систему надёжной. 

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

Именно поэтому Никита Кузнецов предлагает начинать разговор об инфраструктуре не с названия облачного провайдера, панели управления или модной технологии.

«Инфраструктура начинается не с панели и не со слова "облако”. Она начинается с вопроса: что у нас настоящее, что арендованное и какая смерть будет первой». 

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

Но чем проще становится кнопка «создать», тем важнее не путать простоту интерфейса с простотой самой системы. 

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

Пока всё работает, эту цепочку действительно можно почти не замечать. Во время аварии она проявляется целиком.