12 секунд стали 2 — и никто не понимал почему. История о том, как ИИ нашел три скрытых проблемы в Linux за один час

Разобраться в сложном сбое в Linux за несколько минут вместо нескольких часов звучит как фантастика. Но разработчик Йозеф Бачик уверяет, что именно к такому результату привёл выход Systing 1.0 – инструмента для трассировки системы на базе eBPF, который теперь умеет анализировать данные с помощью искусственного интеллекта.

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

Однако со временем проявились проблемы. Трассы получались слишком объёмными и перегруженными деталями, из-за чего анализ превращался в сложную задачу. Часть данных, например взаимодействие приложения с сетью, и вовсе трудно отобразить наглядно: половина операций проходит в контексте приложения, половина – в контексте ядра Linux. Разбор таких ситуаций требовал ручной работы.

В версии 1.0 Бачик изменил подход. Вместо хранения данных только в формате трасс Perfetto Systing теперь умеет записывать результаты в базу данных DuckDB. Такой формат позволяет выполнять запросы на языке SQL напрямую, без долгой конвертации. По словам автора, DuckDB заметно быстрее при работе с большими объёмами данных.

Главное новшество – интеграция с Claude Code через специальный модуль. Вместо написания и поддержки собственных сценариев анализа Бачик передал разбор трасс искусственному интеллекту. Claude получает доступ к базе DuckDB и отвечает на вопросы о поведении системы в реальном времени.

В одном из примеров речь шла о сетевом приложении, которое не достигало ожидаемой скорости передачи данных. После запуска Systing и передачи трассы в Claude Code система обнаружила внутренние блокировки в библиотеке на Rust. После исправления время передачи сократилось с 12 до 8 секунд. Затем выяснилось, что распаковка данных происходила в том же потоке, что и сетевые операции. После разделения задач время упало до 4 секунд. Финальной причиной стали слишком маленькие буферы передачи, создававшие лишнюю нагрузку. После корректировки показатель снизился до 2 секунд. Вся работа заняла около часа.

Но на этом история не закончилась. В рабочей среде время передачи внезапно выросло до 24 секунд. Новая трассировка показала, что машина в продакшене тратит значительное время на kretprobe в «горячей» сетевой функции. Systing сохраняет информацию о версии ядра, и Claude сразу заметил разницу: в тестовой среде использовалось ядро Linux 6.12, а в продакшене – 6.6. Один из инструментов безопасности подключался к сетевой функции через eBPF-перехват, причём в версии 6.6 такие перехваты работают заметно медленнее. Оптимизации увеличили число сетевых операций в секунду, из-за чего накладные расходы от kretprobe стали критичными и замедлили систему.

По словам Бачика, раньше на поиск подобной причины ушли бы часы. Основное время заняла запись трассы в рабочей среде, а анализ с помощью Claude занял меньше пяти минут. После перевода рабочих задач на более новую версию ядра скорость передачи вернулась к 2 секундам. Разработчик называет новую версию Systing переломным моментом. Инструмент из средства визуализации постепенно превратился в помощника, который не только собирает данные, но и помогает быстро находить корень проблемы.