Диагностика ошибок памяти сервера по журналам BMC

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

Я начинаю с журнала BMC, затем сверяю его с журналом операционной системы и только после этого планирую остановку. Такой порядок сохраняет исходные данные, отделяет коррекцию ECC от фатальной ошибки и не превращает рабочий сервер в стенд для случайных экспериментов. Периодичность сама по себе ничего не диагностирует: недельный интервал часто отражает расписание резервного копирования, сканирования, пакетной обработки или обслуживания, а не внутренний таймер неисправного модуля.

Еженедельный перезапуск еще не указывает на DIMM

Перезагрузка связана с памятью только тогда, когда перед ней есть аппаратная запись о памяти или достоверный машинный отчет с совпадающим временем. Запись «сервер неожиданно завершил работу» сообщает о последствии. Она не называет причину. Точно так же один счетчик Correctable ECC, накопленный за месяцы, не объясняет конкретный перезапуск.

Сначала зафиксируйте четыре времени: последнее нормальное сообщение ОС, первое сообщение после загрузки, событие BMC перед потерей питания и начало регулярной нагрузки. Приведите их к одному часовому поясу. Часы BMC нередко отстают, сбрасываются после снятия дежурного питания или используют UTC, пока ОС показывает местное время. Ошибка на несколько минут легко меняет причинность местами.

Полезная рабочая таблица выглядит просто: время, источник, серьезность, компонент, физический локатор, счетчик, действие системы. В строках рядом с инцидентом ищите не одно слово «memory», а последовательность. Например, растущий поток CE на одном канале, затем UE, Machine Check и новая запись о включении питания гораздо убедительнее, чем старое предупреждение о DIMM в другом сокете.

Проверьте и обычные причины штатного рестарта. Планировщик ОС, оркестратор виртуализации, агент обновлений, watchdog приложения и администратор через BMC оставляют разные следы. Команда перезапуска, watchdog timeout, потеря входного питания и аппаратный сброс не равны друг другу. Если BMC пишет «power cycle requested by user», диагностика памяти закончилась до открытия корпуса.

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

Отделите перезагрузку ОС от полного пропадания питания. При обычном рестарте BMC продолжает работать, время его сессии управления не обнуляется, а последовательность событий питания содержит штатное выключение и включение. При жестком сбросе или просадке вы увидите разрыв, неожиданный старт либо потерю связи с самим BMC. Это различие сразу сокращает список подозреваемых.

Проверьте, не скрыла ли ОС первичную запись. Linux может ограничивать частоту одинаковых сообщений, а Windows иногда публикует сохраненную WHEA-запись уже после следующей загрузки. Время публикации тогда не равно времени аппаратного события. Сопоставляйте идентификатор загрузки, сохраненный timestamp внутри записи и порядок событий BMC, а не сортировку одного окна по времени отображения.

Снимите журналы до очистки и обновления

Первый снимок нужно сделать до сброса счетчиков, обновления BIOS и перестановки модулей, иначе вы уничтожите привязку события к исходной конфигурации. Сохраните журнал событий BMC, сведения о сенсорах, инвентаризацию памяти, версии BMC и BIOS, а также системный журнал ОС. К снимку добавьте дату, серийный номер сервера и причину сбора.

На Linux с локальным интерфейсом IPMI базовый набор команд может выглядеть так:

mkdir -p incident-memory
ipmitool sel info > incident-memory/sel-info.txt
ipmitool sel elist > incident-memory/sel-extended.txt
ipmitool sdr elist > incident-memory/sensors.txt
ipmitool fru print > incident-memory/fru.txt
journalctl -k -b -1 > incident-memory/kernel-previous-boot.txt
journalctl -k -S "14 days ago" | grep -Ei "edac|ecc|mce|hardware error|memory" > incident-memory/kernel-memory.txt
dmidecode -t memory > incident-memory/dmi-memory.txt

Не копируйте пароль BMC в командную строку: он попадет в историю оболочки и иногда в список процессов. Для удаленного IPMI используйте запрос пароля или защищенный файл учетных данных по правилам вашей площадки. Если производитель дает собственную утилиту экспорта сервисного пакета, сохраните и ее полный архив, но не заменяйте им читаемый журнал.

ipmitool sel elist обычно возвращает идентификатор записи, дату, время, имя сенсора, тип события и состояние. Реальный текст зависит от BMC. Искомая форма похожа на эту, а не обязательно совпадает дословно:

