Поделиться
Александр Светкин, Microsoft: Роль ИИ смещается от обнаружения аномалий к помощи в устранении инцидентов
Согласно аналитическим обзорам российского ИТ-рынка, компании всё активнее рассматривают ИИ как способ сократить время обнаружения инцидентов, снизить нагрузку на инженерные команды и повысить предсказуемость работы критичных систем. При этом практическое внедрение ИИ в реагирование на инциденты остается сложной задачей. Организациям приходится искать баланс между автоматизацией и контролем, выстраивать доверие к рекомендациям алгоритмов и учитывать ограничения продакшен-среды — от качества данных до требований по безопасности. CNews поговорил с Александром Светкиным, Principal Software Engineer, Microsoft, с многолетним опытом работы с высоконагруженными ИТ-системами. В интервью он рассказывает, на каких этапах инцидент-менеджмента ИИ уже дает наибольшую ценность, где проходит граница безопасной автоматизации и как меняется роль инженеров и SRE-команд по мере внедрения ИИ в продакшене.
CNews: Вы работали с крупными высоконагруженными ИТ-системами в разных ролях и в разных компаниях, в том числе во «ВКонтакте» и в «Яндекс AdTech». Как за последние годы в целом изменился подход к реагированию на инциденты?
Александр Светкин: Если смотреть в целом, изменения носят скорее эволюционный, чем революционный характер, но их влияние на практику очень заметно. Подход к реагированию постепенно смещается от реактивного устранения последствий и «хаотичного дебага» к более проактивному и формализованному процессу. На инциденты всё чаще смотрят системно — как на часть операционной модели, а не как на уникальные события. Для крупных компаний такой подход был нормой давно, теперь его всё активнее перенимают и небольшие команды.
На фоне роста архитектурной сложности и стремления реагировать на инциденты как можно раньше возрастает роль observability. Объем собираемых данных увеличивается, и на определенном этапе проблемой становится шум: избыточное количество алертов и графиков начинает мешать работе инженеров, что, в частности, отмечается в отчёте State of Observability 2025 от Splunk.
Практика написания постмортемов постепенно становится рутинной, а не исключительной мерой для крупных инцидентов, что позволяет системно работать с причинами сбоев и снижать вероятность их повторения. Параллельно всё больше внимания уделяется созданию плейбуков реагирования на инциденты: формализация типовых сценариев заметно упрощает работу инженеров и снижает когнитивную нагрузку в стрессовых ситуациях. Эффективность такого подхода, в частности, обсуждается в докладе на SREcon APAC.
Хорошо описанные плейбуки не только ускоряют реакцию, но и создают основу для автоматического выполнения отдельных шагов — при наличии соответствующих и безопасных инструментов.
На этом фоне закономерно растёт интерес к AIOps (AI for Operations): когда информации становится слишком много, ручные подходы перестают масштабироваться, и именно развитие observability и накопление данных сделали практическое применение ИИ в реагировании на инциденты возможным.
CNews: На каком этапе управления инцидентом ИИ сегодня дает наибольшую ценность: обнаружение, анализ причин или выбор действий по восстановлению?
Александр Светкин: Методы машинного обучения для автоматического обнаружения аномалий и выявления корреляций на основе метрик и структурированных логов существуют уже достаточно давно — фактически, с этого и начиналось направление AIOps. Современные LLM расширяют возможности анализа разнородных данных, в частности логов, однако их применение для обнаружения аномалий в высоконагруженных системах ограничено производительностью и стоимостью инференса.
Наибольший практический интерес сегодня представляет автоматизированное определение причин инцидентов (root cause analysis), диагностика и триаж. В этих сценариях LLM хорошо справляются с суммаризацией большого объёма разрозненной неструктурированной информации — алертов, логов, тикетов, данных о прошлых инцидентах, постмортемов и истории изменений. Это позволяет инженерам быстрее понять контекст происходящего и перейти к осмысленным действиям. Исследования ByteDance (TikTok) показывают, что ИИ-ассистенты способны существенно сокращать время, затрачиваемое на диагностику, что особенно важно при большом масштабе и высокой частоте инцидентов.
Несмотря на значительный объём данных во время инцидента, он на порядки меньше того, что требуется для обнаружения аномалий, поэтому применение более «дорогих» моделей здесь оправдано. При этом результаты пока остаются неоднозначными: в бенчмарке OpenRCA агент от Anthropic показал точность около 92%, тогда как большинство других моделей не превышают 10–11%. Причины такого разрыва пока не ясны — исходный код агента закрыт, и воспроизводимость результатов остаётся под вопросом.
Логичным следующим шагом после RCA выглядит автоматизация действий по устранению инцидентов. Эксперименты Microsoft показывают, что качество и полнота плейбуков критически влияют на способность ИИ формировать корректный план восстановления. При этом предоставление ИИ прямого доступа к выполнению команд в production-среде по-прежнему выглядит рискованным. Поэтому в ближайшей перспективе наиболее жизнеспособной остаётся модель human-in-the-loop, где ИИ предлагает конкретные действия, а окончательное решение принимает инженер.
CNews: Какие типы инцидентов лучше всего поддаются автоматизации с помощью ИИ, а где участие инженера по-прежнему критично?
Александр Светкин: На практике лучше всего поддаются автоматизации повторяющиеся, типовые инциденты, которые модель может надежно классифицировать и для которых существует четко описанный и относительно безопасный порядок действий. В таких сценариях ИИ способен подтвердить тип инцидента и предложить конкретные шаги по его устранению, включая генерацию команд, а инженер выполняет функцию контроля и принятия решения.
Участие человека остается критичным при недостатке данных, высокой неопределенности причины инцидента и рисках необратимого ущерба, где автоматические действия могут усугубить ситуацию.
CNews: Где, на ваш взгляд, проходит граница безопасной автоматизации? В каких сценариях автоматические действия могут быть рискованными?
Александр Светкин: Безопасными можно считать действия, которые не меняют состояние системы или легко обратимы, не требуют привилегированного доступа и имеют небольшой blast radius. К таким сценариям относятся сбор диагностических данных, откат сервиса на предыдущую версию, переключение фича-флагов и другие операции с ограниченным воздействием.
Рискованными становятся действия, которые необратимо меняют данные, имеют большой blast radius или требуют широких прав доступа. Риск особенно высок в ситуациях, когда автоматические действия могут ухудшить состояние системы быстрее, чем человек успеет это заметить и остановить процесс.
CNews: С какими ключевыми ограничениями сталкиваются ИИ-решения при работе в продакшене?
Александр Светкин: Главное ограничение — качество и полнота данных. Модель не сможет корректно диагностировать инцидент, если у неё нет доступа к ключевым сигналам: логам, трассировкам, истории релизов и изменениям конфигурации. Ограниченный набор метрик часто приводит к неверным выводам.
Дополнительную сложность создает быстро меняющаяся микросервисная архитектура: плейбуки и знания об инцидентах быстро устаревают, из-за чего рекомендации ИИ со временем теряют точность.
CNews: Как использование ИИ влияет на ключевые метрики надежности: время обнаружения, время восстановления и частоту повторных инцидентов?
Александр Светкин: В целом ожидается улучшение метрик за счет сокращения времени обнаружения и восстановления, однако универсальных и гарантированных эффектов пока не существует. Успешные кейсы применения AIOps есть, но их прямое масштабирование на другие системы редко дает сопоставимый результат.
По моему опыту, сокращение TTM (Time To Mitigate) возможно в диапазоне от 5 до 75% в зависимости от сервиса — в первую очередь за счет ускорения триажа и снижения времени ожидания начала работ. В системах без этапа триажа эффект будет значительно ниже.
Предотвращение инцидентов остается более сложной задачей. Как отмечают отраслевые эксперты, ИИ положительно влияет на митигацию, но не устраняет саму природу инцидентов. ИИ может помочь с анализом корневых причин и подготовкой постмортемов, однако внесение изменений в систему для устранения этих причин по-прежнему выходит за рамки применения AIOps.
CNews: Как вы аргументируете инвестиции в ИИ для реагирования на инциденты руководству?
Александр Светкин: В идеальном случае существует прямая связь между метриками надёжности и бизнес-показателями, например стоимостью минуты простоя. Тогда ценность ИИ легко выражается через сокращение времени восстановления.
Если такой связи нет, используются прокси-метрики: время, затрачиваемое инженерами на диагностику, коммуникации и сопровождение инцидентов. Ценность ИИ в этом случае — в высвобождении ресурсов, которые можно направить на развитие продукта.
CNews: Как вы выстраиваете процессы, чтобы инженеры начали доверять рекомендациям или решениям ИИ, особенно в стрессовой ситуации при серьёзном инциденте?
Александр Светкин: ИИ должен давать рекомендации только при высокой степени уверенности. В остальных случаях он должен ограничиваться диагностическими шагами или запросом дополнительной информации. Практика показывает, что даже одна «уверенная ошибка» или галлюцинация резко подрывает доверие инженеров.
Чтобы модель была проверяемой, необходимо обеспечивать прозрачность ее рассуждений. Инженер должен видеть, на каких данных основан вывод, какие факты использованы, а какие предположены. Рекомендации, сопровождаемые объяснением логики и ссылкой на соответствующий плейбук, верифицируются значительно проще, чем изолированные инструкции.
Важно также иметь простой механизм обратной связи: возможность быстро отметить ответ ИИ как корректный или ошибочный и оставить комментарий. И, наконец, доверие формируется через практику — ИИ должен регулярно использоваться в учениях и разборах инцидентов, иначе в реальной стрессовой ситуации им просто не будут пользоваться.
Короткая ссылка
