Эксплуатация Zabbix: борьба с шумом алертов, бэкап мониторинга, безопасность и обновления

Меня зовут Евгений Семёнов, я технический директор «АйТи Фреш» — мы пятнадцать с лишним лет ведём IT-аутсорсинг московских компаний до 50 рабочих мест и держим собственные серверы в дата-центре МТС. Это четвёртая статья цикла про Zabbix: в обзоре системы в 2026 году я объяснял выбор, в пошаговой инструкции мы ставили сервер, в материале про интеграции — подключали Telegram, 1С и Grafana. Сегодня — о том, о чём почти никто не пишет: что происходит с мониторингом на второй год жизни и почему без регламента эксплуатации он тихо умирает.

Почему мониторинг умирает через полгода

Когда мы принимаем на обслуживание инфраструктуру от предыдущего подрядчика, Zabbix там чаще всего уже стоит. И примерно в семи случаях из десяти он находится в одном и том же состоянии: система формально работает, метрики собираются, но чат с алертами давно замьючен всеми участниками, а на панели Problems висит полсотни «вечных» проблем, на которые никто не смотрит месяцами. Технически мониторинг жив. Практически — мёртв.

Сценарий деградации всегда одинаковый. Внедрили, навесили шаблоны из коробки, порадовались графикам. Шаблоны с дефолтными порогами начали генерить 30–40 уведомлений в день: «нагрузка процессора высоковата», «диск заполнен на 81%», «сервис перезапустился». Первую неделю инженеры честно читали каждое. Через месяц — проглядывали по диагонали. Через три — поставили чат на беззвучный режим. А через полгода случилась настоящая авария, и её уведомление утонуло в потоке между «низкий уровень свободной памяти» и «высокая утилизация swap». Узнали о проблеме от позвонившего клиента — то есть мониторинга как бы и не было.

Самое опасное здесь даже не пропущенная авария, а ложное чувство защищённости. Руководитель уверен: «у нас есть Zabbix, мы всё видим». По факту компания платит за иллюзию. Поэтому первый принцип нашего регламента эксплуатации звучит жёстко: каждый алерт обязан требовать действия. Если уведомление можно проигнорировать без последствий — это не алерт, а строчка лога, и ей место в истории метрик, а не в чате дежурной смены. Всё остальное в этой статье — способы дожать систему до этого принципа и удержать её в таком состоянии годами.

Регламент борьбы с шумом: пять инструментов

Тюнинг триггеров — не разовое мероприятие при внедрении, а процедура, которую мы проводим у каждого клиента ежеквартально. Инфраструктура меняется: добавились серверы, вырос объём базы 1С, переехал филиал — и пороги, выставленные год назад, начинают либо молчать о важном, либо кричать о нормальном. Разберу все пять инструментов регламента.

Квартальный разбор Top 100 triggers

Отправная точка — штатный отчёт Reports → Top 100 triggers: он показывает, какие триггеры срабатывали чаще всего за выбранный период. Мы выгружаем его за квартал и разбираем первую десятку. По каждой строке принимается одно из трёх решений, и «оставить как есть» среди них нет:

• Чиним причину в инфраструктуре. Если триггер «мало места на диске» сработал 60 раз за квартал — проблема не в пороге, а в диске: расширяем том, настраиваем ротацию логов, чистим временные файлы 1С.
• Перенастраиваем порог или логику. Резервный канал интернета действительно моргает по ночам, и оператор это не починит — значит, триггер должен срабатывать не на единичный обрыв, а на недоступность дольше десяти минут.
• Понижаем severity. Событие информативно, но действий не требует — переводим его из Warning в Information, и оно перестаёт попадать в оперативный канал, оставаясь в истории.

Час работы раз в квартал сокращает поток уведомлений в разы. По нашей статистике типовой офис на 30–40 рабочих мест генерирует после первого же такого разбора не 400–500 событий в месяц, а 100–150, а после второго-третьего — стабильные 10–20 алертов, каждый из которых реально важен.

Гистерезис: лекарство от флаппинга