01a4 | 07/21/2026 | 02:14:08 | Memory #0x8a | Correctable ECC | Asserted
01a5 | 07/21/2026 | 02:14:11 | Memory #0x8a | Uncorrectable ECC | Asserted
01a6 | 07/21/2026 | 02:14:12 | System Event | Undetermined system hardware failure | Asserted

IPMItool описывает BMC как независимый от CPU и ОС сервисный процессор, который следит за сенсорами и пишет события. Поэтому его журнал часто переживает зависание ядра. Но независимость не делает BMC безошибочным: прошивка может неверно декодировать слот, часы могут уйти, а небольшой SEL может перезаписать старые записи. Экспортируйте его сразу после инцидента.

На платформах с Redfish проверьте не только LogEntry, но и ресурсы Memory и MemoryMetrics. Стандарт DMTF разделяет счетчики CorrectableECCErrorCount и UncorrectableECCErrorCount для текущего периода и всего срока, а ресурс Memory может отдавать DeviceLocator. Это полезное разделение: счетчик показывает динамику, локатор связывает ее с железом. OEM-поле без расшифровки из реестра сообщений нельзя трактовать по памяти.

В Windows отберите события провайдера Microsoft-Windows-WHEA-Logger из системного журнала и сохраните XML записи, а не снимок экрана. Документация Microsoft говорит, что WHEA строит аппаратные записи в формате, основанном на CPER, и может включать отдельную секцию ошибки памяти платформы. Читаемое описание удобно, но поля записи важнее общего текста события.

Если ОС работает в гипервизоре, собирайте данные с хоста, а не только из гостевой машины. Гость может увидеть падение виртуального CPU или внезапное выключение и не получить физический адрес, канал либо WHEA/EDAC-событие. Журнал кластера нужен для времени миграции и fencing, но физическую память локализуют BMC, прошивка и ядро хоста.

Сразу посчитайте вместимость SEL и процент заполнения. Кольцевой журнал способен удалить именно раннее предупреждение CE, оставив только поздний рестарт. Если заполнение быстро растет из-за шумного сенсора, экспортируйте журнал автоматически и устраните шум отдельно. Отключать запись сенсора ради удобства чтения нельзя, пока производитель не подтвердил, что событие не участвует в диагностике.

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

CE, UE и фатальная ошибка требуют разных решений

Correctable Error означает, что механизм ECC обнаружил и исправил ошибку до передачи данных потребителю. Uncorrected Error означает, что исправить данные не удалось; такая ошибка может быть отложенной, локализованной или фатальной в зависимости от того, где оказались поврежденные данные и что умеет платформа. Эти категории нельзя переводить в правило «CE безопасна, UE всегда выключает сервер».

Документация подсистемы Linux EDAC прямо различает corrected, uncorrected, deferred и fatal события. Она также предупреждает, что поток CE может указывать на деградацию, но сам по себе не гарантирует будущую UE. Практический вывод жестче бытового совета «ECC все исправила»: одиночная коррекция без повторения требует наблюдения, а устойчивый рост на одном локаторе требует плановой изоляции до простоя.

Смотрите на пять признаков вместе:

• серьезность и действие платформы;
• повторение на одном сокете, канале, ранге или DIMM;
• скорость прироста после обнуления текущего периода;
• совпадение с температурой и нагрузкой;
• переход от CE к UE, отключению ранга, sparing или перезапуску.

Универсального допустимого числа CE нет. Порог зависит от процессора, режима памяти, прошивки, типа DIMM и политики производителя сервера. Чужое число из форума опасно: один BMC считает отдельные исправленные слова, другой объединяет бурст в одно событие, третий пишет запись только после пересечения собственного порога. Используйте правило замены из сервисной документации вашей модели и сравнивайте скорость прироста в одинаковых условиях.

Не путайте событие с диагнозом конкретной планки. Контроллер памяти находится в процессоре на современных серверных платформах, а путь сигнала проходит через сокет, дорожки платы, разъем и DIMM. Сообщение «memory channel A» доказывает область сбоя. Оно оставляет среди подозреваемых модуль, слот, канал контроллера и контакт в сокете.

