Администрирование

effective_cache_size - один из самых непонятных параметров.

Смотрим описание в переведённой документации:

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

Вот прямо с первых строк мозги выносит: при чём тут оценка (ОЦЕНКА!) размера дискового кэша и выбор между индексным или полным сканированием? Не знаю, кому как, но лично мне совсем непонятно.
Следующее, если effective_cache_size показывает оценку размера ДИСКОВОГО кеша (для меня одного словосочетание “дисковый кэш” означает “кэш файловой системы”?), то откуда взялась рекомендация в значение 3/4 размера оперативной памяти, если 1/4 - это shared_buffers? Рекомендатели, ау! 1/4 + 3/4 = 1, арифметика, начальная школа. А где СУБД должна выполнять манипуляции с данными? В свопе?
Всё остальное описание совершенно не добавляет ясности по использованию данного параметра, увы нам, постгресовым администраторам баз данных.

Но счастье есть, оно не может не есть, появилось более вменяемое описание этого параметра: All Your GUCs in a Row: effective_cache_size.

Кратко.
Главное. Данный параметр показывает ОБЩИЙ размер кэша: постгресовый shared_buffers плюс (плюс выделен жирным шрифтом в оригинальной статье!) кэш файловой системы. С этим уточнением рекомендация в 3/4 размера оперативной памяти выглядит приемлемой.
Следующее. Обсуждаемый параметр применяется для вычисления вероятности того, что однажды прочитанные данные будут находиться в кэше при повторном обращении в рамках ОДНОГО запроса. Т.е. для предпочтения соединения таблиц вложенным циклом (Nested loop join) при выборе методов соединения. Если высока вероятность того, что данных при повторном запросе в кэше не окажется, то будет выбрано либо полное сканирование таблиц(ы), либо сканирование по битовой маске, либо соединение хешем (hash join), либо соединение слиянием (merge join).
Далее. Этот параметр - верхняя оценка, завышенное значение не приводит к серьёзным проблемам (по крайней мере в статье об этом говорится).
Ограничение. effective_cache_size должен быть больше shared_buffers, ибо меньшее значение является бессмысленным (по статье).

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

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

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

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

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

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

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

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

Представлено бесплатное десктопное приложение Streambert с открытым исходным кодом для ПК на Windows, macOS и Linux. Решение распространяется по лицензии GNU GPL v3.0. Главное преимущество Streambert — здесь совсем нет рекламы и трекеров. Разработчики подчёркивают, что приложение всегда будет бесплатным и не станет собирать личные данные пользователей.

Для поиска и отображения информации о фильмах и сериалах Streambert использует базу TMDB и для работы понадобится бесплатный API-ключ TMDB. Программа поддерживает русский интерфейс и субтитры, а также даёт возможность скачивать любые медиафайлы для офлайн-просмотра.

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

30 июня эксперты «Тантор Лабс» представят разбор Tantor XData Gen3 — третьего поколения машины баз данных для высоконагруженных корпоративных систем, реализующей ряд технологий, ранее доступных в таких западных продуктах как Oracle Exadata, SAP HANA и IBM Netezza.

В программе:

• эволюция архитектуры Tantor XData и ключевые изменения в Gen3: независимое масштабирование подсистем вычислений и хранения, полноценная обработка смешанной нагрузки (HTAP) на едином наборе данных;

• новые возможности платформы и сценарии их применения;

• устройство и особенности распределенной СУБД Tantor Polar;

• организация вычислительных ресурсов и ресурсов хранения;

• инструменты управления и мониторинга.

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

Эксперты мероприятия:

• Вадим Яценко, генеральный директор «Тантор Лабс»

• Сергей Серегин, руководитель технического пресейл «Тантор Лабс».

Когда: 30 июня, начало в 11:00 (онлайн)

Зарегистрироваться

Зачем провайдеру помогать клиенту снижать счёт за облако

Обычно всё растёт постепенно: сервисов стало больше, команды активнее используют инфраструктуру, появились новые тестовые среды, где-то добавились AI-нагрузки, где-то остались временные инстансы после задачи.

Потом приходит счёт, и начинается разбор.

— Кто создал ресурс?
— Он ещё нужен?
— Можно ли его выключить?
— Почему рост увидели только в конце месяца?
— Кто должен отвечать за такие расходы: финансы, инженеры, продуктовая команда или владелец сервиса?

На этом месте появляется ещё один вопрос, уже к рынку:

зачем облачному провайдеру помогать клиенту платить меньше?

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

