Cloud4U - облачный провайдер

Энергия и связь - то, чего теперь не хватает инфраструктуре. Собрали главное за последнее время. 1️⃣ Москве не хватает энергии для ЦОД. Новые дата-центры в столице фактически не подключают к сетям: свободных энергомощностей нет, они зарезервированы до 2028 года. Минцифры и Минэнерго прорабатывают схему подключения новых ЦОД со сроком 5-7 лет и собственной генерацией на площадках. 2️⃣ Магистральная связь держится на резерве. ММТС-9 - крупнейший узел обмена трафиком, через который идёт значимая часть Рунета, - уходил на резервное питание из-за сбоя на подстанции. Сервисы устояли, но инцидент показал, насколько критичен один узел. 3️⃣ Дата-центры уходят под воду. Питер Тиль вложил $140 млн в плавучие ЦОД Panthalassa на энергии волн. В Китае запустили подводный дата-центр на 24 МВт у Шанхая: морское охлаждение даёт PUE ниже 1,15 против ~1,5 у наземных площадок. 4️⃣ Вредоносный код всё чаще генерирует ИИ. Positive Technologies насчитала 808 образцов вредоносного ПО за квартал против 584 ранее - рост почти на 40%. У части группировок зафиксирована генерация кода через LLM. 5️⃣ ИИ-агентов массово возвращают из эксплуатации. По опросу Sinch (2500+ компаний), 74% сняли агентов поддержки с эксплуатации и вернули в тест: поддерживать ИИ в работе оказалось дороже и сложнее, чем его разработать. Что объединяет эти новости: запуск всё чаще упирается не в модели и код, а в энергию, охлаждение и каналы связи. Больше новостей и подробностей - тут

12 июня прошёл GameDev Meetup - встреча разработчиков игр, геймдизайнеров и людей из индустрии. Cloud4Y поддержала мероприятие, а двое наших коллег участвовали в программе: ведущий специалист по маркетингу Никита Галашин выступил с докладом, а системный администратор Иван Галямин провёл встречу как ведущий. Говорили о самом ремесле: как удерживать внимание историей в игре, как инди-разработчику дойти от идеи до релиза, как устроены небольшие проекты и что делать с их безопасностью.

DDoS - это не одна угроза, а два разных класса атак, и защищаться от них нужно по-разному. ▪️ Объёмные атаки уровней L3/L4 (UDP- и SYN-флуды) насыщают канал и таблицы соединений: их цель - забить полосу и исчерпать ресурсы сетевого оборудования до того, как трафик дойдёт до приложения. ▪️ Прикладные атаки уровня L7 (HTTP-флуд, Slowloris) работают тоньше: это валидные с виду запросы, которые маскируются под обычных пользователей и медленно истощают само приложение. Отсюда и разница в защите. ▪️ L3/L4 фильтруются на подходе - через скраббинг и StormWall, которые отсекают паразитный трафик до инфраструктуры. ▪️ L7 распознаёт WAF, анализируя содержимое HTTP-запросов уже на уровне приложения. Современные атаки всё чаще мультивекторные: бьют по нескольким уровням сразу, поэтому защита только одного уровня оставляет брешь. Настроить многоуровневую защиту от DDoS-атак: уровней L3/L4 и уровня L7

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

Управляемая база данных снимает с команды рутину администрирования, но ответственность за схему и запросы остаётся на вас. Это разделение важно увидеть до миграции. В модели DBaaS провайдер берёт на себя установку и обновление СУБД, патчи, резервное копирование, мониторинг и отказоустойчивость с автоматическим переключением на резерв. Команде больше не нужен отдельный администратор для рутинных операций - она фокусируется на схеме данных, запросах и интеграции с приложением. Но универсального решения здесь нет: удобство управляемой БД оборачивается потерей части контроля над настройкой. Тонко настроить ядро СУБД под специфическую нагрузку, как на собственном сервере, в управляемой БД не получится. Поэтому DBaaS оправдан, когда нужна предсказуемая работа без выделенной команды баз данных. Если же требуется полный контроль над настройкой, используются нестандартные СУБД или действуют жёсткие требования к инфраструктуре - выбирают самостоятельное администрирование. Рассчитать конфигурацию управляемой БД.

Service mesh решает реальные задачи - mTLS между сервисами, управление трафиком, наблюдаемость, - но нужен не каждому кластеру. Несколько лет классический sidecar-подход (Envoy в каждый pod) добавлял столько накладных расходов и операционной сложности, что многие команды от него отказывались: по данным CNCF, доля sidecar-меша в 2024 году снизилась. Каждый pod требовал прокси, а обновление меша означало перезапуск приложений. Ситуацию изменил ambient mode: с конца 2024 года Istio умеет работать без sidecar. Трафик разделён на два уровня:

L4 (mTLS, телеметрия) закрывает общий ztunnel на узле, а L7-прокси разворачивается только там, где нужна маршрутизация HTTP.

Это убрало главный барьер - overhead на каждый pod. Service mesh оправдан, когда у вас десятки и сотни сервисов, нужен mTLS по умолчанию, канареечные выкатки и единая наблюдаемость. Для пары сервисов это избыточно: проще обойтись API gateway и сетевыми правилами. Развернуть кластер Kubernetes под такую архитектуру.

