Что на этом сервере сломается первым: составляем карту рисков

MAATRIX

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

Зачем ранжировать, а не чинить по списку сверху вниз

Список найденных проблем после разбора чужого сервера обычно похож на бессистемную свалку: «Node.js 14, нет мониторинга диска, сертификат непонятно кем настроен, RAID без резерва, сервер 2018 года». Если чинить этот список в том порядке, в котором проблемы были обнаружены, вы почти гарантированно потратите первую неделю на что-то некритичное, а тем временем закончится место под базой данных — и всё встанет в самый неподходящий момент.

Приоритизация — это не про то, чтобы найти больше проблем. Их вы уже нашли достаточно на этапе разбора машины (если ещё не проходили этот этап — есть отдельная методология: «Достался чужой сервер без документации: с чего начинать разбор»). Здесь задача другая — рассортировать найденное по двум осям: насколько вероятен отказ в обозримом горизонте (недели, а не годы) и насколько болезненны будут последствия. Формула простая:

Приоритет = Вероятность отказа × Тяжесть последствий

Оба множителя — не точные числа, а экспертная оценка по шкале, например, от 1 до 3. Она не обязана быть идеальной — важно, чтобы она была явной и записанной, а не жила только в голове. Ниже — пять признаков, по которым эта оценка ставится, и в конце — как свести их в одну таблицу.

Если вам нужна не приоритизация рисков, а полная инвентаризация всего хозяйства — серверов, доменов, интеграций, доступов — это отдельная, более объёмная задача: «Карта инфраструктуры с нуля: описываем чужое хозяйство за неделю». Здесь же цель уже, но острее: не описать всё, а понять, что откажет раньше остального.

Признак первый: версии софта без патчей

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

Быстрая проверка на Debian/Ubuntu:

# сколько пакетов ждут обновления и какие из них critical/security
apt list --upgradable 2>/dev/null

# сколько апдейтов безопасности накопилось конкретно
apt-get -s dist-upgrade | grep -i security | wc -l

# когда последний раз реально обновлялись пакеты
grep " upgrade " /var/log/dpkg.log* 2>/dev/null | tail -5

На RHEL-подобных (AlmaLinux, RockyLinux):

dnf check-update
dnf updateinfo list security

Отдельно проверьте версию самой ОС и её жизненный цикл — конкретные даты окончания поддержки быстро устаревают в тексте, поэтому не полагайтесь на память, а сверяйтесь с официальной страницей дистрибутива (lsb_release -a или cat /etc/os-release, затем сверка с сайтом производителя). Если релиз уже вышел из цикла security-обновлений — это высокий риск независимо от того, сколько лет сервер проработал без инцидентов: отсутствие инцидентов при вышедшей из поддержки системе значит не «система надёжная», а «вам пока везло».

Отдельно смотрите на приложения поверх ОС — часто они устаревшие сильнее самой системы: старый PHP, версия PostgreSQL без security-релизов год как, Node.js LTS-ветка вне поддержки. Проверяется вручную по каждому стеку (php -v, psql --version, node -v) со сверкой по странице поддержки конкретного проекта.

Признаки высокого риска по этому пункту: ОС или ключевое приложение вне цикла security-поддержки; apt-get -s dist-upgrade показывает счёт обновлений безопасности на десятки и больше; в логе dpkg.log последняя запись про upgrade — многомесячной давности.

Признак второй: диск, который вот-вот закончится

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

Разовый снимок:

df -h
df -i          # отдельно проверьте inode — кончиться могут они, а не байты

Одного снимка недостаточно для оценки риска — нужен тренд. Минимальный способ его получить без внешнего мониторинга — простой cron, который раз в день пишет процент занятости в файл:

# /etc/cron.d/disk-trend
0 6 * * * root df --output=pcent,target / | tail -1 >> /var/log/disk-trend.log

Через одну-две недели по файлу видно скорость роста в процентных пунктах в день, а по ней — грубую оценку, через сколько дней диск дойдёт до критической отметки. Если тренда ещё нет, а решение нужно сейчас, суррогат — сравнить заполнение с возрастом сервера: 70% за первый год из пяти — не то же самое, что 70% за первый месяц.

Отдельно проверьте, что именно растёт — часто это не данные приложения, а логи или снапшоты:

du -sh /var/log/* 2>/dev/null | sort -rh | head -10
du -sh /var/lib/docker/* 2>/dev/null | sort -rh | head -10

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

Признаки высокого риска: заполнение растёт на 1% и больше в неделю без видимой причины (не разовая загрузка, а системный тренд); свободного места по текущей скорости роста хватит меньше чем на месяц; на разделе с базой данных заполнение выше 80% — многие СУБД начинают деградировать по производительности задолго до фактического «диск полон».

Признак третий: сертификаты и домены на грани истечения

Просроченный TLS-сертификат — риск с почти нулевой сложностью диагностики и катастрофическими последствиями в моменте: сайт или API перестаёт открываться у всех сразу, обычно в момент, когда никто не готов чинить это срочно (классика — пятница вечером).

Проверка срока действия сертификата на конкретном хосте:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

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

whois example.com | grep -iE "expiry|expiration"

Здесь риск считается не только по дате, но и по тому, кто продлевает. Автопродление Let's Encrypt через certbot/acme.sh в cron — низкий риск, если вы проверили, что задача реально срабатывает, а не просто когда-то была настроена. Ручное продление коммерческого сертификата, зависящее от своевременной оплаты счёта и человека, который не забудет зайти в панель — высокий риск даже при формально долгом сроке до истечения: слишком много шагов, которые можно забыть выполнить.

Подробный разбор мониторинга сертификатов и доменов — как автоматизировать проверку сразу по всему парку, а не по одному домену вручную — в статье «Мониторинг сертификатов и доменов».

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

Признак четвёртый: единая точка отказа без резервирования

Single point of failure (SPOF) — компонент, отказ которого останавливает всё, потому что дублирующего пути нет. Это единственный из пяти признаков не про вероятность отказа компонента самого по себе, а про то, что происходит, если он всё же откажет: даже надёжный диск однажды выходит из строя, вопрос в том, есть ли за ним резерв.

Что проверить в первую очередь:

• Диски и RAID. cat /proc/mdstat для программного RAID, mdadm --detail /dev/mdX для деталей; для аппаратного контроллера — утилита производителя (storcli, megacli, perccli). Один диск без RAID и без свежей проверенной копии — это не «риск», а гарантированная потеря данных при первом же отказе накопителя, вопрос только в сроке.
• Резервные копии. Файл бэкапа — не то же самое, что рабочий бэкап. Риск высокий, если восстановление ни разу не проверялось на практике: тест восстановления — единственный способ узнать, что бэкап действительно рабочий.
• Сеть и питание. Один аплинк без резервного маршрута, один блок питания или два блока на одном вводе электропитания — резервирование существует на бумаге, но не защищает от реального отказа общей точки. Проверяется напрямую у провайдера, из самой машины не всегда видно.
• Люди. Единственный человек, который знает пароли и умеет чинить архитектуру — тоже точка отказа, просто не аппаратная. Один админ без документации и без аварийного доступа для второго — риск того же класса, что диск без RAID.
• DNS и внешние сервисы. Один DNS-провайдер без вторичного NS, один почтовый сервис без резервного MX — при отказе стороннего сервиса вы теряете контроль полностью.

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

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

Признак пятый: старое железо и виртуализация на пределе

Этот признак актуален и для выделенных серверов на старом «железе», и для виртуальных машин на перегруженном или устаревшем гипервизоре — просто индикаторы разные.

Для физического сервера или диска под ним — SMART-показатели являются наиболее прямым сигналом приближающегося отказа накопителя:

smartctl -a /dev/sda | grep -Ei "Reallocated_Sector_Ct|Current_Pending_Sector|Power_On_Hours|Uncorrectable"

Растущее число Reallocated_Sector_Ct или ненулевой Current_Pending_Sector — сигнал, что диск уже деградирует, а не «может однажды сломаться». Power_On_Hours даёт грубую оценку возраста накопителя: многолетний диск под постоянной нагрузкой статистически ближе к отказу, чем свежий, даже при формально «здоровых» показателях.

Возраст сервера в целом оценивается по дате покупки в биллинге хостера (для аренды) или по инвентарным данным, косвенно — по модели процессора (dmidecode -t system, lscpu). Для виртуальной машины «своего железа не видно», но перегруженный гипервизор заметен изнутри косвенно — по устойчиво высокому steal time:

vmstat 1 5
# колонка st — steal time; устойчиво выше нескольких процентов —
# сигнал соседства с перегруженными VM на том же хосте

Отдельная категория риска — версия самого гипервизора (Proxmox, VMware, KVM-хост), если вы администрируете его сами: устаревшая виртуализация без патчей — тот же риск, что устаревшая ОС, но с более тяжёлыми последствиями, потому что отказ или уязвимость гипервизора задевает разом все VM на нём.

Признаки высокого риска: растущие Reallocated_Sector_Ct/Current_Pending_Sector на SMART; возраст диска или сервера превышает типичный жизненный цикл оборудования для его класса нагрузки; устойчивый steal time на виртуальной машине; гипервизор не обновлялся дольше, чем сама гостевая ОС.

Как собрать всё в одну таблицу приоритизации

Пять признаков выше дают сырой список наблюдений. Чтобы превратить его в план работ, а не в тревожный список без начала и конца, сведите каждое наблюдение в одну строку с оценкой вероятности и тяжести последствий по шкале 1–3, и отсортируйте по произведению — это и есть приоритет.

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

Практическое правило по срокам: приоритет 7–9 — действовать в течение недели; 4–6 — в ближайший спринт работ; 1–3 — зафиксировать в реестре и пересматривать раз в квартал, без немедленных действий. Таблицу стоит пересчитывать не единожды, а регулярно — заполнение диска, сроки сертификатов и возраст железа меняются каждый месяц сами по себе, даже если вы ничего не трогали.

Частые вопросы