Классическая болезнь дефолтных триггеров — «флаппинг»: диск заполнен на 89,9%, файл подкачки подрос — 90,1%, алерт; ужался — 89,8%, восстановление; и так двадцать раз за ночь. Каждое колебание — два сообщения в чат. Лечится это раздельными условиями проблемы и восстановления (recovery expression): проблема регистрируется при пересечении верхней границы, а закрывается только когда метрика опустилась заметно ниже. Зазор между порогами и есть гистерезис:

# Триггер "Мало места на /data" с гистерезисом
# Problem expression — проблема при заполнении > 90%:
last(/Файл-сервер/vfs.fs.size[/data,pused])>90

# Recovery expression — восстановление только при < 85%:
last(/Файл-сервер/vfs.fs.size[/data,pused])<85

# В интерфейсе: OK event generation = Recovery expression

Пока метрика болтается в коридоре 85–90%, триггер молчит в состоянии «проблема», и дежурный получает ровно два сообщения: одно о начале, одно о завершении. Тот же приём мы применяем к загрузке CPU (проблема при среднем >85% за 5 минут, восстановление при <65%) и к свободной памяти. Правило простое: любой триггер на «плавающую» метрику обязан иметь recovery expression, иначе он рано или поздно начнёт флапать.

Зависимости триггеров: один алерт вместо сорока

Вторая по частоте причина шума — каскады. Упал роутер филиала — и Zabbix честно рапортует о недоступности всех сорока устройств за ним: серверов, принтеров, точек доступа. Дежурный получает лавину, в которой ещё нужно догадаться, что первопричина одна. Решение штатное — зависимости триггеров (trigger dependencies): триггерам «хост недоступен» для всего, что стоит за роутером, назначается зависимость от триггера «роутер недоступен». Пока родительская проблема активна, зависимые триггеры не генерируют событий вообще. В чат приходит одно сообщение — «недоступен шлюз филиала», и оно же указывает, куда бежать. У нас выстраивание дерева зависимостей — обязательный пункт сдачи мониторинга: сначала магистральные узлы, от них — серверы, от серверов — сервисы.

nodata() и перезагрузки: ложные «агент недоступен»

Третий источник мусора — уведомления «Zabbix agent is not available» на каждую штатную перезагрузку после установки обновлений Windows. Сервер ушёл в ребут на четыре минуты — агент замолчал — триггер сработал — через пять минут восстановился. Формально всё верно, практически — шум. Мы правим окно в функции nodata() так, чтобы оно заведомо перекрывало нормальную длительность перезагрузки конкретной машины:

# Плохо: алерт через 3 минуты тишины — ловит каждый ребут
nodata(/MSK-SRV01/agent.ping,3m)=1

# Наш стандарт для серверов с долгим циклом обновлений:
nodata(/MSK-SRV01/agent.ping,10m)=1

# Для критичных хостов, где 10 минут ждать нельзя,
# оставляем 3m, но закрываем плановые ребуты maintenance-окном

Здесь важно не увлечься: растянув таймаут до получаса «чтобы не беспокоило», вы на те же полчаса отложите обнаружение настоящего падения. Десять минут — компромисс, который у нас прижился для рядовых серверов; для боевого хоста 1С таймаут остаётся коротким, а плановые работы закрываются следующим инструментом.

Maintenance-окна на плановые работы

Любые запланированные работы — обновление платформы 1С, перезагрузка гипервизора, замена диска — у нас начинаются с постановки maintenance-окна в Data collection → Maintenance. Режим «со сбором данных, без уведомлений»: история метрик остаётся полной, но ни одно событие в чат не уходит. Периодические работы (еженедельная перезагрузка терминального сервера, ночное окно бэкапа) оформлены постоянными расписаниями раз и навсегда. Побочный бонус — чистая отчётность: плановые простои не портят статистику доступности, которую мы ежемесячно показываем клиенту.

База данных: главный потребитель ресурсов

Если алертный шум — болезнь первого полугодия, то распухшая база — болезнь второго года. Таблицы history* (сырые значения каждой метрики) и trends* (почасовые агрегаты) растут линейно от числа элементов данных и частоты опроса. Тысяча метрик с опросом раз в минуту — это полтора миллиона записей в сутки только в history. Сначала растёт диск, потом начинают тормозить графики за длинные периоды, потом housekeeping перестаёт успевать за ростом — и администратор узнаёт о проблеме, когда место на разделе БД кончилось.

