Что делать, если у облачной виртуальной машины с CPU-кредитами закончились кредиты в 2026 году?

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

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

Признаки исчерпания CPU-кредитов

CPU-кредиты позволяют некоторым виртуальным машинам временно работать выше базового уровня процессорной производительности. В модели, описанной для B-серии, кредиты накапливаются при работе ниже базового уровня и расходуются при превышении этого уровня. У разных платформ, серий и режимов детали различаются, поэтому переносить правила одной виртуальной машины на другую нельзя: сначала требуется свериться с документацией именно выбранной серии. Это разъясняют официальное описание кредитной модели B-серии и документация модели кредитов для EC2.

CPU Credit Remaining — полезная поисковая формулировка для показателя остатка, но конкретное название метрики зависит от платформы. Например, в документации EC2 показатель остатка называется CPUCreditBalance. Проверяйте имя, единицы измерения и применимость метрики к конкретной серии в описании мониторинга кредитов.

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

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

Как проверить остаток, расход и влияние на приложение

Мониторинг нужно читать как временную последовательность, а не как набор несвязанных графиков. Сначала найдите в документации платформы метрики остатка и расхода кредитов, затем сопоставьте их с загрузкой CPU и бизнес-показателями. В мониторинге Azure список доступных метрик зависит от ресурса и определяется официальным справочником метрик виртуальных машин; определение метрик также можно проверить через документацию API мониторинга.

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

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

Что показывают CPU Credit Remaining и скорость расхода

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

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

Проверка конкурирующих причин

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

• Длительная загрузка CPU. Найдите процессы и запросы, которые занимают процессор, и проверьте, нет ли новых фоновых задач, повторных попыток или цикла обработки ошибок. Сравните нагрузку в обычные и проблемные периоды.
• Изменение трафика и параллельности. Сопоставьте число запросов и активных соединений с журналами балансировщика и приложения. Рост нагрузки может объяснить расход кредитов, но не обязательно означает, что сам тип машины выбран неверно.
• Регламентные задачи и релизы. Проверьте расписания резервного копирования, индексации, импорта, обновлений и развёртываний. Разовый пик после плановой операции не равен постоянной потребности в более мощном процессоре.
• Память, диск и сеть. Проверьте нехватку памяти, подкачку, задержки дискового ввода-вывода и сетевые ошибки. Процессор может выглядеть загруженным, пока приложение фактически ждёт другой ресурс.
• База данных и очереди. Сравните время выполнения запросов, блокировки, число ожидающих задач и объём повторной обработки. Медленная база способна увеличить очередь и задержки даже без исчерпания CPU-кредитов.

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

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

Выбор между текущей машиной, фиксированной производительностью и выделенным сервером

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

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

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

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

Условия принятия решения

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

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

Проверка перед миграцией и расширением изменений

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

• Зафиксируйте исходный профиль. Сохраните графики загрузки, остатка и расхода кредитов, задержек приложения, ошибок, активности базы, очередей, памяти, диска и сети. Отметьте релизы и регламентные работы, чтобы не сравнивать разные условия.
• Определите критерии приёмки. Выберите показатели, которые важны пользователям и эксплуатации: допустимое время ответа, число ошибок, глубина очереди, успешность фоновых задач и поведение под характерным пиком. Установите критерии до теста, а не после просмотра результата.
• Проверьте зависимости. Составьте перечень управляемых баз данных, очередей, хранилищ, DNS-записей, сертификатов, секретов, расписаний и внешних API. Для каждой зависимости определите, останется ли она в облаке и как изменятся сетевые связи.
• Оцените ресурсы и операционные обязанности. Уточните потребность в CPU, памяти, диске, пропускной способности и IP-адресах. Назначьте ответственных за обновления ОС, мониторинг, восстановление, контроль доступа и аппаратные инциденты.
• Подготовьте резервирование и откат. Проверьте, что резервная копия доступна вне основной машины, а восстановление проверено по процедуре. Отдельно определите условие возврата на прежнюю конфигурацию, действия с DNS и порядок переключения записей.
• Проведите тест на ограниченном контуре. Используйте тестовую среду или изменение, которое можно отменить без потери данных. Запустите репрезентативные операции и сравните заранее выбранные показатели с исходным профилем.
• Расширяйте изменение по результатам. Если проверка не прошла критерии, вернитесь к диагностике либо скорректируйте размер облачной машины. Не переносите сервис на основании одного успешного запуска, если не проверены восстановление и штатные регламентные операции.

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

Сопоставление вариантов по одному расчётному периоду

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

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

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

Аренда выделенного сервера XFP Cloud уместна для сервисов со стабильной нагрузкой, когда команде важны ресурсы отдельной физической машины и она готова отвечать за резервное копирование, обновления и восстановление. В отличие от burstable-виртуальной машины с риском ограничения при исчерпании кредитов, физический сервер не использует эту кредитную модель; но он не отменяет ограничений конкретной конфигурации, отказов оборудования и эксплуатационных обязанностей. Поэтому сначала подтвердите причину замедления и критерии приёмки, затем сравните облачный счёт с актуальными параметрами XFP Cloud и переходите к оценке только в том случае, если тестовая схема подходит приложению.

Последняя проверка источников и правил кредитных моделей: 2 ноября 2026 года; сверены официальная документация модели B-серии, описание кредитной модели EC2 и материалы по мониторингу, приведённые выше.