What are the opening hours?

Monday 10:00 - 19:00 Tuesday 10:00 - 19:00 Wednesday 10:00 - 19:00 Thursday 10:00 - 19:00 Friday 10:00 - 18:00

Компания Wizard, Нижняя 14с2, Moscow (2026)

28/05/2026

⚡️ЭнергоЛига снова собрала тех, кто отвечает за надежность

20 мая состоялось очередное заседание закрытого клуба ЭнергоЛига — профессионального сообщества для тех, кто отвечает за устойчивость ИТ и инженерной инфраструктуры.

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

✅ Открыла встречу Марина Кравченко, коммерческий директор Компании ВИЗАРД. Она рассказала о развитии ЭнергоЛиги, целях клуба и его главной ценности — живом профессиональном диалоге между заказчиками, интегратором и производителями.

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

Отдельный экспертный блок провел Алексей Соловьев, технический директор управления «ИТ-решения» Systeme Electric. Он рассказал о решениях SE для современной ИТ-инфраструктуры:

⏺️ новом поколении однофазных ИБП SmartSave;
⏺️ обновленной линейке трехфазных ИБП, включая Excelente VX мощностью 1200 кВА, Uniprom Base и Uniprom RM;
⏺️ первой российской цифровой стойке UnipromRack Digital;
⏺️ инфраструктурных решениях для ИИ-ЦОД и новых сценариев нагрузки.

🔍 В завершении мероприятия участники посетили демо-зону Systeme Electric, познакомились с новинками оборудования и увидели практические сценарии работы решений.

Спасибо всем участникам за интерес, вопросы и открытый диалог. ЭнергоЛига — это не просто встреча. Это среда, где профессиональный опыт становится общей силой. Двигаемся дальше. Вместе — надежнее 🤝

🔗 Подробнее о заседании клуба — на нашем сайте. Ссылка в комментариях.

14/05/2026

⚙️ Сервис инженерной инфраструктуры— это не просто «приехали, проверили, уехали»

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

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

🔋 ИБП может работать, но батареи уже деградируют.
🌡 Кондиционеры могут быть исправны, но охлаждать не те зоны.
⚡️ Нагрузка может быть в допустимых пределах, но при переключении на резерв возникает перекос.
📊 Мониторинг может показывать норму, но не видеть первопричину будущего сбоя.

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

— Хороший сервис отвечает не только на вопрос: «Что проверили?»
— Он отвечает на главный вопрос: «Что может стать проблемой дальше?»

В новой статье разбираем, почему сервис ЦОД должен быть инженерным инструментом управления рисками, а не формальным ритуалом по чек-листу.

➡️ Читайте материал на сайте: https://wizard.ru/press-center/servis-inzhenernoj-infrastruktury-cod/

07/05/2026

🔋 ИБП есть. А устойчивости нет

Одна из самых опасных иллюзий в инженерной инфраструктуре — считать, что наличие ИБП автоматически означает защиту от проблем с питанием.

Формально всё выглядит правильно: ИБП установлен, оборудование подключено, индикаторы зелёные, аварий нет. Но в реальной ситуации система может не выдержать даже короткую просадку или переключение.

Почему так происходит? Потому что резервное питание — это не коробка в стойке и не строчка в спецификации. Это сценарий. И этот сценарий должен быть рассчитан, проверен и понятен тем, кто будет эксплуатировать систему.

Типовая ситуация: на объекте есть два ввода, ИБП и критичное оборудование. На схеме всё выглядит надёжно. Но при проверке выясняется, что один ввод загружен почти полностью, второй используется минимально, батареи давно не тестировались под реальной нагрузкой, а часть критичного оборудования подключена «как было удобно при монтаже».

Что чаще всего ломает логику резервного питания:

⏺ нагрузка распределена неравномерно между вводами;
⏺ автономия ИБП рассчитана «по паспорту», а не под реальную нагрузку;
⏺ батареи имеют высокую степень деградации;
⏺ не проверен сценарий байпаса и переключений;
⏺ часть оборудования подключена не по проекту и не запитана от ИБП;
⏺ нет понятного регламента: кто, когда и что делает при аварии.

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

ИБП не должен просто «стоять». Он должен закрывать конкретный сценарий: какую нагрузку держит, сколько времени держит, что происходит при переключении, какие системы остаются в работе и кто отвечает за действия в этот момент. Иначе получается классическая ситуация: резерв есть, а устойчивости нет.

В следующем посте разберём, что нужно проверить в системе бесперебойного питания до первой аварии — чтобы ИБП был не просто оборудованием в стойке, а реальной защитой для бизнеса.

29/04/2026

🤖ЦОД для ИИ — это не просто «поставить больше мощных серверов»

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

Он упирается в электроснабжение, охлаждение, распределение нагрузки, размещение оборудования и готовность площадки к совсем другой плотности мощности. По оценкам экспертов, доля ИИ-нагрузок в общем потреблении ЦОДов может вырасти с 8% в 2023 году до 15–20% к 2028 году. В абсолютных значениях — с 4,3 ГВт до 13,5–20 ГВт. И это уже меняет правила проектирования.

