Привет, Хабр!
Сегодня поделимся не историями грандиозных IT-побед, а скромными буднями борьбы с коварными, но редкими багами. Нам "повезло" столкнуться сразу с тремя такими на одном проекте. Спойлер: виноваты были забытые обновления Windows, коварный апдейт Касперского и упрямый PCI-райзер. Читайте, как мы их ловили, и берите на заметку наши шишки!
⚠️ Дисклеймер: Подвигов не будет, только серая, но поучительная реальность. Хотим напомнить, что путь настоящего самурая иногда состоит из мелких неудач и разного масштаба трудностей. Но самурай идет вперед.
Кейс 1. Windows Server 2016 зависает при входе пользователей. Виновен... DWM?
Проблема: у клиента на высоконагруженном SQL-сервере (Win Srv 2016) периодически появлялся черный экран, а затем сервер намертво зависал. ОЗУ хватало, логи молчали. Проанализировали всевозможные журналы, но безуспешно. Единственное, что удалось понять, — проблема начиналась чуть раньше и разрасталась как снежный ком, что и приводило к полному зависанию.
Охота: подключились по RDP, свернули сессию и стали ждать. Закономерность вырисовалась не сразу: зависание случалось при попытке другого пользователя войти на сервер. Тесты всех сценариев входа/выхода (штатный выход, закрытие сессии, "убийство" через диспетчер) показали: проблема запускалась, когда пользователь штатно завершал сеанс и потом (когда угодно) подключался снова (не важно, тот же или другой).
Механика бага: запускалась цепная реакция:
Падал диспетчер окон рабочего стола (DWM) -> черный экран при подключении.
Последовательно отваливались службы пользовательских сеансов.
Сервер → труп.
Причина: гуглёж указал на известную в прошлом проблему со стабильностью DWM в Windows Server 2016.Решение лежало на поверхности: установить последние обновления Windows. Почему это не сделали раньше? Вопрос философский.
Вывод 1: не игнорируйте системные обновления! Даже на "стабильных" серверах. Банально, но актуально.
Кейс 2. Стреляем себе в ноги: обновляем «Касперский» без перезагрузки
Проблема: Терминальные серверы (Windows Server 2019 в VMware) начали зависать с потерей сети. В логах – совпадение: незадолго до падения обновлялся Kaspersky с 12.4 до 12.5.
Первая реакция: Нашли причину – при миграции на новую версию консоли администрирования активировалась старая политика автообновления AV. Срочно попросили коллег, в чьём ведении это находилось, перестать хулиганить и выключить безобразие. Выключили политику → казалось, проблема решена. Но не тут-то было.
Акт второй: после планового обновления ПО клиента в ночь на понедельник пользователи массово не смогли работать.
Важная ремарка про архитектуру: есть серверная часть, состоящая из фронта, бэкенда, БД и вот этого всего, а есть клиентская часть, расположенная на DFS (репликация между четырьмя серверами для отказоустойчивости). Обновление прошло штатно, но только на первый взгляд. Один из финальных этапов — завершение работы запущенных процессов ПО (клиентская часть). Этот этап прошёл так же гладко, как и остальные, только список завершённых процессов был короче обычного в несколько раз…
Перезапустили четыре сервера с клиентской частью — лучше не стало. Пришлось проделать то же самое с терминальными серверами — проблема была решена, но временно. Через пару недель – завис критичный терминальный сервер. В логах – массовые дисконнекты в момент зависания.
Охота (продолжение).
Воспроизвели баг:
Установили Kaspersky 12.5 без последующей перезагрузки.
Пользователь штатно завершает сеанс.
Запускается "маховик веселья": отваливаются сетевые библиотеки → все остальные сеансы аварийно завершаются → сервер зависает.
Причина: Баг проявлялся именно при отсутствии перезагрузки после установки/обновления Kaspersky в нашей среде (Windows Server 2019 + VMware). Решение: всегда перезагружать сервер после установки/мажорного обновления антивируса!
Вывод 2: перезагрузка – не формальность! Особенно после установки ПО, глубоко интегрированного в систему (антивирусы, драйверы). Игнорирование = игра в рулетку. Даже если "вроде работает".
Кейс 3. Обновляем железный сервер SWIFT без бэкапа
Задача: срочно обновить ОС на изолированных физических серверах с Windows Server 2016 до 2019. Операция тривиальная, делалась многократно, мы даже образ специально собрали. «Железо» поддерживает работу в Windows Server 2019 — сюрпризов никаких быть не должно. Но был нюанс.
Сегмент изолирован, серверы физические (HP Proliant DL определённой версии), есть доступ по iLO. Серверы никак не бэкапятся, из четырёх дисков собран один-единственный raid, и средствами ОС диск поделён на C и D. В этой ситуации прекрасно всё, включая хотелку заказчика — возможность откатиться, если что-то пойдёт не так. Но, пожалуй, главное ограничение — это сжатые сроки. Поэтому от создания бэкапа отказались.
План: начать с резервного сервера (не с тестового!). Обновление прошло гладко → появилась "подушка безопасности".
Ошибка на тестовом: у него резерва не было, значит, в случае неустранимых проблем – только переустановка с нуля. На последнем этапе обновления (установка драйверов) – фатальная ошибка: Uncorrectable PCI Express Error (Embedded device, Bus 0, Device 0, Function 0, Error status 0x00000000). «Ну всё, приплыли — назад не откатишься, вперёд не докатишься», — наши мысли в тот момент.
Интернет намекал:
PCI-райзер в слоте? Серверы в ЦОД, опечатаны, и их просто так не вскроешь. На бою и резерве пересмотрели все устройства PCI, но ни одного райзера там не нашли. Похоже, конфигурация теста слегка отличалась от боя с резервом. Неудобненько вышло.
Драйвер видеоадаптера Matrox? Его советуют заменить на стандартный, который входит в состав Windows.
Решение: Доступа к железу нет. ОС "полумертвая". Догадка: если ошибка при установке драйвера на устройство, значит, нужно сделать так, чтобы система его не видела (хотя бы временно). Отключили консоль iLO во время загрузки (чтобы система не пыталась инициализировать "проблемное" устройство при наличии активной консоли) → ОС загрузилась! В диспетчере устройств нашли Matrox, установили стандартный драйвер MS. Проблема решена. Устройств PCI в диспетчере было подозрительно много...
Prod: Обновление продуктивного сервера провели уже по известной схеме— с закрытой консолью на этапе установки драйверов. Всё прошло без сучка и задоринки. И без бэкапов. Но этот опыт лучше не повторять.
Вывод 3:
Бэкапы – святое. Игнорировать – преступление. Нам повезло.
Знайте свое железо (и его отличия!). Конфигурация теста != прод.
Иногда помогает "ослепить" систему от проблемного устройства на время критичных операций (но это хак, а не решение!).
Заключение / Мораль:
Рефлексируйте над "Днем Сурка". Каждый баг – урок, если делать работу над ошибками, то, возможно, получится из него выбраться.
Юмор и самоирония – не грех. Серьезные задачи можно (и нужно!) обсуждать без излишнего пафоса. Надеемся, мы немного снизили градус серьезности вашего дня 😉
Мелочи решают. Забытый апдейт, пропущенная перезагрузка, неучтенный нюанс конфигурации – и вот уже ночь на пролете, а сервера – в откате.
До встречи! Делитесь своими историями хорошей охоты в комментариях!