Режимы lockstep и memory mirroring еще сильнее расширяют область. В руководстве Linux RAS отмечено, что lockstep группирует модули для более широкой коррекции, но при ошибке контроллер может обвинить пару, потому что не умеет выделить один DIMM. Если BMC называет сразу два модуля в таком режиме, это может быть ограничением локализации, а не одновременной смертью двух планок.

События threshold exceeded и disabled не равны отдельной коррекции. Первое говорит, что внутренняя политика платформы накопила достаточно ошибок для предупреждения, второе может означать вывод ранга или канала из работы после training либо ошибки выполнения. Запишите состояние памяти после загрузки: уменьшившийся доступный объем иногда и есть выполненное действие восстановления.

Адрес ошибки тоже требует осторожности. Повтор одного физического адреса или узкого диапазона усиливает гипотезу постоянного дефекта ячейки, а случайные адреса по одному каналу могут указывать на общий электрический путь. Но ОС, interleaving и преобразование адресов контроллером усложняют обратное сопоставление. Без декодера для конкретного CPU не превращайте адрес страницы в самодельный номер DIMM.

Обычный kernel panic, bug check или Machine Check не всегда означает память. Intel описывает MCA как механизм отчетности для ошибок шин, кэшей, ECC, parity и других аппаратных источников. Читайте секцию и банк машинной проверки. Заголовок WHEA_UNCORRECTABLE_ERROR на синем экране называет класс остановки, а не заменяемую деталь.

Привяжите код контроллера к физическому слоту

Менять модуль можно только после перевода логического адреса из события в маркировку на системной плате. Обозначения CPU1_CH2_DIMM0, A2, P1-DIMMB1 и «канал 1, слот 0» не взаимозаменяемы. Производитель задает собственную схему, а нумерация в ОС может начинаться с нуля.

Соберите карту до остановки. В ней нужны: имя слота на плате, локатор BMC, Locator и Bank Locator из SMBIOS, серийный номер DIMM, номер детали, объем, скорость и привязка к процессорному сокету. Сверьте данные с руководством именно для модели и ревизии платы. Фотография заполненных слотов до работ часто полезнее памяти инженера после перестановки.

dmidecode показывает то, что прошивка записала в SMBIOS, а не измерение проводки. Если в выводе стоит Locator: DIMM_A2, это хорошая подсказка, но не независимое подтверждение. Redfish DeviceLocator тоже формирует прошивка. Два интерфейса могут повторять одну и ту же ошибочную таблицу BIOS.

Код синдрома ECC помогает контроллеру определить поврежденные биты, но редко позволяет администратору без документации назвать микросхему на модуле. Не пытайтесь расшифровать произвольный syndrome 0x... по таблице от другого поколения CPU. Поля channel, slot, rank и bank полезны только в контексте руководства процессора и реализации производителя платы.

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

До открытия корпуса проверьте правила заполнения памяти. Сервер может требовать одинаковую емкость и организацию модулей в паре каналов, определенный порядок слотов или одинаковые DIMM для lockstep. Случайная перестановка способна создать новую ошибку конфигурации и скрыть исходную.

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

Если локатор отсутствует, не угадывайте по порядку строк dmidecode. Получите сервисный дамп и посмотрите, дает ли производитель декодирование MCA или OEM-кода. При отсутствии надежной привязки область изоляции расширяется до пары или канала, а окно работ станет длиннее. Это честнее, чем заменить модуль с удобным номером.

Изолируйте модуль одной переменной за проход

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

Перед остановкой выгрузите нагрузку, проверьте резервирование и получите окно работ. Завершите ОС штатно, снимите питание по сервисной процедуре, дождитесь разряда и примените защиту от статического электричества. Горячая замена обычного DIMM не допускается, если руководство явно не описывает такую возможность для конкретной платформы.

Порядок диагностики:

1. Зафиксируйте исходные слоты и серийные номера, затем повторно установите подозреваемый DIMM в тот же слот. Осмотрите контакты, защелки, воздуховоды и загрязнение.
2. Запустите встроенную офлайн-диагностику производителя без изменения прошивки. Сохраните полный результат, включая идентификатор теста и физический локатор.
3. Если ошибка вернулась, переставьте подозреваемый модуль и заведомо исправный совместимый модуль между двумя разрешенными эквивалентными слотами. Не нарушайте схему каналов.
4. Повторите ту же нагрузку и сравните новые события. Ошибка следует за модулем, заменяйте DIMM; остается в слоте, исследуйте плату, сокет и контроллер; исчезает, продолжайте наблюдение, потому что контактная проблема могла временно уйти.
5. Для двухпроцессорной системы не переносите DIMM между сокетами без проверки совместимости и топологии. Такой перенос меняет сразу модуль, канал и контроллер памяти.

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

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

