Система стала медленнее после обновления: как найти причину и вернуть стабильность

Если система стала медленнее сразу после обновления пакетов, ядра, драйвера или конфигурации, сначала зафиксируйте симптомы, время начала деградации и состав последнего изменения. Приостановите rollout, автоматические обновления и несвязанные работы. Затем сравните текущие метрики с нормальным состоянием и решите, допустима ли диагностика на продуктивной системе или нужен контролируемый rollback.

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

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

Система стала медленнее после обновления: что делать сразу

Первое действие при регрессии производительности - отделить подтвержденный симптом от предположения. Жалоба пользователей на медленную работу может означать рост latency API, задержку фоновой очереди, увеличение времени SQL-запросов, потерю пакетов или перегрузку одного узла. Запишите, какая операция замедлилась, на каких узлах это видно и какой период затронут.

Зафиксируйте симптом и момент начала деградации

Зафиксируйте точное время первого отклонения и сравните его с началом работ. Для HTTP-сервиса обычно нужны p50, p95 и p99 задержки, RPS, error rate, количество 499, 502, 503 и 504, число активных соединений. Для очередей проверьте длину backlog, время ожидания сообщения и скорость обработки. Для базы данных нужны время запросов, блокировки, соединения и задержка репликации.

На уровне узла сохраните CPU по режимам user, system, iowait и steal, использование RAM, swap, load average, latency диска, IOPS, длину очереди I/O, retransmits и ошибки сетевых интерфейсов. Важна форма графика: постоянный рост p95 после перезагрузки отличается от пиков только во время резервного копирования.

date -Is
uptime
free -h
vmstat 1 5
iostat -xz 1 5
ss -s
systemctl --failed

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

Остановите дальнейшие изменения

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

uname -a
cat /etc/os-release
systemctl cat nginx
systemctl show nginx -p ExecStart -p Environment -p MemoryMax -p CPUQuota
journalctl --since "2026-08-31 10:00:00" --until "2026-08-31 11:00:00"

Для Debian и Ubuntu проверьте историю пакетного менеджера. Для RHEL-подобных систем сохраните историю транзакций. Для контейнеров зафиксируйте digest образа, версию runtime, манифесты и фактические переменные окружения. Конфигурация в Git полезна, но процесс может получить другое значение через systemd drop-in, Helm values, секреты или переменные CI.

Определите границу между диагностикой и срочным откатом

Срочный rollback нужен при критических таймаутах, быстром росте ошибок, отказе зависимых сервисов, потере кворума, исчерпании диска, памяти или пулов соединений. Такой же сценарий применяйте, если нет безопасного временного обхода, а SLO уже нарушается.

Продолжайте диагностику без отката, когда деградация ограничена одним резервным узлом, есть запас мощности, нагрузку можно снизить или симптом стабилен и не угрожает доступности. Решение должно опираться на измеримые критерии: например, p95 выше baseline в 2 раза более 15 минут, error rate выше 2%, очередь растет при постоянном входящем потоке.

Сравните состояние системы до и после изменения

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

Соберите базовые показатели производительности

Минимальный baseline содержит latency, throughput, error rate, CPU, RAM, swap, load average, disk latency, IOPS, сетевые ошибки и время ответа зависимостей. Для приложения добавьте число воркеров, занятые и свободные соединения, размеры очередей, время GC, лимиты cgroups и количество рестартов.

Сопоставьте изменение с журналом событий

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

journalctl --list-boots
journalctl -k -b
journalctl -u nginx --since "2026-08-31 10:00:00"
dmesg -T | tail -n 200

Ищите новые предупреждения, OOM killer, reset устройства, ошибки файловой системы, смену сетевого линка, падение воркеров, ошибки TLS, timeout upstream и сообщения о недоступности DNS. Сопоставляйте частоту сообщений с графиками, а не с единичной строкой в логе.

Проверьте внешнюю нагрузку и фоновые операции

