Два сервера сгорели при отключении света: мониторинг UPS для оператора связи

Наши инженеры провели полный аудит серверной. Картина оказалась хуже, чем ожидалось:

Проблемы:

• Нет мониторинга — состояние UPS не отслеживалось вообще, от слова совсем
• Нет автоматического отключения — серверы работали до последнего вольта в батареях
• Изношенные батареи — стойки 1, 2 и 4 требовали замены, причём давно
• Перегрузка — стойки 1, 3, 4 работали на 80%+ мощности; норма — не выше 70%, иначе при просадке напряжения UPS просто не вытянет
• Разнородное оборудование — три разных бренда UPS с разными интерфейсами управления, которые между собой никак не связаны

Унифицировать всё это под одним инструментом не вышло бы — слишком разные интерфейсы. Поэтому мы выбрали два инструмента и распределили роли:

• NUT (Network UPS Tools) — для UPS с USB/Serial-подключением (APC и CyberPower)
• SNMP — для UPS с сетевыми картами (Eaton с предустановленными Network-M2)

Архитектура:

# Архитектура мониторинга UPS
┌──────────────────────────────────────────────────┐
│              Zabbix Server (Стойка 5)             │
│  ┌───────────┐  ┌────────────┐  ┌─────────────┐ │
│  │ Dashboards │  │   Alerts   │  │  Capacity   │ │
│  │   & Maps  │  │ (Telegram) │  │  Planning   │ │
│  └───────────┘  └────────────┘  └─────────────┘ │
└───────┬──────────────┬──────────────┬────────────┘
        │              │              │
   NUT (SNMP)     NUT (USB)     SNMP native
        │              │              │
 ┌──────┴──────┐ ┌─────┴─────┐ ┌─────┴─────┐
 │ APC×3       │ │CyberPower │ │ Eaton×2   │
 │ (USB→NUT)   │ │ (USB→NUT) │ │(SNMP card)│
 └─────────────┘ └───────────┘ └───────────┘

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

NUT-сервер мы развернули на выделенном хосте мониторинга в стойке 5. К нему по USB подключили APC Smart-UPS из стоек 1 и 2, остальные опрашивали по сети:

# Установка NUT на Ubuntu 22.04
sudo apt update
sudo apt install -y nut nut-client nut-server

# Определение подключённых UPS
sudo nut-scanner -U  # Сканирование USB-устройств
# [nutdev1]
#   driver = "usbhid-ups"
#   port = "auto"
#   vendorid = "051D"    # APC
#   productid = "0002"
#   serial = "AS1234567890"

Конфигурация UPS-устройств в /etc/nut/ups.conf:

# /etc/nut/ups.conf

[apc-billing]
    driver = usbhid-ups
    port = auto
    serial = AS1234567890
    desc = "APC Smart-UPS 3000 - Стойка 1 (Биллинг)"
    pollinterval = 5

[apc-bras]
    driver = usbhid-ups
    port = auto
    serial = AS0987654321
    desc = "APC Smart-UPS 3000 - Стойка 2 (BRAS)"
    pollinterval = 5

[apc-media]
    driver = usbhid-ups
    port = auto
    serial = AS1122334455
    desc = "APC Smart-UPS 2200 - Стойка 4 (Медиа)"
    pollinterval = 5

[cyberpower-monitoring]
    driver = usbhid-ups
    port = auto
    serial = CP6677889900
    desc = "CyberPower OL3000 - Стойка 5 (Мониторинг)"
    pollinterval = 5

Настройка режима работы NUT и пользователей:

# /etc/nut/nut.conf
MODE=netserver

# /etc/nut/upsd.conf
LISTEN 0.0.0.0 3493
MAXAGE 25

# /etc/nut/upsd.users
[admin]
    password = UPS_Adm1n_S3cure!
    actions = SET
    instcmds = ALL

[monitor]
    password = UPS_M0n_R3ad!
    upsmon slave

[upsmon_local]
    password = UPS_L0cal_M@ster!
    upsmon master

На каждом сервере, который должен корректно завершать работу при разряде UPS, установили NUT-клиент:

# Установка на сервере биллинга
sudo apt install -y nut-client

# /etc/nut/nut.conf
MODE=netclient

# /etc/nut/upsmon.conf
MONITOR apc-billing@10.0.5.10 1 monitor UPS_M0n_R3ad! slave

MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
POLLFREQ 5
POLLFREQALERT 2
HOSTSYNC 15
DEADTIME 25
RBWARNTIME 43200   # Предупреждать о замене батареи каждые 12 часов
NOCOMMWARNTIME 300 # Предупреждать о потере связи через 5 мин
FINALDELAY 5