В новом выпуске «Практики FinOps» мы поговорили об этом с Александром Либкиндом, руководителем направления развития сервисов управления затратами в Cloud.ru.

О чём выпуск

Разговор получился не про разовые скидки и не про универсальный способ «порезать облако».

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

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

Какие вопросы разобрали

• почему FinOps в России развивается медленнее, чем на западных рынках;

• зачем Cloud.ru помогает клиентам снижать счета;

• где обычно находятся первые 15–30% экономии;

• почему отчёт раз в месяц плохо работает для управления затратами;

• чем FinOps для AI отличается от классического FinOps;

• почему автоматические рекомендации не решают проблему без владельцев ресурсов и процессов;

• как компании проходят этап Inform и почему на нём часто начинаются сложности.

Для кого выпуск

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

Смотреть выпуск:
YouTube
Rutube
VK Видео

Мы в телеграм. Подписывайтесь.

Представлен открытый проект Navidrome Music Server, который позволяет слушать музыку с ПК где угодно. Работает очень просто: пользовательский ПК превращается в сервер, к которому можно получить доступ с любого устройства. Есть демо-версия проекта, чтобы понять принцип работы.

Открытые уроки для прокачки: Linux, backend, ИИ, безопасность и управление

Эта неделя хорошо закрывает сразу несколько рабочих зон: инфраструктуру, backend, безопасность, ИИ, аналитику и управление. Темы подобраны так, чтобы за один открытый урок можно было не просто «послушать про тренды», а разобраться в конкретной задаче: от cache и swap в Linux до проектирования аутентификации, SRE-инцидентов, NLP и системного анализа.

Все уроки бесплатные и проходят с преподавателями-практиками OTUS — можно познакомиться с экспертами, протестировать формат обучения и задать вопросы по теме.

Linux, DevOps и инфраструктура

• 22 июня, 20:00. «Память в Linux. Cache, swap, dirty pages». Записаться

• 22 июня, 20:00. «Роль и задачи DevOps в современном IT». Записаться

• 24 июня, 20:00. «Инцидент-менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться

• 25 июня, 19:00. День открытых дверей курса «Администратор Linux. Продвинутый уровень». Записаться

Backend и разработка

• 22 июня, 20:00. «Контейнеризация Java-приложений с Docker». Записаться

• 24 июня, 20:00. «RabbitMQ против Kafka — что выбрать для вашей структуры: сравнение и лучшие практики». Записаться

• 24 июня, 20:00. «Отказоустойчивый и высокодоступный кластер RabbitMQ». Записаться

• 25 июня, 20:00. «Кеширование в ASP.NET Core: от IMemoryCache до Redis». Записаться

Информационная безопасность

• 22 июня, 20:00. «OAuth 2.0, JWT и коварные куки: проектируем безопасную аутентификацию». Записаться

• 22 июня, 20:00. «Киберпанк для CISO — щит и меч ИИ». Записаться

• 22 июня, 20:00. «Анализ журналов событий ОС Windows». Записаться

ИИ, ML и NLP

• 22 июня, 20:00. «Продвинутое структурирование промптов: как получать предсказуемый результат». Записаться

• 22 июня, 20:00. «ИИ-агенты против младших разработчиков: кто кого заменит к концу 2026 года». Записаться

• 23 июня, 20:00. «Обзор инфраструктуры Ollama». Записаться

• 25 июня, 18:00. «Ландшафт современного NLP: от эмбеддингов и классических ML-методов до современных LLM». Записаться

Data, аналитика и базы данных

• 23 июня, 20:00. «ClickHouse: интеграция с Postgres, Kafka, S3 и Superset — готовые решения». Записаться

Системный анализ

• 24 июня, 20:00. «Внедрение новой функции системным аналитиком на примере услуги на Госуслугах». Записаться

• 25 июня, 20:00. «Какие навыки прокачать, чтобы стать экспертом в системном анализе в 2026 году». Записаться

Управление, продукт и Agile

• 23 июня, 20:00. «Как тимлиду победить синдром самозванца». Записаться

• 24 июня, 20:00. «Ретроспектива в Agile: что это, нужна ли она и как сделать её полезной». Записаться

• 24 июня, 20:00. «Топ-навыки менеджера продукта в 2026 году». Записаться

• 24 июня, 20:00. «Кто такой COO и почему он нужен сейчас». Записаться

Это только часть программы недели. Ещё больше тем, направлений и открытых уроков собрали в дайджесте — выбирайте то, что ближе к вашим задачам сейчас.

