🏃‍♂️ Эксплуатацию вспоминают слишком поздно

Во многих инфраструктурных проектах фокус смещён на момент сдачи. На отчёт. На приёмку. На «чтобы запустилось».

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

🔴зоны ответственности уже зафиксированы;
🔴логика реакции «как-нибудь потом»;
🔴удобство обслуживания не было критерием выбора.

В результате система формально соответствует ТЗ, но в реальности оказывается:

⏺сложной в управлении;
⏺хрупкой при сбоях;
⏺дорогой в поддержке.

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

♾️И это всегда проявляется одинаково: проект закрыт, система работает — а первый серьёзный инцидент превращается в ручной режим и хаос. Если эксплуатация не участвовала в архитектуре, она потом участвует в аварии.

В четверг покажем, как понять, что эксплуатацию не встроили в проект — по простым признакам, которые обычно игнорируют💡

🔗 WIZARD 🔗

❓ Как понять, что эксплуатацию не встроили в проект

Есть несколько признаков, по которым это видно почти сразу — даже если система формально работает и «проблем пока нет».

1️⃣ Управление начинается только в аварии

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

Это означает, что сценарии жизни и отказов не были частью архитектуры. Их заменили надеждой, что «как-нибудь справимся».

2️⃣ Устойчивость держится не на системе, а на людях

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

Эксплуатация в таких проектах не управляет системой — она компенсирует её слабые места личным опытом и вниманием.

3️⃣ После инцидентов ничего не меняется по сути

Разборы есть. Выводы формулируются. Контроль усиливается. Но сама архитектура остаётся прежней.

Потому что менять её сложно, дорого и «уже не в рамках проекта». А значит следующий инцидент — не вопрос «если», а вопрос «когда».

Эксплуатация не ошибается. Она просто сталкивается с решениями, принятыми без неё.

Если эксплуатация не участвовала в архитектуре, она неизбежно участвует в аварии📶

🔗 WIZARD 🔗

💽 Ленточные накопители: почему к ним возвращаются

Интерес к ленточным накопителям сегодня растёт не из-за ностальгии. Во многих инфраструктурах пересматривают подходы к хранению данных — в том числе из-за изменившихся условий. На этом фоне лента всё чаще появляется как предсказуемый инструмент долгосрочного хранения.

📦 Проблема в другом. Ленточные накопители нередко внедряются реактивно — как быстрый ответ на внешние ограничения, а не как продуманная часть архитектуры хранения.

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

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

Лента остаётся сильным инструментом. Но только если понимать, когда она действительно работает.

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

🔗 WIZARD 🔗

💽 Ленточные накопители: что важно учитывать при выборе

Ленточное хранение выбирают не «про запас» и не как замену дискам, а под конкретные задачи и сроки хранения данных.

Чтобы лента действительно работала, важно понимать несколько базовых вещей🔤

1️⃣ Формат и поколение лент

В большинстве корпоративных решений используются ленты LTO (Linear Tape-Open). Одно из их ключевых преимуществ — долгая межпоколенная совместимость,
что и делает ленту подходящей для архивов на 10–15 лет.

Каждое поколение LTO отличается:
— ёмкостью одной ленты;
— скоростью последовательной записи и чтения;
— сроком активной поддержки оборудования.

Поколения обновляются в среднем раз в 2–3 года, при этом приводы обеспечивают обратную совместимость. Например, привод LTO-5:
— записывает на ленты LTO-5 и LTO-4;
— читает LTO-5, LTO-4 и LTO-3.

Однако начиная с LTO-10, эта логика меняется. Из-за резкого увеличения ёмкости (более чем в два раза по сравнению с предыдущим поколением) обратная совместимость с более ранними лентами отсутствует.

2️⃣ Скорость записи и чтения

Скорость работы с лентой измеряется в мегабайтах в секунду и у современных приводов может достигать 300–400 МБ/с.

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

Поэтому лента лучше всего подходит для больших объёмов данных, записываемых последовательно.

3️⃣ Ёмкость и плотность записи

Производители указывают:
— нативную ёмкость ленты;
— ёмкость «со сжатием».

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

