Почему скрипт работает руками, но падает из cron 

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

Все потому что у cron другое окружение. Он не подхватывает настройки из ~/.bashrc, PATH может отличаться от интерактивной shell-сессии, относительные пути вести не туда, а stderr вообще потеряться, если его заранее никуда не направить. Поэтому для cron-задач лучше сразу указывать абсолютные пути к командам и сохранять вывод в лог.

Например: 

*/10 * * * * /opt/scripts/sync.sh >> /var/log/sync.log 2>&1 

Если задача не запускается, начать можно с самого cron:

systemctl is-active cron
journalctl -u cron --since today

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

env -i /bin/sh -c '/opt/scripts/sync.sh'

Так быстрее всплывают зависимости от PATH и других переменных, которые были доступны в обычном терминале. 

Есть еще несколько мелочей, на которых cron легко ломается: 

• В crontab символ % имеет специальное значение. Поэтому, например, в date +%F его нужно экранировать: date +\%F.

• В файлах /etc/cron.d/ последняя запись должна заканчиваться переводом строки. Иначе cron может ее просто пропустить.

• @reboot запускает задачу после старта системы, но не ждет, пока поднимутся сеть, база или сетевой диск. Если скрипт от них зависит, удобнее описать зависимости через systemd. 

• Если предыдущий запуск еще не закончился, cron спокойно может запустить второй экземпляр. Для простых задач от этого защищает flock.

Сам cron хорошо подходит для независимых задач по расписанию. Когда нужно выполнить пропущенный запуск после простоя, дождаться другого сервиса или ограничить ресурсы процесса, возможностей одной строки в crontab уже мало. В Ubuntu для таких сценариев есть anacron и systemd timers: у последних можно задавать зависимости, сохранять пропущенные запуски через Persistent=true и смотреть логи через journalctl.

В блоге Рег.облака собрали полную шпаргалку по cron в Ubuntu: синтаксис расписания, пользовательские и системные задания, примеры для бэкапов и обслуживания сервера, диагностику, права и секреты, а также сравнение cron с anacron и systemd timers. 

Если файлы уже шифруются, не начинайте с их спасения

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

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

Что имеет смысл сделать в первую очередь:

• Изолировать зараженные устройства от сети, виртуальной частной сети компании и других подключений;

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

• Сохранить логи и подозрительные файлы, а не чистить систему сразу;

• Ограничить скомпрометированные учетные записи, причем менять пароли с чистого устройства;

• Проверить не только рабочие станции, но и серверы, общие папки, гипервизоры, облачные ресурсы и систему резервного копирования.

А также есть несколько действий, которые не стоит делать:

• Не подключать резервный диск к зараженной машине;

• Не восстанавливать данные поверх зараженной ОС;

• Не удалять журналы до фиксации артефактов;

• Не считать инцидент завершенным сразу после того, как файлы снова открылись. 

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

Бэкап еще не означает, что данные получится корректно вернуть. Копия должна быть актуальной, целой, недоступной атакующему, а сам процесс восстановления — заранее проверенным. Постоянно подключенная сетевая папка может быть зашифрована вместе с основной системой. Для критичных данных стоит держать изолированную или неизменяемую копию и заранее понимать свои RPO/RTO.

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

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

Скролл без костылей — что уже умеет CSS

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

Но обычно проблемы начинаются с нескольких базовых свойств. Вот что полезно знать:

• Overflow — основа скроллинга. Если у контейнера ограничена высота, overflow: auto добавит прокрутку только тогда, когда контент перестанет помещаться. Через overflow-x и overflow-y можно отдельно управлять каждой осью. 

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

• Плавные переходы по якорям делаются одной строкой: scroll-behavior: smooth. Но есть нюанс с доступностью: если пользователь включил prefers-reduced-motion, плавную анимацию лучше отключить. 

• Scroll Snap может заменить простой JS-слайдер. scroll-snap-type и scroll-snap-align позволяют фиксировать карточку или секцию после прокрутки, а scroll-snap-stop: always — не перескакивать через элементы при быстром свайпе. 

• Фиксированный header не должен перекрывать якорь. Вместо дополнительных скриптов можно задать scroll-padding-top для страницы или scroll-margin-top для отдельных секций. 