Наш стандарт хранения для офиса до 50 рабочих мест: history 14–31 день, trends 1 год. Сырые поминутные значения старше месяца не нужны никому и никогда — для разбора «а что было в марте» достаточно почасовых трендов. Эти сроки задаются в шаблонах на уровне элементов данных (History storage period / Trend storage period), а вычищает устаревшее либо housekeeping, либо партиционирование:

# /etc/zabbix/zabbix_server.conf — параметры housekeeping
# Как часто запускается уборка (часов между запусками)
HousekeepingFrequency=1
# Максимум строк, удаляемых за один проход по таблице
MaxHousekeeperDelete=50000

# Проверить, успевает ли уборка: внутренний item
# zabbix[process,housekeeper,avg,busy] — если стабильно
# десятки процентов, housekeeping не справляется

Housekeeping удаляет строки обычными DELETE — на больших объёмах это медленно и нагружает БД. Поэтому на инсталляциях от пары тысяч метрик мы уходим на PostgreSQL + TimescaleDB: history и trends превращаются в партиционированные гипертаблицы, устаревшие чанки не вычищаются построчно, а отбрасываются целиком — мгновенно и без нагрузки. Вдобавок TimescaleDB даёт нативное сжатие: на наших инсталляциях старые чанки history ужимаются до 90% — поддержка этого сжатия в Zabbix штатная, включается параметрами в интерфейсе (Administration → Housekeeping).

Отдельно про items-сироты: при удалении хоста из интерфейса Zabbix его история удаляется housekeeping'ом постепенно, но если уборка отключена или не успевает — мёртвые данные копятся вечно. При аудитах чужих инсталляций мы всегда сверяем объём таблиц с числом живых элементов данных: расхождение в разы — верный признак, что в базе лежит археология.

Кто мониторит мониторинг: бэкап и самоконтроль

Неудобный вопрос, который я задаю на каждом аудите: «Zabbix следит за всеми серверами. А кто следит за самим Zabbix?» Обычно в ответ — пауза. Между тем сервер мониторинга — такая же машина: у неё умирают диски, кончается место, зависают процессы. И если она умерла молча, вы живёте без глаз и не знаете об этом.

Что бэкапим: два дампа и три каталога

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

# Ежедневно: конфигурация без history/trends (DR-вариант)
pg_dump -U zabbix -Fc \
  --exclude-table-data='history*' \
  --exclude-table-data='trends*' \
  zabbix > /backup/zabbix/config_$(date +%F).dump

# Еженедельно (вс, ночью): полный дамп с историей
pg_dump -U zabbix -Fc zabbix \
  > /backup/zabbix/full_$(date +%F).dump

# Плюс файлы, которых нет в базе:
tar czf /backup/zabbix/etc_$(date +%F).tgz \
  /etc/zabbix \
  /usr/lib/zabbix/alertscripts \
  /usr/lib/zabbix/externalscripts

Обратите внимание на третью команду: конфиги сервера, кастомные скрипты оповещений и внешних проверок в базе не лежат, и про них при бэкапе «только БД» забывают почти все. Копии, разумеется, уезжают с самого сервера мониторинга на внешнее хранилище — бэкап, лежащий на той же машине, бэкапом не считается.

Восстановление за 30 минут: проверенный сценарий

Дамп без истории существует ради скорости аварийного восстановления. Наш отработанный сценарий DR укладывается в полчаса: разворачиваем чистую VM, ставим пакеты той же версии Zabbix (вот зачем мы фиксируем версию в документации клиента), создаём пустую базу, заливаем вчерашний конфигурационный дамп, возвращаем /etc/zabbix и скрипты из архива, стартуем сервер. Мониторинг снова видит все хосты, все триггеры и все действия; история начинает копиться с нуля, а полная — доливается позже из еженедельного дампа, если она вообще нужна. Этот сценарий мы не просто описали — мы его прогоняем на тестовой площадке раз в год, потому что непроверенный план восстановления равен его отсутствию.

Внешняя проверка: независимая нода