Хорошая практика — считать объёмы без сжатия и закладывать запас на рост данных.

4️⃣ Ресурс и условия хранения

Ленточные носители рассчитаны на долгий срок, но при соблюдении условий хранения.

Критичны:
— температура и влажность;
— аккуратная транспортировка;
— ограничение количества полных проходов ленты.

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

5️⃣ Эксплуатация и ответственность

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

Люди в организации меняются — архивы и данные остаются.

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

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

Проектирование таких систем требует специализированной экспертизы и практического опыта. У нас он есть❗️

🔗 WIZARD 🔗

😶 Наследие, о котором не говорят

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

⚠️ Проблема в том, что в инфраструктуре «работает» — не равно «безопасно», «масштабируемо» или «управляемо».

Чаще всего это:

🙅‍♂️ старые сервисы, которые никто не решается отключить;

🙅‍♂️ промежуточные серверы без понятного владельца;

🙅‍♂️ системы, к которым «лучше не прикасаться»;

🙅‍♂️ устаревшие версии ПО, живущие вне общего контура обновлений.

Они не создают инциденты каждый день. Они просто существуют — как часть ландшафта. И постепенно становятся инфраструктурным наследием.

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

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

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

🗣В следующем посте разберём, по каким признакам можно определить, что «работает» уже давно перестало означать «контролируется».

🔗 WIZARD 🔗

🔎Что в вашей инфраструктуре работает слишком давно?

По отраслевой статистике (Gartner, ISACA), до 60% критических инцидентов в крупных ИТ-средах связаны не с новыми внедрениями, а с устаревшими компонентами и неучтёнными зависимостями.

Риск возникает не из-за возраста, а из-за отсутствия контроля. Вот признаки, которые стоит проверить:

1️⃣ Нет регулярной оценки состояния
Формально ответственные назначены, но нет процедуры пересмотра роли компонента в текущей архитектуре. Часто такие элементы:
⏺работают на устаревших версиях ОС или middleware;
⏺исключены из общего контура обновлений и патч-менеджмента;
⏺не включены в централизованный мониторинг или резервное копирование.

2️⃣ Невозможно быстро оценить последствия изменений
Если нельзя оперативно ответить:
⏺какие системы зависят от элемента;
⏺что произойдёт при его отключении или обновлении
То это уже зона риска.

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

3️⃣ Его избегают менять
Фраза «лучше туда не лезть» — индикатор накопленного технического долга.

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

4️⃣ Он критичен, но не отражён в стратегии
Компонент участвует в важных процессах, но не включён в планы модернизации и бюджеты обновлений.

Технически это часто выражается в том, что:
⏺узел остаётся единственной точкой отказа;
⏺не предусмотрено резервирование или кластеризация;
⏺отсутствует план миграции на актуальную архитектуру.

🛡 Инфраструктурное наследие опасно не возрастом. Оно опасно тем, что выпадает из поля регулярного анализа.

Если элемент не входит в стратегию развития, но влияет на бизнес-процессы, это уже повод для внимания.

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

➡️ Подробнее о комплексных инфраструктурных решениях - в нашем портфолио.

🔌 Как один «умный» кабель может создать проблемы всей сети

Иногда причиной сетевых проблем становится не авария в ЦОДе, не отказ оборудования и даже не ошибка администратора. Иногда всё начинается с обычного патч-корда и «изобретательности» пользователей.

Типовой сценарий выглядит довольно буднично:

Сотруднику не хватает портов — под столом появляется маленький неуправляемый свитч.
Кто-то подключает свой Wi-Fi-роутер «чтобы интернет был быстрее».
Иногда на свободный порт просто ставят неизвестное устройство — «временно проверить».

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

⏺️ в сети появляется несанкционированный DHCP-сервер
⏺️ рабочие станции начинают получать неправильные IP-адреса
⏺️ трафик может перенаправляться через чужое устройство
⏺️ возникают нестабильности в работе сервисов и телефонии

📉Для пользователей это выглядит одинаково:
системы работают нестабильно, интернет «пропадает», а мониторинг показывает сразу несколько странных симптомов.

❗️ И такие ситуации происходят даже в современных инфраструктурах. Причина обычно не в оборудовании, а в том, что пользовательские порты остаются слишком «открытыми».

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

