Почему трафик в ЦОДе балансируется не так, как вы ожидали
LAG часто воспринимают как простую и понятную вещь: объединили несколько линков — получили больше пропускной способности и отказоустойчивость. Но в реальности всё упирается не только в наличие агрегированного канала, а в то, как именно по нему раскладываются потоки.
Из-за этого и появляются знакомые инфраструктурные сюжеты: один линк забит, другой почти пустой; после изменения топологии поведение трафика меняется неочевидно; ECMP вроде есть, но равномерности всё равно нет; в VxLAN/EVPN-фабрике проблема становится ещё менее прозрачной.
7 июля в 20:00 на бесплатном уроке вместе с преподавателями-практиками разберём, как на самом деле работает балансировка трафика в сетях ЦОД: от LAG и хеширования до ECMP, vPC/MLAG и VxLAN/EVPN. Фокус — на том, какие решения в дизайне сети помогают избежать перекосов, перегрузок и сценариев уровня «всё упало, всё пропало». Присоединяйтесь.
Больше бесплатных уроков июля по инфраструктуре, сетям, разработке, AI и другим направлениям собрали в дайджесте — там можно посмотреть все темы месяца.
SimpleOne подтвердила совместимость своей платформы с РЕД ОС. Для заказчиков это значит, что запуск проектов в импортонезависимой ИТ-среде становится проще и предсказуемее.
Подтвержденная совместимость помогает:
сократить барьеры на этапе архитектурных согласований
упростить прохождение аудитов безопасности
быстрее запускать проекты по переходу на российское ПО
РЕД ОС широко используют в корпоративной и государственной инфраструктуре. По данным разработчика, систему уже применяют 12 000 компаний и государственных организаций, а общее количество инсталляций превысило 2 млн.
Релиз ≠ деплой: почему прод падает именно после обновлений
Большинство крупных инцидентов происходят сразу после релиза. Не во время нагрузочного теста, не в случайный вторник — а именно тогда, когда команда только что что-то выкатила и выдохнула. Почему так, если всё прошло тестирование?
В новом выпуске «В SREду на кухне»вместе с Артёмом Гетманским, техруком юнитов в Авито, и Андреем Мухиным, TechLead из MWS, разобрались: что вообще считается релизом, чем он отличается от деплоя — и как не превратить каждое обновление в рулетку.
Что на повестке
Оказывается, релиз может сломать прод даже без единой строчки нового кода — и это не баг, а особенность современных систем. Разбираем, как Feature Flags, Canary, Blue-Green и Rolling-стратегии помогают снизить риск, когда hotfix тоже считается релизом и что с этим делать, и как error budget влияет на то, насколько смело команда вообще решается катить изменения.
Отдельно досталось вопросу, должны ли SRE участвовать в продуктовых релизах — и у участников выпуска на этот счёт нашлись весьма конкретные мнения.
Искусственный интеллект перестал быть экспериментом — сегодня от него ждут конкретных результатов. При этом эффективность ИИ-инициатив ограничена возможностями инфраструктуры.
Мы упаковали наш опыт работы с десятками компаний из госсектора, финансов, ритейла, промышленности, НГХ и создали Сезон ИИ-инфры: пройдите весь путь к ИИ — от первичной оценки готовности инфраструктуры до конкретных решений и рекомендаций экспертов, которые внедряют ИИ в продакшн.
Как Форк ИТ обучил ИИ‑систему контроля качества горной добычи
🏭 Что за компания Форк ИТ — российская команда разработчиков, которая специализируется на цифровой трансформации промышленности. Компания запускает проекты по автоматизации контроля качества, прогнозированию нагрузок и оптимизации производственных процессов с использованием машинного обучения.
⚡ Задача Крупному горнодобывающему предприятию была нужна ИИ‑система, которая оценивает качество сырья и заранее замечает аномалии в технологическом процессе, снижая риск брака и остановок. Требовалось быстро обучить модели на больших массивах данных и запустить их в работу без остановки действующих ИТ‑систем и без закупки собственной GPU‑инфраструктуры. При этом требовалось обеспечить высокий уровень безопасности данных (187-ФЗ, 152-ФЗ).
☁️ Что сделали Форк ИТ арендовал GPU‑ресурсы и воспользовался средой для разработки и обучения ИИ в облаке Cloud.ru. Важнейшим компонентом будущей системы было компьютерное зрение, способное анализировать гранулометрический состав руды, размеры кусочков сырья, структуру флотационной пены при извлечении интересующих фракций. Данные о технологических процессах загрузили в облако, настроили пайплайн подготовки и запустили серию экспериментов с ML‑моделями, гибко масштабируя мощности под каждую итерацию обучения.
🦾 Что получили в итоге Форк ИТ смог быстро протестировать гипотезы благодаря использованию GPU A100, увеличить точность прогнозов и сэкономить на капитальных расходах. Cloud.ru выступил платформой для тяжелых задач по обучению моделей и анализу больших данных. Ну а предприятие получило ИИ‑систему, которая уже успешно снижает риск брака и незапланированных остановок производства.
Узнайте, как использовать новые требования к КИИ как конкурентное преимущество
Работаете с ГИС или объектами КИИ и ищете способ выполнить регуляторные требования, не теряя в гибкости и скорости? Эксперты Cloud.ru разберут, как облачная инфраструктура закрывает вопросы защиты и при этом становится реальным инструментом развития.
На вебинаре разберем:
Актуальные изменения в требованиях к ГИС и КИИ — что важно учесть прямо сейчас.
Какие сценарии возможны с решением «Облако для КИИ» и что оно дает.
Способы применения: от защищенной инфраструктуры до ускорения цифровых сервисов.
Будет полезно инженерам инфраструктуры, руководителям ИБ-направлений, менеджерам цифровой трансформации и всем, кто планирует работать с ГИС и КИИ.
📅 Когда? 7 июля в 11:00 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикеру в прямом эфире.
Вебинар уже через 20 минут: расскажем, как защищать данные в S3
В 12:00 мск на вебинаре разберем все: от базовых Bucket Policies и версионирования до продвинутых Conditional Write, Object Lock (WORM) и клиентского шифрования. Расскажем, как комбинировать эти инструменты для защиты от случайного удаления и кибератак. Объясним, как соответствовать регуляторным требованиям. Вебинар практический, так что вы увидите реальные примеры настройки S3 через API и CLI.
Вы узнаете
Какие уровни защиты данных в S3 существуют
Как настраивать версионирование, Conditional Write, Object Lock, шифрование с реальными командами и примерами кода
Какие границы и подводные камни существуют у каждого инструмента
Как комбинировать механизмы для защиты от ransomware, случайного удаления, взлома ключей и соответствия 152-ФЗ
Как я в Zabbix мониторю аккаунт в REG.RU: баланс, неоплаченные счета и сроки всех услуг - через API reg.ru
Домен можно сторожить по WHOIS: взял имя, посмотрел дату, повесил триггер «истекает через 30 дней». Но WHOIS видит ровно один домен и ничего вокруг. Он не знает, что на счёте кончились деньги, что висит неоплаченный счёт, из-за которого услугу снимут раньше срока, что в том же аккаунте ещё десяток доменов, SSL и хостинг. Поэтому я опрашиваю не WHOIS, а биллинговый API самого регистратора - он отдаёт весь аккаунт целиком. Собрал из этого шаблон под Zabbix 7.0, MIT. Расскажу, как он устроен и что в нём, на мой взгляд, сделано правильно.
Архитектура Три HTTP-айтема ходят в api.reg.ru - список услуг, неоплаченные счета и баланс - и складывают сырой JSON. Дальше всё считается из него: dependent items тянут баланс, сумму и число счетов через JSONPath, а LLD разворачивает прототипы под каждую услугу (ненужные типы отсекаются макросом-регуляркой). Каждая цепочка начинается с error_handler - битый или пустой ответ API не роняет айтем, а подставляет безопасное значение. На весь аккаунт получается несколько запросов в час, а не отдельная проверка на каждую услугу.
Что считаю правильным дизайном - две цепочки зависимостей Первое - nodata. Когда API регистратора отваливается целиком, каждый триггер «нет данных» (услуги, счета, баланс) хочет сработать сам, и ты получаешь пачку алертов про одну причину. Я завязал nodata услуг и счетов на корневой «No data from balance API». Полный отвал API теперь - один алерт, а не три. Корень я специально оставил без зависимостей, чтобы случайно не завязали и его, - об этом есть комментарий прямо в шаблоне.
Второе - сроки. На каждую услугу не один триггер, а каскад: ИСТЕКЛА (Disaster) → ≤7 дней (High) → ≤14 (Warning) → ≤30 (Info). Каждый уровень зависит от более тяжёлого. Поэтому услуга, которой осталось три дня, даёт один алерт High - а не три штуки (Info, Warning, High) одновременно. По мере приближения срока ты видишь ровно один триггер нужной серьёзности.
Для работы API, необходимо прописать разершенные IP в кабинете https://www.reg.ru/user/account/settings/api/, в настройках API задать адьтернативный пароль, и сохранить в макрос хоста {$RR_PASSWORD} как Secret. Логин - {$RR_USERNAME}. Для рег.облако взять API в https://cloud.reg.ru/panel/settings и сохранить в {$RRC_API_KEY}
Итог Баланс, неоплаченные счета и сроки всех услуг - под алертами в одном дашборде, без отдельного демона-прослойки. В репозитории два шаблона: разобранный выше под api.reg.ru (домены, хостинг, SSL) и отдельный под облачный api.cloudvps.reg.ru - там к балансу и срокам добавлен мониторинг самих VPS: реглеты, снапшоты, сети. Шаблоны, README и changelog - GitHub, PR и issues welcome.
А чем вы следите за биллингом у провайдеров и регистраторов - дёргаете API, или живёте на письмах «ваша услуга истекает»?
Подключайтесь к вебинару — покажем, как автоматизировать управление сложной инфраструктурой
Когда часть сервисов находится в облаке, а остальное — в изолированных контурах, доставка серверного ПО и контроль лицензий превращаются в настоящий квест для команды DevOps.
На вебинаре расскажем, как собрать весь зоопарк решений в единую систему с помощью MWS B2B Store. Разберем деплой инсталляций, когда разные ноды находятся на разных инфраструктурных провайдерах, доставку и обновления в закрытых контурах, версионирование и распространение внутренних и внешних решений.
В прямом эфире в режиме демо покажем:
Деплой сервисов (VMware + K8S) для разных сред, имплементацию Terraform as a service.
Автоматическое развертывание в изолированные контуры: от стандарта упаковки до «раскатки» в гибридную инфраструктуру.
Как управлять лицензиями на серверное ПО и контролировать, кто, где и сколько использовал.
Работу с инстансами из разных инфраструктур в едином окне: мониторинг, аудит и управление жизненным циклом.
Будет полезно CTO, DevOps, директорам по инфраструктуре и тимлидам инфраструктурных команд.
📅 Когда: 30 июня в 11:00 мск.
📍 Где: онлайн. Зарегистрируйтесь, подключайтесь и задавайте вопросы нашим экспертам в чате трансляции.
Обновили ядро Linux на всех Ryzen-серверах в Москве
В копилку стабильности — и с конкретным обновлением под капотом.
Во время работы с высокопроизводительными серверами на Ryzen 7950X нашли причину редких зависаний нод. На старом ядре Ubuntu 22.04 эти процессоры могли работать нестабильно.
Это могло обернуться внезапной недоступностью виртуальных машин, хотя с самими проектами все было в порядке.
Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.
Переезд выполнили поэтапно: сначала подняли резервные серверы, перенесли на них проекты и только потом приступили к обновлению основных хостов. Поэтому пользователи не столкнулись с простоем.
Теперь гипервизоры работают на новом ядре, а риски возможных зависаний нод осталась в прошлом.
Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.
От Hyper‑V и VMware к VMmanager — 3 кейса импортозамещения виртуализации
Импортозамещение ИТ‑инфраструктуры перестало быть просто трендом — сегодня это необходимость. Ниже — три истории перехода с Microsoft Hyper‑V и VMware ESXi на платформу VMmanager.
▶ Импортозамещение Hyper‑V на предприятии железнодорожной отрасли
АО «Московский ЛРЗ» — дочернее предприятие ОАО «Российские железные дороги», специализирующееся на ремонте железнодорожного подвижного состава. В парке обслуживания около 200 хостов. Изначально виртуализация была развернута на базе гипервизора Hyper-V на двух физических серверах без кластеризации, на каждом хосте работало по восемь виртуальных машин. Отдельные сервисы на ВМ были настроены на репликацию между серверами.
В рамках программы цифровой трансформации потребовалась замена зарубежного ПО на отечественное — с сохранением надежности и безопасности.
Решение: внедрение VMmanager с поэтапным масштабированием — от лицензии на 80 ядер до расширения на физические серверы.
Итоги: централизованное управление всей инфраструктурой через единый интерфейс, гибкое масштабирование благодаря удобной модели лицензирования, ускоренное развертывание сервисов через готовые шаблоны ВМ. Платформа адаптирована под разнородную архитектуру с NVMe‑дисками, в планах — подключение RuBackup и Termidesk.
▶ От VMware ESXi к управляемой облачной инфраструктуре в фармацевтике
«Волгофарм» — одно из крупнейших фармацевтических предприятий Волгоградской области. ИТ‑инфраструктура работала на VMware ESXi, но ручное управление, сложности масштабирования и низкая отказоустойчивость тормозили развитие. Компании требовалась платформа, позволяющая перейти от управления «железом» к управлению сервисами.
Решение: переход на платформу серверной виртуализации VMmanager.
Итоги: сокращено время развертывания новых сервисов, повышена отказоустойчивость ключевых бизнес‑приложений, включая ERP‑системы 1С. Снижены операционные расходы (OPEX) за счет консолидации серверов и сокращения трудозатрат системных администраторов. Обеспечена база для цифровой трансформации: создана гибкая и масштабируемая ИТ-среда, способная быстро адаптироваться под меняющиеся потребности бизнеса.
▶ Единая экосистема вместо Microsoft‑инфраструктуры в лесопромышленном холдинге
Югорский лесопромышленный холдинг — ведущее деревообрабатывающее предприятие УрФО. До перехода на российское ПО инфраструктура компании была построена на продуктах Microsoft. Доменная структура работала на Active Directory, а виртуализация — на Hyper-V. В рамках импортозамещения и выполнения государственных требований предстояло перейти на отечественное ПО, избежав технологического «зоопарка» от разных вендоров и создав единую экосистему.
Решение: внедрение VMmanager в экосистеме «Группы Астра» — вместе с ОС Astra Linux, ALD Pro, RuPost и RuBackup.
Итоги: компания смогла заместить Microsoft-инфраструктуру отечественными решениями без потери ключевых возможностей и выстроить единую экосистему на базе продуктов «Группы Астра».
В результате проекта удалось развернуть:
комплексную виртуализацию сервисов предприятия: от ALD Pro до СКУД и таможенного ПО.
5 площадок по минимум 2 ноды для отказоустойчивости в каждой.
более 100 ВМ для различных сервисов в общей сложности.
ГОСТ Р 56939-2024 на практике: что мы сделали, чтобы получить сертификат РБПО
🔎 Контекст У Cloud.ru есть платформа, созданная специально для заказчиков, которые обязаны соблюдать особые требования к хранению данных и разработке ПО. Вся инфраструктура, которую они используют, должна быть аттестована на соответствие стандартам безопасности, а платформенные сервисы должны пройти жесткую проверку у регуляторов. Ранее платформа уже получала сертификат ФСТЭК России №4979, но при внесении определенной массы изменений в продукт, процесс требуется пройти заново, а сделать это невозможно без привлечения сторонней лаборатории и многомесячных ожиданий. Чтобы иметь возможность развивать продукт более оперативно, требовалось сертифицировать не только платформу для создания частного, гибридного или распределенного облака Cloud.ru Evolution Stack, но и все процессы вокруг нее, т.е. подтвердить соответствие ГОСТу Р 56939-2024.
🚀 Задача Стандарт требует выстроить25 взаимосвязанных регламентов и поддерживать более 200 артефактов в актуальном состоянии постоянно. Но этого мало: ведь стандарт есть, но конкретной методологии его реализации не существует, нужно было приземлить элементы процесса на орг.структуру нашей компании. Осложнялось всё тем, что в любой крупной ИТ-компании команды непрерывно перетасовываются, ответственные меняются, а любое кадровое изменение должно быть тут же отражено во всей документации сразу.
Аудиторы во время сертификации проверяют всё: опрашивают разработчиков, смотрят трекер задач, оценивают стек применяемых технологий, сверяют, соответствуют ли реальные процессы тому, что закреплено «на бумаге». Соответственно, ситуации, когда документация устаревает быстрее, чем обновляется, а новые исполнители не успевают вникнуть в свои обязанности, нужно было истребить полностью.
☁️ Что мы сделали Применили существующую в компании BPM-систему как единый источник правды: описали в ней ключевые процессы РБПО, зафиксировали роли, связали их с командами через орг.структуру, разместили все артефакты, точки контроля и указали их взаимосвязи. Следующим этапом автоматизировали конвертацию и публикацию свежих документов: по расписанию из BPM-модели экспортируется HTML, который автоматически конвертируется в Markdown и публикуется во внутреннюю Wiki. Изменился владелец роли — один раз вносишь правки в BPM, все документы актуализируются и тут же становятся доступны всем и каждому. Чтобы новички не впадали в ступор от количества регламентов, поверх Wiki добавили ассистента с RAG под капотом. Можно написать в корпоративный чат любой вопрос и получить структурированную информацию о том, кто за что отвечает и как действовать в любой ситуации, причем сразу со ссылками на конкретный документ в базе знаний.
🦾 Что получили в итоге В компании появилась полная живая и взаимосвязанная база элементов, включающая организационные единицы, роли, артефакты и инструкции по процессам. То есть на аудите мы показываем не просто набор Word'овских файлов, а живую модель с автоматически собранными артефактами. Каждый сотрудник, причастный к процессу безопасной разработки ПО, четко знает, что в какой ситуации делать и уверен в том, что данные не устарели. ИИ-ассистент сокращает время погружения в регламенты и процессы с дней до пары десятков минут, что значительно упрощает онбординг при смене роли.
Также такой подход позволил снизить затраты на устранение уязвимостей, поскольку их выявление предусмотрено на самых ранних стадиях процесса. Мы получили подтверждение качества платформы и стали первым облачным провайдером в России с сертификатом РБПО. У нас появилось больше контроля над собственным релизным циклом и теперь мы можем планировать обновления на годы вперед.
6+ млн товаров, 130 ритейлеров и до 70 млн запросов во время распродаж. Мигрировали USmall в наше облако и записали видеокейс о том, как устроена инфраструктура такого проекта.
Из любопытного:
1️⃣ 130 площадок — 130 изолированных контуров. На каждую свой репозиторий и Docker-образ. Релизы независимы, все изменения изолированы.
2️⃣ Свой механизм иерархических подов. В основе паттерн одноразовых подов — каждый выполняет один цикл и завершается. Поверх него команда построила иерархию, где родительский под запускает дочерние. Так обходят ограничение Python по пропускной способности одного воркера и обрабатывают задачи параллельно.
3️⃣ Выделенный сервер под оркестратор. Когда Airflow потребовалась отдельная конфигурация, под него собрали сервер на двух 32-ядерных процессорах и перенесли без простоя.
4️⃣ AI прямо в Kubernetes-кластере. В тестовом режиме крутится нейросеть, которая ускоряет подключение новых магазинов.
Все это команда ведет сама — новые ноды добавляет за пару минут через панель, без отдельных DevOps-инженеров. А инфраструктура у нас вышла на 35% дешевле прежнего провайдера — при том же объеме.
В видео Станислав, руководитель Python-разработки USmall, рассказывает про архитектуру и почему выбрали наше облако.
Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис
В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:
пользователи – в одном контуре;
серверы и рабочие станции – в другом;
тестовая среда – в третьем.
На схеме это выглядит логично: сегментация, изоляция ошибок, разные зоны ответственности, поэтапная миграция без шуму и пыли.
Но в эксплуатации важен не только вопрос «где лежит объект».
Важнее другое: какие зависимости связывают объекты между собой.
Многодоменная архитектура не опасна сама по себе. Проблема начинается тогда, когда её начинают восстанавливать как набор независимых доменов.
Сценарий
Пользователь – в домене A. Рабочая станция – в домене B. Группа доступа к приложению – в домене C.
Цепочка доступа:
учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.
Каждый компонент по отдельности может выглядеть исправным:
KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.
А доступ к приложению всё равно не работает.
Почему? Потому что сломался не отдельный объект, а связь между объектами.
Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.
В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.
Что стоит проверить заранее
Основной источник данных – где создаются пользователи, где живут группы, какие домены участвуют в кросс-аутентификации.
Карта доверительных отношений – какие домены доверяют друг другу, в каком направлении работает доверие и что произойдёт, если одно звено станет недоступным.
Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.
DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».
Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.
Главный вывод
Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.
Если пользователи, ресурсы, группы и политики разнесены по разным доменам, план восстановления должен описывать всю цепочку, а не один объект.
Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.
Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?
Terraform в zVirt: базовая автоматизация виртуальной инфраструктуры
Привет, Хабр! 24 июня в 11:00 мы проведем вебинар о различных подходах к автоматизации.
Автоматизация — это способ сделать ИТ-ландшафт более прозрачным, управляемым и предсказуемым. На вебинаре разберем, как применять Terraform в zVirt, чтобы сократить объем рутинных операций, снизить риск ошибок и перейти к управлению инфраструктурой с помощью кода.
Что разберем:
- Различные подходы к автоматизации: когда и зачем нужен Terraform?
- Технический обзор: архитектура поддержки Terraform в zVirt
- Управление примитивами виртуализации: виртуальные машины, диски и сети
- Live-demo: от ознакомительных сценариев до устранения неисправностей
Кому будет полезен вебинар?
- Руководителям ИТ-инфраструктуры
- Системным инженерам
- Системным администраторам
- DevOps-инженерам
Участники вебинара первыми получат доступ к Cookbook zVirt Terraform — практическому гайду, составленному на опыте реальных кейсов управления комплексной инфраструктурой zVirt средствами Terraform.
Настроить мониторинг за 60 секунд: вебинар про Deckhouse Observability на практике
Метрики, лейблы, Prometheus, PromQL, Grafana, дашборды, алерты, каналы уведомлений. Тема мониторинга большая и сложная, но базовый пайплайн от сбора метрик до визуализации данных и настройки алертов можно разобрать за 60 минут. Этим и займёмся на вебинаре Deckhouse Академии на примере живого сценария.
Разберём, как формируется метрика, что такое лейблы и кардинальность, а также как не допустить взрыва кардинальности.
Рассмотрим, как Prometheus собирает данные и как начать собирать их со своего приложения, добавив три строчки в Deployment.
Визуализируем метрику и покажем пример агрегации сырых данных с помощью PromQL.
Создадим правило для алерта, настроим свой канал уведомлений и получим уведомление по агрегированной метрике.
Регистрируйтесь и подключайтесь 23 июня в 12:00 (МСК). После вебинара вы поймёте, как работает цепочка App → Metric → Prometheus → PromQL → Grafana → Alert, сможете подключить своё приложение к Prometheus без правки scrape_config, написать простой запрос на PromQL и настроить оповещения с защитой от шума.
GLM 5.2 в open source: модель уровня Claude Opus 4.7, которую негде запустить, пока негде.
Zhipu выложили веса GLM 5.2 под MIT лицензией. 744 миллиарда параметров, MoE, 40 миллиардов активных на токен, контекст на миллион. GLM-5.2 играет достойно на многих бенчмарках.
Дома не запустить. FP8 веса ~800 гигабайт, нужно минимум 8 карт H200 или 10 карт H100. Теперь про abliteration, потому что в этом вся суть.
Любая западная модель отказывает вам по десять раз на дню. Напиши эксплоит для пентеста: отказ. Проанализируй уязвимость по CVE: отказ. Разбери вредоносный код из лога: отказ. Безопасники и разработчики каждый день упираются в стену цензуры и делают руками то что нейросеть могла бы закрыть за секунды.
Abliteration это удаление цензурных слоёв из модели. Модель перестаёт решать за вас что можно а что нельзя. Для моделей поменьше энтузиасты делают это за дни. Для 744B монстра уйдёт пара недель, но результат появится на Hugging Face неизбежно. MIT лицензия, веса открыты, технически ничего не мешает. Вопрос кто первым поставит под эту версию железо и откроет API.
Считаем деньги.
Huawei Ascend, легальный путь. Чип 910B: ~110 тысяч юаней (~1.4 млн рублей), нужно 16 штук (два сервера Atlas 800, ~1 ТБ видеопамяти). Итого 55-90 млн рублей. Производительность 60-70% от NVIDIA, зато без санкционных рисков.
NVIDIA H100, серый путь. Карта ~3.3 млн рублей, 10 штук с обвязкой: 40-50 млн. Быстрее, но риски поставки и нет гарантии.
Операционка: ~1-1.5 млн рублей в месяц (локация, электричество, инженеры).
Кто заплатит. Корпорации, которым нельзя лить данные в западные API: выделенный сервер с abliterated моделью, договор с юрлицом, ответственность на клиенте. Разработчики и физлица: публичный доступ, базовый тариф с обычной версией, премиум с abliterated после верификации.
Для российского рынка это окно. Ни один провайдер в РФ пока не даёт доступ к abliterated модели такого уровня. Что думаете?
Evolution Managed RAG — теперь источники для базы знаний сканируются глубже: при добавлении нового источника автоматически обходятся все директории сервиса. Больше никаких «а вот этот раздел мы не проиндексировали»: охват данных стал полным, и на качестве ответов LLM это будет заметно.
Evolution AI Agents — в сервисе обновили дизайн интерфейсов для инструмента EvoClaw. Меньше визуального шума, можно быстрее сориентироваться в конфигурации агента.
☁️ Cloud.ru Evolution — новые возможности в различных сервисах
Evolution Load Balancer — во вторую версию добавили балансировку трафика на виртуальные IP. В связке с поддержкой Proxy Protocol v2, которая добавилась в апреле, бэкенды теперь видят все, что нужно видеть.
Evolution Managed ClickHouse — реализовали поддержку версии 25.8. Если аналитические запросы у вас исчисляются миллиардами строк, то это обновление будет как нельзя кстати.
Evolution Managed Kubernetes — сразу несколько точечных, но важных улучшений в сервисе:
Недоступные при создании ресурсы скрываем сразу — вместо ошибки при деплое вы видите рабочие альтернативы.
Добавлены плагины: Agent Sandbox — для изолированного запуска ИИ-агентов, и Reloader — для автоматического перезапуска рабочих нагрузок при обновлении конфигураций и секретов.
Теперь поддерживается Kubernetes 1.35.
Evolution Managed OpenSearch — добавили возможность настроить окно обслуживания для технических работ. Теперь вы сами задаете время, когда кластер может быть недоступен, и техобслуживание не застанет врасплох.
Evolution Data Platform — платформа получила сразу несколько важных обновлений: Control Plane мигрировал в мультизональный кластер, появилась ручная остановка и возобновление инстансов для экономии ресурсов, обновлена система уведомлений по событиям и авариям, добавлены индикаторы статусов кластеров.
Evolution Artifact Registry — Terraform 2.0.2: теперь реестры разворачиваются через IaC.
💰 Оплата и контроль затрат
Три точечных улучшения для борьбы с типичными неудобствами: проверка пересечений бюджетов, редактирование или полное удаление лимитов, которые больше неактуальны.
🏢 Cloud.ru Advanced и Облако VMware
Cloud.ru Advanced — Terraform-провайдер обновлен до 1.79.0 с расширенным набором Data Sources и ресурсов для Direct Connect (DC).
Облако VMware — в VDI появилась веб-консоль мастер-образа прямо в личном кабинете: ставите ПО один раз — все ВМ на его базе наследуют настройки автоматически. Балансировщик ALB стал доступен на площадке PD50-02 и остается бесплатным. В вЦОД с GPU добавлены хосты на платформе HGX с ускорителями A100-80 SXM на площадках PD30-01 и PD50-01.
📊Практический гайд для тех, у кого данные есть, а толку мало
Дашборды, модели и данные есть, но все это живет в разных системах, не дружит друг с другом и весьма туманно отвечает на вопросы бизнеса?
Как раз для тех, у кого не клеится польза с реализацией, мы собрали практический гайд «Платформа данных и ИИ». Там прописана вся цепочка «бизнес-задача → метрики → архитектура». Берите на следующую встречу с CTO или CDO, когда речь снова зайдет про платформу данных и нужно будет показать, что это не «очередная хранилка».
📽️Вебинары
Выложили записи прошедших вебинаров, самое время наверстать, если пропустили:
Рассказали про кейс провайдером сервисов для мобильного аудита Retailiqa. Читайте, если вам актуально «поженить» 152-ФЗ с одинаковой доступностью сервисов из России и из-за рубежа.
Вебинар: через час расскажем, как управлять IT-инфраструктурой через Terraform
Terraform-провайдер Selectel позволяет управлять физическими серверами и другими ресурсами по концепции IaC. Мы готовим большой апдейт этого сервиса — на вебинаре расскажем все подробности.
Что вас ждет:
поделимся возможностями Terraform-провайдера для управления IT-инфраструктурой;
презентуем большой обновление и покажем, как теперь управлять локальными сетями и настраивать разделы;
объясним, как работают новые функции.
Приятный бонус: все слушатели вебинара получат промокод на 3 000 бонусов в панели Selectel, чтобы протестировать возможности Terraform.
О невольной индивидуализации идентифицированных доменов
Уже много написано о деанонимизации администраторов доменов и прочих прелестях жизни. Расскажу о главной прелести при идентификации доменов переходящих подобно красному знамени с регистратора Р01. Один непоименованный продавец доменов, которым я был вполне доволен в последние 10 лет внезапно признался, что неаккредитован для идентификации доменов и их надо своим пешком в nic.ru заносить и там идентифицировать. Веселье заключается в том, что nic.ru открывает новый договор каждый раз когда делается попытка идентификации домена.
Ну у меня их допустим несколько есть. Но уже при количестве доменов более 30 возникает некоторое недоумение. Почему nic.ru , он же Руцентр, не может сверить данные владельца доменов со столь недружественно не прошедшего аккредитацию продавца со своими и предложить регистрацию на уже существующий с nic.ru договор?
Я задал этот вопрос техподдержке nic.ru и она его обдумывает уже вторую неделю, не отвечая ни на письма по этому поводу, ни на сам тикет.
Второй забавный нюанс -- на каждый домен nic.ru прислал мне отдельное письмо с требованием идентификации. Интересно, а сколько писем они послали массовым регистраторам доменов? Им тоже по-одному домену на договор будут открывать?
По какому принципу посты минусуются? Пишу пост, об образовательной платформе по AI, которую я сам собирал уже несколько месяцев, вкладываю в нее свои деньги. Абсолютно некоммерческая история. Предлагаю туда писать авторские статьи. Пользуются уже в банках и университетах. Мне в ответ прилетает, что это реклама от местных жителей. Как дела-то, ребят? Или вы переживаете, что свои цыганские курсы потом не продадите?
Привет, Хабр! Мы выпустили вторую и третью части бесплатного курса в Академии Selectel. Материалы будут полезны опытным специалистам, которые хотят углубить знания и освоить инструменты защиты. Приступите к обучению прямо сейчас — изучение займет около двух часов.
Чтобы обеспечить безопасность ПО, важно корректно работать с кодом, данными и внешними компонентами. Во второй части рассмотрим, как проверять и ограничивать входные данные, безопасно обрабатывать информацию, взаимодействовать с внешними системами и отправлять выходные данные.
Уделять внимание безопасности необходимо на ранних этапах разработки ПО. В третьей части рассмотрим особенности статического и динамического анализа, а также процесс работы с уязвимостями — от обнаружения до обработки сообщений и устранения найденных проблем.
ESM VS ITSM: что выбрать, когда начинать проект и как обосновать бюджет
Вебинар 24 июня, 12:00 по мск
В крупных компаниях большинство запросов от сотрудников приходят не в IT-отдел, но автоматизацию при этом чаще всего начинают именно с IT-услуг.
Наладив работу с обращениями в IT-отделе, компании начинают приводить в порядок работу с заявками, которые поступают в другие подразделения: HR-департамент, АХО, юридическую службу, бухгалтерию. Это новые проекты внедрения, требующие новых бюджетов, которые приходится каждый раз заново согласовывать.
Компании, которые при автоматизации IT-услуг, закладывают в проект внедрения ITSM масштабирование до ESM, экономят колоссальные ресурсы, окупают внедрение быстрее и получают конкурентное преимущество. К тому же поддержка одной системы обходится IT-департаменту значительно дешевле, чем управление разрозненным IT-ландшафтом для бухгалтерии, АХО, HR и др. отделов. Но как доказать это руководству и обосновать бюджет на комплексную автоматизацию?
На вебинаре мы рассмотрим, как единая платформа SimpleOne работает для разных отделов и как сквозные процессы экономят время. Представим кейсы внедрения ESM-системы. Покажем калькулятор экономической ценности внедрения ESM, который поможет определить возможную окупаемость проекта.
В программе:
Отличие ESM от ITSM
Преимущества ESM и почему внедрение ESM актуально сейчас
ESM-система на платформе SimpleOne
Успешные кейсы внедрения SimpleOne ESM
Подходы к реализации проекта внедрения ESM
Формирование бюджета на проект и расчет экономического эффекта от внедрения ESM
Спикеры:
Илья Жакашев, коммерческий директор SimpleOne
Алексей Лыков, руководитель направления ESM Softline
Теперь можно отслеживать стабильность работы сайтов, серверов и приложений, размещенных в нашей инфраструктуре или на сторонних платформах.
Если что-то пойдет не так, вы сразу получите уведомление на почту, в Телеграм или Макс. О восстановлении — тоже.
Что можно мониторить:
Сайты и веб-приложения. Интернет-магазин упал ночью — узнаете сразу, а не утром по потерянным заказам.
Доступность серверов. Сервер перестал отвечать на запросы — среагируете до того, как это заметят остальные.
TCP-порты сервисов — базы данных, почта, API. База перестала отвечать — увидите до того, как приложение начнет спамить юзеров ошибками.
SSL-сертификаты. Продлите сертификат заранее — пока пользователи не заметили в браузере предупреждение о небезопасном соединении.
Проверки идут из нескольких регионов — без ложных алертов из-за временных сетевых сбоев.
Бонусом: история инцидентов по каждому сервису, дашборд с аптаймом, настройка интервала и таймаута, пауза без потери настроек. Подробнее в документации →
Стоимость — 30 ₽ в месяц за сервис, списания почасовые.
Проходите бесплатный мини-курс в Академии Selectel. Внутри — восемь полезных материалов, которые помогут освоить инструмент с открытым исходным кодом для работы с контейнерами. Вы научитесь:
использовать базовые команды и Podman Compose,
работать с зависимостями и переменными окружениями,
мигрировать инфраструктуру из Docker.
Примените полученные знания на практике в облаке Selectel и SELECTOS. Вы можете запросить промокод, чтобы попрактиковаться в панели управления бесплатно.
Недавно писал, что вписался консультантом в проект Signal. Бекенд развернут на self-host Supabase. Мне дико не нравится работать с их логами, поэтому решил поднять VictoriaLogs + VictoriaMetrics и прикрутить Grafana как UI.
Вся эта связка живет на одной железке в докере. У такого конфига есть только одна огромная проблема это безопасность. Виктория из коробки вообще не идет ни с какой авторизацией. Обычно это не парит: засовываешь всё за VPN и забываешь. Но с 2025 года с VPN всё туго. Его надо постоянно поддерживать и оживлять, а времени на это нет.
Отсюда вопрос: как не светить Викторию голой в сеть, но при этом иметь доступ к админке, если вдруг что сломается?
Докер сам строит внутри себя сети, и контейнеры отлично общаются по адресам типа grafana:3000. Мой локальный браузер про эти внутренние адреса на VPS, конечно, ничего не знает. Но оказалось, что кто-то уже столкнулся с этой проблемой до меня и собрал докер-образ с Хромом (lscr.io/linuxserver/chromium).
Работает это так: на удаленной виртуалке поднимается браузер, к которому я подключаюсь из своего обычного браузера. Получается такой фрейм прямо в приватную сеть докера. Сидишь и вбиваешь в строку имена контейнеров. Естественно, сам веб-интерфейс этого Хрома надо закрыть паролем, иначе вся затея теряет смысл.
Штука прикольная. Можно даже срезать качество картинки и FPS, если инет тупит. Но есть боль с буфером обмена. Текст просто так не скопируешь, приходится пихать его в отдельное окошко. Плюс у меня Мак с cmd+c/v, а на сервере крутится линукс с ctrl и мозг при переключении немного ломается.
Как итог, костылем я доволен. Собрал себе админку без VPN, в которую буду залезать может раз в полгода, но зато без боли.
А как вы сейчас прячете внутренние тулзы на пет-проектах? Страдаете с ключами и туннелями или есть решения проще?
Учёт ИТ-активов в России: 80% компаний — на троечку
Опросили 100+ компаний из ИТ, промышленности, банков и ритейла, как у них устроено управление ИТ-активами. Картина отрезвляющая:
80% оценивают зрелость своих ITAM-процессов на 1–3 из 5;
42% не используют никаких стандартов;
каждая пятая до сих пор ведёт учёт в Excel;
приоритет №1 — банальное «понять, что у нас вообще есть».
Самые большие потери — не на закупке, а в «серой зоне»: перемещения между офисами, замена сотрудников, списание. Оборудование числится за кем-то, а физически недоступно.
Внутри — срез рынка с цифрами, разбор ключевых проблем, кейсы «Ленты» и ITGLOBAL.COM и тренды на ближайшие годы: TCO, ИИ, облако, compliance.
Вебинар «Переход с Microsoft Exchange на Почту VK WorkSpace: пошаговый план»
16 июня в 11:00 К2Тех совместно с VK Tech проведет вебинар о переходе с Microsoft Exchange на почту VK WorkSpace. Поговорим о том, как подойти к миграции без лишнего стресса, что важно учесть на старте проекта и как перенести ключевые данные без потерь.
Поддержка Microsoft Exchange 2016 и 2019 завершена, поэтому вопрос миграции для многих компаний уже перестал быть теоретическим. Когда обновления безопасности больше не выходят, почтовая система становится источником растущих рисков, а откладывать переход все сложнее.
На вебинаре разберем, как выглядит пошаговый план миграции на VK WorkSpace: от предварительной оценки и подготовки до переноса данных и настройки целевой среды. Отдельно обсудим типовые риски проекта и практические способы их минимизации.
Покажем и техническую сторону вопроса. В программе — демонстрация встроенных инструментов миграции VK WorkSpace: перенос писем, календарей, контактов и групп рассылки, а также разбор того, что важно проверить заранее, чтобы не столкнуться с неприятными сюрпризами на этапе переключения.
Еще один важный блок — экосистемность платформы. Коротко пройдемся по возможностям VK WorkSpace: почта, календарь, мессенджер, видеоконференции, диск, документы и другие сервисы для совместной работы в едином контуре.
Команда К2Тех поделится практикой проектов в различных отраслях: какие задачи чаще всего возникают при миграции, где обычно скрываются узкие места и какую роль играет интегратор при использовании встроенных средств переноса.
Также обсудим, как выстраивать политики безопасности корпоративной почты с учетом требований регуляторов, и расскажем, какие возможности VK WorkSpace появятся в ближайших релизах.
Спикеры:
Антон Тен, коммерческий директор VK WorkSpace, VK Tech.
Павел Бухтияров, руководитель направления «Почта» VK WorkSpace, VK Tech.
Владимир Сергеев, эксперт практики UC и ПО для совместной работы, К2Тех.
Для кого будет полезен вебинар
ИТ-директора и CIO, которые планируют отказ от Exchange и выбирают целевую почтовую платформу.
Руководители ИБ и CISO, отвечающие за снижение рисков, связанных с устаревшими системами и отсутствием обновлений безопасности.
Руководители инфраструктурных и почтовых команд, администраторы Exchange и VK WorkSpace.
Архитекторы и руководители проектов, которым нужно спланировать миграцию и оценить ее влияние на бизнес-процессы.
🎁 Бонус:
Для компаний, которые рассматривают переход с Exchange, на вебинаре будут доступны консультация по миграции, специальные условия технической поддержки до 30 июля 2026 года.
Продолжаем рубрику с видеообзорами железа, которое используем в нашей инфраструктуре. Перед запуском на проде тщательно отбираем оборудование и гоняем его под высокими нагрузками, чтобы убедиться в стабильности и надежности.
В новом видео Влад Олейник, ведущий инженер ЦОД, рассказал про 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-процессорами ускоряют этапы сборки, требующие высокой однопоточной производительности.
Как RETAILIQA совместила 152‑ФЗ, SLA для иностранцев и задел под новые ИИ‑сценарии
👨💻 Что за компания RETAILIQA (бренд компании ООО «Крона Лабс») с 2014 года развивает сервисы мобильного аудита: электронные чек-листы для контроля качества, мониторинга цен конкурентов и оценки лояльности клиентов (NPS). Решения компании используют крупные федеральные и региональные игроки в ритейле, общепите, телекоме, банках, страховании, управлении недвижимостью, промышленности, логистике и других отраслях.
🚀 Задача На фоне роста клиентской базы и объема собираемых данных команда столкнулась с несколькими ограничениями: прежний провайдер не мог масштабировать хранилище и вычислительные ресурсы, усилились требования федеральных заказчиков к безопасности и хранению чувствительных данных в российском ЦОД, у зарубежных клиентов возникали проблемы с доступностью сервисов. Параллельно RETAILIQA готовилась внедрять ИИ-модели для распознавания полок и ценников, что требовало гибкой и отказоустойчивой облачной инфраструктуры.
☁️ Что сделали В 2024 году всю инфраструктуру перенесли в облако VMware на платформе Cloud.ru, закрыв потребность в ресурсах и отказоустойчивости без простоя для клиентов. Для хранения терабайтов данных подключили S3-совместимое хранилище Evolution Object Storage и перешли на модель pay-as-you-go — оплачивают только фактическое потребление без необходимости «держать запас» на стороне. Для защиты и соответствия требованиям безопасности добавили StormWall: Anti-DDoS и сервис резервного копирования виртуальных машин VMware, обеспечив дополнительный уровень защиты от атак и потери данных.
🦾 Что получили в итоге RETAILIQA сняла ресурсный потолок: теперь можно без ограничений подключать федеральных и региональных клиентов с тысячами объектов контроля и десятками тысяч пользователей. Доступность сервисов достигла 99,98%, а надежное хранение фото- и видеоматериалов в сертифицированных российских ЦОД укрепило доверие крупных заказчиков и регуляторно-чувствительных отраслей. Например, крупная аптечная сеть с более чем 2 000 точек ежедневно отправляет «тяжлые» фотоотчеты по строжайшим стандартам мерчендайзинга — инфраструктура провайдера справляется с таким потоком без деградации.
В планах — внедрение сервисов AI Factory для анализа фотографий и распознавания информации на ценниках. Это позволит автоматически проверять, соответствует ли выкладка товара в торговых залах утвержденным схемам (планограммам), а также ускорит подготовку отчетов и позволит гибко масштабировать ресурсы под новые сценарии с применением ИИ, не перестраивая всю архитектуру с нуля.
Модернизировали дата-центры для быстрого внедрения ИИ
Команда Yandex Infrastructure модернизировала подход к строительству и охлаждению дата‑центров. Новая концепция кампусов дата‑центров и внедрение жидкостного охлаждения поможет ускорить создание и вывод на рынок ИИ‑сервисов Яндекса.
Концепция «кампус дата‑центров». Кампусы — несколько независимых дата‑центров в одной локации с общей внешней инфраструктурой. Команда внедрила концепцию кампусов, чтобы повысить эффективность использования ресурсов, снизить издержки и увеличить мощности в три раза до 180 МВт — рекордного в России показателя.
Жидкостное охлаждение. Для модернизации существующей инфраструктуры инженеры компании разработали сайдкары — дополнительные стойки с жидкостно‑воздушными радиаторами. Они позволяют использовать жидкостное охлаждение в дата‑центрах с фрикулингом без масштабной реконструкции. Сочетание двух технологий обеспечивает эффективное терморегулирование и ускоряет адаптацию инфраструктуры к растущим нагрузкам.
Благодаря фрикулингу и отказу от доохлаждения дата‑центры Яндекса уже достигают показателя энергоэффективности PUE 1,1. Внедрение жидкостного охлаждения позволит дополнительно снизить энергозатраты и повысить экологичность дата‑центров, делая их ещё более «зелёными».
Для всех, кто ценит честный подход и свободу выбора
ОФИЦИАЛЬНАЯ ОФЕРТА!
Каждый желающий может приобрести видеоблейзер - умный видеорегистратор на основе нейросетей, протестировать его в реальных условиях и — если вдруг устройство не подойдёт — вернуть без объяснения причин.
Мы прекрасно понимаем, что людям важно быть уверенными в покупке. Поэтому решили убрать любые барьеры и формальности. Никаких договоров на тестирование, никаких сложных процедур — только наша открытость и 30-летняя репутация, на которую тоже не нужно теперь опираться, потому что всё можно проверить!
Спецлаб дает 60 дней на возврат оборудования и ПО без каких-либо вопросов. Единственный возможный расход — пересылка.
Если вы захотите поделиться впечатлениями, рассказать причину возврата или отправить логи — мы будем благодарны. Но это исключительно по вашему желанию.
За годы работы мы заключили столько договоров на тестирование, что пришли к простому выводу: гораздо удобнее и быстрее сделать процесс свободным и прозрачным. Зачем тратить месяцы на согласования, если можно просто делать нужный продукт, который не хотят возвращать?
И самое удивительное — за всё время ни один тестировщик так и не вернул оборудование.
Как понять до внедрения, станет ли Low-code платформа точкой роста?
На старте почти любая No/Low-code система, основанная на платформе, выглядит удобно: быстрый запуск, простые сценарии, минимум разработки.
Проблемы начинаются позже, когда нужны нестандартная логика, интеграции и масштабирование. Тут часто выясняется, что у платформы есть потолок:
бизнес снова идет в очередь к разработчикам
растет зависимость от вендора
доработки становятся дорогими и медленными
В новом интервью для TAdviser Илья Радченко, директор по платформенным продуктам SimpleOne, рассказал, как проверить поставщиков платформенных решений.
Полезный материал для тех, кто выбирает платформу не под пилот, а на несколько лет вперед.
UPD1: Так же возможно ситуация затронула следующие хостинги: THE.Hosting UFO.Hosting Alexhost.com Vdsina.com Hip.hosting Datacheap.ru ihc.ru
Оператор дата-центров nLighten в одностороннем порядке и без уведомления остановил работу серверов MIRhosting в Нидерландах и Германии. В MIRhosting назвали действия поставщика абсолютно неприемлемыми.
Что делается сейчас:
MIRhosting привлекает юристов для выяснения деталей;
Идутся поиски альтернативных площадок для размещения инфраструктуры;
Инженеры пытаются восстановить доступ к серверам для спасения данных;
Готовятся варианты экстренного переезда для клиентов.
Компания «Евробайт» полностью контролирует ситуацию и находится на связи с партнёром. Как только появится конкретика по срокам и параметрам миграции оборудования, специалисты «Евробайт» свяжутся с каждым пострадавшим клиентом индивидуально. Команда приложит все усилия, чтобы решить проблему с минимальными неудобствами.
Материал основан исключительно на данных из открытых источников. Автор публикации не гарантирует достоверность предоставленных сведений и не несёт ответственности за их точность.
Атака Shai-Hulud: как скомпрометировали npm-пакеты Red Hat
Инфраструктура публикации пакетов @redhat-cloud-services оказалась под контролем злоумышленников. Десятки зараженных библиотек попали в публичный реестр npm.
Как сообщает Xakep, исследователи в области информационной безопасности зафиксировали атаку на цепочку поставок Red Hat. Целью стали официальные npm-пакеты под префиксом @redhat-cloud-services — библиотеки, которые используются в корпоративных проектах на базе экосистемы Red Hat.
Механика атаки классическая для supply chain: компрометация учетных записей или инфраструктуры публикации. После получения доступа злоумышленники выпустили обновления легитимных пакетов с внедренным вредоносным кодом. Разработчики, обновляющие зависимости через npm install, получали инфицированные версии.
Особенность в используемом инструменте — черве Shai-Hulud. По данным исследователей, в атаке задействован новый вариант под названием Miasma. Shai-Hulud специализируется на горизонтальном распространении внутри npm-экосистемы: заражает один пакет, затем через цепочку зависимостей пытается компрометировать связанные библиотеки и downstream-проекты.
Для проверов: пересоберите lock-файлы, проверьте хеши установленных версий @redhat-cloud-services против официальных сигнатур. Если используете эти пакеты в production — аудит логов сетевой активности на предмет неожиданных соединений. Red Hat, вероятно, уже отозвал скомпрометированные версии, но в локальных кэшах и приватных зеркалах они могут остаться.
Случай напоминает, что доверие к корпоративным пакетам не отменяет базовых практик: dependency pinning, проверка integrity-хешей, мониторинг аномалий в поведении библиотек. Supply chain остается самым уязвимым звеном — компрометация одного аккаунта мейнтейнера дает доступ к тысячам downstream-проектов.
На конференции ЦИПР одной из важных тем для облачных операторов была постройка дата-центров в московском регионе. Сразу скажем, что пока это не закон и конкретных документов под эти планы нет, но радует, что правительство понимает важность этой темы.
Заместитель министра цифрового развития, связи и массовых коммуникаций Евгений Филатов сообщил, что Минцифры обсуждают с Минэнерго возможность разрешить новым игрокам подключиться, если у них есть свои источники энергии. Почему это важно?
Облачные сервисы хороши тем, что пользователю не приходится задумываться, где находятся серверы — в Москве, Сибири или даже за границей. Грамотная организация позволяет бесшовно использовать сервисы в любой локации. Но провайдеру как раз приходится заботиться о том, чтобы дата-центры обладали нужной скоростью доступа и низким пингом, имелась возможность быстро переключиться на другие сервисы при инцидентах в текущем. Кроме того, для некоторых задач важны Edge Computing, то есть технологии, обеспечивающие вычисления в ближайших ЦОДах (для минимальной задержки сигнала).
Однако в таких регионах, как Москва, с февраля подключение ЦОД к электросетям ограничено, так как нет лишних мощностей — они уже использованы или зарезервированы для крупных игроков. А значит, рынок монополизируется: небольшим облачным операторам труднее расширять серверные мощности, чтобы запускать уникальные сервисы и показывать конкурентоспособность на рынке.
Возможность запускать дата-центры, пусть и со своими источниками энергии (которые найти в таких регионах, как Москва, непросто), расширит количество игроков, даст возможность выбора для облачных операторов и позволит достичь максимальной функциональности и надежности сервисов.
Дефицит электроэнергии — не российская особенность, а тренд для всех развитых стран мира. В частности, в США из-за массового строительства дата-центров под ИИ планируется даже возрождение АЭС, которые смогут дать постоянные мощности по приемлемым ценам (СЭС ночью не работают, ВЭС зависят от ветра). Ресурс Servernews отмечает, что такие крупные компании, как Microsoft, SoftBank и SpaceX (недавно слилась с ИИ-компанией xAI), собираются использовать газовые генераторы, а OpenAI под проекты Oracle закупает топливные элементы.
Надеемся, что и российские регуляторы не останутся в стороне и помогут решить общемировую проблему.
Локальный ИИ-сервер на Tesla V100: 200 тысяч рублей против облачных подписок
Собрали сервер на двух Tesla V100 за 200 000 ₽ и прогнали 128 моделей — от LLM до генерации изображений. Разбираемся, когда старые дата-центровые GPU выгоднее новых RTX и облаков.
Tesla V100 — флагманская GPU NVIDIA 2017 года для дата-центров. Сейчас б/у карты стоят 80-100 тысяч рублей за штуку, что в 3-4 раза дешевле современных RTX 4090. Причина простая: массовый вывод из эксплуатации корпоративных серверов и переход на архитектуру Ampere/Hopper. Для локального ИИ это шанс собрать мощную лабораторию без миллионных бюджетов.
Почему V100 всё ещё интересна
V100 даёт 16 ГБ HBM2-памяти на карту с пропускной способностью 900 ГБ/с. Для сравнения: RTX 4090 предлагает 24 ГБ GDDR6X, но её стоимость 200-250 тысяч рублей. Две V100 в SXM2-форм-факторе объединяются через NVLink с общей пропускной способностью 300 ГБ/с между картами — это позволяет распределять большие модели на 32 ГБ без узкого места.
Ключевое ограничение — отсутствие Tensor Cores четвёртого поколения и поддержки FP8. V100 работает в FP16/FP32, что означает в 2 раза меньшую эффективность на токен по сравнению с A100 или H100 при одинаковой памяти. Но для экспериментов, файн-тюнинга малых моделей и локального инференса этого достаточно.
Что показали бенчмарки
Авторы прогнали 128 моделей через llama.cpp, vLLM, Stable Diffusion и VideoGen. Вот ключевые выводы:
LLM до 13B параметров — 40-60 токенов в секунду на одной V100 в FP16, что сравнимо с RTX 3090.
Модели 30-70B — требуют обеих карт через NVLink, скорость падает до 15-25 токенов в секунду из-за ограничений пропускной способности.
Stable Diffusion XL — 6-8 секунд на изображение 1024x1024, приемлемо для прототипирования.
Видеогенерация (CogVideoX, ModelScope) — медленно, 2-3 минуты на 2 секунды видео, здесь V100 уже не конкурент новым картам.
Проблемы выявились на квантизации: GPTQ и AWQ показывают нестабильность на V100 из-за особенностей работы с низкоразрядными операциями. Модели лучше запускать в нативном FP16 или использовать llama.cpp с Q4/Q5 квантизацией, что даёт предсказуемое качество.
Когда это имеет смысл
Локальная лаборатория на V100 оправдана в трёх случаях:
Исследования и обучение — постоянный доступ к GPU без тарификации по времени. Окупается за 6-8 месяцев по сравнению с облачными инстансами p3.2xlarge на AWS.
Файн-тюнинг моделей до 13B — LoRA и QLoRA работают эффективно, 32 ГБ хватает для батчей.
Приватные развёртывания — данные не покидают периметр, что критично для финансовых и медицинских приложений.
Не подходит для продакшн-инференса высоконагруженных сервисов — там нужна энергоэффективность и throughput современных Ampere/Hopper. V100 потребляет 300 Вт на карту, что при промышленной эксплуатации съедает экономию на железе за год.
Вывод: V100 — это компромисс между стоимостью входа и возможностями. Для малых команд и стартапов, которым нужна локальная ИИ-инфраструктура без вендор-локина, это разумный выбор в 2025-2026 годах. Главное понимать ограничения и не ожидать от пятилетних карт производительности новых поколений.
Сегодня 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 начались около двух недель назад, через несколько дней стало известно об изъятии серверов в Нидерландах, теперь история подошла к закономерному финалу.
Три подразделения, три правды. Куда уходит ИТ-бюджет и при чём тут ITAM
Бухгалтерия: «3000 на балансе». ИТ: «1800 в сети». Безопасность: «2200 под защитой». И никто не врёт — каждый считает свой срез.
Корень проблемы — не сами расходы, а отсутствие единой экономической модели ИТ. CFO видит строку «50 млн руб./год» без детализации. CIO знает, что серверы на грани, но не может перевести это на язык финансов. Бизнес требует цифровизации, не понимая нагрузки на бюджет.
При этом контекст 2024–2026 усложнил всё кратно: параллельный импорт — плюс 20–40% к закупкам, импортозамещение — рост годового бюджета на 40–70% не за счёт расширения, а за счёт выкупа лицензий в альтернативных стеках. Компании тратят миллионы на ПО «про запас», которое не используют прямо сейчас.
Если раньше мы платили 10 млн руб./мес. за подписку M365, то сейчас вынуждены держать 50 млн руб. единовременного резерва на закупку ПО в реестр, плюс 15 млн руб./мес. на доработку интеграций.
Алексей Бородин, эксперт по развитию ITAM- и ITSM-проектов
Совместно с практикующими экспертами по ITAM и ITSM мы подготовили материал о том, как IT Asset Management помогает сделать ИТ-затраты прозрачными и управляемыми.
Внутри:
Анализ ключевых вызовов 2024–2026: санкции, переход от OPEX к CAPEX, рост НДС, дефицит ИТ-специалистов
Почему Excel, ERP, ITSM с CMDB и BI-системы перестают справляться с управлением затратами — и где у каждого инструмента потолок
Системный подход к управлению ИТ-активами через ITAM — на примере SimpleOne ITAM
Кейс ITGLOBAL.COM (by ITG): переход с Excel на ITAM в международной структуре с присутствием в 12 странах
Чек-лист «Как сделать ИТ-затраты управляемыми»: 4 шага + методика расчёта TCO и ROI
