Хостинг

Фактические показатели SLA хостинг-провайдеров: что вы получаете?

Фактические показатели SLA хостинг-провайдеров стоит сопоставлять с тем, что обещано в договоре. Мы предлагаем участникам r/sysadmin описать реальный опыт SLA инфраструктуры: сколько длились сбои, как отвечала поддержка и что удалось получить в качестве компенсации. Стоит иметь в виду, что ответы в треде не заменяют статистики по всем клиентам.

Как сравнить фактический uptime с обещанным SLA?

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

Какие данные сравниваем

Доступность сервера, скорость поддержки и компенсации лучше рассматривать отдельно. Реальный опыт SLA инфраструктуры сравним только внутри одного типа услуги, региона и периода.

Как считать доступность

Фактический аптайм против SLA сравнивают за один период: при простом расчёте ровно 99,9% доступности за 30 суток означают 43 минуты 12 секунд простоя. Расчёт по договору может исключать плановые работы. Укажите источник замеров, частоту проверок и пропуски наблюдений. Если сайт не работает, это не значит сразу отказ VPS.

Ответ поддержки

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

Как сравнить сроки реакции и устранения P1-инцидентов?

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

Восстановление и исправление

Обходное решение иногда возвращает сервис к работе раньше устранения причины. Поэтому нужны два интервала от начала сбоя: до восстановления и до окончательного исправления. Незавершённые инциденты и повторные открытия заявок при наличии отмечайте отдельно. Для нескольких случаев хватит и списка длительностей. При большом числе однотипных сбоев будут полезны p50 и p95: времена, в которые укладываются 50% и 95% случаев. Для ответа, восстановления и исправления нужны отдельные расчёты.

Сообщения об аварии

Когда запись появилась на странице статуса? Как часто её обновляли, давали ли срок восстановления и объяснили ли причину после сбоя? Обсуждение SLA системными администраторами на таких деталях и держится.

Что компенсировали

Интересен и опыт получения компенсации по SLA: требовалась ли заявка, какие доказательства запросили и сколько в итоге начислили. Например, в SLA Amazon EC2 сервисный кредит обычно уменьшает будущие платежи за EC2. У вашей услуги могут быть другие условия. Отдельно отметьте maintenance exclusions – плановые работы, которые договор выводит из расчёта доступности.

Как сопоставить компенсацию по SLA с ущербом?

1. Сумма и форма полученной компенсации: деньги или зачёт будущих платежей.

2.     Сумма ущерба и способ оценки, если такой расчёт есть.

3.     Срок начисления или причина отказа.

Что оставить за рамками

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

Шаблон ответа

Скопируйте поля ниже. Если цифра неизвестна, так и напишите. Догадки только исказят сравнение.

Услуга, регион, тарифы услуги и поддержки:

Период, часовой пояс, число инцидентов:

Условия SLA, ссылка, исключения:

Наблюдаемый аптайм, минуты простоя, источник:

Тяжесть сбоя, начало отсчёта каждого интервала:

Время ответа, восстановл

22 → 187 сборок выделенных серверов в Москве ⚡️

Расширили линейку выделенных серверов в Москве с 22 до 187 конфигураций. Теперь подобрать сервер под нужную задачу можно еще точнее.

➖ Ходовые Intel Xeon E3, E5 и E-серии, Intel Core i7 и i9, AMD Ryzen 9 на DDR5. Под сайты, приложения, dev-стенды и 1С, где важна высокая частота ядер.

➖ Двухсокетные Intel Xeon Scalable Silver. Под виртуализацию, средние базы и все, где нужно много памяти и потоков.

➖ Мощные двух- и четырехсокетные Intel Xeon Gold 6230R, 6240 и 6330. Под тяжелые базы, большую аналитику и крупные проекты.

Посмотреть все конфигурации →

Облачные провайдеры поднимают российский ИТ-рынок

Аналитики считают, что российский ИТ-рынок вырастет в 2026 году всего на 4%, а к двузначному росту вернётся не раньше 2028 года. Основные причины — замедление экономики и смещение фокуса с цифровизации к поддержке базовых процессов. Мы бы ещё прибавили значительный рост цен на комплектующие и их дефицит.

Кто тянет российский рынок? Облачные сервисы — хотя в 2026 году темп роста замедлится, но все равно составит 20%. А сервис аренды GPU-мощностей — на 36% и будет столько же прибавлять до 2028 года. Полагаем, что главным драйвером развития рынка остаётся ИИ: компании разрабатывают собственные модели, локально запускают доступные мировые решения. И аналитики считают, что рост проходил бы ещё быстрее, если бы не дефицит площадок под дата-центры, из-за которого замораживаются проекты постройки новых ЦОДов. RUVDS уже писала, что повышение аренды земли под вычислительные комплексы в десятки раз — не лучший стимул для развития отрасли.