Если сервер поддерживает memory sparing, rank sparing или отключение поврежденной страницы, зафиксируйте активированное действие. После него объем или производительность могут измениться, а симптом исчезнет до следующего порога. Успешная загрузка после автоматического вывода области памяти не доказывает исправность железа.

Есть полезный отрицательный результат: ошибка не следует за DIMM и не остается в одном слоте, но появляется только при полной конфигурации. Тогда проверьте правила нагрузки на канал, предельную частоту при текущем числе модулей и одинаковость комплектов. Сокращенная конфигурация может работать не потому, что вы вынули сломанный DIMM, а потому, что контроллер снизил электрическую нагрузку или изменил training.

Не протирайте контакты случайной химией и не ластиком. Следуйте процедуре производителя, используйте одобренные материалы и не касайтесь контактной гребенки. Следы коррозии, перегрева или повреждения фиксируйте фотографией; такой модуль не нужно возвращать в эксплуатацию ради еще одного теста.

Нагрузочный тест должен повторять условие, а не просто греть память

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

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

Для воспроизведения еженедельного инцидента повторите штатное задание на копии данных или резервном узле, если это возможно. Следите одновременно за CE и UE, температурой входящего воздуха, температурой CPU и DIMM, мощностью, состоянием блоков питания и частотой коррекции. Интересен не максимальный нагрев сам по себе, а порядок событий.

Проверка должна ответить на заранее записанный вопрос. Например: «Появятся ли новые CE на локаторе A2 в течение полного задания резервного копирования после переноса серийного номера X в B2?» Такой критерий не дает заменить вывод фразой «вроде стабильно».

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

Сравнивайте одинаковые интервалы. Счетчик lifetime не подходит для оценки последнего прохода, если его нельзя сбросить. DMTF Redfish для MemoryMetrics специально разделяет CurrentPeriod и LifeTime; используйте текущий период или разницу двух снимков. Ноль новых ошибок за короткий простой ничего не говорит о поведении под прежней нагрузкой.

Следите за тем, кто именно пишет счетчик. BMC, EDAC и WHEA могут получить одно аппаратное событие по разным путям, поэтому сложение трех чисел завышает результат. Группируйте записи по времени, локатору, синдрому и severity. Задача не в подсчете максимального числа ошибок, а в восстановлении одной последовательности.

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

Питание выдает себя общей картиной событий

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

Ищите записи AC lost, power unit failure, voltage out of range, power good lost, внезапный сброс BMC, переключение входа и потерю резервирования. Формулировки зависят от платформы. Сопоставьте их с журналом ИБП, PDU и соседнего оборудования, а не только с ОС этого сервера.

Проверьте физическую цепь: вводы A и B, разные ли у них источники, защелкнуты ли кабели, исправны ли оба блока, одинакова ли их поддерживаемая мощность и прошивка. Резервирование на экране BMC не помогает, если оба кабеля включены в один перегруженный PDU. После обслуживания убедитесь, что сервер действительно видит ожидаемый режим резервирования.

Показания напряжения BMC полезны для тренда, но они не заменяют измерение качества питания. Контроллер опрашивает сенсоры с конечной частотой и может пропустить короткий провал. Если журнал ИБП показывает переход на батарею или перегрузку в ту же секунду, а SEL успел записать только неожиданное выключение, расследуйте питание первым.

Общая нагрузка тоже важна. Резервное копирование может одновременно загрузить CPU, память и диски, подняв потребление. Если CE разбросаны по нескольким каналам обоих сокетов рядом с сигналами питания, замена одного DIMM выглядит слабой гипотезой. Если ошибки упорно идут с одного серийного номера при стабильных шинах, питание отходит на второй план.

Не проверяйте блок питания перестановкой его между рабочими серверами без оценки мощности и совместимости. Безопаснее использовать поддерживаемый запасной блок, отдельный проверенный ввод и контролируемую нагрузку. Любое изменение фиксируйте так же строго, как перенос DIMM.

