Наталья Коливошко, эксперт разработки, ранее главный инженер разработки в системно значимом российском банке, несколько лет работала над этими задачами в условиях промышленной эксплуатации.  Ее работа была сосредоточена на трансформации диагностики инцидентов: из ручного и фрагментированного процесса, в структурированную операционную модель, способную сократить первичный анализ инцидента с часов до минут.

— Как эксперт разработки, работавшая с крупномасштабной банковской инфраструктурой, вы играли ключевую техническую роль в изменении подхода к операционной диагностике. С какими повседневными проблемами сталкивались инженерные команды до внедрения этих изменений?

— Сложность заключалась в том, что современные банковские системы имеют распределённую архитектуру. Одна клиентская операция может задействовать множество внутренних сервисов, внешние интеграции, слои обмена сообщениями, системы аутентификации и инфраструктурные компоненты.

Когда возникала проблема, инженеры имели дело не с единичным изолированным отказом. Им приходилось восстанавливать всю операционную цепочку сразу по нескольким системам, работающим одновременно. Исторически это часто требовало ручного анализа логов и сопоставления фрагментированных источников телеметрии.

По мере масштабирования систем такой подход становится все труднее поддерживать в операционной практике.

— Один из ваших вкладов заключался в перестройке самой операционной модели, а не просто во внедрении новых инструментов мониторинга. В чем состояла эта трансформация?

— На тот момент уже существовал большой объем операционных данных: логи, метрики, трассы, дашборды. Но разные сервисы формировали телеметрию по-разному, а операционная видимость была неодинаковой у разных команд.

Одна из ключевых проблем заключалась в том, что телеметрия существовала в виде отдельных фрагментов, а не как целостная операционная модель.

Частью моей роли было выстроить стандартизированный подход к наблюдаемости и диагностике во всем интеграционном ландшафте. Мы ввели единые требования к структурированным логам, распределенной трассировке, корреляционным идентификаторам, метрикам и моделям ошибок. Цель заключалась в том, чтобы события, генерируемые разными сервисами, можно было последовательно интерпретировать на уровне системы.

Это стало основой перехода от реактивного устранения проблем к структурированному операционному анализу.

— Вы также инициировали механизмы операционного анализа, ориентированные на ИИ, которые изменили подход к расследованию инцидентов. Как это выросло из работы с телеметрией?

— Когда телеметрия стала стандартизированной и воспроизводимой, появилась возможность более системно применять методы машинного обучения.

Я инициировала контур анализа телеметрии, ориентированный на AIOps и предназначенный для выявления аномалий, кластеризации инцидентов и помощи в поиске первопричин. Вместо того чтобы инженеры вручную сопоставляли разрозненные операционные события, система могла автоматически находить связанные сигналы и подсвечивать вероятные цепочки деградации.

Важно подчеркнуть, что цель не состояла в замене инженеров. Задача была в том, чтобы сократить время, уходящее на поиск информации, и дать командам возможность сосредоточиться на интерпретации и решениях по восстановлению.

— Одним из результатов, связанных с вашей работой, стало сокращение первичного разбора инцидентов с часов до минут. Как этого удалось добиться на практике?

— До внедрения этих подходов диагностика нередко зависела от многочасового ручного сопоставления логов в разных системах.

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

Этот сдвиг существенно изменил операционный рабочий процесс, потому что команды больше не тратили основную часть времени на реконструкцию технических событий.

— Ваша работа, кажется, одновременно объединяет архитектуру, эксплуатацию и инженерные стандарты. Это изначально было осознанным выбором?

— Да, потому что наблюдаемость становится эффективной только тогда, когда с самого начала встроена в архитектуру и инженерные стандарты.

Если телеметрию и диагностируемость рассматривать как второстепенные задачи, со временем становится значительно сложнее интерпретировать поведение систем во время инцидентов в промышленной эксплуатации. В нашем случае требования к операционной видимости были напрямую включены в стандарты релизов и практики разработки.

Каждый новый сервис, входящий в промышленную эксплуатацию, по умолчанию должен был поддерживать требования к структурированной телеметрии, трассировке, корреляции и диагностируемости.

— Вы также координировали внедрение в нескольких командах, работавших в распределенной банковской среде. Насколько важной была эта часть процесса?

— В распределенных системах согласованность обычно является самой сложной частью.

Операционный анализ зависит не только от отдельных сервисов, но и от того, как разные команды в целом подходят к телеметрии и инженерной дисциплине. Частью моей роли была координация стандартов между командами разработки, эксплуатации, инфраструктуры и смежных систем.

Без общих подходов к телеметрии и операционной видимости даже продвинутые аналитические модели становятся значительно менее эффективными.

— Ваши проекты отражают более широкое движение к банковским операциям с поддержкой ИИ. Почему, на ваш взгляд, этот сдвиг происходит именно сейчас?

— Финансовая инфраструктура движется к средам, где операционной сложностью уже невозможно эффективно управлять только за счет ручного анализа.

ИИ и AIOps становятся актуальными, потому что помогают структурировать операционные данные в масштабе. Но эти технологии приобретают ценность только в сочетании с архитектурной дисциплиной, воспроизводимой телеметрией и четко определенными инженерными стандартами.

Во многом современная операционная зрелость все больше сводится к тому, чтобы делать системы понятными в реальных условиях промышленной эксплуатации.

— Оглядываясь на эту работу, что вы считаете главным инженерным результатом трансформации, которую вы возглавляли?

— Вероятно, переход от фрагментированного операционного устранения проблем к более системной инженерной модели.

Сокращение диагностики с часов до минут было не только ускорением процессов поддержки. Это изменило то, как команды взаимодействовали с системами в эксплуатации,  сделало инфраструктуру более прозрачной, предсказуемой и управляемой по мере дальнейшего роста сложности.