Бэкап спасает от потери, но не отвечает на вопрос «жив ли мониторинг прямо сейчас». Если сервер Zabbix завис, он не отправит алерт о собственной смерти — некому. Поэтому у каждого нашего клиента есть внешний контролёр: крон-скрипт на независимой площадке (у нас — сервер в ЦОД МТС), который раз в несколько минут дёргает API клиентского Zabbix и проверяет, что тот отвечает и что среди недавних значений есть свежие. Молчит API или данные протухли — алерт уходит дежурному по другому каналу, не через тот же Zabbix. Скрипт умещается в десяток строк:

#!/bin/bash
# Внешний контроль Zabbix: жив ли API (запускается с независимой ноды)
RESP=$(curl -s -m 10 -X POST https://zabbix.client.ru/api_jsonrpc.php \
  -H 'Content-Type: application/json-rpc' \
  -d '{"jsonrpc":"2.0","method":"apiinfo.version","params":{},"id":1}')

echo "$RESP" | grep -q '"result"' || \
  curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" \
    -d chat_id=$CHAT -d text="ALARM: Zabbix клиента не отвечает по API"

Внутренний самоконтроль: очередь, пуллеры, кэши

Третий слой — внутренние элементы данных самого Zabbix, которые предупреждают о деградации до того, как она станет отказом. Три метрики, на которые у нас всегда стоят триггеры: zabbix[queue,10m] — сколько метрик не может получить значения больше десяти минут (растущая очередь означает, что сервер не успевает опрашивать); zabbix[process,poller,avg,busy] — средняя занятость процессов-опросчиков (стабильно выше 75% — пора увеличивать StartPollers); zabbix[rcache,buffer,pfree] и zabbix[wcache,values] — свободное место в кэшах конфигурации и записи. Все они входят в штатный шаблон Zabbix server health — его нужно просто не забыть навесить на сам сервер и не отключать триггеры «потому что жёлтым горит».

Безопасность: что мы находим в чужих инсталляциях

Zabbix знает о вашей сети всё: адреса, версии ОС, имена сервисов, топологию. А через удалённые команды агентов он ещё и умеет выполнять код на каждом сервере. Захваченный злоумышленником сервер мониторинга — это готовая карта инфраструктуры плюс фреймворк для развёртывания чего угодно на все хосты разом. При этом относятся к его защите обычно как к «внутренней игрушке». Вот реальные находки из наших аудитов за последние пару лет — каждая встречалась не по одному разу:

• Панель наружу по HTTP с дефолтным Admin/zabbix. Веб-интерфейс проброшен на публичный IP «чтобы смотреть из дома», TLS нет, а стандартная пара логин-пароль Admin/zabbix не менялась с установки. Боты находят такие панели сканерами за часы.
• Агенты с Server=0.0.0.0/0. Параметр Server в конфиге агента ограничивает, кто вправе запрашивать метрики. Маска «все адреса» означает, что любой узел сети (а при кривом файрволе — и не только сети) может читать с сервера всё, что умеет агент.
• EnableRemoteCommands=1 на всех агентах. Кто-то однажды настроил автоперезапуск службы и включил удалённые команды везде. Теперь тот, кто контролирует сервер Zabbix (см. пункт про Admin/zabbix), выполняет произвольные команды на каждом сервере компании. В современных агентах этот механизм управляется директивами AllowKey=system.run[*]/DenyKey — и разрешать его стоит точечно, на тех единицах хостов, где автоматическое действие реально нужно.
• Древние версии 4.x/5.x «работает — не трогай». В устаревших ветках за годы накопились опубликованные уязвимости, включая SQL-инъекции в компонентах фронтенда. Непатченная панель с известными CVE, да ещё и доступная из интернета, — это не мониторинг, это приглашение.