Возвращаясь к дефициту компонентов, он приводит к интересным последствиям — аналитики OCS сообщили, что впервые поставки серверных SSD превысили продажи жестких дисков для серверов. Хотя твердотельные накопители дорожают быстрее, в условиях ограниченных ресурсов компании выбирают более эффективное решение. Производству жёстких же дисков мешает дефицит комплектующих — производители начинают уделять внимание самым топовым моделям, но они стоят дороже и у клиента уже возникают вопросы — не целесообразнее ли купить HDD. Естественно, базовые преимущества SSD (скорость) и жёстких дисков (низкая цена хранения) остаются, и в мировом масштабе основная информация хранится именно на HDD.

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

SpaceWeb — 25 лет. По этому поводу мы спрятали немного истории и раздаем подарки

Привет, Хабр! На связи команда хостинг-провайдера SpaceWeb. Сегодня, четвертого сентября, нам исполняется 25 лет. За это время мы прошли путь от первых сайтов на хостинге до VDS, облачной инфраструктуры и ИИ в техподдержке — и накопили достаточно историй, чтобы не ограничиваться обычным юбилейным постом.

К 25-летию мы уже выпустили на Хабре серию материалов под хэштегом #spaceweb25лет. В них вспоминаем, как менялся рынок хостинга, спорим о будущем shared-хостинга, обсуждаем ИИ-агентов с админскими правами, клиентский сервис, наем и то, кто вообще будет выбирать провайдера через следующие 20 лет — человек или AI.

А теперь предлагаем проверить, насколько внимательно вы всё это читали.

Мы собрали небольшой юбилейный квест из 10 вопросов. Ответы специально не лежат рядом с формой: за ними придется немного побродить по нашим статьям на Хабре, сайту SpaceWeb и соцсетям. Где-то нужно найти факт из истории компании, где-то — пасхалку, а где-то вспомнить техническую деталь из одного из материалов.

Например, придется выяснить, на чем был запущен самый первый сайт SpaceWeb, каким словом наш коммерческий директор описал состояние shared-хостинга, как зовут паука-птицееда, которого мы опекаем в Ленинградском зоопарке, и сколько сайтов сегодня размещено на нашем хостинге.

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

И еще один подарок без всяких вопросов и розыгрышей: по промокоду #spaceweb25 можно получить скидку 20% на услуги хостинга и VDS.

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

Переходите на страницу юбилейного квеста, отвечайте на все вопросы и участвуйте в розыгрыше. А если какой-то ответ не знаете — скорее всего, мы уже где-то спрятали его в материалах по тегу #spaceweb25лет.

Одно из преимущество размещения системы складского учёта на своём хостинге по сравнению с облаком.

Крупные SaaS‑сервисы — «вкусная» мишень для DDoS‑атак, ведь упавший гигант парализует тысячи компаний. Self‑hosted система убирает ваш бизнес из этого «списка массового поражения»: отдельный сервер не представляет интереса для масштабных атак, а значит, риски простоя снижаются.

Дайджест Рег.облака за август

Август выдался насыщенным: ввели оплату ИИ-моделей по токенам, выпустили новый тариф со 192 ГБ видеопамяти, опубликовали два кейса по миграции, подвели итоги первого полугодия, провели вебинар по выделенным серверам и выложили несколько полезных статей на Хабре. Дальше — кратко о главном.

Запустили оплату ИИ-моделей по токенам

Добавили возможность оплаты по токенам на ИИ-платформе. Теперь можно подключаться к 29 LLM-моделям через OpenAI-совместимый API без развертывания собственной инфраструктуры. Этот формат рассчитан на компании, которые внедряют генеративный ИИ, но не готовы к затратам на выделенные GPU. 

Выпустили новый тариф со 192 ГБ видеопамяти

Внутри — две NVIDIA RTX 6000 Pro по 96 ГБ, 32 vCPU, 128 ГБ RAM и 1024 ГБ NVMe. Подойдет для крупных LLM, обучения моделей и генерации видео. Протестировать можно здесь.  

Опубликовали два новых кейса

В блоге вышли материалы с реальными примерами из практики:

• Кейс холдинга «Випсервис» — как перевезти ИТ-инфраструктуру в новый ЦОД и облако VMware без остановки информационных сервисов. 

