В городе наступает ночь, на дежурство выступает цифровой техлид. Он склеивает сотни алертов в один инцидент, отвечает первой линии и пишет разборы, пока инженер допивает кофе. А ещё предлагает решения, но порой такие, после которых всё может стать только хуже. Поэтому последнее слово всегда остаётся за человеком, который контролирует принятие решений.
Одну такую неделю из жизни с AIOps-агентом мы разыграли как пьесу в пяти действиях. В ней есть дежурный Алексей, его цифровой напарник и кнопка перезапуска, которая весь сюжет висит на дашборде и ждёт своего часа. Алексей — собирательный персонаж. Ночные звонки, остывший кофе и общий чат, где три команды чинят одну поломку, придумывать не пришлось.
Действующие лица
АЛЕКСЕЙ, дежурный инженер. Рассчитывал на спокойную неделю.
ЦИФРОВОЙ ТЕХЛИД, AIOps-агент.
ДЕНИС РОМАНОВ, рассказчик и автор. Директор центра развития ИИ-продуктов ИТ-экосистемы «Лукоморье». Раньше тоже руководил развитием продуктов и с тех пор про любую технологию первым делом спрашивает, что она даёт пользователю.
СЕТЕВАЯ НОДА. Лежит. Роль без слов.
340 АЛЕРТОВ. Массовка.
КНОПКА ПЕРЕЗАПУСКА. Висит на дашборде с первого действия. По Чехову, к финалу должна сработать.
Сцена из третьего действия. На сцену разом высыпает массовка: 340 алертов за двадцать минут.
АЛЕКСЕЙ. Сколько их там?
ЦИФРОВОЙ ТЕХЛИД. Все про одну ноду. Я склеил их в один инцидент, можно выдохнуть.
АЛЕКСЕЙ (выдыхает и косится на кнопку перезапуска).
ЦИФРОВОЙ ТЕХЛИД. На меня даже не смотри. Это твоя реплика.
Пролог. Пятница, 04:40. Начнём с конца
Кухня, ноутбук, рядом кружка остывающего кофе. Дашборды зелёные, дежурный телефон лежит экраном вниз и наконец-то молчит. Инцидент закрыт полчаса назад. Алексей сидит перед ноутбуком и не торопится его закрывать, хотя после такой ночи ему уже пора спать.
АЛЕКСЕЙ (ноутбуку). Знаешь, что смешно? Ты сейчас уверен, что всех спас, хотя спасло нас то, что последнее слово осталось за мной.
На экране мигает уведомление. Цифровой техлид отчитывается за ночную смену: 23 тикета первой линии разобраны, три статьи в базе знаний обновлены, черновик отчёта по инциденту готов.
Алексей листает отчёт. Хронология собрана, логи приложены, гипотезы верны, выводы скромно помечены как предварительные.
АЛЕКСЕЙ. Неплохо. Финальный абзац допишу сам.
Он откидывается на спинку стула и наконец делает глоток. Кофе ледяной.
Чтобы понять, почему Алексей прав, вернёмся в понедельник, когда неделя ещё обещала быть спокойной.
От рассказчика. Как я смотрю на эту историю
AIOps для меня такой же продукт, как любой другой: у него есть пользователь, и в нашей пьесе это дежурный инженер. Его боль знакома всем, кто хоть раз держал дежурный телефон в руках: сотни одинаковых алертов за 20 минут, 47 минут на восстановление сервиса и ночи, которые заканчиваются под утро.
Такой пользователь измеряет успех очень приземлённо: сколько времени ушло на диагностику, сколько на восстановление и сколько сбоев прошло незамеченными. Красивый дашборд для отчёта перед начальством в этот список не входит, как бы его ни любили на планёрках.
И есть граница, которую не стоит переходить ни одному продукту: лечение не должно оказаться хуже болезни.
Действие первое. Понедельник, 19:15. Навигатор
Офис пустеет. Алексей с кружкой кофе смотрит на монитор.
Цифрового техлида подключили к боевому мониторингу три недели назад. Раньше вечер понедельника чаще всего выглядел совсем иначе: сотни тревог, три команды в общем чате выясняли, чья это поломка. Восстановление тянулось почти час, и кто-то уже задумчиво поглядывал на бутылку виски в шкафу. Сегодня на экране один инцидент, и тот уже закрыт.
За эти три недели среднее время восстановления (MTTR) сократилось с 47 до 12 минут, а шумовых алертов стало на 73 % меньше. Алексей к этой тишине ещё не привык.
Пока Алексей пьёт кофе, агент отвечает на 14 тикетов первой линии, пишет черновик статьи о постоянно возвращающейся ошибке сертификата и собирает сводку по инфраструктуре. Все тикеты закрыты с пометкой «решено автоматически». Алексей относится к этой пометке примерно как к детскому «мам, я уроки сделал» и открывает пару тикетов наугад.
АЛЕКСЕЙ. Седьмой ты закрыл рано. Клиент описывал нестандартный сценарий, тут надо было уточнить детали.
ЦИФРОВОЙ ТЕХЛИД. Переоткрываю. Задаю клиенту уточняющий вопрос. Добавляю случай в выборку для разбора ошибок.
Алексей называет цифрового техлида личным навигатором. Тот знает все пробки, подсказывает повороты и честно предупреждает о ямах. Руль при этом остаётся у инженера, и Алексея это вполне устраивает.
Как это устроено
Пока Алексей допивает кофе, заглянем навигатору под капот.
Мы увидим там два слоя. Нижний занимается классическим AIOps: собирает сигналы из разных источников, ищет странности в поведении систем и склеивает связанные оповещения в инцидент. Поверх него работает языковой агент. Это он пишет тикеты и статьи, рассылает сводки и объясняет гипотезы человеческим языком. Цифровым техлидом мы называем всю связку целиком.
Рабочая схема такая: источники данных → сбор и нормализация → корреляция и поиск аномалий → агент → инженер.
Главное отличие от порогового мониторинга в том, что система учитывает контекст. Классическое правило срабатывает, когда загрузка CPU превышает 80 %. Представьте сервер, который каждую ночь собирает отчёты: для него 90 % в два часа ночи — обычная рабочая смена. И другой сервер, который по ночам обычно дремлет: если у него в три часа ночи нагрузка вдруг подскакивает с 20 % до 55 %, это уже повод насторожиться. Пороговое правило ошибётся дважды: в первом случае разбудит дежурного зря, во втором промолчит. AIOps сравнивает каждую цифру с её собственной историей.
Диагноз система оставляет инженеру. Её работа в том, чтобы сузить круг подозреваемых: убрать шум, показать самую вероятную причину и положить на стол факты для проверки.
Действие второе. Вторник, 14:32. Пять следов одной поломки
Разгар дня. Где-то у себя дома покупатель нажимает «Оплатить».
Обычно оплата проходит за 0,8 секунды. Сегодня система задумывается на 5,2 секунды и выдаёт ошибку. Покупатель вздыхает, закрывает вкладку и уходит к конкурентам. В пиковый час таких покупателей 120 в минуту.
По одному графику такое дело не раскрыть, тут нужен детектив, и улики ему придётся собирать из пяти источников.
Метрики рассказывают, что происходит прямо сейчас: CPU, память, время ответа, длина очереди, место на диске. По ним видно, что сервис замедлился. Почему — метрики не знают: высокую нагрузку дают и наплыв покупателей, и неудачное обновление, и зависший процесс.
Логи — бортовой журнал, который ведут сразу на десятке языков: 12 миллионов записей в сутки в разных форматах. Где-то там лежат самые ценные строки вроде «Не удалось подключиться к БД» или «Сертификат истёк», но руками их не выловить. Агент перелопачивает этот поток и оставляет суть.
Трассировки восстанавливают маршрут запроса: сайт, корзина, платёжный сервис, база данных, внешний банк. По ним видно, на каком участке пути запрос застрял. Без трассировок каждая команда держит в руках только свою улику и спорит с соседями, кто виноват.
История изменений показывает, кто крутился рядом с местом происшествия: выпуск версии, смена настроек, перенос базы, замена сертификата. Инциденты часто происходят вскоре после изменений, поэтому агент накладывает шкалу изменений на графики ошибок. Совпадение по времени ещё не приговор, но для версии вполне годится.
Обращения клиентов добавляют улики, которых нет на графике. Люди порой замечают проблему раньше мониторинга: страница открывается, но кнопка оплаты молчит. Сегодня поддержка получила 847 обращений за 11 минут, и первое пришло раньше первого технического алерта.
Пока Алексей разглядывает метрики, агент сопоставляет логи с трассировками, сверяется с историей изменений и выкладывает на стол три версии.
ЦИФРОВОЙ ТЕХЛИД. Версия первая: перегрузка платёжного шлюза из-за наплыва покупателей. Версия вторая: деградация соединения с базой после утреннего обновления конфигурации. Версия третья: завис процесс на ноде корзины, и задержка расходится каскадом.
АЛЕКСЕЙ. Наплыв в пределах нормы, первую вычёркиваем. Вторая мне нравится больше всех, проверяю её.
Через двадцать минут вторая версия подтверждается: утреннее обновление конфигурации ужало пул соединений с базой. Конфигурацию откатывают, и оплата снова укладывается в свои 0,8 секунды.
Тем временем агент успел собрать черновик статьи для базы знаний «Паттерн задержки больше 5 секунд в платёжном потоке» со ссылками на логи, трассировки и похожие инциденты за последние 90 дней. Алексей читает его уже после отката, когда можно выдохнуть.
АЛЕКСЕЙ. Добавь раздел «Ложные следы». И отметь, что наплыв покупателей был в пределах нормы.
ЦИФРОВОЙ ТЕХЛИД. Добавил. Отметил. Что-нибудь ещё?
АЛЕКСЕЙ (после паузы). Пока нет.
Откат помог, но Алексея кое-что волнует: с чего бы пулу соединений вообще заканчиваться? Он оставляет себе пометку вернуться к базе.
Каждый источник даёт только часть ответа. Система видит перегруженный сервер, но может не знать, какой сервис на нём живёт, кто от него зависит и что в нём недавно меняли. Чем полнее данные и точнее описаны связи, тем точнее выводы. Старое правило garbage in, garbage out работает и здесь.
Действие третье. Среда, 18:00. 340 уведомлений, один инцидент
Конец рабочего дня. Алексей уже надел куртку.
Месяц назад, ещё до цифрового техлида, в компании Алексея отказал сетевой узел. За 20 минут на сцену высыпали почти четыре сотни уведомлений: серверы были недоступны, база сыпала ошибками, платежи падали. Каждая команда видела свою беду и чинила её у себя, как умела. Настоящую причину нашли только через 32 минуты.
В среду, ровно в конце рабочего дня, отказал другой узел той же сети. Массовка снова повалила на сцену в полном составе, только на этот раз её встретил агент. Он сопоставил время появления уведомлений, связи между компонентами и недавние изменения, и все следы привели к одному узлу. Алексей получил один инцидент вместо сотни алертов и нашёл причину за 4 минуты. Куртку он так и не снял.
За кулисами агент прошёл пять шагов:
-
Заметил необычное поведение.
-
Нашёл связанные оповещения, убрал повторы, отделил сигнал от шума.
-
Склеил сообщения в один инцидент.
-
Показал затронутые сервисы, вероятную первопричину и факты.
-
Передал инцидент нужной команде, после чего инженер проверил вывод и выбрал, что делать.
Параллельно он взял на себя всю переписку, которая обычно съедает дежурному половину нервов. Уведомил клиентского менеджера и владельцев затронутых сервисов, открыл канал для аварии, ответил на первые 18 тикетов вежливым ответом «Знаем о проблеме, работаем», каждые 10 минут обновлял страницу статуса и отправлял стейкхолдерам короткую сводку.
Черновик отчёта с хронологией, логами и первой гипотезой появился ещё до того, как сервис ожил. В базу знаний ушла новая статья «Каскадный отказ при потере сетевого узла». Опубликуют её после разбора, с пометкой «проверено человеком».
От рассказчика. Чем мерить эффективность
Тут есть ловушка, в которую очень легко попасть. Когда алертов становится меньше, хочется радоваться и рисовать красивый график для планёрки. Однако слишком усердная фильтрация может спрятать важный сигнал или приклеить его к чужому инциденту.
Поэтому мы смотрим: как быстро замечена проблема, сколько ушло на поиск причины, сколько длилось восстановление и сколько сбоев прошло незамеченными. По этим цифрам и решаем, оправдывает ли продукт вложенные в него деньги.
Действие четвёртое. Четверг, 10:00. Норма или уже нет
Утро. До распродажи три дня. В офисе снова пахнет кофе и предпраздничной паникой.
Алексей открывает сводку, которую агент собрал за ночь. Сам платёжный сервис стал отвечать за 250 мс вместо 150. Ожидание соединения с базой, то самое место из вторника, выросло с 12 до 89 мс, запись на диск замедлилась с 2 до 8 мс. Каждая цифра по отдельности укладывается в допустимые пределы, и пороговые правила дружно молчат.
Агент при этом за 72 часа насчитал 14 аномалий в поведении платёжного сервиса и пришёл с готовым планом.
ЦИФРОВОЙ ТЕХЛИД. Вероятность перегрузки на пике — 87 %. Рекомендую расширить кластер до 6 нод. Для бизнеса подготовлено предупреждение: деградация платёжного потока, оценка потерь — 2,3 млн рублей за три часа пика.
Алексей смотрит на графики и вспоминает прошлогоднюю распродажу. Тогда такая же деградация оказалась следствием неоптимального запроса, который просыпался только при определённом профиле нагрузки. И ещё он вспоминает свою пометку со вторника.
АЛЕКСЕЙ. Масштабирование пока не запускаем. Сначала проверим запросы к базе.
ЦИФРОВОЙ ТЕХЛИД. Принято. Предупреждение для бизнеса придержу.
Проверка подтверждает догадку: запрос из последнего релиза брал блокировку при конкурентной записи. Во вторник урезанный пул соединений просто вытащил эту проблему на свет раньше времени. Если бы команда добавила ноды, конкурентных записей стало бы больше, блокировок тоже, и в разгар распродажи платежи бы встали. Искать причину пришлось бы под пиковой нагрузкой и под пристальным вниманием бизнеса.
Здесь видно одно из ограничений агента. Он анализирует инциденты за последние 90 дней, а прошлогодняя распродажа в это окно не попадает. О ней помнил только Алексей. После четверга в модель загрузили историю прошлых распродаж, и в следующий раз агенту будет что вспомнить.
Как система отличает обычную нагрузку от проблемы
Система изучает привычки каждого сервиса: в какие часы растёт число запросов, сколько длится резервное копирование, чем будни отличаются от выходных, как инфраструктура нервничает в конце месяца. Из этих наблюдений складывается динамическая модель нормального поведения.
Чтобы изучить привычки, нужно время. Для суточных закономерностей хватает 7–14 дней, для недельных нужно 4–6 недель. Ежегодную распродажу без данных прошлых лет модель не поймёт вообще, это и показал четверг.
Норму приходится пересматривать: после переезда в облако, запуска нового приложения или резкого роста аудитории, старая модель устаревает. Если её не перестроить, система начнёт либо дёргать дежурного лишними предупреждениями, либо принимать новые проблемы за обычное поведение.
Есть случаи и коварнее. Если производительность падает на 3–5 % в неделю, система может постепенно привыкнуть к деградации и принять её за новую норму, как лягушка в медленно нагревающейся воде. Поэтому динамические модели мы страхуем жёсткими ограничениями: например, свободного места на диске должно оставаться не меньше 10 %, как бы плавно оно ни таяло.
Действие пятое. Пятница, 03:15. Право на отмену
Ночь. Квартира Алексея. В темноте звонит дежурный телефон.
АЛЕКСЕЙ (хрипло). Да.
Голос в трубке сообщает, что зависло приложение.
Алексей идёт на кухню и открывает ноутбук. Агент уже разобрался в ситуации и параллельно готовит черновик отчёта, обновление для базы знаний, ответы на три новых тикета и рекомендацию, как избежать повторения.
ЦИФРОВОЙ ТЕХЛИД. Рекомендую перезапуск. Риск низкий. Нужно твоё подтверждение.
Кнопка перезапуска, которая висела на дашборде с самого начала, наконец дождалась своей сцены. Курсор мыши Алексея замирает над «Подтвердить».
Пауза.
Действия агента мы делим на три класса. Типовые обратимые операции он выполняет сам, рискованные — только после подтверждения человека, а кое-чего не делает никогда. Перезапуск процесса относится к низкому риску. Изменение прав доступа, удаление данных и вмешательство в платёжную систему относятся к высокому риску. Это приложение обслуживает платёжный контур, поэтому даже перезапуск здесь ждёт человека.
На бумаге всё чисто, риск низкий. Алексей всё равно заглядывает в трассировки, и сон с него слетает окончательно. Зависшее приложение всё ещё держит часть активных операций. Перезапусти его сейчас, и эти операции оборвутся, а повторные попытки клиентов разом обрушатся на соседние компоненты.
АЛЕКСЕЙ. Отмена.
ЦИФРОВОЙ ТЕХЛИД. Отменяю. Какой план?
АЛЕКСЕЙ. Выводим ноду из балансировки. Ждём, пока активные операции спокойно завершатся. Потом перезапуск, руками.
Так и делают. Ружьё всё-таки выстрелило.
Сервис оживает, агент обновляет статус, отправляет стейкхолдерам финальную сводку и кладёт в базу знаний статью с полным разбором. В заголовке стоит пометка «Проверено Алексеем».
После разбора перезапуск нод с активными операциями перевели в класс «только после подтверждения» во всех контурах, а вывод ноды из балансировки добавили в сценарий агента. В следующий раз агент предложит этот шаг сам.
От рассказчика. Почему последнее слово за человеком
Ответ на этот вопрос всю неделю разыгрывался на нашей сцене.
Во вторник причину нашли, потому что у агента под рукой были логи, трассировки и история изменений. Если часть данных потеряна или схема связей устарела, вывод может звучать очень убедительно и всё равно оказаться неверным.
В четверг графики кричали о нагрузке, а причина сидела в одном запросе. Похожие графики могут требовать совсем разных решений, и выбирать должен тот, кто видит картину целиком.
В пятницу перезапуск по инструкции мог превратить одну проблему в несколько. Как действие отзовётся во всей системе, оценивает инженер.
А после остаётся разбор. Инцидент мало закрыть: нужно понять, почему он случился, и поменять архитектуру или процесс, чтобы он не повторился. Черновик отчёта агент напишет быстрее любого из нас, а выводы об архитектуре и процессах всё равно делают люди.
Я видел компании, которые долго внедряли ИИ и потом жалели, что не потратили пару недель на то, чтобы сначала навести порядок в логах. Видел, как сотни алертов превращаются в один инцидент. И видел, как из-за устаревшей схемы зависимостей один важный инцидент тонет среди сотни алертов.
За неделю агент закрыл за Алексея десятки тикетов, собрал черновики разборов и превратил шум в понятные инциденты. За Алексеем осталась режиссура: он проверяет гипотезы, правит статьи, дописывает выводы в отчётах и нажимает «Отмена», когда чувствует риск.
Подводим итоги
За пять месяцев пилота цифрового техлида ручной рутины стало меньше на 20–50 %, а типовые задачи решаются в 3–6 раз быстрее.
Прежде чем развивать любой продукт, я проверяю самую неудобную гипотезу: нужен ли он вообще? Цифровой техлид пригодится далеко не каждой компании: небольшому сайту на 3–5 серверах хватит понятных правил, надёжного мониторинга и удобной панели. Сложная аналитическая платформа может стоить больше миллиона рублей в год только за лицензии и съесть больше ресурсов, чем сэкономит.
Технология окупается прежде всего в двух случаях. Первый — когда у компании от 50 связанных сервисов, своё железо работает вместе с облаками, релизы выходят чаще раза в неделю и сервисы должны жить круглосуточно. Самый верный признак того, что обычного мониторинга уже не хватает: дежурный получает более 100 повторяющихся сообщений в час и тратит на сбор информации больше времени, чем на саму починку. Второй — когда у компании ИТ-сервисы несут критически важную функцию для бизнеса.
Что подготовить до внедрения
Это минимальный набор, без которого агент окажется навигатором без карты.
-
Метрики и логи со всех важных компонентов. Целевой охват — не менее 95 % критичных сервисов.
-
Единый формат данных. Иначе миллионы записей в сутки так и останутся шумом.
-
Карта зависимостей между приложениями, серверами и базами данных. Чем точнее топология, тем точнее корреляция.
-
Владелец у каждого критичного сервиса. Без хозяина инцидент уходит в пустоту.
-
История инцидентов и инструкции по устранению. Агент учится на прошлом, и без истории ему просто не на что опереться.
-
Порядок реагирования: кто получает уведомление в первые 5 минут, когда подключается руководитель, какие действия требуют согласования. Иначе агент найдёт проблему за 4 минуты, а сообщение ещё 40 минут пролежит без ответственного.
Карту зависимостей нужно обновлять вместе с инфраструктурой. Если про карту забыть, точность рекомендаций со временем сильно падает. Навигатор со старой картой бодро ведёт команду по адресам, которых уже нет, а статьи в базе знаний уверенно вводят людей в заблуждение.
Эпилог
Снова кухня. Пятница, почти пять утра. За окном сереет, кофе окончательно остыл.
Алексей протягивает руку, чтобы закрыть ноутбук. В последний момент замечает, что на экране мигает уведомление.
ЦИФРОВОЙ ТЕХЛИД. Предлагаю обновить модель нормального поведения.
АЛЕКСЕЙ. Завтра. Сегодня я человек.
Агент откладывает задачу на утро и возвращается к тикетам. Алексей идёт спать. Кнопка перезапуска остаётся висеть на дашборде до следующего дежурства.
Занавес.
Автор: RoDeniss