Представлен проект CamLoop для Zoom, Meet, Slack и Teams. Решение записывает несколько секунд лица пользователя, а затем подменяет во время созвона веб-камеру зацикленным видео Переключаться между настоящей и фейковой камерой можно одной кнопкой.

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

Юху!
Смотрите sshto обновилось до версии 1.01! В новой версии по многочисленным (2) просьбам добавил поддержку множественных значений Host. Теперь вот такой конфиг:

Host     homyak home house
HostName localhost
User     root

Будет обработан вот так:

Творите, выдумывайте, пробуйте!)

Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис

В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:

• пользователи – в одном контуре;

• серверы и рабочие станции – в другом;

• тестовая среда – в третьем.

На схеме это выглядит логично: сегментация, изоляция ошибок, разные зоны ответственности, поэтапная миграция без шуму и пыли.

Но в эксплуатации важен не только вопрос «где лежит объект».

Важнее другое: какие зависимости связывают объекты между собой.

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

Сценарий

Пользователь – в домене A.
Рабочая станция – в домене B.
Группа доступа к приложению – в домене C.

Цепочка доступа:

учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.

Каждый компонент по отдельности может выглядеть исправным:

KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.

А доступ к приложению всё равно не работает.

Почему? Потому что сломался не отдельный объект, а связь между объектами.

Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.

В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.

Что стоит проверить заранее

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

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

• Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.

• DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».

• Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.

Главный вывод

Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.

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

Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.

Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?

#Linux #Инфраструктура #Backup

Подборка вебинаров на июнь 

В июне вас ждут еще три онлайн-встречи с экспертами Cloud.ru — о Spark, облачных расходах и Redis. Регистрируйтесь заранее, чтобы ничего не пропустить.

🎥Spark Connect для ИТ-команд: упрощаем разработку и работу с данными

Покажем, как сделать использование Apache Spark удобным для всей команды с помощью Spark Connect и Evolution Managed Spark. Затронем вопросы разработки в IDE, анализа данных в Jupyter и построения ETL на чистом SQL в dbt. Не бойтесь споткнуться о порог входа — здесь он минимальный. 

🧑‍💻 Для кого: дата-инженеры, аналитики, руководители дата-отделов.

📅 Когда? 23 июня 11:00 мск.

📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

🎥Как управлять расходами в облаке и не удивляться счетам

Разберем, как сделать облачные расходы прозрачными с помощью FinOps-инструментов. Вы узнаете, почему важно назначать владельцев ресурсов, как правильно выбирать тариф, выставлять автоматические квоты и настраивать алерты, чтобы сократить затраты на 20–30%. Всё — с живым демо в личном кабинете.

🧑‍💻 Для кого: ИТ-менеджеры, DevOps, финансовые директора.

📅 Когда? 25 июня 11:00 мск.

📍 Где?  Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

🎥Эволюция приложения в облаке: как настроить кеш с Redis и ничего не сломать

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

🧑‍💻 Для кого: бэкенд-разработчики, DevOps-инженеры, архитекторы.

📅 Когда? 30 июня 11:00 мск.

📍 Где?  Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

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 и настроить оповещения с защитой от шума.

Установка и использование 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.

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

В Китае запустили первую в мире коммерческую оптоволоконную систему, которая работает сразу в трёх диапазонах длин волн: S, C и L. Обычные магистрали задействуют преимущественно C-диапазон, поэтому одновременное использование трёх окон прозрачности сразу расширяет доступную полосу.

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

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

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

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

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

Источник: https://interestingengineering.com/innovation/worlds-first-three-lane-optical-fiber-network

Представлен открытый проект HTML skills for pragmatic visual artifacts для генерации HTML‑файлов за один клик, включая диаграммы, презентации, резюме, отчёты, планы и прочее:

• html — создает любые HTML‑страницы исходя из задачи: от лендингов до портфолио;

• html‑diagram — создает схемы, планы и диаграммы с фокусом на SVG;

• html‑plan — выкатит вам дорожные карты, планы, стратегии, расписания и многое другое.

Дайджест: новости за май 2026

Рассказываем, что произошло в мае и объясняем, зачем это может пригодиться.

🧠 AI Factory — цифровая среда для работы с генеративным ИИ становится умнее

Evolution Foundation Models — появились новые китайские модели GLM-5.1, Kimi K2.6 и DeepSeek V4 Pro.

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, когда речь снова зайдет про платформу данных и нужно будет показать, что это не «очередная хранилка».

📽️Вебинары

Выложили записи прошедших вебинаров, самое время наверстать, если пропустили: 

