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