Проверьте объем входящих запросов, размеры полезной нагрузки, расписание резервного копирования, репликацию, cron-задачи, сборку контейнеров, антивирусные проверки и активность пользователей. На узлах с ZFS оцените scrub, resilver, заполнение пула и задержки записи. На виртуальных машинах проверьте steal time и события на стороне гипервизора.

Воспроизведите проблему под сопоставимой нагрузкой на тестовом или резервном узле. Методика подготовки профиля нагрузки и фиксации точки деградации описана в материале о нагрузочном тестировании автоматизированных систем.

Определите, какой компонент вызвал проблемы производительности после обновления

Начинайте с компонента, который меняли, затем проходите по зависимостям в направлении запроса. Проверяйте гипотезу измерением. Изменение трех параметров одновременно делает результат непригодным для расследования.

Пакеты и библиотеки

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

dpkg-query -W -f='${binary:Package} ${Version}\n' | sort
apt history 2>/dev/null || true
rpm -qa --last | head -n 50
dnf history info last

При контейнерной поставке не ограничивайтесь tag образа. Сравните digest, базовый образ, lock-файлы зависимостей и переменные окружения. Tag вроде latest не позволяет доказать, какой набор библиотек работал до инцидента.

Драйверы и ядро

Проверьте загруженное ядро, версию модулей, ошибки драйверов, I/O latency, retransmits и счетчики сетевой карты. Регресс ядра может проявляться ростом system CPU, iowait, softirq, задержками файловой системы или потерями пакетов. На виртуальной машине дополнительно оцените steal time.

uname -r
lsmod
ethtool -S eth0 2>/dev/null | head -n 80
ip -s link show
cat /proc/interrupts | head -n 30

Сравните поведение с предыдущим ядром на тестовом или резервном узле. Не удаляйте старое ядро до завершения постпроверки. При откате проверьте совместимость драйверов, DKMS-модулей и параметров загрузчика.

Конфигурация сервиса и лимиты ресурсов

После обновления сервис может читать другой файл, получить новый unit-файл systemd или запуститься с измененными лимитами. Сравните конфигурацию на диске с эффективными параметрами процесса. Проверьте cgroups, ulimit, LimitNOFILE, MemoryMax, CPUQuota, число воркеров, таймауты, размеры буферов и лимиты конкурентности.

systemctl cat your-service
systemctl show your-service -p LimitNOFILE -p MemoryMax -p CPUQuota
cat /proc/$(pidof your-service | awk '{print $1}')/limits
ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head

Типичный симптом неверного лимита: CPU и диск свободны, но запросы стоят в очереди, растет число ожидающих соединений или сервис быстро достигает лимита файловых дескрипторов. Изменение worker_processes, connection pool или timeout может дать такой же эффект.

Хранилище и сетевой путь

Отделите локальную задержку от задержки сети. Если локальный запрос к сервису быстрый, а путь через балансировщик медленный, проверяйте DNS, TLS, прокси, MTU, потери пакетов, retransmits и заполнение канала. Для дисков проверьте latency, очередь, ошибки файловой системы, RAID, ZFS и свободное место.

Практический порядок проверки потерь, джиттера, DNS- и TLS-сбоев приведен в руководстве по влиянию сети на производительность.

Проверка логов после обновления системы: метрики, события и трейсы

Метрики показывают масштаб и форму инцидента. Логи объясняют события. Трейсы указывают конкретный участок цепочки, который добавил задержку. Проверяйте все три источника в одном временном интервале и с единым часовым поясом.

Начните с графиков, а не с отдельных сообщений в логе

Сначала найдите момент отклонения latency, throughput, ошибок, потребления ресурсов и рестартов. Это сокращает область поиска в логах. Разделите сценарии: единичный всплеск, постоянный регресс после перезапуска, деградация только под нагрузкой, медленная работа одного endpoint или одного узла.

Если p95 вырос при прежних CPU, RAM и RPS, проверьте зависимые сервисы и сеть. Если растет iowait, исследуйте хранилище. Если растет system CPU и softirq, проверьте сетевой драйвер, обработку прерываний и частоту пакетов.

