Введение в комплексный траблшутинг (PBL). В этом уроке мы объединим знания об архитектуре серверов, виртуализации, мониторинге и процессах ITIL для решения сложной инженерной задачи методом Problem-Based Learning (проблемно-ориентированное обучение). Сценарий: Вы — старший системный администратор ЦОД. В системе Service Desk зарегистрирован инцидент приоритета P1: один из серверов кластера виртуализации (Bare-metal гипервизор VMware ESXi, архитектура x86, NUMA-узлы, RAID 5) внезапно перезагрузился в разгар рабочего дня. Виртуальные машины были перезапущены на других хостах благодаря механизму HA (High Availability), но инфраструктура потеряла часть вычислительных мощностей. Инженер L1 закрыл инцидент, так как сервер снова включился и доступен (Workaround сработал). Однако вы, как Problem Manager, берете задачу в расследование (RCA), так как самопроизвольные перезагрузки — предвестник катастрофы. Вам нужно найти Root Cause.

Шаг 1: Сбор данных и метрики гипервизора. Траблшутинг начинается не с отвертки, а со сбора аналитики. Вы открываете дашборд Grafana и смотрите исторические данные за час до падения. Сетевой трафик в норме (штормов не было), дисковая подсистема: задержка (DAVG) около 10ms, что является нормой для RAID 5 на SSD. Вы проверяете логи гипервизора. Главная ошибка новичков при жалобах на 'тормоза' ВМ — назначать им как можно больше виртуальных процессоров (vCPU). Вы используете утилиту esxtop (в исторических логах) и проверяете метрику %RDY (CPU Ready). Эта метрика показывает, сколько времени ВМ ждала свободных физических ядер. Значение %RDY было около 2%, что говорит о здоровом распределении ресурсов. Также метрика SWCUR (Swap Current) была равна 0, значит гипервизору хватало физической оперативной памяти, и он не сбрасывал страницы на диск. Следовательно, проблема не в программном слое и не в перегрузке ресурсов (Oversubscription).

Шаг 2: Анализ инженерной инфраструктуры. Исключив программный уровень, спускаемся на физический. Возможно, проблема в климате или питании? Вы запрашиваете данные из системы мониторинга климата серверной (Zabbix). Температура в 'холодном коридоре' (откуда сервер забирает воздух) стабильно 20°C. Прецизионные кондиционеры работают штатно. Данные с ИБП (On-line топологии) показывают чистое напряжение без просадок, переходов на батареи или дизель-генератор (ДГУ) не зафиксировано. Это исключает внешние факторы окружающей среды. Сервер не мог перегреться из-за жары в помещении, и не мог выключиться из-за скачка напряжения в городской сети. Кольцо подозрений сужается вокруг внутренних аппаратных компонентов самого физического хоста.

Шаг 3: Исследование 'Черного ящика' (IPMI/BMC). Самый надежный источник правды при внезапных перезагрузках (когда ОС не успевает записать дамп памяти) — это контроллер удаленного управления (IPMI). Вы подключаетесь к web-интерфейсу BMC сервера и переходите в раздел System Event Log (SEL). Чтение логов идет снизу вверх (от старых к новым). Вы видите следующую картину: за 15 минут до падения начали появляться записи: 'Sensor: FAN_3 - RPM Lower Critical - Going Low'. Скорость вращения третьего кулера упала ниже критического порога, а затем он остановился. Сразу после этого график метрики 'CPU_1 Temp' в Grafana показал резкий рост с 60°C до 95°C. Финальная запись в SEL перед отключением: 'CPU_1 Thermal Trip - System Reset'. Пазл сложился. Вы нашли корневую причину (Root Cause).

Шаг 4: Разрешение проблемы (Permanent Fix). Что произошло? Один из высокооборотистых кулеров (Hot-swap fan) в шасси сервера вышел из строя (заклинило подшипник). Радиатор процессора потерял обдув. Несмотря на наличие термопасты, отводящей тепло на радиатор, без потока воздуха температура кристалла CPU превысила критическую отметку (Thermal Trip). Встроенная аппаратная защита процессора мгновенно отключила питание (Hardware Reset), чтобы кристалл не расплавился. Это и вызвало внезапную перезагрузку. Ваши действия как Problem Manager: 1. Вывести сервер в режим обслуживания (Maintenance Mode). 2. Создать Change Request на физическую замену кулера. 3. Надеть антистатический браслет (защита ESD). 4. Заменить кулер горячей замены (Hot-swap). 5. Внести в систему мониторинга Zabbix жесткий триггер на остановку кулеров, чтобы в будущем получать Critical Alert до того, как процессор перегреется. Проблема успешно закрыта.