• Свой ML-завод: что дает собственная ML-платформа и как ее запустить.

• Антистресс для инфраструктуры: как гарантировать сохранность данных.

• Как эффективно построить потоковый конвейер данных на базе Evolution Data Platform.

💼Свежие кейсы

Рассказали про кейс провайдером сервисов для мобильного аудита Retailiqa. Читайте, если вам актуально «поженить» 152-ФЗ с одинаковой доступностью сервисов из России и из-за рубежа.

На связи! ✌️

О невольной индивидуализации идентифицированных доменов

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

Ну у меня их допустим несколько есть. Но уже при количестве доменов более 30 возникает некоторое недоумение. Почему nic.ru , он же Руцентр, не может сверить данные владельца доменов со столь недружественно не прошедшего аккредитацию продавца со своими и предложить регистрацию на уже существующий с nic.ru договор?

Я задал этот вопрос техподдержке nic.ru и она его обдумывает уже вторую неделю, не отвечая ни на письма по этому поводу, ни на сам тикет.

Второй забавный нюанс -- на каждый домен nic.ru прислал мне отдельное письмо с требованием идентификации. Интересно, а сколько писем они послали массовым регистраторам доменов? Им тоже по-одному домену на договор будут открывать?

Запустили мониторинг сервисов

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

Если что-то пойдет не так, вы сразу получите уведомление на почту, в Телеграм или Макс. О восстановлении — тоже.

Что можно мониторить:

Сайты и веб-приложения. Интернет-магазин упал ночью — узнаете сразу, а не утром по потерянным заказам.

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

TCP-порты сервисов — базы данных, почта, API. База перестала отвечать — увидите до того, как приложение начнет спамить юзеров ошибками.

SSL-сертификаты. Продлите сертификат заранее — пока пользователи не заметили в браузере предупреждение о небезопасном соединении.

Проверки идут из нескольких регионов — без ложных алертов из-за временных сетевых сбоев.

Бонусом: история инцидентов по каждому сервису, дашборд с аптаймом, настройка интервала и таймаута, пауза без потери настроек. Подробнее в документации →

Стоимость — 30 ₽ в месяц за сервис, списания почасовые.

Подключить мониторинг →

Совместимость есть. А что дальше?

«Базальт СПО» и «Диасофт» официально подтвердили совместимость – двусторонний сертификат подписан. Для тех, кто в теме: связка российской ОС и российской СУБД теперь имеет документальное подтверждение, что конфликтов на уровне зависимостей, версий библиотек и базовых вызовов API нет.

Но если вы инженер, вы знаете: «совместимо» ≠ «будет летать».

Что даёт этот сертификат на практике

Digital Q.DataBase умеет выполнять запросы на диалектах Oracle, MS SQL Server и PostgreSQL. Это ключевая фича: код прикладного ПО переписывать не нужно. Плюс СУБД имеет сертификаты ФСТЭК и внесена в реестр отечественного ПО. Неплохо, да?

«Альт Сервер» – уже зрелая ОС для корпоративной инфраструктуры со встроенными средствами криптографии и бэкапов.

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

Но есть нюанс, который не напишут в пресс-релизах

Совместимость гарантирует, что база запустится и SQL-запросы выполнятся корректно. А вот с какой скоростью – зависит от дефолтного тюнинга. Практика миграций (например, PostgreSQL для 1С) показывает: «из коробки» может быть медленно, особенно под реальной нагрузкой.

Digital Q.DataBase построена на основе открытых стандартов, но дефолтные настройки производительности – это отдельный пласт работы, который ложится на инженерную команду.

Что имеет смысл проверить до прогона в прод

Не ограничивайтесь формальным «сертификат есть». Перед внедрением такой связки стоит проверить несколько вещей:

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

• Поддерживаемые версии компонентов. Не каждая версия ОС совместима с конкретной версией СУБД.

• Стратегию обновлений и отката. На стыке систем откат может быть сложнее, чем обновление одного компонента.

• Резервное копирование и восстановление. Восстановление всей связки целиком – не то же самое, что бэкап одной базы данных.

• Зависимости для критичных сервисов. Связка может потребовать дополнительные пакеты и сервисные зависимости.

Резюмирую для технических руководителей

Сертификат совместимости – это точка опоры. Он снимает вопрос «а заработает ли вообще?» и упрощает согласование с безопасниками и закупщиками. Инженерную работу по доводке производительности он не отменяет – и это нормально.

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

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

Больше про российский ИТ без простоев – в телеграм-канале.