Сервер перезагрузился без приглашения. Утренний заход обнаруживает чистый экран входа и аптайм в минуты. История ушла вместе с прошлой сессией, и первая реакция почти всегда эмоциональная, а первая команда почти всегда не та. Между эмоцией и командой стоит короткая инструкция из трёх шагов, и она превращает загадку в разбор за двадцать минут. Статья разбирает различие штатного и аварийного выключения, навигацию по загрузкам, чтение хвоста прошлой сессии, типовые причины, автоматику обновлений и аппаратный контур.
Первый вопрос было ли выключение штатным
Все перезагрузки делятся на два вида: осознанные и внезапные, и лечатся они по-разному. Осознанная перезагрузка оставляет следы цивилизованного завершения: сообщения служб о остановке, запись менеджера системы о цели перезагрузки, чистые границы сессии. Внезапная не оставляет ничего: журнал прошлой загрузки просто обрывается, как оборванная фраза.
Различение проводится за минуту: хвост журнала прошлой загрузки читается глазами, и наличие или отсутствие ритуала выключения видно без специальных знаний. Если журнал заканчивается сообщениями о завершении служб, вопрос переходит в плоскость "кто послал команду", и это управленческая загадка. Если журнал обрывается на полуслове, вопрос про ядро, железо или питание, и это техническая загадка.
Второй разведочный вопрос к системе: время. Презагрузка час назад или ровно в три ночи, единожды или каждую ночь, после события или на пустом месте. Время сузит круг подозреваемых быстрее любой команды: ночная регулярность намекает на автоматику, случайность в течение дня на аппаратную природу, следом за конкретным событием на причинно-следственную цепочку.
Третий вопрос к окружению: не заходил ли кто-то. Люди стесняются признаваться в поздних подключениях, а система не стесняется их фиксировать. Журнал подключений прошлой загрузки отвечает на вопрос о сеансах, и это дешевле, чем час технической диагностики в поисках чужой человеческой команды.
Навигация по загрузкам и границы сессий
Журнал системы хранит границы сессий, и первая команда разведки показывает все известные загрузки списком с временами. Каждая загрузка получает номер, и время между строками сразу показывает график: сколько длилась каждая сессия и когда случился разрыв. Список загрузок это кардиограмма сервера, читаемая без приборов.
По номеру прошлой загрузки открывается её журнал целиком. Хвост читается первым: последние записи перед обрывом или завершением. Для осознанных выключений хвост содержит вежливые сообщения о остановке служб и последнюю запись менеджера о цели операции. Для внезапных хвост содержит всё, что система успела зафиксировать до момента обрыва:
journalctl --list-boots
journalctl -b -1 -n 50 --no-pagerОтдельная дисциплина это постоянство журнала. Если журнал хранится только в памяти, прошлые загрузки исчезают вместе с сессиями, и диагностика внезапных перезагрузок теряет главного свидетеля. Сервер с регулярными загадками обязан иметь постоянный журнал на диске, и проверка этого условия входит в первую пятиминутку.
Сравнение нескольких загрузок дополняет картину: если загадки повторяются, выгрузки хвостов нескольких обрывов складываются рядом, и общий паттерн видно сразу. Одинаковые последние события, одинаковое время суток, одинаковый подозреваемый ресурс: три обрыва дают уверенность, которой не даёт один.
Учётная дисциплина завершает навигацию: в протоколе парка фиксируются все внезапные границы сессий, даже те, что разобраны и закрыты. Частота из протокола отвечает на вопрос, растёт ли проблема, и решение о профилактике принимается по тренду, а не по памяти последней тревоги.
Хвост прошлой загрузки и чтение последних событий
Чтение хвоста это искусство малых деталей. Технический обрыв оставляет след последнего события: сообщение ядра об ошибке, тревогу датчика, запись о сбое диска, и всё это за секунды до обрыва. Журнал фиксирует до последнего мгновения, и потому последние строки это обычно самое содержательное место всей диагностики.
Свидетели варьируются. Сообщение о критической ошибке ядра говорит само за себя. Записи датчиков о температуре процессора намекают на контур охлаждения. Ошибки памяти в журнале контроллера указывают на модули. Сообщения о сбоях дисковой подсистемы переводят взгляд на массив. Каждая деталь хвоста это либо улика, либо зацепка, и профессиональное чтение отличает одно от другого быстро.
Отдельный класс улик это тишина. Хвост обрывается без единого тревожного сообщения, на ровном месте, посреди нормальной работы. Такая тишина указывает на питание и аппаратный уровень: мгновенное исчезновение питания не оставляет следов в программном журнале, потому что записи некому и некуда делать. Тишина хвоста при внезапной перезагрузке это улика сама по себе, и она направляет диагностику к контроллеру и блоку питания.
Косвенные следы остаются и в текущей загрузке: счётчики перезагрузок контроллера, отметки в журнале загрузки о причинах предыдущего старта, сообщения самопроверки. Собранные вместе, следы двух сессий дают больше, чем каждый в одиночку, и процедура разбора собирает их по очереди.
Типовые причины от паники ядра до перегрева
Паника ядра это драматичный класс причин: критическая ошибка, из которой система не может выйти, и мгновенная перезагрузка по настройке. Журнал при панике обрывается, а точный текст ошибки остаётся на консоли, которую никто не видел. Для таких случаев существует механизм сохранения снимка при аварии: конфигурация снимка включается заранее, и после перезагрузки в специальном каталоге появляется материал для разбора. Сервер с регулярными необъяснимыми сессиями заслуживает этого механизма до следующей аварии, а не после.
Перегрев это второй драматичный класс. Современные платформы защищают себя сами: пороговые температуры процессора инициируют защитную перезагрузку, и это правильное поведение умирающего охлаждения. Подозрение проверяется чтением температуры в текущей сессии под нагрузкой, осмотром вентиляторов и рёбер, и предупреждением в журнале перед обрывом, если система успела его написать.
Сбои памяти и подсистемы хранения дают более медленные сюжеты с симптомами: исправимые ошибки копятся в журнале днями до рокового сбоя. Утилиты чтения счётчиков ошибок памяти показывают накопление, и сервер с растущими счётчиками отправляется на обслуживание до того, как счётчики вырастут в аварию.
Питание это тихий класс. Просадка, отключение, деградация блока питания не всегда оставляет программные следы, и диагностика уходит в аппаратный контур: журналы контроллера управления, состояние источников, история электропитания машинного зала.
Отдельная проверка контура электропитания это история соседей: сервер, делящий линию с прожорливым оборудованием, собирает просадки чужой жизни. Изоляция линий, измерение качества питания и перенос розетки это скучные меры с хорошим эффектом, и применяются они до того, как контроллер начнёт писать жалобы. Ответы там часто оказываются менее загадочными, чем вид изнутри системы.
Запланированные перезагрузки и автоматика обновлений
Класс управленческих загадок раскрывается списками планов. Планировщик заданий пользователя и системы проверяется на строки перезагрузки, таймеры менеджера системы на задания обслуживания, и списки эти честно показывают, что система делала ночью сама. Автоматика обновлений с режимом автоматической перезагрузки после установки ядра это частый кандидат: поведение правильное, но неожиданное для того, кто не знал о настройке.
Различение запланированной и незапланированной перезагрузки по журналу однозначно: плановая перезагрузка проходит со всеми вежливыми сообщениями, незапланированная без них. И плановая перезагрузка после обновления оставляет следы установки вплоть до минуты, и чтение журнала обновлений рядом с временем обрыва закрывает вопрос.
Человеческий фактор проверяется журналом подключений и журналом аудита команд с правами. Классическая история: коллега подключался вечером, увидел уведомление об обновлении, подтвердил не читая, и ушёл спать с чистой совестью. Журналы не осуждают, журналы фиксируют, и разбор с ними занимает минуты.
Гигиена планов закрывает класс на будущее: плановые перезагрузки задокументированы и объявлены, автоматика обновлений настроена под регламент парка, и каждая следующая ночная перезагрузка перестаёт быть сюрпризом, потому что она либо в плане, либо авария.
Аппаратный контур и журналы контроллера
Сервер это не только операционная система. Контур управления с собственным процессором ведёт собственные журналы: события питания, температурные пороги, сбои компонентов, и доступ к этим журналам отдельный от системного. Чтение журнала контроллера входит в разбор любой внезапной перезагрузки, потому что там фиксируются события, о которых операционная система не успела узнать.
Второй уровень контура это показания датчиков текущей сессии: напряжения, температуры, скорости вентиляторов. Сравнение с нормами платформы и с прошлыми показаниями превращает подозрение в измерение. Деградация питания часто видна по датчикам до того, как станет аварией.
Третий уровень это физика подключения: розетка, кабель, распределение, соседство с прожорливым оборудованием. Аппаратная диагностика заканчивается физическим осмотром, и истории про перезагрузки по вине перебитого кабеля и перегруженной линии вентилятора встречаются чаще, чем это принято признавать в приличном обществе администраторов.
Четвёртый уровень это нагрузочные эксперименты. Подозрение на питание проверяется стресс-тестом с мониторингом датчиков, подозрение на перегрев тестом охлаждения под нагрузкой. Эксперимент превращает гипотезу в факт за полчаса, и это честная цена за уверенность вместо легенды.
Рабочая процедура разбора внезапной перезагрузки
Процедура, ведущая от эмоции к ответу, выглядит так:
- Определить характер перезагрузки по хвосту журнала прошлой сессии;
- Проверить время и регулярность по списку загрузок;
- Исключить плановые причины: планировщики, таймеры, автоматика обновлений;
- Прочитать последние события и проверить наличие снимка аварии;
- Проверить аппаратный контур: журналы контроллера и датчики;
- Зафиксировать вывод в протоколе и подготовить механизм снимков на будущее.
За процедурой стоит принцип последовательности: от программного к аппаратному, от дешёвых проверок к дорогим. Каждый шаг либо закрывает вопрос, либо сужает круг, и диагностике некуда деться от прогресса.
Итоговое суждение спокойное. Внезапная перезагрузка это не приговор и не загадка, это событие с историей, записанной в трёх местах: системном журнале, журнале контроллера и счётчиках планов. Диагностика собирает историю за двадцать минут, и тот же разбор в следующий раз укладывается в десять, потому что процедура однажды составленная работает быстрее эмоций. Сервер, который "перезагружается сам", всегда перестаёт удивлять после первого честного разбора: либо причина найдена, либо установлено наблюдение с механизмами фиксации, и в обоих случаях загадка перестаёт быть загадкой.
Мелкая привычка с большим эффектом: после каждого разбора перезагрузки обновляйте протокол парка одной строкой с причиной и выводом. Через год протокол отвечает на вопросы об истории загадок без единого нового разбора.
Последний штрих процедуры: разбор заканчивается записью о наблюдении, если причина не найдена с первой попытки. Механизм снимков аварий включён, датчики под наблюдением, журналы контроллера в протоколе, и следующая перезагрузка встречает систему во всеоружии, а не с чистым листом.
Практика парков с сотней машин показывает: честный разбор каждой внезапной перезагрузки снижает их частоту сам по себе, потому что у каждой причины находится владелец и лечение. Удивительные перезагрузки любят парки, где их не разбирают.