• Кейс компании «АКС» — как гибридное облако помогло запустить ИИ и обновить ИТ-инфраструктуру. 

Подвели итоги первого полугодия 2026 года

Опубликовали в блоге статью с аналитикой рынка и результатами Рег.облака за первые шесть месяцев года. Приток новых клиентов публичного облака за первое полугодие 2026 года вырос на 113% по сравнению с аналогичным периодом 2025-го. Общая база клиентов достигла 30 тысяч, а за последние 12 месяцев пользователи подняли 165,1 тысячи новых облачных серверов.

Провели вебинар по выделенным серверам

13 августа прошел вебинар, посвященный переходу с виртуальных серверов (VPS) на физические выделенные серверы (Bare Metal). Запись — по ссылке. 

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

Публиковали полезные статьи

В августе вышло несколько статей — если пропустили, читайте:

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

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

• Введение в виртуальные сетевые интерфейсы Linux — базовые концепции и практические примеры для администраторов и разработчиков.

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

Память VDS. Что стоит за строкой «8 ГБ» в тарифе
Число в тарифе отвечает на один вопрос: сколько памяти увидит гостевая система. Зарезервирован ли объем физически, может ли гипервизор забрать страницы обратно и что будет при пике соседей, оттуда не следует.

Три слова, которые каждый понимает по своему. Dedicated обычно означает объем, постоянно доступный машине по условиям тарифа. Слово «постоянно» стоит уточнить: резервируется ли память на хосте и может ли ballooning ее уменьшить. В burstable часть доступна всегда, остальное при свободном ресурсе узла. Shared значит, что резервирования нет. Даже при dedicated провайдер может разрешать swap на хосте, поэтому гарантия в договоре важнее названия модели.

Ballooning и overcommit. Ballooning работает через драйвер внутри гостя. По команде хоста он занимает страницы, ядро гостя освобождает кеш или уходит в свой swap, а высвобожденную память гипервизор отдает другим машинам. Пока баллон надут, приложения работают с меньшим объемом, чем в тарифе. Overcommit это когда сумма лимитов больше физической RAM узла. Умеренная переподписка работает годами, пока гости используют часть лимитов. Пример: после резерва под системные процессы на узле осталось 120 ГБ, машинам назначено 180. При суммарном рабочем наборе 80 ГБ никто ничего не заметит. При 140 придется забирать страницы через ballooning или уходить в swap хоста. Overselling это тот же overcommit, но с недостаточным запасом: разница не в технологии, а в коэффициенте.

Что видно изнутри, а что нет. Сразу о границе: коэффициент переподписки из гостевой системы не определяется никак, эти данные есть только у провайдера. Изнутри ловится давление на память и его совпадение с замедлением сервиса.

free -m && grep -E "MemAvailable|SwapFree" /proc/meminfo
vmstat -y 1 10

procs ---swap-- -----io---- ---cpu---
 r  b   si   so    bi    bo  us sy id wa st
 1  2  184  412  1240   980  22  6 61 10  1

Смотреть надо на MemAvailable, а не на free: файловый кеш при нужде освобождается. Ненулевые si и so в нескольких интервалах подряд это обмен сейчас, а не след прошлого пика.

cat /proc/pressure/memory

some avg10=14.82 avg60=9.31 avg300=3.07 total=8123441
full avg10=6.55 avg60=4.02 avg300=1.18 total=3910228

PSI это доля времени, потерянного задачами из за нехватки памяти. Строка some означает, что простаивала хотя бы одна задача, full что вставала вся работа. Четырнадцать процентов в avg10 при выросшем времени ответа это разговор, а не шум.

journalctl -k -g "oom|Killed process"

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

Признаки, которые стоит собрать вместе. Задержка растет в одни и те же часы при сопоставимой нагрузке. Устойчивые si и so без изменения профиля приложения. PSI растет синхронно с замедлением. Машина останавливается без записи об OOM у себя. Один признак ничего не доказывает, три совпавших уже повод писать в поддержку с временем эпизодов и метриками.

Что спросить до заказа. Какой объем зарезервирован, а не просто виден. Допускается ли ballooning и до какого минимума. Разрешен ли swap на хосте для памяти машин. Для burstable отдельно: гарантированная часть и условия доступа к остальному.

Тип гипервизора говорит об архитектуре, а не о гарантиях: overcommit поддерживают и KVM, и VMware, и Xen. SLA обычно описывает доступность и компенсацию за простой, но не производительность.

Дайджест Рег.облака за июль

