История одного проекта. Как ИИ помог доказать, что виноват антивирус с ИИ
Есть инженерские расследования, где с самого начала понятно, куда копать. А есть истории, в которых первые несколько дней ты даже не можешь честно назвать главный класс проблемы. Именно такой случай у меня произошёл на проекте по внедрению 1С:КИП
Мы внедряли не «одну галочку мониторинга», а полноценный контур с 1С:ЦКК как рабочим центром контроля и с заделом под 1С:ЦУП и 1С:ЦА. То есть речь шла о живой инфраструктуре, где мониторинг, диагностика и административные сценарии должны были повысить управляемость. Вместо этого на одном из этапов именно контур наблюдения сам стал выглядеть как источник нестабильности.
Сразу оговорюсь: все технические примеры ниже обезличены. В анализ с ИИ я передавал только служебные артефакты: имена процессов, временные метки, сигнатуры сбоев, faulting module, коды ошибок и фрагменты командных сток без чувствительных данных прикладного контура. Ни бизнес-данные, ни содержимое баз, ни рабочая переписка заказчика в это расследование не попадали.
Сначала это выглядело не как история про антивирус
Самая большая ошибка, которую здесь легко было сделать, — слишком рано выбрать виновника. В момент старта у меня не было никакого готового ответа в духе «это точно SentinelOne». Я вообще не знал, что на серверах стоит именно этот антивирус, и то, что его процессы висели в диспетчере задач, поначалу не вызывало никаких подозрений. Картина выглядела как смесь сразу нескольких плохо связанных проблем.
Самое первое, что я увидел, —пропадание счётчиков по серверам. Служба АгентКИП собирает метрики и передаёт их в ЦКК, и на отдельных серверах эта передача периодически прекращалась. Подключаясь к серверу, от которого перестали приходить данные, я каждый раз видел разную картину: иногда процесс агента ещё висел в диспетчере задач, иногда его уже не было; иногда служба числилась запущенной, а иногда нет. В каждой из этих ситуаций помогало одно и то же: убить процесс, если он существовал, и перезапустить службу. Но важно вот что — происходило это не постоянно и без чёткой периодичности. Агент мог отработать несколько недель без единого сбоя, а мог падать несколько раз в неделю.
Рядом с этим всплывали и другие неприятные симптомы. Было три случая за всё время, когда процессы cmd.exe и typeperf.exe, через которые АгентКИП собирает счётчики, начинали неконтролируемо размножаться. АгентКИП генерировал очередной запуск команды сбора метрик, но то ли сам умирал, оставив дочерний процесс работать, то ли создавал дубли — точную механику на тот момент восстановить было невозможно. Важно другое: процессы множились до тех пор, пока не съедали всю оперативную память сервера. Результат — полная деградация: свободная память на нуле, сервер практически неработоспособен.
Были ситуации, когда у одного разработчика на сервере КИП зависал интерфейс RDP так, что работать было невозможно, а другой в это же время спокойно работал и не испытывал никаких проблем. Периодически и без какой-либо закономерности служба ring переставала передавать информацию о лицензиях, из-за чего ЦКК воспринимал это как отвалившуюся лицензию и генерировал инцидент, хотя на самом деле лицензия никуда не девалась и пользователи прекрасно работали.
Пользовательская формулировка в такие моменты обычно очень простая: «1С тормозит» или «всё зависло». Но для инженера это худший тип жалобы — слишком общий, чтобы сразу найти корень. И первичные гипотезы были вполне земные. Я рассматривал сам КИП, режим опроса метрик, проблемы IIS-публикации, перегрузку сервера, особенности лицензирования через ring, платформенные сбои 1С. Более того, закрадывалась мысль, что сам алгоритм АгентаКИП недостаточно стабильный и именно в его коде живёт ошибка. Но АгентКИП работает на Java, код его закрыт — посмотреть внутрь и отладить нет никакой возможности. Антивирус же в этот список на старте входил не как основной подозреваемый, а как один из многих возможных факторов.
Первый полезный шаг был очень прозаичным
Поворотным моментом стало не «озарение», а довольно скучное инженерное решение: перестать лечить симптомы и сначала собрать нормальную карту процессов.
До WER, до дампов и до разговоров про faulting module мне нужно было ответить на более базовые вопросы. Кто именно кого запускает? Какие дочерние процессы зависают? Как долго они живут? Что у них в командной строке? Какие цепочки воспроизводятся регулярно, а какие случайны? Что происходит рядом по времени: старт, зависание, завершение, перезапуск?
Именно на этом этапе всплыли две важные процессные цепочки. Первая была связана с cmd.exe и typeperf.exe: сбор метрик шёл с интервалом в пять секунд и без внятного ограничения времени жизни, из-за чего при неблагоприятном сценарии дочерний процесс мог зависнуть и остаться висеть. Вторая цепочка вела к ring.cmd и java.exe на стороне проверки лицензий. Рядом с ними стабильно присутствовал AgentETP, а в общей картине процессов был хорошо заметен и тяжёлый след самого SentinelOne по CPU и RAM.
Это было важно, потому что расследование перестало быть разговором в стиле «серверу плохо». У меня появилась древовидная процессная карта, из которой стало видно: да, часть проблемы действительно находится процессах мониторинга КИП. Но одновременно стало понятно и другое: этим нельзя объяснить всё. Даже если поправить агрессивный запуск typeperf, это не объясняет, почему валятся AgentETP, PowerShell, рабочие процессы 1С и процессы cmd.exe.
Почему обычные инструменты быстро упёрлись в потолок
На этом этапе я довольно быстро дошёл до неприятной границы. Обычные средства наблюдения показывали последствия, но не показывали источник. Event Viewer честно фиксировал APPCRASH и похожие события. Диспетчер задач подтверждал деградацию. PowerShell позволял снимать снимки процессов. Но всё это отвечало на вопрос «что упало», а не на вопрос «кто это сломал».
Ситуацию дополнительно портило качество исторических данных. Security log очищался слишком быстро, и ретроспективно восстановить всю картину по событиям создания процессов уже было нельзя. Лог активности WMI тоже не хранился так, как мне было нужно. Иными словами, я пришёл к классической проблеме полевого расследования: когда по-настоящему важные данные нужны уже вчера, а типовая инфраструктурная телеметрия хранит их недолго или вообще не хранит.
И вот тут я упёрся уже не только в ограничение инструментов, но и в границу собственной специализации. Это проблема общего характера, и она, думаю, знакома многим: ты хорошо разбираешься в своей области — в моём случае это 1С-инфраструктура — но вдруг оказываешься перед задачей из совершенно другого домена, где у тебя недостаточно навыков и опыта.
Я уже упоминал, что АгентКИП — это Java-приложение с закрытым исходным кодом. Когда сбои начали накапливаться, всерьёз казалось, что проблема именно в его алгоритмах: нестабильный код, который периодически ломается. Но проверить эту гипотезу было невозможно — ни поставить точку останова, ни залезть в логику, ни понять, почему процесс вдруг умирает. А когда разговор дошёл до faulting module, сигнатур WER, разборов дампов, WinDbg и внутреннего поведения закрытого EDR-агента — это уже совсем другая глубина. ОС почти всегда валит вину на процесс-жертву. Исходников SentinelOne у меня, естественно, нет. А значит, без низкоуровневой доказательной базы любой разговор с безопасностью обречён на формат «нам кажется». Для корпоративной среды этого недостаточно. И справедливо недостаточно.
Почему я вообще решил подключить ИИ
К этому моменту ИИ для меня уже не был игрушкой или «генератором красивых текстов». У меня был вполне прикладной опыт его использования в рабочих задачах..
Например, незадолго до этого я разбирал другой неприятный кейс в том же техническом ландшафте: ws-публикация 1С:КИП жила в режиме постоянных SeanceContextException, IIS засыпал журналы ответами 401.1, 401.2 и 401.5, а Security log — событиями 4625. Проблема выглядела как очередная «мистика 1С», но на деле оказалась аутентификационной каруселью между IIS и механизмом сеансов платформы. ИИ тогда помог мне быстрее собрать матрицу проверки: свести вместе ТЖ 1С, W3C-логи IIS, настройки публикации и модель аутентификации, а потом дойти до правильного архитектурного решения. Для RemoteControl пришлось оставить только Windows-аутентификацию, а анонимный доступ не тащить туда, где он рушит сеансы.
Кроме этого, я уже использовал ИИ для анализа официальной документации, для структурирования больших массивов требований и переписки, а также для подготовки и проверки проектных предложений. Поэтому в новом расследовании я смотрел на него не как на машину ответов, а как на ускоритель инженерного мышления.
И это важная разница. В хорошей инженерной работе ИИ не заменяет специалиста. Он помогает быстрее собрать следующую итерацию: уточнить гипотезу, не забыть слабые места в диагностике, быстрее написать черновой скрипт, подсказать, какие артефакты ещё стоит сохранить, и ускорить вход в смежную область, если времени на полноценное отдельное погружение нет.
Что именно сделал ИИ в этом расследовании
Самое ценное, что дал ИИ, — не готовый вердикт «виноват SentinelOne», а правильный порядок действий.
Вместо хаотичного перебора у меня появилась нормальная схема расследования. Сначала надо собрать телеметрию по процессам в реальном времени, а не надеяться только на посмертные снимки. Потом фиксировать жизненный цикл процессов и временную корреляцию событий. Потом отдельно мониторить WER ReportQueue и забирать оттуда артефакты. И уже после этого переходить к разбору faulting module и дампов.
Фактически вместе с ИИ я итерационно довёл PowerShell-инструмент, который раз в пять секунд снимал состояние нужных процессов, вёл часовой сеанс наблюдения, отслеживал старт и завершение через WMI, собирал релевантные события из журналов Windows и параллельно смотрел в WER ReportQueue. Всё это было специально сужено до ограниченного набора процессов: 1С, AgentETP, связанных служебных утилит и процессов SentinelOne. И по соображениям приватности, и по соображениям нагрузки.
Это тоже важный практический момент. В такие расследования очень легко утащить «всё подряд»: все журналы, весь Security, все дампы, все процессы. На реальном сервере так делать нельзя. Нужно собирать только то, что помогает ответить на конкретный инженерный вопрос, и не создавать дополнительную турбулентность там, где и без того нестабильно.
Где хаос впервые начал складываться в доказательство
Настоящий перелом произошёл, когда мы системно обработали WER. До этого я видел множество симптомов, но они плохо складывались в единую причинно-следственную цепочку. С WER картина стала другой. За период наблюдения накопился уже не просто набор случайных падений, а большой массив повторяющихся сбоев, больше тысячи записей. Среди регулярно падающих процессов оказались AgentETP, PowerShell, zabbix_sender, conhost и рабочие процессы 1С. То есть набор «жертв» был слишком широким для одной локальной ошибки внутри КИП.
Но ключевым оказалось даже не это. В файлах Report.wer начал повторяться один и тот же тип улики: в качестве faulting module всплывал InProcessClient64.dll, связанный с SentinelOne. Рядом повторялись характерные коды ошибок: Access Violation, BEX64, сбои PowerShell с OutOfMemoryException. Отдельные процессы падали по-разному, но внешний модуль рядом с ними всплывал слишком последовательно, чтобы это можно было списать на совпадение.
В этот момент подозрение на антивирус перестало быть интуицией. Оно стало инженерной гипотезой, у которой появился материальный след.
И здесь важно сделать честную оговорку. По ходу расследования вскрылись и сопутствующие проблемы, которые тоже надо было исправлять. Например, сам контур мониторинга действительно использовал слишком агрессивный режим вызова typeperf. Отдельного внимания требовали и публикации IIS. То есть история не сводилась к формуле «во всём виноват только один компонент, а всё остальное идеально». Но именно WER показал, что даже после учёта этих факторов остаётся ещё один системный разрушитель, который вмешивается уже на другом уровне.
Где ИИ дал максимальный эффект
Максимальную пользу ИИ дал не в момент сбора логов, а на стыке WER и дампов.
Когда у тебя в руках уже есть сотни и тысячи строк артефактов, дальше возникает другая проблема: как не утонуть в них и как не принять слабую корреляцию за сильную улику. ИИ здесь помог как навигатор. Не в смысле «он сам всё понял за меня», а в смысле «он ускорил проход по методике». Куда смотреть в WinDbg? Какие поля в WER для меня ключевые, а какие вторичны? Что считать сильным совпадением между разными падениями? Как отделять полезный сигнал от информационного шума?
Именно на этом шаге выяснилось, что в дампах AgentETP и zabbix_sender воспроизводится один и тот же дефектный участок внутри модуля SentinelOne. Для рабочих процессов 1С WER стабильно показывал либо тот же внешний модуль, либо сигнатуры падений, хорошо согласующиеся с внешним вмешательством. Для PowerShell обнаружился отдельный разрушительный сценарий с OutOfMemoryException. Для conhost разбор помог объяснить, почему проблемы временами ощущались даже как «странное» поведение консоли и RDP, а не только как падение прикладных компонентов.
С практической точки зрения это был тот самый момент, ради которого весь поход и затевался. Потому что спор с службой безопасностью на уровне ну он же рядом в процессах почти бесполезен. А вот повторяющийся модуль, повторяющийся сбойный участок и несколько независимых классов падений, которые на него указывают, это уже предметный технический разговор.
Что удалось получить на выходе
На выходе у меня получилась уже не эмоциональная жалоба, а нормальная доказательная цепочка.
С одной стороны, были процессные данные: кто кого запускал, что зависало, как себя вели cmd.exe, typeperf.exe, ring и связанные дочерние процессы. С другой стороны, WER-отчёты и сигнатуры падений. С третьей, низкоуровневые подтверждения по дампам. В сумме этого оказалось достаточно, чтобы подготовить предложения по корректировке политик и исключений SentinelOne не в формате «давайте попробуем наугад», а в формате «вот процессы, пути и сценарии, по которым у нас есть подтверждённый технический конфликт».
На текущем этапе часть предложенных мер уже была применена, а часть остаётся на рассмотрении у службы безопасности. Для реального корпоративного проекта это, на мой взгляд, нормальный исход. Важнее другое: разговор удалось перевести из плоскости общих ощущений в обсуждение конкретных артефактов и проверяемых технических решений.
Что я вынес из этой истории
Для меня это очень показательный кейс про зрелое использование ИИ в инженерной работе.
ИИ не заменил мне ни диагностику, ни ответственность за выводы. Он не отменил необходимости проверять гипотезы на реальных данных. Он не выдал «магический правильный ответ» по первой команде. Но он резко сократил время на переход между этапами расследования: от хаоса симптомов к структуре, от структуры к сбору нужных данных, от данных к доказательной цепочке.
Если совсем коротко, ИИ помог мне в пяти вещах. Он ускорил построение плана расследования. Помог быстро собрать и довести до ума скрипты диагностики. Подсветил WER как ключевой источник фактуры. Ускорил вход в низкоуровневую область с дампами и faulting module. И, наконец, помог упаковать всё это не в «ощущения инженера», а в материал, с которым можно идти на согласование.
И да, в этой истории есть хорошая инженерная ирония. SentinelOne сам относится к классу систем, которые активно используют ИИ и поведенческий анализ для защиты инфраструктуры. В моём случае другой ИИ помог достаточно быстро собрать доказательства того, что именно этот слой защиты и стал существенной частью проблемы.
Без ИИ я, скорее всего, тоже дошёл бы до похожего вывода. Но точно позже. А в проектных расследованиях разница между «дошёл через два дня» и «дошёл через две недели» — это уже не академический вопрос, а цена простоя, затянутых согласований и потерянного темпа внедрения.
Андрей Поздняков
Технический архитектор