22 июня 2026 года InfoQ выпустил подкаст с Дэном Файнераном из Isovalent at Cisco о том, как технология eBPF ушла далеко за пределы сетевой фильтрации и стала рабочим способом безопасно расширять Linux-ядро. Для разработчиков, DevOps-команд и инженеров по безопасности это важный сигнал: то, что еще недавно ассоциировалось в основном с Cilium и сетями, все заметнее превращается в универсальный слой наблюдаемости и контроля на уровне системных вызовов.
Файнеран обсуждает не абстрактную «эволюцию платформы», а вполне практическую вещь: как получить доступ к внутренностям ядра без переписывания приложений, без инвазивной инструментализации и без старого набора боли в виде нестабильных kernel modules. По данным InfoQ, ключ к этому переходу — строгая модель безопасности eBPF, построенная вокруг verifier, который проверяет программу перед загрузкой в ядро и не дает ей зависнуть, повредить память или уронить систему.
Исторически eBPF вырос из Berkeley Packet Filter — механизма для фильтрации сетевых пакетов. Но, как объясняет Файнеран, нынешнее состояние технологии уже настолько далеко ушло от исходной идеи, что само название eBPF в сообществе давно воспринимается как отдельный термин, а не просто «расширение BPF». Важнее другое: Linux-сообщество десятилетиями крайне осторожно относится к любым изменениям ядра. И не из вредности, а потому что на Linux работает критическая инфраструктура, от мобильных устройств до крупных production-систем. В такой среде обычный путь изменения поведения ядра выглядит тяжеловесно: взять исходники, подготовить patch set, пройти несколько уровней ревью, дождаться решения мейнтейнеров, а потом еще и ждать, когда новый kernel подхватят дистрибутивы вроде Ubuntu или Red Hat. Для команд, которым нужно быстро включить наблюдаемость, сетевую логику или защитный механизм, такой цикл часто просто не совпадает со скоростью бизнеса и инцидентов.
На этом фоне технология eBPF выглядит не магией, а прагматичным компромиссом. Она позволяет подгружать код в работающую систему «на горячую», но не так, как это делали старые kernel modules, способные превратить одну ошибку в kernel panic. Именно verifier, который Файнеран сравнивает с охранником на входе, делает эту модель приемлемой для production: программа должна доказать, что не уйдет в бесконечный цикл, не полезет в недопустимую память и не заблокирует выполнение. Иначе ее просто не пустят в ядро. Для инженерных команд это означает важную вещь: можно добавлять логику ближе к системным вызовам и внутренним слоям ОС, не разворачивая операцию по согласованию патча в апстриме и не принимая на себя все риски кастомных модулей.
Самая известная витрина eBPF по-прежнему связана с сетью, и здесь Файнеран прямо называет Cilium. Но в разговоре он делает акцент не на networking как таковом, а на том, что eBPF стало инструментом наблюдаемости почти за любым syscall. Отсюда и главный практический выигрыш: разработчики и SRE могут смотреть не только на приложение, но и на файловые системы, storage-слои, драйверы устройств и другие части стека, которые традиционные APM-агенты либо не видят, либо видят уже постфактум и слишком грубо. Для русскоязычной IT-аудитории это, пожалуй, самая полезная часть сигнала: технология eBPF — не еще один способ построить красивый дашборд, а способ получать системный контекст там, где раньше приходилось выбирать между слепотой и опасным вмешательством.
Еще интереснее выглядит поворот eBPF в сторону превентивной защиты. Файнеран приводит в пример Tetragon — проект, который использует eBPF не только для наблюдения, но и для «front-foot» enforcement, то есть для реакции до выполнения опасного действия, а не после. Если обычный агент безопасности фиксирует событие уже по факту, то eBPF-программа может быть привязана к pre-hook системного вызова и перехватить попытку до того, как ядро выполнит команду. В практическом выражении это означает возможность блокировать несанкционированное удаление файлов, отсекать опасное поведение и даже применять своего рода live patching для критических CVE, не дожидаясь классического полного цикла обновления. Это не отменяет патч-менеджмент и не превращает eBPF в серебряную пулю, но добавляет командам еще один слой оперативной защиты, особенно полезный там, где downtime слишком дорогой.
Отдельный сюжет — попытка вывести eBPF за пределы Linux. В подкасте говорится о появляющейся поддержке Windows, и это звучит как ранний, но важный сдвиг. Если направление закрепится, у компаний появится шанс постепенно унифицировать архитектуру наблюдаемости и security policy для смешанных сред, где рядом живут Linux-серверы, контейнерные платформы и Windows-хосты. Пока это скорее вектор развития, чем готовый ответ на все вопросы, но уже сам факт движения в эту сторону показывает, что технология eBPF перестает быть нишевым трюком для kernel-энтузиастов и становится частью более широкой инженерной инфраструктуры.
Файнеран затрагивает и менее приятную, но актуальную тему: как выбирать open source-проекты вокруг eBPF в эпоху массовых AI-вкладов. Его рекомендация звучит трезво: смотреть не на список фич и не на поток pull request, а на силу сообщества мейнтейнеров, способность проекта к долгой поддержке и подлинность кода. Для корпоративных команд это особенно важно, потому что слой, который работает рядом с ядром, требует не только удобного маркетинга, но и зрелой инженерной дисциплины. Чем ниже уровень интеграции, тем дороже ошибка и тем меньше пользы от репозитория, который красиво растет на GitHub, но не имеет устойчивой человеческой поддержки.
Главный вывод из разговора прост: технология eBPF быстро выходит из узкой категории «штука для сетевиков» и превращается в общий механизм для наблюдаемости, сетевой логики и превентивного контроля в production-системах. Следующий большой вопрос уже не в том, может ли eBPF заглянуть внутрь ядра, а в том, насколько далеко компании готовы перенести туда собственные правила диагностики и защиты, не превратив удобный низкоуровневый инструмент в еще один сложный слой, которым умеют пользоваться только несколько самых упрямых инженеров в команде.