• Вложенный скролл тоже можно контролировать. Если внутри страницы есть модальное окно или боковая панель, overscroll-behavior: contain не даст прокрутке после конца блока автоматически перейти на родительскую страницу. 

Есть и менее очевидные детали. Например, scrollbar-gutter: stable помогает избавиться от горизонтального «прыжка» страницы при появлении полосы прокрутки, а кастомный scrollbar лучше не делать слишком узким или малоконтрастным — это уже влияет на доступность интерфейса.

JavaScript понадобится уже там, где скроллинг запускает дополнительную логику: Infinite Scroll с подгрузкой данных, синхронизацию нескольких областей, аналитику или сложные интерактивные сценарии. А вертикальный и горизонтальный скролл, Scroll Snap, плавные якоря и управление вложенной прокруткой вполне можно оставить браузеру. 

Если хотите посмотреть готовые HTML/CSS-примеры и разобрать типичные ошибки, читайте полное руководство в блоге Рег.облака.

API Security на практике: что проверить в API перед продом

API может быть закрыт авторизацией, работать по HTTPS и стоять за WAF — и при этом оставаться уязвимым. Например, пользователь успешно вошел в аккаунт и запрашивает /orders/125. Если сервер позволяет заменить 125 на 126 и получить чужой заказ, пароль взламывать вообще не нужно: проблема не в аутентификации, а в том, что API не проверяет права на конкретный объект. 

И это только один сценарий. Через API можно напрямую обращаться к методам, менять параметры запросов, автоматизировать разрешенные операции и продолжать использовать старые эндпоинты, о которых основная команда уже забыла. Поэтому перед запуском стоит проверить как минимум несколько вещей. 

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

• Входные данные и запросы сервера. Параметры, JSON, имена файлов и URL нельзя без проверки передавать дальше в SQL-запросы, команды или внутренние сервисы. Иначе появляются инъекции и SSRF — вплоть до запросов к ресурсам, которые вообще не должны быть доступны извне. 

• Бизнес-логику. Иногда API технически работает правильно, но им легко злоупотребить: бот может перебрать промокоды, занять все слоты бронирования или отправить тысячи SMS-кодов, за каждый из которых платит компания. Обычного общего rate limit здесь бывает недостаточно — ограничения нужно задавать именно на чувствительные операции. 

• Старые и тестовые версии. API меняется, а забытый endpoint может продолжать работать со старой аутентификацией, лишними правами или уязвимыми зависимостями. Поэтому важно вести инвентаризацию методов и версий и отключать то, что больше не используется. 

• Защиту на уровне инфраструктуры. WAF может отфильтровать часть веб-атак, API Gateway — централизовать правила доступа и лимиты, DDoS-защита — отсечь большой поток до сервера. Но эти инструменты не исправят ситуацию, если само API не проверяет, имеет ли пользователь право выполнить конкретное действие. 

В статье собрали основные риски из рейтинга OWASP API Security Top 10, разобрали аутентификацию и авторизацию, SSRF и инъекции, атаки на бизнес-логику, работу с секретами, WAF, API Gateway, rate limiting и мониторинг. В конце — чек-лист, по которому можно пройтись по своему API и понять, где искать основные пробелы в защите. Если хотите пройти проверку целиком, читайте материал в блоге Рег.облака.

Изолируем зависимости: как создать виртуальное окружение в Python

Когда пишешь код на Python, рано или поздно наступает момент, что один проект начнет ломать другой. Установили новую библиотеку, и вдруг скрипт, который вчера работал, падает с ошибкой. Знакомо? Причина обычно одна — конфликт зависимостей. Все пакеты свалены в один системный Python, версии пересекаются, и что-то обязательно отваливается.

Решение — виртуальное окружение. Это отдельная песочница для проекта: свои библиотеки, свой Python, никакого пересечения с соседями.

Вот с чего стоит начать и что стоит разобрать, если вы только садитесь за такую изоляцию зависимостей:

• Виртуальное окружение vs виртуальная машина. Первое — это просто отдельная папка с пакетами, второе — целая ОС. Хотя некоторые новички часто путают, и потом удивляются, почему venv весит пару мегабайт.

• venv, virtualenv, pipenv, poetry, conda. Это пять инструментов, которые решают похожие задачи, но по-разному. Для большинства проектов хватает встроенного venv — он уже есть в Python с версии 3.3, и ничего ставить не надо.