В июле запустили третий этап Free Tier — бесплатный облачный сервер, ресурсов которого хватает уже на бизнес-проекты. Плюс упростили работу с ispmanager, открыли линейку «Стандартные» в двух регионах, добавили готовые образы в аттестованный контур ФЗ-152 и поделились исследованием о спросе на облако и GPU. Ниже — главное.

Запустили третий этап Free Tier — теперь и для бизнес-нагрузок

Расширили бесплатный облачный сервер до конфигурации, которой хватает для корпоративных порталов, крупных интернет-магазинов и ресурсоемких сервисов. На третьем этапе Free Tier дает выделенный облачный сервер бесплатно на два месяца: два виртуальных ядра, 4 ГБ оперативной памяти и 40 ГБ NVMe. Сервер подходит для проектов на «1С-Битрикс», переноса крупных сайтов с виртуального хостинга, баз данных и подготовки CI/CD-сред.

Подробности — на странице программы.

Исследование: спрос смещается к облаку, bare metal и GPU

Посмотрели, как за два года изменился спрос бизнеса на инфраструктуру. В публичном облаке акцент сместился с запуска проектов на резервирование: снапшоты используют 35,2% компаний малого бизнеса и 37% среднего. В dedicated и bare metal стало больше крупных клиентов — число компаний с расходами выше 500 тыс. руб. в месяц выросло более чем вдвое.

Особенно вырос спрос на GPU: за январь–июнь 2026 г. потребление прибавило 507% год к году. Чаще всего берут NVIDIA A4000 — у 63% компаний, и приходят за ускорителями уже не только ИТ, но и электронная коммерция, производство, логистика и финансы.

Все цифры — в исследовании.

Управление ispmanager для выделенных серверов в личном кабинете Рег.облака

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

Открыли линейку «Стандартные» в Москве-1 и Санкт-Петербурге-1

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

Готовые образы GitLab, GitLab Runner, Nextcloud и Portainer в регионе Москва ФЗ-152

В аттестованном контуре появились предустановленные инструменты для разработки и совместной работы. Развернуть нужное решение в защищенной среде можно без ручной настройки.

Разобрали свои продукты в статьях

В июле вышли два продуктовых обзора на Хабре — если пропустили, читайте:

• Логи, бэкапы, образы, артефакты: где мы используем S3 внутри Рег.облака — как объектное хранилище работает у нас под капотом;

• MCP Gateway: когда инструменты перестают быть интеграцией и становятся архитектурой — про MCP-серверы и подход к их устройству.

Желаем всем продуктивного месяца и спасибо, что следите за обновлениями Рег.облака!

Как проверить VDS до покупки: ядра, память, диск?
Слово VDS не закреплено ни за одной технологией. У одного это машина KVM, у другого контейнер, у третьего просто тариф подороже с пометкой dedicated. За одинаковой строкой характеристик стоят разные модели распределения ресурсов, и утренний тест дает результат, который вечером не повторится.

Что стоит выяснить до тестов? KVM запускает гостя с собственным ядром на аппаратной виртуализации, OpenVZ и LXC делят ядро хоста. Распространенное заблуждение: KVM якобы исключает оверкоммит. Не исключает, провайдер назначает машинам больше vCPU и памяти, чем есть на хосте. Отсюда вопросы к тарифу. Закреплены ли vCPU за физическими процессорами. Зарезервирована ли память. Есть ли лимит IOPS и что при его превышении. Слова dedicated, isolated и NVMe без этих ответов не значат ничего.

Ядра. Под dedicated понимают физическое ядро, закрепленное за машиной. Pinning эксклюзивности не дает: на тот же процессор оператор может посадить чужие vCPU. Проверяется это наблюдением.

mpstat -P ALL 1 60

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

cat /sys/fs/cgroup/cpu.max /sys/fs/cgroup/cpu.stat

200000 100000
nr_throttled 1843
throttled_usec 21904331

Ненулевой nr_throttled означает, что режет лимит, а не сосед. В виртуальной машине таких значений не будет. Дальше sysbench в один поток и на всех ядрах, одна версия утилиты и один cpu-max-prime на кандидатах.

sysbench cpu --threads=1 --cpu-max-prime=20000 --time=60 run
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 --time=60 run

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

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

free -m && swapon --show
stress-ng --vm 1 --vm-bytes 70% --vm-keep --timeout 10m --metrics-brief

Тест гоняйте на пустой машине и параллельно смотрите vmstat. Использование swap само по себе ни о чем не говорит, оно зависит от настроек гостя. Тревожат устойчивые si и so при умеренной нагрузке и падение MemAvailable. Если процесс исчез раньше срока, ответ в журнале ядра.

