...я Дима Пирогов, руковожу финтех-направлением Яндекса. ... Мы очень ценим, что даже в такой сложный момент вы остаётесь с нами. Вернёмся к вам с новостями, как только сможем. Дима
Ну ок, уже давно в некоторых корпорациях, по имени отчеству мало кого называют - не принято. Но полные имена, как правило остаются (если ты не близко знаком с человеком)
Но вот здесь: - человеку почти 40 лет; - официальный пресс релиз компании с миллиардным оборотом; - человек, руководитель высшего звена; - а он все Дима;
Вопрос то не в нем лично, это сообщение писала пресс служба.
Чего хотели добиться ? Варианта "в этот сложный час мы с вами, и у нас тоже есть имена: Ваня, Саша, Лена, Коля, Дима, Оля." вызвать сопричастность ?
К самому пресс релизу вопросов нет, если абстрагироваться что его пишет не Дмитрий, а Дима.
В рамках проекта pg_expecto разработана и внедрена система прогнозирования риска возникновения инцидентов производительности на основе цепей Маркова.
Реализация представляет собой полноценное решение, адаптированное к потоковым данным и способное к самонастройке.
Постановка задачи
Производительность СУБД PostgreSQL подвержена влиянию множества факторов, включая характер нагрузки, состояние операционной системы и внутренние события ожидания.
Традиционные подходы к мониторингу, как правило, реагируют на уже возникшие проблемы, тогда как задача проактивного обнаружения предвестников сбоев требует более глубокого анализа динамики системы.
В основу предлагаемого решения положена идея дискретизации непрерывных метрик производительности в конечное множество состояний, переходы между которыми описываются марковским процессом. Это позволяет моделировать эволюцию состояния системы во времени и оценивать вероятности неблагоприятных исходов.
Формализация состояния системы
Непрерывные метрики – операционная скорость, время ожиданий и корреляция между ними – преобразуются в дискретное пространство из 189 состояний.
Каждое состояние характеризуется тремя параметрами:
коэффициентом корреляции (21 градация от –1,0 до +1,0 с шагом 0,1),
трендом операционной скорости
трендом времени ожиданий (каждый принимает значения –1, 0, +1).
Такая дискретизация обеспечивает баланс между детализацией модели и вычислительной эффективностью.
Архитектура системы
Система построена по многослойному принципу:
Слой данных
Включает таблицы:
хранения переходов (transition_log)
накопленных частот (markov_frequencies)
матрицы вероятностей (markov_probabilities)
поглощающей матрицы для многошагового прогноза (markov_absorbing).
Отдельно выделены таблицы:
конфигурации (markov_config), справочник состояний (state_descriptions) и динамический список критических состояний (critical_states).
Слой обучения
Реализует пошаговое обновление модели с частотой одна минута.
На каждом шаге выполняются:
получение текущих метрик,
вычисление идентификатора состояния,
логирование перехода,
обновление частот ,
при необходимости, применение забывания.
Слой прогнозирования
Предоставляет функции для оценки риска на заданном горизонте.
Ключевая функция mchain_predict_risk_k_v2 вычисляет вероятность хотя бы одного попадания в критическое множество за k шагов.
Слой оценки
Включает механизмы расчёта достоверности прогнозов и суточных метрик качества.
Обучение модели и адаптивное забывание
Обучение происходит в реальном времени на потоке данных. По мере поступления новых наблюдений обновляются частоты переходов и пересчитываются вероятности. Ключевой механизм, обеспечивающий адаптацию к изменению характера нагрузки, – забывание.
Коэффициент забывания α определяет скорость, с которой устаревающие наблюдения теряют вес.
где days_since_last_incident – время, прошедшее с последнего попадания в критическое состояние.
Такой подход позволяет ускорить забывание после инцидентов и замедлить его в стабильные периоды. Дополнительно введён stability_factor, корректирующий α в зависимости от нестабильности вероятностей.
Важным условием применения забывания является достаточность накопленных данных. Функция mchain_check_sufficiency проверяет, что общее число переходов превышает порог min_transitions_for_forgetting (по умолчанию 5000).
Прогнозирование риска
Прогноз риска строится на основе текущего состояния системы и матрицы вероятностей переходов. Для одношагового прогноза используется прямая сумма вероятностей перехода в критические состояния.
Многошаговый прогноз (mchain_predict_risk_k_v2) реализует итеративное умножение вектора распределения вероятностей на матрицу переходов. На каждом шаге вероятности, попавшие в критические состояния, накапливаются в значении риска, а затем обнуляются, чтобы исключить учёт повторных попаданий. Горизонт прогноза задаётся параметром forecast_horizon_minutes в конфигурации (по умолчанию 30 минут).
Сформированные прогнозы сохраняются в таблицу prediction_log. По истечении горизонта выполняется обновление фактических исходов: для каждого прогноза определяется, произошёл ли переход в критическое состояние в течение заданного интервала.
Оценка качества и достоверности
Для оценки качества прогнозов предусмотрен комплекс метрик:
ROC-AUC – площадь под ROC-кривой, характеризующая дискриминационную способность модели.
Достоверность прогнозов оценивается рейтингом от 0 до 5 на основе трёх факторов: общего числа переходов, стабильности вероятностей и покрытия частых состояний.
Профилирование нагрузки (версия 14)
Начиная с версии 14, система дополнена модулем профилирования нагрузки.
Этот модуль позволяет:
Сохранять оперативные (за последние 60 минут), суточные и недельные профили производительности.
Строить эталонные профили на основе исторических данных с исключением инцидентных окон.
Обнаруживать аномалии путём сравнения текущих профилей с эталонными.
Анализировать связь между отклонениями профилей и возникновением инцидентов.
Функция compare_profiles выполняет сравнение текущего профиля с эталонным, вычисляя JS-дивергенцию гистограмм состояний и формируя статус (NORMAL, WARNING, CRITICAL).
Результаты сохраняются в журнал profile_comparison_log, что позволяет проводить ретроспективный анализ.
Историческое обучение
Для первоначального построения модели предусмотрена процедура mchain_initial_train_from_history, которая обучает цепь Маркова на исторических данных, имитируя пошаговое обучение.
Это позволяет развернуть систему на основе уже накопленных метрик без необходимости ждать накопления данных в реальном времени.
Заключение
Представленная реализация цепи Маркова представляет собой законченную систему прогнозирования риска инцидентов производительности, интегрированную в экосистему pg_expecto.
Ключевые преимущества системы:
работа в реальном времени с низкой задержкой;
адаптация к изменению характера нагрузки благодаря механизму забывания;
гибкая настройка горизонта прогноза и параметров обучения;
встроенные механизмы оценки качества и достоверности;
Комплекс с открытым исходным кодом объединяет нагрузочное тестирование, корреляционный анализ событий ожидания и интеграцию с нейросетями.
Сообщество разработчиков и администраторов PostgreSQL получило мощное обновление инструментария для анализа производительности. Команда разработчиков под руководством Рината Сунгатуллина (kznalp) представила релиз версии 7 комплекса pg_expecto — свободно распространяемого решения для глубокого статистического анализа и нагрузочного тестирования СУБД PostgreSQL .
В то время как многие инструменты лишь констатируют факт наличия проблемы, pg_expecto отвечает на вопрос «почему?» и, что важнее, «что делать дальше?». Отличительной чертой комплекса является его методологическая основа: он заменяет устаревшие эмпирические правила (вроде пресловутой настройки shared_buffers = 25% RAM) на точные математические расчеты и воспроизводимые эксперименты .
От мифов — к цифрам: ВКО и проактивный подход
Ключевое новшество, реализованное в методологии комплекса — «Взвешенная корреляция ожиданий (ВКО)» . Этот показатель позволяет администраторам больше не гадать, какой из десятков типов ожиданий (wait events) является корнем проблем.
ВКО ранжирует проблемы по шкале от 1 до 5, отвечая на вопрос: «Какой тип ожиданий (IO, IPC, LWLock) является доминирующим и стабильным фактором, определяющим нагрузку на систему?» . Это позволяет мгновенно отсеять статистический шум и сфокусироваться на критических узких местах.
Более того, pg_expecto позволяет перейти от реактивного подхода к проактивному мониторингу. Инструмент рассчитывает индикатор деградации производительности, анализируя угол наклона линии регрессии операционной скорости и ожиданий. Если скорость падает, а ожидания растут — система генерирует оповещение об инциденте еще до того, как пользователи начнут жаловаться на тормоза .
Что внутри коробки: возможности pg_expecto v.7
Комплекс предоставляет администратору «единый источник истины» (Single Source of Truth), объединяя метрики на уровне СУБД и операционной системы .
Всесторонний статистический анализ: Глубокий анализ событий ожидания (wait_event_type/wait_event) и их корреляции с производительностью .
Интеграция с ОС: Выход за пределы СУБД. pg_expecto использует утилиты vmstat и iostat для прямой привязки нагрузки на диск, память и CPU к поведению базы данных . Это позволяет, например, увидеть корреляцию между ожиданиями IO и загрузкой дисковой подсистемы .
Встроенное нагрузочное тестирование: Возможность проводить тесты с различными сценариями (Select only, Inser , Update) и сразу получать структурированные отчеты .
Экспорт отчетов: Автоматическое формирование данных для построения графиков и диаграмм Парето в Microsoft Excel, что упрощает подготовку отчетности для руководства .
Интеграция с нейросетями (v.7): Новейшая версия автоматически подготавливает промпты для анализа статистически обработанных метрик с помощью больших языковых моделей (таких как DeepSeek). Нейросеть получает не «сырые» логи, а уже обработанные статистические данные (медианы, корреляции, тренды), что позволяет ей формировать экспертные выводы и рекомендации, избегая информационного шума .
Экспериментальное подтверждение: Разрушение мифов
Возможности pg_expecto подтверждены серией практических экспериментов. В одном из последних исследований с использованием pg_expecto был наглядно разрушен миф о магических 25% RAM для shared_buffers .
Эксперименты показали, что при увеличении shared_buffers бутылочное горлышко смещается: дисковая подсистема перестает быть проблемой, но на смену приходит ожесточенная конкуренция за CPU и внутренние блокировки (LWLocks). pg_expecto позволил зафиксировать момент, когда дальнейшее увеличение параметра не только перестает давать прирост, но и начинает вредить производительности из-за возросших накладных расходов на синхронизацию .
Другие эксперименты, проведенные с использованием инструмента, показали, как избыточное индексирование может увеличить ожидания по легковесным блокировкам (LWLock) более чем на 50%, а также позволили математически точно сравнить эффективность различных вариантов написания SQL-запросов (JOIN против EXISTS) .
Как начать работу
pg_expecto распространяется через репозитории на GitHub . Для работы комплекса требуются предустановленные расширения PostgreSQL pg_stat_statements и pg_wait_sampling, а также утилиты vmstat и iostat .
Процесс установки автоматизирован с помощью скрипта pg_expecto_install.sh, а мониторинг работоспособности ведется через лог-файл /postgres/pg_expecto/sh/pg_expecto.log .
Голос сообщества
«В мире администрирования PostgreSQL данные об ожиданиях являются ключевым источником диагностики, — отмечает сообщество на профильных ресурсах. — Однако отдельные метрики без аналитической обработки создают лишь информационный шум. pg_expecto с его методом ВКО превращает данные в четкий план действий, ранжируя проблемы по критичности» .
Комплекс pg_expecto v.7 уже доступен для скачивания. Для обратной связи и обсуждения результатов разработчик приглашает в Telegram-канал и Дзен .
Преодоление предела: почему традиционные методы оптимизации бессильны против высокой параллельности и что приходит им на смену.
Результаты новых исследований указывают на необходимость создания отдельного направления по оптимизации параллельных процессов в СУБД PostgreSQL
Казань, 21.11.2025 – По результатам серии экспериментов, проведенных, был выявлен фундаментальный пробел в современных методологиях оптимизации производительности систем управления базами данных (СУБД). Установлено, что традиционные паттерны и методики оптимизации демонстрируют резкое снижение эффективности или полную неприменимость в средах с высоким уровнем параллельной обработки транзакций.
Эмпирические данные свидетельствуют о том, что при значительной конкурентной нагрузке, когда множество процессов обращаются к данным одновременно, классические подходы, такие как тонкая настройка отдельных запросов или индексация, оказываются недостаточными. Вместо ожидаемого линейного роста производительности наблюдаются нелинейные эффекты, включая интенсивную борьбу за ресурсы (contention), блокировки (locks) и деградацию общей пропускной способности системы.
На основании полученных результатов был сделан вывод о назревшей необходимости системного пересмотра принципов анализа и оптимизации СУБД. Для обеспечения устойчивой работы высоконагруженных информационных систем на базе СУБД PostgreSQL требуется выделение и глубокая проработка нового специализированного подраздела, посвященного исключительно оптимизации параллельных процессов (Parallel Processes Optimization).
Введение данной дисциплины предполагает фокусировку на таких аспектах, как:
Анализ и минимизация конфликтов блокировок на уровне строк и таблиц.
Оптимизация работы планировщика задач и управления памятью в условиях высокой конкуренции.
Разработка специализированных метрик для диагностики узких мест, специфичных для параллельной работы.
Создание рекомендаций по проектированию схемы данных и логики приложений, ориентированных на параллелизм.
Этот шаг является закономерным ответом на вызовы, связанные с ростом объемов данных и требований к масштабируемости современных приложений. Новая парадигма оптимизации позволит вывести управление производительностью СУБД PostgreSQL на качественно новый уровень, обеспечивая стабильность и эффективность в высокопараллельных средах.
ℹ️ Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic и GitHub
Новая версия выводит продукт на качественно новый уровень, превращая его из мощного инструмента диагностики в интеллектуальную систему прогнозирования и автоматизированной оптимизации.
Ключевые инновации версии 3.0:
1. Проактивный мониторинг и автоматизация реагирования
Вместо того чтобы пассивно ждать появления проблем, PG Expecto 3.0 теперь активно предотвращает их.
Система научилась формировать репрезентативные профили производительности на основе стандартизированных файлов метрик. Это позволяет создать «цифровой двойник» вашей СУБД в ее оптимальном состоянии.
Как это работает? Любое отклонение ключевых метрик от установленного профиля теперь автоматически регистрируется как событие снижения производительности.
Автоматизация инцидентов: Данное событие служит триггером для автоматического создания инцидентов в ваших системах мониторинга (например, в Zabbix, Grafana Labs). Система самостоятельно классифицирует критичность и инициирует стандартные или приоритетные процедуры реагирования, значительно сокращая время на обнаружение проблемы (MTTD).
2. Интеграция с нейросетями для семантического анализа и оптимизации запросов
Самая передовая функция PG Expecto 3.0 — это встроенный «мозг», который помогает не только найти проблему, но и понять пути ее решения. Мы реализовали автоматическую интеграцию с современными языковыми моделями (такими как GPT, Claude и аналогичными).
Автоматическое конструирование контекста: Система автоматически генерирует детализированные и структурированные промпты (вводные инструкции) для нейросети. В них входит вся необходимая информация: от проблемных SQL-запросов, выявленных методами корреляционной аналитики, до контекста выполнения и метрик СУБД.
Семантический анализ рекомендаций: Нейросеть получает идеально подготовленные данные и выдает готовые, понятные рекомендации на естественном языке.
Это позволяет: Минимизировать задержки обработки: Получать конкретные советы по настройке параметров PostgreSQL, индексов и архитектуры. Улучшать структуру сложных SQL-запросов: Нейросеть проводит семантический разбор запросов, предлагает варианты рефакторинга, оптимизации JOIN'ов и конструкций WHERE, объясняя логику своих предложений.
Резюме для администраторов и разработчиков:
С выходом PG Expecto 3.0 работа с производительностью PostgreSQL становится проще, быстрее и интеллектуальнее. Вы получаете не просто инструмент с графиками, а проактивного помощника, который сам находит аномалии, создает тикеты и, с помощью интеграции с ИИ, дает вам готовые, обоснованные решения для их устранения.
Это следующий шаг к полностью автономной и самооптимизирующейся системе управления базами данных.
Представлен комплекс pg_hazel "Орешник": революционные know-how для предиктивного анализа и обеспечения высокой доступности PostgreSQL
📅 Дата публикации: 17 сентября 2025 года
📍 Место: Россия
Разработчики проекта pg_hazel "Орешник" (https://dzen.ru/kznalp) представляют уникальный программный комплекс, предназначенный для глубинного мониторинга и анализа производительности высоконагруженных систем управления базами данных (СУБД) PostgreSQL. Решение включает в себя ряд эксклюзивных технологий (know-how), которые радикально меняют подход к обеспечению стабильности и предсказуемости работы критически важных баз данных.
В эпоху, когда простои и лаги в работе БД напрямую влияют на бизнес-показатели, традиционный мониторинг, отслеживающий лишь общие метрики, уже недостаточен. Комплекс "Орешник" предлагает проактивный и корреляционный анализ, выявляя проблемы на стадии их зарождения и точно определяя первопричину.
Ключевые решённые технологические задачи (know-how):
Интеллектуальное удаление выбросов в исходных данных. Алгоритмы "Орешника" автоматически фильтруют аномальные значения, возникающие из-за кратковременных скачков нагрузки или ошибок сбора. Это обеспечивает высокую достоверность исходных данных для последующего анализа и исключает ложные срабатывания.
История изменения метрик производительности и ожиданий. Система сохраняет не только текущее состояние, но и полную историю всех ключевых метрик СУБД (LWLocks, IPC, IO и т.д.) . Это позволяет проводить ретроспективный анализ и точно определять, в какой момент и при каких условиях началась деградация производительности.
Индикатор снижения производительности как стартовое событие для инцидентов. Комплекс в реальном времени вычисляет репрезентативные показатели производительности СУБД. При их отклонении от нормы система автоматически может инициирует процесс создания инцидента в Service Desk, позволяя инженерам начать расследование до того, как проблема отразится на пользователях.
Глубокий сбор статистики по SQL-запросам. Для высоконагруженных систем "Орешник" обеспечивает детальный сбор статистики выполнения ( calls, rows) и ожиданий (wait_event_type, wait_event) для каждого отдельного запроса. Это даёт бесценную информацию для точечной оптимизации самых ресурсоёмких операций.
Статистический анализ метрик ОС (vmstat, iostat). Анализ не ограничивается данными СУБД. Система строит динамические статистические модели по метрикам операционной системы (загрузка CPU, очереди диска, потребление памяти), выявляя аномалии и тренды на уровне всего сервера.
Корреляционный анализ ожиданий СУБД и метрик ОС. Это ключевое ноу-хау комплекса. "Орешник" автоматически находит корреляции между событиями ожидания внутри PostgreSQL (например, ожидание записи на диск) и показателями ОС (например, высокая очередь записи на iostat). Это в разы ускоряет диагностику, позволяя однозначно ответить на вопрос: "Проблема в неоптимальном запросе или в медленном диске?".
Цитата руководителя проекта: «Наш опыт эксплуатации кластеров PostgreSQL под экстремальными нагрузками показал, что стандартные инструменты мониторинга часто показывают лишь следствие, а не причину проблемы. Мы создали "Орешник" как систему, которая мыслит как опытный администратор БД. Она не просто фиксирует факт падения производительности, а предупреждает о нём заранее и сразу выдаёт гипотезу о корневой причине, экономя часы и дни на расследование. Наши know-how в области корреляционного анализа — это настоящий прорыв в предиктивной аналитике для СУБД».
О проекте pg_hazel "Орешник": Проект посвящён разработке и внедрению передовых методов мониторинга, анализа и обеспечения отказоустойчивости кластеров PostgreSQL. Решения проекта основаны на глубоком практическом опыте и предназначены для использования в высокодоступных и высоконагруженных системах, где стабильность работы БД является критически важной для бизнеса.
📅 Дата публикации: 15 сентября 2025 года 📍 Место: Россия
Новая веха в мониторинге и диагностике производительности PostgreSQL
Комплекс PG_HAZEL представляет собой инновационное решение для глубокого анализа производительности СУБД PostgreSQL. Этот инструмент сочетает в себе методы статистического анализа, мониторинга в реальном времени и причинно-следственного моделирования, что позволяет точно определять корневые причины инцидентов производительности и прогнозировать потенциальные сбои.
PG_HAZEL использует методы корреляционного анализа для установления взаимосвязей между:
Метриками ОС (iostat, vmstat, использование CPU, памяти, дискового I/O).
Ожиданиями СУБД PostgreSQL (типы ожиданий IO, IPC, LWLock, и др.).
Тактический и оперативный анализ PG_HAZEL работает на тактическом уровне, анализируя влияние отдельных SQL-запросов на производительность СУБД. Он идентифицирует запросы, которые оказывают наибольшее негативное воздействие, и связывает их с конкретными типами ожиданий (IO, IPC, LWLOCK).
Многомерный анализ производительности PG_HAZEL интегрирует данные из различных источников, включая метрики ОС (iostat, vmstat), события ожидания PostgreSQL и статистику выполнения SQL-запросов. Это позволяет построить единую модель производительности и количественно оценить вклад каждого фактора в общую производительность СУБД.
Планируемое направление развития : причинно-следственный анализ и прогнозное моделирование, визуализация и интерактивные дашборды Используя методы причинности по Грэнджеру и байесовские сети, комплекс поможет выявляет не просто корреляции, а реальные причинно-следственные связи между метриками. Например, он может определить, что рост времени отклика диска (await) вызывает увеличение времени ожидания ввода-вывода в PostgreSQL, что приводит к деградации производительности. Используя методы ARIMA и машинного обучения возможно будет прогнозировать инциденты производительности СУБД PostgreSQL , таких как исчерпание дискового пространства или достижение критической нагрузки на CPU. Это позволит администраторам СУБД заранее принимать превентивные меры. Тепловые карты(heatmaps) корреляций и дашборды, позволят быстро выявлять аномалии и анализировать их в контексте всех метрик.
🚀 Практическое применение
PG_HAZEL уже успешно применяется для анализа инцидентов производительности в реальных условиях.
Кроме того, комплекс используется для нагрузочного тестирования, помогая определить предельные значения нагрузки, которые СУБД может выдержать без деградации производительности. 📈 Преимущества подхода
Раннее обнаружение проблем
Анализ метрик ОС позволяет выявлять потенциальные проблемы до их воздействия на производительность СУБД:
Точное определение корневой причины инцидентов значительно сокращает время восстановления:
Четкое разграничение проблем ОС и проблем СУБД
Возможность фокусирования на реальной причине, а не симптомах
📊 Примеры использования:
1.Рост ожиданий типа IO в PostgreSQL:
В ходе анализа инцидента производительности PG_HAZEL выявил, что наибольшая корреляция наблюдается между ожиданиями типа IPC и снижением операционной скорости СУБД. Это указало на проблему взаимодействия между процессами, что позволило администраторам быстро устранить причину.
2.Рост времени отклика дисков в iostat:
Начало инцидента: Рост утилизации CPU и значений iowait в метриках ОС
Корреляционный анализ: Выявление высокой корреляции между: - Ростом времени ожидания записи для устройств хранения (/data и /wal) - Снижением производительности СУБД - Ростом ожиданий типа IO в PostgreSQL
Заключение: Первичной причиной являлись проблемы на уровне дисковых подсистем
💬 Цитата разработчика
«PG_HAZEL — это не просто инструмент мониторинга, а экспертная система, которая превращает разрозненные метрики в понятные и осуществимые предложения. Наша цель — сделать диагностику производительности PostgreSQL максимально автоматизированной и точной».
🔮 Планы развития
В ближайших планах развития PG_HAZEL — разработка и внедрение методов причинно-следственного анализа и прогнозного моделирования.
📌 О компании
Разработчик PG_HAZEL специализируется на создании решений для мониторинга и анализа производительности СУБД PostgreSQL.
Наша миссия — помогать компаниям поддерживать высокую производительность и надежность их баз данных.
📞 Контакты для СМИ
Для получения дополнительной информации обращайтесь: Имя: Сунгатуллин Ринат Раисович Телефон: +7 927 245 80 49 Email: kznalp@yandex.ru Веб-сайт:https://dzen.ru/kznalp
💎 Заключение
PG_HAZEL устанавливает новый стандарт в мониторинге и диагностике производительности PostgreSQL. Его способность объединять данные из различных источников, выявлять корневые причины проблем и прогнозировать инциденты делает его незаменимым инструментом для администраторов баз данных и IT-специалистов.
Яндекс заключил масштабное соглашение с легендарным российским хоккеистом Александром Овечкиным. В рамках партнёрства спортсмен будет представлять проекты и сервисы компании, а также станет героем эксклюзивных кинопроектов - фильмов и сериалов.
Также в официальном пресс-релизе уточняется, что Плюс Студия (продюсерский центр Яндекса) приобрела права на создание оригинального кинопроекта о жизни хоккеиста. Это может быть как полнометражная адаптация, так и многосерийная драма - окончательный формат пока не определён.
Напомним, что Александр Овечкин начал профессиональную спортивную карьеру в юном возрасте в московском хоккейном клубе "Динамо", а в 2005 году перешёл в НХЛ, где до сих пор выступает за "Вашингтон Кэпиталз". Он неоднократно принимал участие в крупнейших международных состязаниях, выступая за сборную России.
В сезоне 2024/2025 он добился исторического достижения, превзойдя рекорд Уэйна Гретцки по количеству голов в регулярных чемпионатах - 895 шайб. Этот результат считался недосягаемым с 1999 года.
Ожидается, что подробности о съёмках и датах релиза станут известны в ближайшие месяцы. Соглашение о партнёрстве со знаменитым спортсменом заключено сроком на три года.
