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

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

21 октября 2026 года в PHP обнаружены две критические уязвимости (CVSS 9.2), позволяющие неаутентифицированному злоумышленнику выполнить произвольный код (RCE). Риск особенно высок для Apache с mod_php, где атака возможна до запуска кода приложения.

Обновление — единственное полное решение. Все временные меры лишь снижают риск и не делают сервер безопасным.

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

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

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

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

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

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

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

Продолжаем тему резервирования и непрерывности сервисов, но теперь посмотрим на нее шире. Вместе с нашим партнером по IT-безопасности GRAF group разберемся, что действительно меняется после переезда в дата-центр, какие риски остаются на стороне компании и как связать площадку, доступы, данные и резервирование в единый контур.

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

Именно здесь заканчивается резервирование отдельных компонентов и начинается disaster recovery.

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

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

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

На тестовом стенде вопрос выбора GPU часто кажется второстепенным. Команда выбирает LLM, собирает RAG-систему или пробует запустить собственный AI-сервис. Модель отвечает, идея работает. Но как только сервис нужно переносить в рабочую среду, довольно быстро возникает следующий вопрос: на какой GPU всё это ставить?

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

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

Поэтому сначала стоит понять, что именно мы собираемся запускать, а уже потом сравнивать V100, RTX 4090, RTX 5090 и A100.

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

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

Сентябрь 2026 года заметно поменял правила работы с российскими доменами. С 1 сентября вступил в силу новый законодательный порядок регистрации .RU и .РФ, а 10 сентября начала действовать новая редакция соглашения об аккредитации регистраторов. В основе изменений - Федеральный закон № 569-ФЗ и принятые 31 августа постановления Правительства № 1119 и № 1120.

Для владельца домена самая заметная новация - идентификация через ЕСИА. После 1 сентября она требуется для значимых операций с доменом: регистрации, продления, смены администратора или регистратора, делегирования. Сам срок регистрации при этом не изменился: домен .RU или .РФ по-прежнему регистрируется на один год и затем может продлеваться ещё на год неограниченное количество раз.

Регистраторов тоже не стали переключать одним рубильником. Компании, аккредитованные до 1 сентября, продолжают работать до включения в новый официальный перечень, но не позднее 18 января 2027 года. С технической точки зрения схема вполне привычная: сначала вводим новый контур, убеждаемся, что он жив, потом выключаем старый.