# Скрипт уведомлений
NOTIFYCMD /opt/scripts/nut-notify.sh
NOTIFYFLAG ONLINE     SYSLOG+EXEC
NOTIFYFLAG ONBATT     SYSLOG+EXEC
NOTIFYFLAG LOWBATT    SYSLOG+EXEC
NOTIFYFLAG FSD        SYSLOG+EXEC
NOTIFYFLAG REPLBATT   SYSLOG+EXEC
NOTIFYFLAG NOCOMM     SYSLOG+EXEC

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

#!/bin/bash
# /opt/scripts/nut-notify.sh

TG_BOT_TOKEN="..."  # Из переменных окружения
TG_CHAT_ID="..."
HOSTNAME=$(hostname)

MSG="⚡ UPS Alert на ${HOSTNAME}:\n${NOTIFYTYPE}\n\nUPS: ${UPSNAME}"

curl -s -X POST "https://api.telegram.org/bot${TG_BOT_TOKEN}/sendMessage" \
  -d chat_id="${TG_CHAT_ID}" \
  -d text="${MSG}" \
  -d parse_mode=HTML

logger -t nut-notify "${NOTIFYTYPE}: ${UPSNAME}"

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

Мы реализовали каскадное отключение через скрипт на NUT-сервере:

#!/bin/bash
# /opt/scripts/cascade-shutdown.sh
# Вызывается при LOWBATT от любого UPS

set -euo pipefail

LOG="/var/log/cascade-shutdown.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG"
}

log "=== КАСКАДНОЕ ОТКЛЮЧЕНИЕ НАЧАТО ==="

# Фаза 1: некритичные сервисы (медиа-платформа)
log "Фаза 1: Отключение медиа-сервера..."
ssh root@10.0.1.40 'systemctl stop iptv-streaming && shutdown -h now' &

sleep 10

# Фаза 2: BRAS (завершение абонентских сессий)
log "Фаза 2: Graceful shutdown BRAS..."
ssh root@10.0.1.20 '/opt/scripts/bras-graceful-stop.sh && shutdown -h now' &

sleep 30  # Даём время на завершение сессий

# Фаза 3: Биллинг (после завершения BRAS)
log "Фаза 3: Отключение биллинга..."
ssh root@10.0.1.10 'systemctl stop billing-app && pg_ctlcluster 16 main stop && shutdown -h now' &

sleep 15

# Фаза 4: Мониторинг (последний)
log "Фаза 4: Отключение мониторинг-сервера..."
log "=== ВСЕ СЕРВЕРЫ ОТКЛЮЧЕНЫ ==="
shutdown -h now

Весь каскад отрабатывает примерно за 60 секунд. При батареях с запасом хода от 5 минут — времени более чем достаточно, даже с учётом замедленной реакции на старте.

SNMPv3 — не опция, а обязательное требование для продакшна. Версии v1 и v2c гонят community string открытым текстом. В серверной оператора связи, где крутятся данные 15 000 абонентов, это просто недопустимо: перехватив SNMP-пакеты, злоумышленник узнает состояние инфраструктуры и может спланировать атаку в момент переключения на батарею. Классический сценарий, который мы видели в реальных инцидентах.

Eaton Network-M2 вставляется прямо в слот UPS и превращает его в полноценное сетевое устройство: веб-интерфейс, SNMP, Modbus TCP, REST API. Настройку делали через веб-интерфейс:

# Настройка через веб-интерфейс Eaton Network-M2
# https://10.0.5.30 → Network → SNMPv3

# Параметры пользователя:
# Username: zabbix_mon
# Auth Protocol: SHA-256
# Auth Password: SNMP_Auth_S3cure!
# Privacy Protocol: AES-256
# Privacy Password: SNMP_Priv_K3y!
# Access: Read-Only

# Проверка с хоста мониторинга
snmpwalk -v3 -u zabbix_mon \
  -l authPriv \
  -a SHA-256 -A "SNMP_Auth_S3cure!" \
  -x AES256 -X "SNMP_Priv_K3y!" \
  10.0.5.30 \
  1.3.6.1.4.1.534.1  # Eaton MIB root

# Пример: получение заряда батареи
snmpget -v3 -u zabbix_mon \
  -l authPriv \
  -a SHA-256 -A "SNMP_Auth_S3cure!" \
  -x AES256 -X "SNMP_Priv_K3y!" \
  10.0.5.30 \
  1.3.6.1.2.1.33.1.2.4.0  # upsEstimatedChargeRemaining