journalctl -k --since "-15 min" | grep -Ei "oom-kill|killed process"

Диск. Лимит в 20000 IOPS без размера блока, соотношения чтения и записи и глубины очереди это просто число. Те же 20000 при iodepth 32 ничего не обещают при iodepth 1, а именно так работает приложение, ждущее ответа на запрос. Файл сначала заполняют целиком, иначе чтение из пустых областей завысит результат.

fio --name=randrw --filename=/var/tmp/fio.test --size=4G \
    --rw=randrw --rwmixread=70 --bs=4k --direct=1 --ioengine=libaio \
    --iodepth=1 --time_based --runtime=120 --refill_buffers=1 \
    --group_reporting --percentile_list=50:95:99:99.9

Затем тот же вызов с iodepth 32 и проверка в разделе IO depths, достигнута ли глубина. Сохраняйте IOPS и процентили clat, а не среднее. Один прогон шумного соседа не покажет, нужны три в разные часы. Растущий p99 при стабильной медиане это и есть нестабильность.

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

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

Облако для продакшена. Что показывают steal, await и реальная полоса?
Два провайдера, одинаковая строка в тарифе: 4 vCPU, 8 ГБ, 100 ГБ SSD, гигабит. Цена расходится на 15 процентов, и непонятно почему. Через неделю тестов выясняется, что p99 отличается в разы. Тариф описывает то, что выделено виртуально. Что происходит в железе, туда не попадает.

Почему синтетика не отвечает на вопрос? Geekbench и sysbench меряют потолок за короткий тест. Продакшен работает иначе: нагрузка неровная, соседи по ноде непредсказуемы. Провайдеры делают оверкоммит, и пока суммарная нагрузка умеренная, все хорошо. Стоит нескольким машинам дать всплеск разом, растет steal, удлиняется дисковая очередь, канал упирается в шейпер. Короткий тест может не попасть в это окно. Нужно от получаса нагрузки, а на суточные паттерны от 24 часов.

CPU steal. Steal это доля времени, когда vCPU готов работать, но гипервизор не дает ему физическое ядро. Приложение получает задержку без видимой причины: процессор загружен, работа не идет.

vmstat 1 30

procs -----------memory---------- ---cpu---
 r  b   swpd   free   buff  cache  us sy id wa st
 2  0      0 512344  81920 210488  31  4 58  1  6

Колонка st справа. Шесть процентов несколько строк подряд это не шум. Разбивку по ядрам дает mpstat -P ALL 1 10, длинный срез пишут в файл через sar -u 1 3600 и сравнивают часы между собой.

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

Для транскодирования и компиляции steal переводится во время выполнения почти линейно. Для API и запросов к базе иначе: медиана держится, а p99 растет, потому что в моменты steal запросы копятся в очереди. Отдельная история это всплески до 20 процентов на пару секунд при спокойном фоне. Такой скачок опаснее ровного высокого steal, он тянет каскад таймаутов.

Диск. Публикуемые IOPS измерены в идеальных условиях и под смешанной нагрузкой мало о чем говорят. Мониторинг запускают параллельно с тестом.

iostat -xz 1 10

В выводе важны два числа: await это время запроса вместе с ожиданием в очереди, avgqu-sz это глубина очереди. Растет второе, следом первое. Профиль OLTP проверяют так:

fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --direct=1 \
    --numjobs=4 --iodepth=32 --size=4G --runtime=60 \
    --time_based --ioengine=libaio --group_reporting

Флаг direct обязателен, без него тест уедет в страничный кеш и покажет память вместо диска. В отчете смотрите iops и clat p99, именно второе объясняет хвосты запросов. Ориентир для средней базы это 5000 IOPS на чтении 4К при await ниже 2 мс, для нагруженной 20000 при await ниже миллисекунды.

Очередь выше восьми под OLTP это первый признак насыщения. Загрузка под 100 процентов для SSD не приговор, тревожно когда вместе с ней растет await. У дисков с лимитом IOPS порог срабатывает раньше насыщения железа, и покажет это именно await.

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

iperf3 -c 10.0.0.5 -t 60 -P 4
mtr --report --report-cycles 100 10.0.0.5

Четыре потока нужны потому, что один упирается в размер окна и RTT, а не в канал. Минута нужна, чтобы поймать burst лимит: полная полоса первые пятнадцать секунд и просадка дальше это он. Потери на одном промежуточном хопе при чистом трафике дальше это деприоритизация ICMP роутером. Потери подряд на нескольких хопах уже другое.

Проверьте MTU. Overlay сети добавляют заголовок к каждому пакету, 1500 превращаются в 1450, а пакеты с флагом DF молча теряются.