Резервная копия есть почти у всех, а вот восстановление из неё проверяют единицы - и узнают о проблеме в момент аварии. Правило 3-2-1 остаётся базовым: три копии данных, на двух разных типах носителей, одна вне основной площадки. В 2026 году к нему добавляется четвёртая копия - неизменяемая, которую не сотрёт ни администратор, ни вирус-шифровальщик. Так отвечают на то, что шифровальщики поражают весь домен меньше чем за четыре часа. Копия в той же стойке или здании не считается размещённой вне площадки: один инцидент уничтожит обе. Дальше всё определяют две метрики:

▪️ RTO задаёт, сколько времени бизнес терпит простой; ▪️ RPO задаёт, какой объём данных допустимо потерять (RPO в один час означает копию минимум раз в час).

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

Приказ ФСТЭК №117 действует с 1 марта 2026 года и меняет саму логику защиты государственных систем: вместо разовой аттестации внедряется непрерывное управление информационной безопасностью. Он заменил приказ №17 и распространяется теперь не только на ГИС, но и на любые информационные системы госорганов, ГУП и госучреждений. Прежний подход «определил класс, взял меры из таблицы, аттестовал и забыл» сменился на постоянный процесс с оценкой эффективности и регулярной отчётностью. Практический путь начинается с инвентаризации, а дальше выстраивается процесс:

1️⃣ Cоставить полный перечень информационных систем под защитой: все ГИС, иные ИС для госфункций, компоненты инфраструктуры 2️⃣ Построить модель угроз и подобрать меры под конкретную систему по риск-ориентированному принципу, а не типовым списком 3️⃣ Выстроить процесс оценки эффективности и отчётности - ядро новых требований.

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

Смена лицензии Terraform на BSL в 2023 году сделала OpenTofu разумным выбором для команд, которым важна стабильность инструмента. HashiCorp перевела Terraform с открытой MPL 2.0 на закрытую Business Source License, ограничивающую коммерческое использование, и сообщество создало форк последней открытой версии - OpenTofu, который теперь развивается под эгидой Linux Foundation на лицензии MPL 2.0. Для инфраструктуры, которую нужно держать под полным контролем, открытый инструмент без лицензионных рисков ценен сам по себе. OpenTofu - прямая замена Terraform: тот же HCL, те же провайдеры, тот же формат state. Миграция обычно механическая: заменить исполняемый файл, выполнить tofu init -upgrade и tofu plan. Если plan не показывает изменений - готово. При этом OpenTofu добавил то, чего нет в открытой версии Terraform: шифрование state на стороне клиента, ранний разбор переменных, флаг -exclude. Описанная в коде инфраструктура на российском облаке разворачивается одинаково в каждой среде, а ревью изменений идёт через обычный pull request. Рассчитать конфигурацию под IaC.

За май охватили инфраструктуру сверху донизу - от регуляторики до оборудования. Что разобрали: Суверенный стек разработки ▪️Показали, как собрать CI/CD-конвейер в изолированном контуре, не обращаясь к зарубежным облачным сервисам ▪️Сравнили открытые аналоги GitHub, Jira и Confluence и разобрали, как из них собрать рабочий стек для команды до 50 человек ▪️Показали, как заменить Datadog связкой VictoriaMetrics, Grafana и Loki и во сколько это обходится на практике Экономика физической инфраструктуры ▪️ Разобрали, какая видеокарта подходит под обучение, инференс и графику - от RTX 4090 до Blackwell ▪️ Объяснили, когда модульный ЦОД оправдан, а когда выгоднее стационарный ▪️ Посчитали, при каком профиле нагрузки аренда стоек обходит облако по TCO Регуляторика и надёжность ▪️ Разобрали, что приказ ФСТЭК №117 изменил для субъектов КИИ и операторов ГИС ▪️ Сравнили архитектурные варианты хранения персональных данных по 152-ФЗ и их экономику ▪️ Показали, когда георезервирование реально снижает риски, и какие настройки Kubernetes-манифестов обычно забывают Обсудить инфраструктуру под вашу задачу.

Облачный счёт за стабильную нагрузку часто оказывается выше, чем кажется на старте. Публичное облако тарифицирует вычисления, хранение, запросы и исходящий трафик по отдельности. Когда нагрузка работает круглосуточно, эти списания идут без пауз и за месяц складываются в сумму выше ожидаемой. Для такой стабильной нагрузки фиксированная аренда стоек или частное облако обходятся дешевле. В России аренда 5-кВт стойки в ЦОД уровня Tier III начинается от 85 000 ₽ в месяц, и при сопоставимой мощности это становится альтернативой облаку в трёх сценариях. Colocation выигрывает там, где нагрузка предсказуема, а оборудование своё.

1️⃣ Устойчивая высокая утилизация. При загрузке выше 70% круглосуточно собственное железо в аренде стоек достигает паритета с облаком примерно за год, дальше обходится дешевле. 2️⃣ Специфическое оборудование: GPU-плотность, кастомные конфигурации, контроль над firmware и топологией хранения, которые публичное облако даёт с наценкой. 3️⃣ Длинный горизонт: на 3–5 лет амортизация оборудования и фиксированная аренда защищают от роста облачных тарифов.

Облако остаётся выгоднее для переменных и непредсказуемых нагрузок. Аренда стоек оправдана при стабильном профиле и своём оборудовании. Рассчитать TCO под вашу нагрузку.