Проверьте журнал не только в момент отключения, но и за несколько часов до него. Повторяющиеся переходы блока питания между состояниями present, degraded и OK могут предшествовать сбою. Такие флаппинги иногда не попадают в короткий фильтр вокруг рестарта, хотя хорошо показывают нестабильный контакт или вход.

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

Прошивка, сокет и плата могут обвинить исправную память

Прошивку следует подозревать, когда ошибки начались после обновления, локаторы в разных интерфейсах расходятся, релиз-ноты описывают коррекцию RAS или memory training, либо одинаковая аппаратная конфигурация массово дает один код. Это не разрешение сразу прошивать аварийный сервер. Сначала сохраните версии и журналы, затем проверьте матрицу совместимости и инструкцию производителя.

BIOS настраивает память при старте, BMC декодирует и хранит события, а микрокод и системная прошивка участвуют в обработке машинных ошибок. Несогласованный набор версий способен дать неверный локатор, повторяющееся training failure или неправильную политику восстановления. Обновляйте компоненты в порядке, который задает производитель, с возможностью отката и отдельным тестом после каждого логического этапа.

Сброс настроек BIOS иногда временно меняет режим памяти и частоту, поэтому он не нейтральный диагностический шаг. До сброса экспортируйте конфигурацию и отметьте memory mode, частоту, interleaving, sparing, mirroring и параметры питания. После сброса сравните их явно.

Контакт процессора и состояние сокета проверяют, если ошибка остается на канале после замены DIMM или несколько слотов одного канала исчезают при training. Погнутый контакт, неравномерный прижим радиатора или повреждение дорожки может выглядеть как сбой памяти. Такая работа требует сервисной процедуры: снятие CPU без нужного инструмента легко добавит новый дефект.

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

Отдельно проверьте температуру. Забитый воздуховод, неверно установленная заглушка, остановившийся вентилятор или горячий воздух на входе могут вызвать ошибки под недельным пиком. Температурная корреляция не доказывает дефект DIMM, но дает воспроизводимое условие и понятное исправление системы охлаждения.

Ошибки training после холодного старта и ошибки под нагрузкой разделяйте. Первые возникают, когда BIOS обучает каналы до запуска ОС, поэтому журнал ядра может быть чистым, а доступный объем уже уменьшен. Вторые появляются во время чтения и записи. Для training особенно важны совместимость модулей, посадка, сокет, версия BIOS и температура при старте.

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

Закройте инцидент доказательством, а не тишиной

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

Для замены DIMM запишите старый и новый серийные номера, слот, версию прошивки, активный режим памяти и результат офлайн-теста. После загрузки проверьте полный объем памяти, симметрию каналов, рабочую скорость, состояние резервирования и отсутствие training errors. Затем снимите новый базовый уровень счетчиков.

Не удаляйте старые логи после ремонта. Положите рядом временную шкалу, карту слотов, решение о замене и результаты проверки. Это позволяет увидеть повтор на том же канале через месяц и отличить второй дефект DIMM от проблемы платы, которую первая замена только замаскировала.

В инфраструктуре GSE серверы S200 и круглосуточная техническая поддержка дают единый контур для проверки аппаратной конфигурации и сервисного случая, но инженеру все равно нужны исходный SEL, версии прошивок и точный локатор. Без этих данных любой производитель начнет с повторного сбора, а простой станет длиннее.

Настройте предупреждения на новые UE, переход порога CE, потерю блока питания, критическую температуру и переполнение журнала BMC. Не отправляйте каждую коррекцию как ночную аварию: группируйте по серверу и локатору, считайте прирост и повышайте приоритет при ускорении потока или смене серьезности.

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

Для парка одинаковых серверов полезен контрольный фон. Сравните версии, конфигурацию памяти и частоту CE на узлах того же поколения, не раскрывая счетчики между разными моделями. Один узел, который резко отличается при одинаковой нагрузке, заслуживает приоритета; одинаковый новый код сразу на группе после обновления возвращает внимание к прошивке или общему условию.

Хороший итоговый отчет умещает причинность в одной проверяемой фразе: «CE и UE следовали за DIMM с серийным номером X из A2 в B2 при одинаковой нагрузке; после замены счетчики текущего периода остались нулевыми на двух полных циклах задания». Если такой фразы нет, расследование еще не отделило причину от совпадения.