Наш стандарт защиты укладывается в пять пунктов и не требует героизма: панель доступна только через VPN или с белого списка IP; поверх — обязательный HTTPS (сертификат Let's Encrypt обходится в одну строку certbot); учётка Admin переименована и с нормальным паролем, а для людей заведены персональные логины; роли — по минимуму необходимого: директору, который хочет «видеть, что всё зелёное», выдаётся read-only дашборд, а не Super admin; версия — только поддерживаемая LTS с установленными обновлениями. Ничего из этого не стоит денег — только полдня дисциплины.

Шифрование трафика агентов: PSK за один вечер

Момент, о котором не догадывается большинство эксплуатантов: по умолчанию весь трафик между агентом и сервером ходит открытым текстом. Метрики, имена хостов, результаты кастомных проверок, а если включены удалённые команды — то и сами команды. Внутри доверенного офисного сегмента с этим ещё можно мириться; когда филиал шлёт метрики через интернет — нельзя категорически: перехват и подмена трафика превращаются из теории в практику.

Минимальный достаточный вариант — шифрование по предварительно разделённому ключу (PSK). Генерируем ключ, кладём его на агент и на сервер, включаем TLS с двух сторон:

# 1. Генерируем 256-битный ключ
openssl rand -hex 32 > /etc/zabbix/agent.psk
chmod 640 /etc/zabbix/agent.psk
chown root:zabbix /etc/zabbix/agent.psk

# 2. /etc/zabbix/zabbix_agentd.conf на хосте:
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=PSK-msk-srv01
TLSPSKFile=/etc/zabbix/agent.psk

# 3. На сервере: Data collection → Hosts → хост →
#    Encryption → Connections to/from host = PSK,
#    вставить identity и hex-строку ключа. Рестарт агента.

Identity делаем уникальным на хост — так компрометация одного ключа не раскрывает остальные, а отзыв сводится к правке одного хоста. На Windows-парке ключи и конфиги мы раскатываем через GPO: PowerShell-скрипт кладёт файл ключа, правит конфиг и перезапускает службу агента — сотня машин обрабатывается за один цикл групповых политик. Вариант с сертификатами (TLSConnect=cert) технически строже — есть проверка подлинности через цепочку доверия и отзыв через CRL, — но требует собственного удостоверяющего центра; мы применяем его там, где внутренняя CA уже развёрнута для других задач. Для типового офиса PSK закрывает угрозу полностью.

Обновления без страха

Страх обновлений — вторая причина, по которой мы встречаем в 2026 году живые инсталляции Zabbix 4.x. Логика «работает — не трогай» понятна, но она копит и дыры безопасности, и будущую боль: чем дольше откладываешь, тем длиннее прыжок. При понимании механики обновления Zabbix — рутина, а не подвиг.

Минорные: ежемесячная гигиена

Обновление внутри ветки (7.0.x → 7.0.y) не меняет схему базы данных — это исправления ошибок и уязвимостей. Процедура: снапшот VM или свежий дамп конфигурации, затем apt update && apt upgrade (или dnf upgrade), рестарт zabbix-server и фронтенда. Две минуты простоя, никакой миграции. Мы делаем это ежемесячно в стандартное окно обслуживания вместе с прочими обновлениями сервера — на июль 2026-го актуальная сборка LTS-ветки — 7.0.28.

Мажорные: порядок имеет значение

Переход между ветками (6.0 → 7.0) — уже операция со сценарием, потому что меняется схема БД. Порядок строгий:

1. Полный бэкап базы — не «должен где-то быть», а снятый сейчас и проверенный на читаемость.
2. Обновление пакетов сервера. При первом старте новой версии zabbix-server сам мигрирует схему БД. Важно: на большой базе с годами history миграция может идти часы, и всё это время мониторинг лежит. Ещё один аргумент держать history коротким — мигрировать 20 ГБ и 200 ГБ, мягко говоря, не одно и то же. Прогресс виден в логе сервера — не паникуйте и не прерывайте процесс.
3. Фронтенд — обновляется следом за сервером, вместе с ним.
4. Агенты — не спеша. Старые агенты совместимы с новым сервером (обратная совместимость — официальная политика Zabbix), поэтому парк агентов мы обновляем плавно, волнами через GPO, в течение месяца-двух.

Совместимость агентов и прокси

Тонкость, на которой спотыкаются: правило совместимости для прокси жёстче, чем для агентов. Zabbix proxy должен быть той же мажорной версии, что и сервер, — прокси 6.0 с сервером 7.0 работать не будет. Поэтому при мажорном апгрейде прокси в филиалах обновляются сразу после сервера, в то же окно, а вот агенты могут подождать. Перед началом работ мы сверяем список: сервер → прокси → агенты, и для каждого элемента понимаем, когда он переезжает.

Наше правило: прод на LTS

Zabbix выпускает LTS-ветки с поддержкой в несколько лет и промежуточные ветки с коротким жизненным циклом. Расклад на июль 2026-го: LTS 7.0 (текущая 7.0.28) поддерживается до 2029 года; промежуточная ветка 7.4 (текущая 7.4.12) прекращает поддержку уже 30 сентября 2026-го; Zabbix 8.0 пока в стадии беты (8.0.0beta2 от 9 июля). Отсюда правило, которое мы не нарушаем: боевые инсталляции — только на LTS. Поставить клиенту 7.4 ради пары свежих фич — значит через считаные месяцы остаться без патчей безопасности и встать перед принудительным апгрейдом. Промежуточные ветки и беты живут у нас на стенде: посмотреть новое, подготовиться к следующей LTS — и не более.

Zabbix proxy для филиалов и мониторинга снаружи

Как только у клиента появляется второй офис, встаёт вопрос: как мониторить площадку, до которой сервер достаёт только через интернет? Открывать порты всех агентов наружу — безумие с точки зрения безопасности. Правильный ответ — Zabbix proxy: маленький процесс, который живёт внутри филиала, сам опрашивает локальные хосты и отправляет собранное на центральный сервер одним исходящим соединением, разумеется — шифрованным (PSK работает и здесь).

Прокси нетребователен до смешного: виртуалка с 1 vCPU и 1 ГБ памяти или контейнер на уже существующем хосте тянет филиал на пару десятков устройств, локальную базу он держит в SQLite. Главное эксплуатационное достоинство — буферизация: при обрыве канала между офисами прокси продолжает собирать метрики и складывает их локально, а после восстановления связи доливает накопленное на сервер. История остаётся без дыр, и вы видите, что происходило в филиале, пока он был отрезан. Глубина буфера задаётся в конфиге:

# /etc/zabbix/zabbix_proxy.conf — минимум для филиала
Server=zabbix.client.ru        # центральный сервер
Hostname=proxy-filial-tula     # имя, как заведено на сервере
ProxyMode=0                    # active: сам стучится наружу
ProxyOfflineBuffer=24          # часов хранить данные при обрыве
ConfigFrequency=300            # как часто забирать конфигурацию

# Шифрование до сервера — тот же PSK, что и у агентов:
TLSConnect=psk
TLSPSKIdentity=PSK-proxy-tula
TLSPSKFile=/etc/zabbix/proxy.psk

Активный режим (ProxyMode=0) удобен тем, что филиалу не нужен ни один входящий порт: прокси сам инициирует соединение к центру, и на стороне филиала файрвол остаётся глухим. Тот же паттерн мы используем для DMZ: хосты демилитаризованной зоны опрашивает прокси, стоящий внутри неё, и наружу из DMZ смотрит одно-единственное исходящее соединение вместо веера портов агентов. Для клиентов с двумя и более офисами прокси у нас ставится по умолчанию, без обсуждения — это дешевле и безопаснее любых альтернатив с пробросом портов.

Годовой регламент эксплуатации ITfresh одним списком

Всё описанное выше складывается в короткий регламент, который у нас закреплён за дежурной сменой и вписан в договор сопровождения. Ничего сверхъестественного — важна не сложность, а неотвратимость выполнения:

Заметьте: в таблице нет ни одного пункта «купить», зато каждый пункт — «делать регулярно». В этом и состоит главный вывод четырёх статей цикла: мониторинг — это процесс, а не инсталляция. Zabbix, поставленный и брошенный, деградирует до замьюченного чата за полгода — мы наблюдали это десятки раз. Zabbix, который ведут по регламенту, годами остаётся системой, которая будит инженера раньше, чем позвонит клиент.

Если ваш мониторинг уже похож на описанную в начале «спам-машину» — его почти всегда можно реанимировать без переустановки: разбор триггеров, чистка базы, бэкап, закрытие дыр безопасности занимают несколько вечерних окон. Мы в «АйТи Фреш» проводим такие аудиты и берём эксплуатацию Zabbix на сопровождение по описанному регламенту. Напишите в Telegram @ITfresh_Boss или позвоните +7 903 729-62-41 — посмотрим вашу инсталляцию и честно скажем, что в ней лечится тюнингом, а что пора обновлять.