• Активация. А это самая частая точка спотыкания. Команды различаются для Windows, Linux и macOS, а PowerShell вообще блокирует скрипты по умолчанию. source .venv/bin/activate против .venv\Scripts\activate — и это только начало.

• requirements.txt. Важно помнить, что папку окружения нельзя копировать между машинами, так как она привязана к ОС и архитектуре. Вместо этого фиксируем список пакетов и разворачиваем его одной командой pip install -r requirements.txt.

• Git и .gitignore. Виртуальное окружение в репозиторий не кладут — только код и список зависимостей.

Чтобы пройти весь путь по шагам — от создания первой папки до деплоя на сервере через systemd и Gunicorn — читайте подробный гайд на сайте Рег.облака.

Выделенный сервер на Xeon E3: разбираем варианты переезда 

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

В SpaceWeb мы держим линейку на Xeon E3-1270 v3 — процессоре не новом, но зато проверенном годами. Варьируя лишь объем RAM и тип накопителей, можно решить почти любую задачу: от легкого сайта до файлового хранилища на терабайты.

Какую выбрать конфигурацию:

• Сайт или несколько веб-проектов. 16 ГБ RAM и пара SSD — база для Битрикса, WordPress или интернет-магазина. Если проектов больше, тогда берем 32 ГБ.

• Интернет-магазин или портал с контентом. Тот же процессор, но диски побольше: под базы, картинки и логи.

• Бэкапы, архивы, почта. Здесь скорость SSD не нужна, поэтому ставим HDD на терабайты. Дешевле, а задачу решает.

• Сайт и файлы на одном сервере. Гибрид: SSD под приложение, HDD под документы. Удобно для корпоративных порталов и Bitrix24.

Посмотреть полные характеристики и заказать нужную конфигурацию можно на сайте SpaceWeb. А если не нашли подходящий вариант — просто напишите нам на почту dedic@sweb.ru, мы поможем подобрать решение вручную.

Python в VS Code не работает? Разбираем настройку по шагам

Если вы пишете код на Python, рано или поздно встает вопрос: в чем его писать? Вариантов масса: от блокнота до тяжелых IDE вроде PyCharm. Visual Studio Code — отличный компромисс — он легкий, но при этом умеет почти всё, что нужно для комфортной работы. Но сложность в том, что из коробки он бесполезен, пока не настроишь интерпретатор, расширения и окружение. И вот тут начинается самое интересное.

Вот с чего стоит начать и что стоит разобрать, если вы только садитесь за настройку:

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

• Виртуальное окружение. Без него все библиотеки ставятся в общую систему, и рано или поздно два проекта потребуют разные версии одной и той же библиотеки. Что-то одно сломается.

• Расширения. Pylance отвечает за автодополнение, Python Debugger — за отладку по шагам, Ruff — за линтинг и форматирование. Но если поставить всё сразу, инструменты начнут конфликтовать между собой.

• Отладка вместо print(). Точки остановки и панель переменных позволяют увидеть, что реально происходит в коде, вместо того чтобы гадать, где закралась ошибка.

Каждый из этих пунктов — отдельная история с нюансами под Windows, macOS и Linux. Где-то команда называется python, где-то python3. Где-то нужно вручную добавить PATH, где-то переустановить Python из официального пакета.

Если хотите пройти весь путь по шагам: от установки редактора до запуска первого скрипта с отладкой, читайте полное руководство на сайте Рег.облака.

7 новых ИИ-моделей в Рег.облаке: от агентских сценариев до глубокой аналитики

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

• Совсем свежая — сентябрьская. Claude Fable 5.1 от Anthropic, вышедшая 1 сентября: контекст 1M токенов, а в агентных задачах Terminal-Bench 4.0 результат вырос до 55,8% против 42,0% у предыдущей версии. 

• Летние флагманы. Qwen 3.8 Max от Alibaba — это мультимодальная модель с 2,4 трлн параметров и контекстом 1M токенов. Еще одна новинка — Kimi K3 от Moonshot AI, open-weight модель с 2,8 трлн параметров, занявшая первое место в Frontend Code Arena по версии Arena.ai. А также MiMo v2.5 и MiMo v2.5 Pro от Xiaomi — настоящие флагманы для агентских задач. И, конечно, GPT 5.6 Sol от OpenAI, появившаяся в общем доступе 9 июля и которая примерно вдвое дешевле при сопоставимом качестве.