Проверьте системные и сервисные журналы

Фильтруйте журналы по времени начала отклонения и имени компонента. Ищите ошибки, предупреждения, таймауты, повторные подключения, рестарты, OOM, slow requests, отказы соединений и изменение частоты событий.

journalctl -p warning..alert --since "2026-08-31 10:00:00"
journalctl -u your-service --since "2026-08-31 10:00:00" | tail -n 300
dmesg -T | grep -Ei 'error|warn|oom|reset|timeout|I/O'

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

Используйте трейсы для длинной цепочки запроса

Сравните быстрый и медленный trace одного endpoint. Оцените время в приложении, базе данных, кеше, очереди, сетевых вызовах и сериализации ответа. Correlation ID помогает связать запись прокси, лог приложения и запрос к зависимости.

Если приложение тратит 20 мс CPU, а полный запрос длится 900 мс, ищите ожидание: пул соединений, блокировка SQL, очередь, DNS, TLS handshake или сетевой путь. Если trace отсутствует, временно включите выборочное трассирование для проблемного endpoint с ограничением объема данных.

Проверьте саму платформу наблюдаемости

Платформа наблюдаемости тоже может задерживать данные. При хранении временных рядов в VictoriaMetrics, логов и сигналов в ClickHouse, внутренних сущностей в PostgreSQL и оперативного кеша в Redis проверьте задержку ingestion, ошибки запросов, заполнение диска и очереди доставки. Запоздалые метрики создают ложную последовательность событий.

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

Проверьте зависимые компоненты и всю цепочку запроса

Регресс после обновления приложения часто проявляется в базе данных, кеше, очереди, файловом хранилище или сети. Составьте карту пути: клиент, балансировщик, прокси, приложение, БД, кеш, брокер, внешнее API, хранилище. Для каждого звена зафиксируйте latency, ошибки, соединения, очередь и лимиты.

Приложение, прокси и балансировщик

Сравните время обработки на Nginx с upstream response time. Рост времени до передачи запроса приложению указывает на проблему соединений, TLS, балансировки или очереди на прокси. Рост upstream time при стабильном proxy time переносит поиск в приложение или зависимость.

Проверьте keepalive, число активных соединений, backlog, лимиты worker_connections, таймауты, health checks и равномерность распределения по узлам. Один деградировавший узел может повышать p99 всего сервиса при нормальных средних значениях.

Базы данных, кеши и очереди

Проверьте slow queries, блокировки, connection pool, частоту cache miss, заполнение очередей, latency диска и репликацию. Изменение версии драйвера, ORM или TLS-библиотеки способно увеличить число соединений или изменить профиль SQL-запросов. Это видно по росту ожидания соединения и блокировок.

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

Совместимость версий и эффективные настройки

Сверьте версии клиента и сервера, драйверов, ядра Linux, библиотек, контейнерного runtime и базы данных. Проверьте миграции, удаленные параметры и новые значения по умолчанию. Совместимость версии не гарантирует идентичную производительность при смене алгоритма TLS, компрессии, планировщика или настройки connection pool.

Зафиксируйте фактически примененные версии на каждом узле. Частичная поставка опасна: часть кластера может работать с новым runtime, а часть со старым, из-за чего проблема видна только на отдельных запросах.

Как диагностировать проблему с минимальным простоем

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

Собирайте данные без перезапуска сервисов

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

systemctl status your-service --no-pager
ss -tanp
lsof -p $(pidof your-service | awk '{print $1}') | wc -l
ps -eLf | grep your-service

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

Используйте мьют во время плановых работ

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

Задайте срок окончания мьюта и ответственного за его снятие. После работ проверьте latency, error rate, состояние зависимостей и доступность алертов. Бессрочный мьют превращает мониторинг в источник пропущенных инцидентов.

Меняйте только один фактор за раз