ping -M do -s 1472 10.0.0.5

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

Одинаковые характеристики не означают одинаковую производительность. Steal, await и реальная полоса измеряются за несколько часов.

Доброго. Не прошло и года, как я писал статью о mail.ru https://habr.com/ru/posts/940422/ и вот новая. Назвал бы я это фразой "Очередные проделки mail.ru или агрессивное удержание клиентов".

Итак к сути. Достаточно давно к mail.ru привязан мой домен с бесплатной услугой "Почта для домена" от mail.ru. Изначально, к слову, на бесплатном тарифе можно было использовать неограниченное (во всяком случае точно больше 5) почтовых ящиков. Несколько лет назад лимит ящиков на бесплатном тарифе уменьшили до 5. Уменьшил, и так это всё работало у меня до 29.06.2026 примерно до 15:00 мск. Кстати, почтой пользуюсь исключительно через почтового клиента по протоколам pop3/smtp. Ну и сразу напишу, что какой бы то ни было ощутимой нагрузки на сервера не создаю, почтой пользуюсь исключительно я и только я, с одного и того же компьютера и никто другой. Периодичность отправки/получения со всех 5 ящиков примерно 1-2 письма в день, но нередко бывают дни, даже несколько дней с полным отсутствием приёмом/отправкой писем по электронке. Последнее пишу, чтобы было представление о том, создаю ли я вообще какую-либо нагрузку на почтовые сервера.

И, примерно 29.06.2026 ~15:00 мск. в логах почт. клиента появились записи:

29.06.2026, 15:00:00: ******-ERR Net dostupa na vashem tarife. Skachaite prilozhenie VK WorkSpace

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

Самым логичным, в моей ситуации было решение - уйти на сторонний почтовый хостинг. Платный, кстати.Сказано - сделано. В админке аккаунта mail.ru домен был удалён, однако mail.ru написал, что, дескать они его удалят окончательно только через 14 дней.

Тем не менее, начал перепривязывать свой домен для стороннего почтового хостинга, а именно обновил записи DNS домена в частности MX, TXT записи.

Примерно менее чем через час, я уже мог отправлять письма с почтовых адресов своего домена кому бы то ни было, НО вот с получением почты возникли нюансы, а именно: Я могу получать почту со (!)всех почтовых доменов, (!)КРОМЕ почтовых доменов mail.ru - @mail.ru, @inbox.ru, @bk.ru, @list.ru. Этим, кстати, исключается вариант неправильной настройки DNS записей домена, иначе я бы не смог получать почту вообще от кого бы то ни было.

Справедливости ради следует написать, что для смены DNS записей домена у разных хостеров и провайдеров требуется время и происходит это не мгновенно (кстати по личному опыту максимум было несколько часов, вообще), но была информация, что обновление записей может длиться до 3-х суток максимум. На данный момент с момента изменения мной DNS записей домена прошло уже более (!)74 часов, что составляет время более чем трое суток.

Разумеется за это время было написано как обращение к платному хостеру почтового сервера, так и в тех поддержку mail.ru. На последних (mail.ru), по печальному предыдущему опыту я не особо рассчитывал, что практически и оправдало в негативном смысле мои предположения - сразу после обращения от mail.ru получил автоматический ответ с присвоением номера заявки и что они обязательно ответят не более чем через 10 часов. На данный момента с изначального момента обращения прошло более 50 часов, ничего более от них не получил!

Тех. поддержка платного почтового хостинга несколько раз отвечали, сейчас вопрос находится до сих пор в работе, но субъективно это не их вопрос и к ним у меня вопросов нет, ибо с не mail.ru адресов почта доходит без проблем. Более того, как док-во того, что проблема в mail.ru - если я отправляю письмо с одного из @mail.ru почт.серверов на ранее существующий адрес своего домена, когда я хостился в mail.ru - письмо просто не доходит, а если на не существующий адрес - получаю письмо-автоответ, "Ошибка 550 User Not Found", что говорит о том, что сервера mail.ru не обновили информацию о домене.

Обновили ядро Linux на всех Ryzen-серверах в Москве

В копилку стабильности — и с конкретным обновлением под капотом.

Во время работы с высокопроизводительными серверами на Ryzen 7950X нашли причину редких зависаний нод. На старом ядре Ubuntu 22.04 эти процессоры могли работать нестабильно.

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

Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.

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

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

Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.

▶️ История USmall — хайлоад изнутри

6+ млн товаров, 130 ритейлеров и до 70 млн запросов во время распродаж. Мигрировали USmall в наше облако и записали видеокейс о том, как устроена инфраструктура такого проекта.