• Поисковая модель. Sonar от Perplexity — модель для работы с актуальной информацией из интернета, дает 128K токенов и запускает поисковые запросы для подготовки аналитических отчетов.

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

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

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

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

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

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

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

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

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

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

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

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

Август выдался насыщенным: ввели оплату ИИ-моделей по токенам, выпустили новый тариф со 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 — базовые концепции и практические примеры для администраторов и разработчиков.

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

Как аптечная сеть «36,6» снизила ИТ-расходы в 1,5 раза после переезда на bare metal

Аптечная сеть «36,6» росла, а инфраструктура за этим не успевала. Аналитические расчеты требовали все больше мощности, а ядро сети держалось на двух коммутаторах Cisco с потолком 1 Гбит/с — в часы пик из-за этого могли сбоить аптеки. Бюджет при этом растягивать не хотелось.

Решением стал переход на bare metal в Рег.облако. Собрали инфраструктуру, которая оставила «36,6» полный контроль над железом и дала запас мощности для роста.

Что сделали:

• перенесли больше 400 виртуальных машин за два месяца, без простоев в бизнес-процессах;

• в основном ЦОДе — хосты на AMD EPYC с памятью DDR5 и три системы хранения;

• заменили ядро сети: вместо упиравшихся в 1 Гбит/с коммутаторов Cisco поставили масштабируемое программное решение;

• добавили серверы с GPU под большие языковые модели и резервный ЦОД с объектным хранилищем S3.

В результате расходы на инфраструктуру снизились в 1,5 раза, производительность кластера выросла в среднем на 40%, а ключевой расчет ускорился с 22 до 16 часов. Подробнее о технической реализации — в кейсе на сайте Рег.облака.

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

В июле запустили третий этап 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-серверы и подход к их устройству.

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

Не отдавайте базу знаний чужому ассистенту

Wake word устройство ловит локально, а дальше все идет на сервер: ASR переводит звук в текст, NLU достает интент, система выполняет действие, TTS озвучивает ответ. Сервер при этом чаще всего чужой. Вместе с аудио туда попадает и то, на чем ассистента обучали — внутренние инструкции, переписка, документы.

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

Подробности — в блоге Рег.облака.

Первые шаги на сервере: что быстрее освоить — консоль или ispmanager

У новичка на сервере обычно два пути: открыть панель управления в браузере или подключиться по SSH и разбираться с командами. Панель дает готовые формы под типовые операции, консоль — прямой доступ к системе. Освоить панель получится быстрее, но Linux под ней никуда не денется.

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

Подробности — в блоге Рег.облака.

JSON или XML: сравнение популярных форматов обмена данными

Выбор между JSON и XML редко стоит как «что лучше» — это два инструмента с разной философией. JSON оптимизирован под компактность и скорость парсинга, XML — под строгую структуру, валидацию и сложные документы со смешанным содержимым.

В статье разобрали оба формата на одинаковых примерах, прошлись по истории и причинам, по которым JSON вытеснил XML в вебе. Сравнили по ключевым параметрам: синтаксис, объем, скорость обработки, поддержка типов данных, комментарии, пространства имен, валидация через JSON Schema и XSD. И отдельно написали про области применения.

Подробности — в блоге Рег.облака.

Инфраструктура для ИИ-ассистента

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

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

Подробности — в блоге Рег.облака.

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

В июне открыли новый регион Москва-3 и запустили там GPU-инстансы на базе NVIDIA Blackwell. Также запустили Free Tier для миграции с хостинга в облако вместе с ispmanager и поделились исследованием о тратах на GPU-серверы и кейсом аптечной сети «36,6». Ниже — главное.

Открыли регион Москва-3

Новая зона размещения работает в дата-центре Datahouse «Магистральный-1» уровня Tier III. У региона отдельный control plane и собственные вычислительные ресурсы, поэтому инфраструктуру можно масштабировать без риска перегрузить текущие мощности.

Запустили GPU-инстансы на базе NVIDIA Blackwell

В регионе Москва-3 ввели в эксплуатацию GPU-инстансы на архитектуре NVIDIA Blackwell. В основе — ускорители NVIDIA RTX 6000 Pro Blackwell Server Edition с 96 ГБ видеопамяти GDDR7. Доступны конфигурации до 30 vCPU, до 190 ГБ оперативной памяти и до 1,7 ТБ NVMe на инстанс, ресурсы тарифицируются по модели почасового потребления. По сравнению с A100 стоимость задач снижается до трех раз.