🔒 DHCP Snooping — позволяет блокировать несанкционированные DHCP-серверы.
🔒 Port Security — ограничивает количество и тип устройств, которые могут подключаться к порту.
🔒 Отключение неиспользуемых портов — чтобы исключить случайные подключения.

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

🔒Какие настройки реально защищают сеть от «самодеятельности»

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

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

Ниже — минимальный набор, который должен быть включён в любой корпоративной сети⏩

1️⃣Контроль DHCP (DHCP Snooping)

Позволяет исключить появление «левых» DHCP-серверов в сети.

Если кто-то подключит свой роутер или устройство с включённым DHCP — он просто не начнёт раздавать адреса.

📌 Результат: пользователи всегда получают корректные IP и не «прыгают» по сети.

2️⃣Ограничение устройств на порту (Port Security)

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

Например:
— 1 MAC-адрес — рабочее место
— 2 MAC-адреса — ПК + IP-телефон

Любая попытка подключить «ещё что-то» — блокируется.

📌 Результат: под столом не появляется «мини-свитч на 5 человек».

3️⃣Отключение неиспользуемых портов

Самая простая, но часто игнорируемая мера.

Свободный порт = потенциальная точка подключения любого устройства.

📌 Результат: исключаются случайные и несанкционированные подключения.

4️⃣Базовый мониторинг

Storm-control, отслеживание аномалий, уведомления.

📌 Результат: проблема фиксируется сразу, а не через час жалоб пользователей.

🔎 Кейс из практики

В одном офисе пользователи начали периодически «терять интернет». Не у всех — только в отдельных зонах. Симптомы плавающие: то работает, то нет.

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

Один из сотрудников подключил свой Wi-Fi-роутер, чтобы «раздать интернет на переговорку». На роутере был включён DHCP.

В результате часть устройств начала получать IP-адреса не из корпоративной сети, а от этого роутера.

После включения DHCP Snooping ситуация полностью исчезла.

💡 И здесь важный момент.

Все эти настройки — не про «усложнение сети». Они про контроль и предсказуемость.

❗️Устойчивость сети определяется не моделью коммутатора, а тем, насколько дисциплинирована работа с портами и доступом.

❄️ Как один кондиционер перегрел серверную

В серверных редко «ломается всё сразу». Гораздо чаще проблема возникает там, где «всё вроде работает».

Типовой сценарий:
Есть два кондиционера. Днём всё стабильно. Ночью один из них отключается по таймеру.

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

🔥 Температура растёт постепенно, но последствия — резкие:

⏺ серверы начинают снижать частоту CPU (thermal throttling)
⏺ увеличивается время отклика приложений
⏺ пользователи чувствуют «тормоза», хотя «ничего не падало»

📉 На практике это выглядит как деградация, а не авария. И именно поэтому такие кейсы часто ищут дольше всего.

❗️ Ключевой момент:
проблема не в мощности системы охлаждения, а в логике её эксплуатации.

📌 Один из реальных кейсов: в серверной было установлено три кондиционера, но в постоянной работе находились только два — третий считался резервным.

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

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

Проблема не в количестве кондиционеров — в балансе тепловыделения и архитектуре энергоснабжения.

🗓 В следующем посте — разберём, какие ошибки в охлаждении встречаются чаще всего и почему даже «правильная» инфраструктура перегревается.

📗 3 ошибки охлаждения, которые встречаются почти в каждой серверной

После первого перегрева обычно делают вывод: «не хватает мощности». И начинают добавлять кондиционеры.

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

❌ Воздух «гуляет» как попало
Холодный и горячий потоки смешиваются. Кондиционер работает, но охлаждает сам себя.

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

❌ Датчики стоят “для галочки”
Измерение ведётся не там, где реально горячо. Система считает, что всё нормально.

❌ Перегруженные стойки
В одну стойку ставят всё подряд. Локальная плотность мощности растёт — охлаждение не справляется.

Кейс:
после обычной перестановки стоек температура в одной зоне понизилась на ~10°C, хотя кондиционеры работали без изменений.

Система не изменилась. Изменилась логика потоков.