Из любопытного:

1️⃣ 130 площадок — 130 изолированных контуров. На каждую свой репозиторий и Docker-образ. Релизы независимы, все изменения изолированы.

2️⃣ Свой механизм иерархических подов. В основе паттерн одноразовых подов — каждый выполняет один цикл и завершается. Поверх него команда построила иерархию, где родительский под запускает дочерние. Так обходят ограничение Python по пропускной способности одного воркера и обрабатывают задачи параллельно.

3️⃣ Выделенный сервер под оркестратор. Когда Airflow потребовалась отдельная конфигурация, под него собрали сервер на двух 32-ядерных процессорах и перенесли без простоя.

4️⃣ AI прямо в Kubernetes-кластере. В тестовом режиме крутится нейросеть, которая ускоряет подключение новых магазинов.

Все это команда ведет сама — новые ноды добавляет за пару минут через панель, без отдельных DevOps-инженеров. А инфраструктура у нас вышла на 35% дешевле прежнего провайдера — при том же объеме.

В видео Станислав, руководитель Python-разработки USmall, рассказывает про архитектуру и почему выбрали наше облако.

Смотреть видеокейс на ютубе, рутубе и в вк.

Или читать подробный разбор на сайте →

Тестируем 8 серверов в одном шасси

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

В новом видео Влад Олейник, ведущий инженер ЦОД, рассказал про 3-х юнитовый Microcloud компании Supermicro 3015MR с приставкой H8TNR.

В одном 3U-шасси умещается 8 полноценных серверов вместо классической схемы 1 сервер = 1 юнит. Все ноды изолированы друг от друга, а общими остаются только питание и охлаждение.

Универсальное ли это решение? Нет — поэтому покажем, где такая сборка особенно полезна:

1️⃣ 1С (SQL + App). Производительность 1С часто упирается в частоту процессора, а десктопные Ryzen как раз обеспечивают 5+ ГГц.

2️⃣ Frontend-сборка. На высокочастотных процессорах сборка может идти в 1,5–2 раза быстрее, чем на многих серверных Xeon.

3️⃣ Build-фермы. Разные типы лезвий можно подбирать под задачи CI/CD. Конфигурации с десктопными AMD-процессорами ускоряют этапы сборки, требующие высокой однопоточной производительности.

Посмотреть видео можно на ютубе, рутубе и в вк.

nLighten без предупреждения отключил оборудование MIRhosting в Европе

UPD0: возможно причина в этом https://habr.com/ru/articles/1040364/

UPD1: Так же возможно ситуация затронула следующие хостинги:
THE.Hosting
UFO.Hosting
Alexhost.com
Vdsina.com
Hip.hosting
Datacheap.ru
ihc.ru


Оператор дата-центров nLighten в одностороннем порядке и без уведомления остановил работу серверов MIRhosting в Нидерландах и Германии. В MIRhosting назвали действия поставщика абсолютно неприемлемыми.

Что делается сейчас:

• MIRhosting привлекает юристов для выяснения деталей;

• Идутся поиски альтернативных площадок для размещения инфраструктуры;

• Инженеры пытаются восстановить доступ к серверам для спасения данных;

• Готовятся варианты экстренного переезда для клиентов.

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

Материал основан исключительно на данных из открытых источников. Автор публикации не гарантирует достоверность предоставленных сведений и не несёт ответственности за их точность.

Почему Москве нужны новые дата-центры?

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

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

Облачные сервисы хороши тем, что пользователю не приходится задумываться, где находятся серверы — в Москве, Сибири или даже за границей. Грамотная организация позволяет бесшовно использовать сервисы в любой локации. Но провайдеру как раз приходится заботиться о том, чтобы дата-центры обладали нужной скоростью доступа и низким пингом, имелась возможность быстро переключиться на другие сервисы при инцидентах в текущем. Кроме того, для некоторых задач важны Edge Computing, то есть технологии, обеспечивающие вычисления в ближайших ЦОДах (для минимальной задержки сигнала).

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

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

Дефицит электроэнергии — не российская особенность, а тренд для всех развитых стран мира. В частности, в США из-за массового строительства дата-центров под ИИ планируется даже возрождение АЭС, которые смогут дать постоянные мощности по приемлемым ценам (СЭС ночью не работают, ВЭС зависят от ветра). Ресурс Servernews отмечает, что такие крупные компании, как Microsoft, SoftBank и SpaceX (недавно слилась с ИИ-компанией xAI), собираются использовать газовые генераторы, а OpenAI под проекты Oracle закупает топливные элементы.

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