Запустили бесплатный облачный сервер для миграции с хостинга
Вместе с ispmanager запустили Free Tier — первый в России формат, где вместо тестового VPS пользователь получает бесплатный облачный сервер с панелью ispmanager и возможностью бесшовно масштабироваться в основной инфраструктуре Рег.облака. Конфигурация включает 1 виртуальное ядро, 1 ГБ оперативной памяти, 10 ГБ на NVMe-диске, публичный IPv4 и резервное копирование, с возможностью расширения мощности в два раза по запросу. Формат рассчитан на владельцев сайтов, интернет-магазинов и небольших проектов без опыта администрирования серверов — особенно актуально на фоне ухода cPanel и Plesk с российского рынка. К программе Free Tier уже подключилось более 1800 компаний и частных пользователей.

Кейс: аптечная сеть «36,6» перенесла ИТ-инфраструктуру в Рег.облако
Компания перенесла инфраструктуру в Рег.облако и увеличила скорость бизнес-расчетов на 50%, сократив затраты на ИТ в 1,5 раза. Переход на bare-metal серверы поднял производительность вычислительного кластера на 40%. В рамках проекта более 400 виртуальных машин мигрировали на выделенные серверы за 2 месяца без простоев, а время выполнения расчетов сократилось с 22 до 16 часов. Сегодня 2/3 инфраструктуры «36,6» размещено в Рег.облаке.

Исследование: траты на GPU-серверы выросли в четыре раза

За полтора года крупный и средний бизнес увеличил расходы на GPU-конфигурации вчетверо, при этом общее число серверов почти не изменилось. Компании переходят с бюджетных решений на более производительные — H200, H100, A6000.

Несколько цифр из исследования: доля премиальных GPU-конфигураций выросла с 51% до 78%. На конфигурации с видеопамятью до 24 ГБ приходится 46% спроса, на решения от 80 ГБ — 27%. Основные сценарии — ИИ и машинное обучение (33%), рендеринг (30%), тестирование и разработка (25%).

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

Как создать свою нейросеть: от теории к практике 

Базовый пайплайн обучения нейросети складывается из нескольких этапов: подготовка датасета и разделение на train/validation/test, токенизация и приведение последовательностей к единой длине, выбор архитектуры, обучение по эпохам с обратным распространением ошибки и оценка результата. В статье прошлись по основным типам сетей и по инструментам. А также разобрали метрики оценки модели и варианты деплоя обученной сети.

Подробности — в блоге Рег.облака.

Установка и использование Nexus Repository для хранения артефактов

Nexus закрывает типовую DevOps-задачу: единое хранилище для Maven, npm, Docker, NuGet, PyPI и собственных бинарей, кэш внешних зависимостей и предсказуемый источник артефактов в CI/CD. Версии — Community Edition, Pro и связка с Repository Firewall для отсечения небезопасных компонентов на входе.

В статье разобрали установку Nexus Repository 3.91.1 тремя способами, а также показали первичную настройку, загрузку артефактов и политики очистки. И не забыли про разграничение прав через Privileges, Roles и Users, отключение анонимного доступа и вывод Nexus наружу по HTTPS через Nginx с Certbot.

Все детали — в статье Рег.облака.

Облачная или локальная LLM: что выбрать для своего проекта

Выбор между API и self-hosted сводится к балансу четырех параметров: безопасность данных, стоимость на единицу нагрузки, гибкость инфраструктуры и требования к compliance. Для MVP и нерегулярной нагрузки облачный API почти всегда дешевле, для миллионов токенов в день и сценариев с 152-ФЗ или GDPR картина обратная.

В статье разобрали, как устроены оба подхода, и собрали сравнение по ключевым параметрам — от запуска и масштабирования до работы с AI-агентами и длинным контекстом. Показали требования к VRAM для self-hosted (от 8–12 ГБ для 7–8B в квантизации до 48–80+ ГБ для 70B), разобрали гибридные архитектуры с маршрутизацией запросов между локальной и облачной моделью и риски vendor lock-in при работе через API.

Подробности — на сайте Рег.облака.