🔥 И этого оказалось достаточно.

⚠️ Резервирование, которое не работает

На схеме всё выглядит надёжно.
Два сервера.
Два блока питания.
Два канала связи.

❗️ Кажется, что отказоустойчивость учтена. Но при разборе выясняется: всё это резервирование сходится в одной точке.

⏺ оба сервера подключены к одному коммутатору
⏺ питание заведено через один ввод
⏺ стойка одна
⏺ гипервизор один

И в этот момент система перестаёт быть резервируемой. Она просто дублирует элементы внутри одной зоны риска.

📌Кейс из практики:
отказ одного коммутатора — и оба узла кластера одновременно недоступны.
Формально резерв есть. По факту — единая точка отказа.

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

И чаще всего ломается оно не в очевидных местах. А там, где «и так должно работать».

➡️ В следующем посте — разберем, где именно в инфраструктуре чаще всего прячутся такие точки.

⚠️ Где прячутся точки отказа (даже если у Вас «всё зарезервировано»)

В прошлом посте — показали, как резерв может оказаться иллюзией. Теперь — где это ломается чаще всего.

Не на уровне серверов. Глубже.

1️⃣ Сеть

Два сервера → один коммутатор Два канала → одна трасса

📌 Формально: отказоустойчивость
📌 Фактически: один сбой = минус всё

2️⃣ Питание
Два блока питания → один ввод. Или один ИБП

📌 На схеме: резерв
📌 В реальности: одна точка входа

3️⃣ Виртуализация
Кластер есть Но:
— общее хранилище одно
— гипервизор единый контур управления
— сеть управления без разделения

📌 Отказ не железа, а слоя управления — и падает всё сразу

4️⃣ Размещение
Обе ноды:
— в одной стойке
— в одном зале
— за одной системой охлаждения

📌 Любая авария уровня помещения = минус весь «кластер»

5️⃣ Управление и доступ
Один администратор
Один контур доступа
Один VPN

📌 Иногда SPOF — это не железо, а люди и процессы

💡 Ключевой принцип:

Резерв считается не по количеству компонентов. А по независимости контуров.

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

👉 Это не резерв. Это дублирование риска.

📌 Быстрый тест для любой схемы:

Задайте вопрос: «Если выйдет из строя вот это — что перестанет работать?»

Если ответ: «всё сразу» — точка отказа найдена.

🔐 Бэкапы есть. Восстановления нет

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

Из практики. Производственная компания, ~150 ВМ, ERP и склад. Произошёл сбой СХД. По регламенту RTO — 4 часа.

Что по факту:
⏺ старт восстановления — только через 6 часов (искали актуальные копии)
⏺ 30% бэкапов не читаются (ошибки в каталоге)
⏺ ключи шифрования от части копий — неактуальны
⏺ полное восстановление заняло ~38 часов

Простой производства — около 2 суток. Потери — >12 млн ₽.

Формально бэкапы были. Реально — системы не было.
Это не исключение, а типовая картина. Потому что бэкап часто воспринимается как процесс хранения, а не как инструмент восстановления.

❗️ Факт: бэкап без теста восстановления — это просто архив, которому вы доверяете вслепую.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для ИТ это выглядит как случайный сбой или перезапуск отдельных узлов, хотя формально «питание не пропадало».

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

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

В результате оборудование не «падает сразу», а начинает деградировать: отваливаются сервисы, появляются нестабильные узлы.

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

4️⃣ Неправильное распределение нагрузки
Один ввод перегружен, второй простаивает. В момент переключения система ведёт себя непредсказуемо.

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

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

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

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

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

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

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

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

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

📍 Кейс: В процессе переключения резервного питания происходила рассинхронизация фаз, что вызывало сбои в работе нескольких серверов.

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

📍 Кейс: В одном проекте перегрев вводов стал причиной деградации работы серверов под нагрузкой.

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

📍 Кейс: Один ввод был перегружен, другой простаивал, что привело к сбоям в работе серверов в момент переключения.

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

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

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

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

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

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

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

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

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

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

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

Подробнее — на сайте ⬅️

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

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

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

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

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

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

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

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

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

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

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