Не совмещайте откат пакета, изменение лимитов, очистку кеша и перезапуск базы данных. Для каждой гипотезы запишите ожидаемый эффект и критерий успеха. Пример: вернуть предыдущую версию драйвера на одном резервном узле, пропустить через него часть трафика и сравнить p95, retransmits и error rate в течение 30 минут.

Если результат не изменился, верните тестовую правку или отметьте гипотезу как неподтвержденную. Такой журнал экономит время следующей смене и не допускает повторной проверки уже исключенного фактора.

Безопасный откат изменения и проверка восстановления

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

Подготовьте состояние для возврата

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

uname -r
ls -1 /boot | grep -E 'vmlinuz|initrd'
systemctl cat your-service
find /etc/your-service -type f -maxdepth 2 -print

Выберите минимальный и обратимый откат

Сначала откатывайте подтвержденный компонент: конкретный пакет, драйвер, ядро или параметр конфигурации. Полный возврат системы увеличивает риск несовместимости и усложняет расследование. Выполняйте проверку на одном узле, если архитектура допускает канареечный сценарий.

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

Подтвердите восстановление по измеримым критериям

Сравните latency, throughput, error rate, CPU, память, I/O, сеть и состояние зависимостей с baseline. Проверьте несколько типовых операций: чтение, запись, фоновую обработку, авторизацию, работу через прокси и доступ к базе данных. Короткое улучшение сразу после перезапуска не доказывает устранение причины.

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

Что делать, если откат невозможен

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

Для сервисов, которым требуется быстрое добавление резервных ресурсов, подойдет облачная инфраструктура с серверными мощностями, хранилищем, базами данных и Kubernetes, например Timeweb Cloud. Перед переключением проверьте сетевую связность, секреты, версии runtime и совместимость данных.

Профилактика регрессий после обновлений и изменений конфигурации

Плановые изменения проходят предсказуемее, когда baseline, критерии остановки и план возврата готовы до начала работ. Runbook должен позволять дежурному инженеру быстро определить нормальное состояние, проверить изменения и принять решение об откате без поиска информации по нескольким системам.

Определите baseline и критерии успеха до работ

До обновления зафиксируйте допустимые p95 и p99 latency, error rate, нагрузку CPU, потребление памяти, disk latency, сетевые ошибки, время ответа БД и длину очереди. Подготовьте дашборд и ссылки на журналы. Укажите пороги остановки rollout, например рост p95 более чем на 30% при сопоставимом RPS или error rate выше согласованного лимита.

Для подробной диагностики серверных ресурсов используйте практическое руководство по метрикам CPU, памяти, диска и сети в Linux.

Тестируйте обновление поэтапно

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

Канареечный узел должен получать реальный или репрезентативный трафик. Синтетическая проверка полезна для доступности, но может не показать рост времени сложных SQL-запросов, проблемы кеша или задержки фоновой очереди.

Проверяйте релиз и срок поддержки

Перед обновлением проверьте release notes, известные дефекты, требования к ядру и драйверам, совместимость зависимостей и срок поддержки ветки. Debian 13.6 включает 124 обновления с исправлениями стабильности и 120 обновлений с устранением уязвимостей. При этом любой пакетный релиз требует проверки в вашей связке сервисов и нагрузки.

LTS-поддержка Debian 11 Bullseye завершена. Использование ветки без сопровождения повышает риск остаться без исправления критичной проблемы или безопасного пути обновления. Зафиксируйте жизненный цикл дистрибутива в плане работ до того, как версия станет неподдерживаемой.

Оформите runbook для следующего изменения

В runbook внесите состав изменения, ответственных, baseline, ссылки на дашборды и логи, порядок проверки, критерии отката, команду включения и снятия мьюта, план возврата и обязательную постпроверку. После инцидента добавьте подтвержденную первопричину, ошибочные гипотезы и факторы, которые помогли быстрее локализовать проблему.

Короткая последовательность для дежурной смены: зафиксировать симптомы, остановить rollout, сохранить данные, проверить нагрузку и зависимости, подтвердить гипотезу одним изменением, выполнить минимальный rollback при необходимости, сравнить контрольные метрики после восстановления.