Рабочий сервер обслуживает не лампу и не чайник: на нём одновременно могут жить базы данных, 1С, файловые хранилища, почта, виртуальные машины, телефония, облако, очереди обмена и внутренние сервисы. Резкое отключение питания прерывает записи, транзакции и сетевые сессии.
Современные файловые системы и базы данных умеют восстанавливаться после многих сбоев, но журналы транзакций не делают грубое отключение нормальной процедурой. После аварии всё равно нужны проверка целостности, запуск сервисов, анализ ошибок и подтверждение, что данные не повреждены.
- прерываются открытые файлы, транзакции и записи в базы данных;
- виртуальные машины могут завершиться в несогласованном состоянии;
- репликация и очереди обмена получают разрывы и задержки;
- пользователи теряют активные сессии и несохранённую работу;
- после включения требуется проверка, а не простая надежда, что «само поднялось».
ИБП должен не только держать питание несколько минут. Он должен передавать состояние в систему мониторинга: входное напряжение, заряд, нагрузку, время автономии, ошибки батарей и факт перехода на питание от аккумуляторов.
Если автономности недостаточно, серверы и виртуализация должны завершать работу в правильной последовательности: сначала прикладные сервисы и базы, затем виртуальные машины, потом хранилище и физические узлы. Иначе резервное питание только откладывает некорректное выключение.
Надёжность строится не одной покупкой ИБП. Важны помещение, охлаждение, кабели, маркировка, резервные каналы, мониторинг температуры и влажности, контроль доступа, корректное распределение питания и понятный порядок действий при аварии.
Для критичных сервисов нужен риск-ориентированный уровень резервирования: где достаточно N+1, где нужны отдельные линии питания, где нужна репликация или отказоустойчивый кластер, а где достаточно хорошей резервной копии и честного времени восстановления.
- какие сервисы реально остановят бизнес при выключении;
- как серверы подключены к питанию и ИБП;
- есть ли мониторинг ИБП, температуры, дисков, каналов и сервисов;
- как завершаются виртуальные машины и базы при длительной аварии;
- где хранятся резервные копии и как быстро можно восстановиться;
- есть ли документация, маркировка и понятная схема включения после сбоя.
Когда всё спроектировано правильно, серверная не привлекает внимания: сервисы работают, аварии замечаются заранее, обслуживание планируется, а отключение питания не превращается в лотерею. Это дешевле, чем срочно искать оборудование, восстанавливать базы и объяснять клиентам, почему сервис недоступен.
Главная задача — не восстановиться из резервной копии, а не довести инфраструктуру до ситуации, где копия стала единственным шансом вернуть бизнес к работе.
Если серверы уже держат 1С, документы, почту, виртуальные машины или рабочие сервисы, их нельзя обслуживать как бытовое оборудование. Нужны обследование, правильное питание, мониторинг, резервирование и понятная процедура восстановления после аварии.