The.Hosting — всё.

Сегодня The.Hosting разослал юзерам такое сообщение:

IMPORTANT: Notice of Service Discontinuation and Account Closure

Dear Customer,

We are writing to inform you that due to unforeseen and unavoidable force majeure circumstances, THE.Hosting is forced to permanently discontinue all its operational services and wind down its activities.

As a result, our platform, support channels, and all associated services will be closed in the coming days.

What this means for you:

➖ New Orders & Renewals: All active forms of registration, ordering, and renewals have been disabled. No new services can be purchased.

➖ Data & Accounts: If you have any active data, configurations, or account details stored within our systems, we urgently advise you to retrieve and back up your information immediately.

➖ Final Termination: Once the wind-down process is completed, all accounts and data will be permanently deleted from our systems.

We deeply regret that we are forced to take this step and understand the inconvenience this causes. We want to thank you sincerely for your partnership and trust in THE.Hosting over the past period.

Sincerely,The Management of THE.Hosting

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

Проблемы у The.Hosting начались около двух недель назад, через несколько дней стало известно об изъятии серверов в Нидерландах, теперь история подошла к закономерному финалу.

Седьмая локация для облачных серверов

Теперь вы можете развернуть сервер в Нью-Йорке. Хороший вариант, если важна низкая задержка для пользователей в Северной Америке или вы хотите распределить инфраструктуру между США и Европой.

Физически дата-центр находится в Буффало, штат Нью-Йорк. Мы подключили локацию к опорно-магистральной сети, чтобы обеспечить стабильное управление и качественное соединение с инфраструктурой в других локациях.

Есть фиксированные и произвольные конфиги. Минималка 1 CPU, 1 ГБ RAM и 15 ГБ диска.

Уже доступно в панели, проверяйте →

От зоопарка и самописных скриптов к единой экосистеме — 3 кейса автоматизации хостинга

«Зоопарк» из панелей, скриптов и самописных интеграций — типичный этап роста хостинг-провайдера. На начальном этапе такой подход может дать некоторую гибкость, но при масштабировании начинает серьезно ограничивать развитие. Ниже — 3 истории перехода от поиска обходных решений к целостной экосистеме.

▶ Промышленная платформа вместо самописных скриптов

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

Решение: внедрение связки VMmanager + BILLmanager для централизованного управления.

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

👉 Читать целиком

▶ От сложных интеграций к полному контролю

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

Решение: переход на экосистему ISPsystem — BILLmanager, VMmanager и DCImanager.

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

👉 Читать целиком

▶ Построение централизованной платформы управления инфраструктурой

Инфраструктура 4VPS управлялась с помощью набора разрозненных open source решений и самописных скриптов. Ручное управление серверами и сложная интеграция инструментов не позволяли быстро наращивать инфраструктуру в соответствии с растущим спросом. Трудоемкие процессы развертывания услуг и их привязки к биллингу увеличивали затраты, время отклика и риск человеческих ошибок, что напрямую угрожало соблюдению SLA.

Решение: Интеграция VMmanager и DCImanager через единый API с собственной биллинг-системой, системами мониторинга и защиты от DDoS-атак

Итоги: автоматизация 70% процессов выдачи серверов, повышение скорости оказания услуг, увеличение парка до 27 000+ VPS, обеспечение 99.9% отказоустойчивости инфраструктуры

👉 Читать целиком

Еще больше кейсов — на нашем сайте! Там же вы можете познакомиться с возможностями наших продуктов, заказав бесплатный триал интересующей платформы.

Ставим все точки над ai в последних релизах по AI-агентам

1️⃣ MCP-сервер стал ближе к агентам

Теперь можно обновлять подключение к MCP-серверу, если на его стороне появились новые методы.

Пример: вы добавили новый метод для работы с API или базой → его можно подтянуть к агенту без пересоздания.

Кстати, теперь выбрать существующий MCP-сервер или завести новый можно сразу при создании агента.

2️⃣ Гибкая настройка уведомлений

Информацию о статусе агентов (например, о лимите токенов) вы можете получать не только в Телеграме, но и по почте. Также появилась возможность отключать уведомления.

3️⃣ TimewebGPT теперь в контексте

Ассистент в панели быстро ответит на базовые вопросы без обращения в поддержку:

➖ Подсказки по балансу и статусу отложенных платежей
➖ Список подключенных и доступных для заказа продуктов

На неделе выкатим еще больше обновлений — держите руку на пульсе 👀

Настроить MCP-сервер и уведомления о токенах →