# INTEGER: 78

Стандартные OID из UPS-MIB (RFC 1628), которые мы мониторили:

Для UPS через NUT добавили UserParameter в Zabbix Agent:

# /etc/zabbix/zabbix_agentd.d/nut.conf
# Установка на NUT-сервере (10.0.5.10)

UserParameter=nut.ups.status[*],upsc $1 ups.status 2>/dev/null || echo "N/A"
UserParameter=nut.battery.charge[*],upsc $1 battery.charge 2>/dev/null || echo "0"
UserParameter=nut.battery.runtime[*],upsc $1 battery.runtime 2>/dev/null || echo "0"
UserParameter=nut.battery.voltage[*],upsc $1 battery.voltage 2>/dev/null || echo "0"
UserParameter=nut.input.voltage[*],upsc $1 input.voltage 2>/dev/null || echo "0"
UserParameter=nut.output.voltage[*],upsc $1 output.voltage 2>/dev/null || echo "0"
UserParameter=nut.ups.load[*],upsc $1 ups.load 2>/dev/null || echo "0"
UserParameter=nut.ups.temperature[*],upsc $1 ups.temperature 2>/dev/null || echo "0"
UserParameter=nut.battery.date[*],upsc $1 battery.date 2>/dev/null || echo "N/A"

# Перезапуск агента
sudo systemctl restart zabbix-agent

Проверка работоспособности:

# С Zabbix-сервера
zabbix_get -s 10.0.5.10 -k nut.battery.charge[apc-billing]
# 62

zabbix_get -s 10.0.5.10 -k nut.ups.status[apc-billing]
# OL    (Online — работа от сети)

Алерты настроили многоуровневые — чтобы дежурный получал нужное сообщение в нужный момент, а не поток однотипных уведомлений, которые в итоге игнорируются:

# Триггеры Zabbix (экспорт в формате описания)

# CRITICAL: UPS работает от батареи
Trigger: UPS {HOST.NAME} на батарее
Expression: last(/Template NUT UPS/nut.ups.status[{$UPS_NAME}])="OB"
Severity: High
Action: Telegram + SMS дежурному

# CRITICAL: Заряд батареи < 30%
Trigger: UPS {HOST.NAME} заряд батареи {ITEM.VALUE}%
Expression: last(/Template NUT UPS/nut.battery.charge[{$UPS_NAME}])<30
Severity: Disaster
Action: Telegram + SMS + Звонок

# WARNING: Нагрузка > 70%
Trigger: UPS {HOST.NAME} перегружен {ITEM.VALUE}%
Expression: last(/Template NUT UPS/nut.ups.load[{$UPS_NAME}])>70
Severity: Warning
Action: Telegram

# WARNING: Температура батареи > 35°C
Trigger: UPS {HOST.NAME} перегрев {ITEM.VALUE}°C
Expression: last(/Template NUT UPS/nut.ups.temperature[{$UPS_NAME}])>35
Severity: Warning
Action: Telegram

# INFO: Батарея требует замены
Trigger: UPS {HOST.NAME} замените батарею
Expression: last(/Template NUT UPS/nut.ups.status[{$UPS_NAME}])="RB"
Severity: Average
Action: Telegram + Email IT-директору

Дашборд в Zabbix показывает все 6 UPS на одном экране. Без переключений, без поиска. Оператор NOC смотрит на монитор — и за 3 секунды понимает, что происходит со всей системой питания. На дежурной смене это принципиально: если что-то пошло не так в 3 ночи, человек не должен тратить время на навигацию по интерфейсу.

Ключевые виджеты:

• Сводная таблица — статус, заряд, нагрузка, время автономии для каждого UPS
• График входного напряжения — 24 часа, все UPS на одном графике. Очень удобно: сразу видишь, когда и где была просадка
• График нагрузки — тренд за месяц, чтобы понимать, когда пора думать о расширении ёмкости
• Карта серверной — визуальная схема стоек с цветовой индикацией статуса UPS. Зелёный-жёлтый-красный: дежурный видит всё одним взглядом

Карту серверной мы сделали через функцию Zabbix Maps:

# Цветовая индикация:
# Зелёный — OL (Online, питание от сети)
# Жёлтый — OL CHRG (Online, идёт зарядка после отключения)
# Красный — OB (On Battery, работа от батареи)
# Серый — OFF (UPS выключен или нет связи)
# Мигающий красный — OB LB (Low Battery, критический разряд)

Мы составили матрицу требований по каждой стойке:

Считали так: каскадное отключение занимает 60 секунд, плюс двукратный запас безопасности. Итог — минимум 10 минут автономии при текущей нагрузке для каждого UPS. Меньше — уже риск.

Аудит выявил несколько проблем, которые пришлось решать руками:

• Стойка 1 — заменили батарейный модуль APC RBC55, ёмкость восстановилась до 95%
• Стойка 2 — та же история: замена APC RBC55
• Стойка 4 — замена APC RBC43, плюс часть нагрузки перенесли в стойку 6, иначе 10 минут автономии было не достичь
• Стойка 3 — два коммутатора переехали в стойку 6, нагрузка упала с 82% до 65%

Что получилось после замены батарей и перебалансировки:

Все стойки перешагнули порог в 10 минут. Стойка 6 оказалась на границе, поэтому в следующем квартале запланировали апгрейд UPS до 2200VA — лучше сделать это заранее, чем потом в панике.

Три теста в нерабочее время, чтобы не рисковать:

Тест 1: Отключение питания одной стойки — вырубили ввод на стойке 4. UPS перешёл на батарею за 0 мс (online-режим, как и должно быть), NUT сразу показал статус OB, Zabbix отстучал алерт в Telegram через 7 секунд. Подержали на батарее 5 минут, потом восстановили питание — UPS штатно перешёл в OL CHRG и начал заряжаться.

Тест 2: Имитация критического разряда — на тестовом UPS искусственно снизили порог LOWBATT до текущего уровня заряда. Каскадный скрипт отработал чисто: сервер получил сигнал и завершил работу за 12 секунд. Без зависаний, без потери данных.

Тест 3: Полное отключение серверной — выключили основной ввод целиком. Все 6 UPS перешли на батарею одновременно. Каскадное отключение прошло точно по сценарию: медиа (0 сек) → BRAS (10 сек) → биллинг (40 сек) → коммутация (55 сек) → мониторинг (60 сек). Ни одного некорректного завершения, данные целы.

# Лог каскадного отключения (тест 3)
[2025-11-15 03:00:05] === КАСКАДНОЕ ОТКЛЮЧЕНИЕ НАЧАТО ===
[2025-11-15 03:00:05] UPS apc-billing: статус OB, заряд 92%
[2025-11-15 03:00:05] Фаза 1: Отключение медиа-сервера...
[2025-11-15 03:00:08] media-server: shutdown initiated
[2025-11-15 03:00:15] Фаза 2: Graceful shutdown BRAS...
[2025-11-15 03:00:18] bras-server: stopping sessions (1247 active)
[2025-11-15 03:00:35] bras-server: all sessions closed, shutdown
[2025-11-15 03:00:45] Фаза 3: Отключение биллинга...
[2025-11-15 03:00:48] billing-server: PostgreSQL checkpoint complete
[2025-11-15 03:00:52] billing-server: shutdown initiated
[2025-11-15 03:01:00] Фаза 4: Отключение мониторинг-сервера...
[2025-11-15 03:01:05] === ВСЕ СЕРВЕРЫ ОТКЛЮЧЕНЫ ===

Весь проект уложился в 5 рабочих дней: 2 дня ушло на настройку мониторинга и автоматизации, 1 день — на замену батарей и перебалансировку нагрузки, ещё 2 дня — на тестирование.

За 4 месяца после внедрения электричество отключалось трижды. Все три раза система отработала без вопросов: серверы корректно завершились, ни одного повреждения данных. Среднее время восстановления после возврата питания — 8 минут. Раньше было 14 часов.

«Раньше отключение света — это паника. Теперь я получаю SMS, смотрю в Zabbix и спокойно жду. Серверы сами выключатся и сами включатся» — системный администратор КомЛинк.

Теперь про деньги — потому что это аргумент, который понимают все. Два сгоревших сервера до внедрения системы обошлись больше чем в 800 000 ₽: замена RAID-контроллера Dell и двух NVMe SSD. Наш проект вместе с заменой батарей — 320 000 ₽. Если честно, окупаемость считать легко: один предотвращённый инцидент покрывает всё. А за 4 месяца таких инцидентов было три.

Под конец проекта мы передали IT-отделу КомЛинк регламент обслуживания UPS — чтобы через год не начинать всё заново:

• Ежемесячно — просматривать логи NUT, визуально осматривать UPS
• Ежеквартально — запускать self-test на каждом UPS через NUT (upscmd apc-billing test.battery.start)
• Раз в полгода — полный тест автономии: контролируемое отключение питания стойки и замер реального времени работы
• Ежегодно — замер ёмкости батарей, принятие решения о заменах до следующего сезона