Одна стойка с оборудованием под ИИ может потреблять не 8–10 кВт, а десятки и даже более сотни киловатт. Для ИИ-ЦОД сегодня рассматриваются уровни от 40 до 120 кВт на стойку, а в перспективе — 150+ кВт.

❗️Что это означает на практике?

Допустим, компания планирует разместить 20 стоек под ИИ. При плотности 80–100 кВт на стойку это уже 1,6–2 МВт только ИТ-нагрузки. Дальше нужно учитывать охлаждение, резервирование, потери, распределение питания, ИБП, мониторинг, пожарную безопасность и обслуживание.

Именно поэтому ЦОД для ИИ нельзя проектировать как «обычный ЦОД, только мощнее».

Ключевые вопросы появляются ещё до выбора серверов:

⚡️ Достаточно ли доступной мощности на площадке?
🌡 Где проходит граница между воздушным и жидкостным охлаждением?
🔌 Как система питания выдержит кратковременные пики нагрузки?
🏗 Выдержит ли помещение вес оборудования, кабельные линии и инженерные трассы?
🛠 Кто и как будет эксплуатировать такую систему после запуска?

В новой статье Дмитрий Колков, директор департамента проектных решений Компании ВИЗАРД, объясняет, почему ИИ-ЦОД — это не набор серверов с графическими ускорителями, а полноценная инженерная система.

Подробнее — на сайте: https://wizard.ru/?post_type=press-center&p=1850&preview=true&_thumbnail_id=1859

24/04/2026

🔌 Как распознать, что сбой — это не ИТ, а электропитание

Когда серверы «падают» или «тормозят», ИТ ищет причину в своем оборудовании. Но часто причина скрыта в электропитании.

1️⃣ Ошибки в логике переключений (АВР / байпас)
Переключения между вводами питания не всегда отрабатываются под нагрузкой, вызывая рассинхронизацию фаз или кратковременные разрывы.
Статистика: 18% всех аварий в ЦОДах происходят из-за неправильной логики переключений.
📍 Кейс: В процессе переключения резервного питания происходила рассинхронизация фаз, что вызывало сбои в работе нескольких серверов.

2️⃣ Перегретый ввод
Неправильное распределение нагрузки приводит к перегреву одного из вводов, что начинает влиять на стабильность работы оборудования.
Статистика: В 25% случаев перегрев становится причиной отключений оборудования в ЦОДах.
📍 Кейс: В одном проекте перегрев вводов стал причиной деградации работы серверов под нагрузкой.

3️⃣ Неправильное распределение нагрузки
Один ввод перегружен, второй простаивает. При переключении нагрузки это вызывает сбои в работе системы.
Статистика: 22% аварий из-за нагрузки происходят из-за неравномерного распределения нагрузки между вводами.
📍 Кейс: Один ввод был перегружен, другой простаивал, что привело к сбоям в работе серверов в момент переключения.

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

21/04/2026

🤨Почему серверы падают не из-за ИТ

Инфраструктура «зелёная»: виртуализация стабильна, сеть не теряет пакеты, СХД не перегружена. А сервис — падает.

И дальше начинается типовой сценарий: ИТ ищет проблему в ИТ. Хотя причина — не там.

В реальных проектах сбои часто приходят не из серверной, а из электропитания ⚡️

1️⃣ Динамика нагрузки, которую ИБП не держит
На ровной нагрузке всё стабильно. Но при резком росте (запуск, перераспределение, пик транзакций) ИБП не успевает корректно отработать переход — возникает кратковременный провал или «ступенька».

Для ИТ это выглядит как случайный сбой или перезапуск отдельных узлов, хотя формально «питание не пропадало».
2️⃣ Ошибки в логике переключений (АВР / байпас)
Система резервирования есть, но сценарий не отработан под реальную нагрузку.

В момент переключения:
— рассинхронизация фаз
— кратковременные разрывы
— перегрузка одного из вводов

В результате оборудование не «падает сразу», а начинает деградировать: отваливаются сервисы, появляются нестабильные узлы.
3️⃣ Перегретый ввод
Под нагрузкой всё выглядит нормально. На пике начинаются деградации, которые маскируются под «странные ИТ-сбои».
4️⃣ Неправильное распределение нагрузки
Один ввод перегружен, второй простаивает. В момент переключения система ведёт себя непредсказуемо.

Ключевой момент:
ИТ здесь — не источник проблемы. ИТ — первый, кто получает последствия.

Пока команда проверяет гипервизоры и сеть, причина уже повторяется. В крупных инфраструктурах устойчивость — это не только про ИТ.

Это связка:
⏺ электропитание;
⏺ охлаждение;
⏺ распределение нагрузки;
⏺ и только потом — серверы и софт.

Если один слой «плывёт», остальные начинают выглядеть нестабильными.

Хорошая новость: такие проблемы диагностируются быстрее, чем кажется.
Плохая: их редко ищут там, где они реально находятся.

Если ИТ «падает без причины» — причина почти всегда уже вне ИТ. В пятницу разберём, как это распознать на практике 🗓

17/04/2026

📶 Как понять, что модернизация сети упирается не в оборудование, а в СКС

В прошлом посте говорили о ситуации, когда после обновления активного оборудования сеть не даёт ожидаемого эффекта. Для больших площадок и ЦОДов причина чаще не в «плохом кабеле». Причина в другом: активное оборудование обновляется каждые 3–5 лет, а СКС закладывается на 20–30.

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

1️⃣ Активное оборудование готово, СКС — нет
Коммутаторы и серверы поддерживают 25/100G, а существующая среда проектировалась под предыдущий цикл.

2️⃣ Любое изменение превращается в стройку
Оборудование можно заменить за день.
Переделка СКС — это уже месяцы работ, окна, подрядчики и риски для эксплуатации.

3️⃣ Нет запаса под рост 📉
Свободных волокон, портов, резервных трактов или места в кроссах уже недостаточно. Формально сеть работает, но масштабироваться ей уже некуда.

4️⃣ Сроки проекта начинают зависеть не от ИТ ⏳
Решение выбрано, бюджет есть, а сроки съедает подготовка физической среды.

📍 Кейс из практики:
При переходе на новые скорости активная часть была полностью готова.
Но СКС не давала нужного запаса по развитию.
В итоге замену оборудования можно было сделать быстро, а проект сдвинулся на месяцы из-за работ по кабельной системе.

❗️ СКС — это не “дополнение” к оборудованию. Это фундамент, который переживает несколько поколений активки.

Именно поэтому в серьёзных проектах хорошая кабельная система — это не про «сейчас сэкономить», а про то, чтобы через 5–7 лет не тормозить весь проект.

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

15/04/2026

🛜 Когда сеть на 100 Гбит работает на скорости 1

Самая частая иллюзия при модернизации — «мы обновили оборудование, значит стало быстрее». На практике это не так.

Коммутаторы — 100 Гбит, серверы — 25/40 Гбит, бюджеты потрачены. А фактическая скорость остаётся прежней. Иногда даже появляются нестабильности.

Причина почти всегда не в оборудовании. Причина — в кабельной системе.

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

📍 Кейс из практики: после модернизации сети часть сегментов не поднималась выше 1 Гбит. Коммутаторы и серверы работали штатно. Проблема оказалась в унаследованных линиях Cat5e на критичных участках. В результате дорогое оборудование работало в режиме «совместимости назад».

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

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

📶 В следующем посте разберём признаки, по которым можно понять: сеть упирается не в оборудование, а в кабельную систему.

10/04/2026

🔐 Бэкапы есть. А восстановление — проверяли?

В прошлом посте показали кейс, где бэкапы «были», но восстановление заняло 38 часов.

Разберём простой способ проверить ситуацию — без аудитов и долгих тестов.

✅ Метод «одного восстановления» ✅
Не проверяем всё. Проверяем одно — но правильно.

1️⃣ Выберите критичную систему
Не тестовую. Не «какую не жалко».
А ту, простой которой реально стоит денег.

2️⃣ Найдите последнюю резервную копию
И зафиксируйте время, которое уходит на:
⏺ поиск копии
⏺ проверку её целостности
⏺ подготовку к восстановлению

Уже на этом этапе часто теряются часы.

3️⃣ Запустите восстановление (частичное)
Не обязательно поднимать всё. Достаточно:
⏺ развернуть ВМ / БД в изолированном контуре
⏺ убедиться, что система запускается

4️⃣ Ответьте на 3 вопроса
⏺ Сколько времени занял старт восстановления?
⏺ Все ли данные доступны и читаемы?
⏺ Понимает ли команда, что делать без «ключевого человека»?

Если хотя бы на один вопрос нет чёткого ответа — системы нет.

Есть процесс. Есть отчёты. Но нет управляемого восстановления.

💡 Практика показывает: в 7 из 10 случаев проблемы всплывают уже на этапе поиска копии или доступа.

И это хорошая новость. Потому что вы нашли это не в момент аварии.

08/04/2026

В большинстве компаний резервное копирование «есть»: регламент, отчёты, зелёные статусы. Но есть один простой вопрос — вы хоть раз пробовали восстановиться?

Подробнее — https://t.me/wizardcojscgrp/651

Компания Wizard

28/05/2026

14/05/2026

07/05/2026

29/04/2026

24/04/2026

21/04/2026

17/04/2026

15/04/2026

10/04/2026

08/04/2026

Address

Opening Hours

Website

Alerts

Shortcuts

Share

Category

Monday	10:00 - 19:00
Tuesday	10:00 - 19:00
Wednesday	10:00 - 19:00
Thursday	10:00 - 19:00
Friday	10:00 - 18:00