Вопросы с AIOps-собесов: 60 реальных тем, с ответами и граблями

Блок 1. Основы AIOps

1. Что такое AIOps и какую проблему он решает?

AIOps — применение машинного обучения и статистики к данным эксплуатации: метрикам, логам, трейсам, событиям, тикетам. Проблема, которую он решает, — масштаб: современная инфраструктура генерирует телеметрии больше, чем человек физически способен прочитать. Сотни микросервисов, тысячи метрик на сервис, гигабайты логов в час — и дежурный, у которого два глаза и одна ночь. Ручной разбор перестаёт масштабироваться дважды: на входе (нельзя смотреть все дашборды) и на выходе (алертов столько, что их перестают читать — alert fatigue, когда сотое уведомление за смену закрывается не глядя, и среди сотни было одно настоящее). AIOps ставит между телеметрией и человеком фильтрующий и обобщающий слой: аномалии находятся без заранее заданных порогов, тысяча алертов сворачивается в десять инцидентов, к инциденту приезжает контекст — что менялось, что зависит, что похожее уже случалось. Важно проговорить, чем AIOps не является: это не «ИИ заменит дежурных», а инструмент, который сокращает путь от сигнала к диагнозу. Человек остаётся в петле — просто читает выжимку, а не сырой поток.

Кандидаты пересказывают маркетинг: «искусственный интеллект для IT-операций». Без конкретики — какие данные на входе, какие задачи (детект, корреляция, RCA), что на выходе — ответ пуст. Интервьюер ждёт проблему (объём телеметрии, шум алертов) и механизм, а не аббревиатуру.

Follow-up интервьюера: сколько алертов в день — это «много»? — считается не штуками, а долей actionable: если дежурный реагирует действием на меньшинство алертов, остальное — шум, и это уже проблема, сколько бы их ни было в абсолюте.

2. Чем AIOps отличается от MLOps?

Классический вопрос-ловушка на путаницу аббревиатур, и формула ответа короткая: AIOps — это ML про эксплуатацию, MLOps — эксплуатация про ML. AIOps берёт машинное обучение и направляет его на операционные данные: детект аномалий в метриках, кластеризация алертов, поиск первопричины. Заказчик — команда эксплуатации, продукт — меньше шума и быстрее диагноз. MLOps — наоборот: берёт практики эксплуатации (CI/CD, версионирование, мониторинг) и направляет их на жизненный цикл ML-моделей — как обучать воспроизводимо, деплоить, следить за дрифтом. Заказчик — ML-команда, продукт — модели, надёжно живущие в проде. Пересечение при этом реальное, и его стоит назвать: AIOps-система сама содержит модели, которым нужен MLOps — переобучение, версионирование, мониторинг качества. То есть зрелый AIOps опирается на MLOps-практики, оставаясь другой дисциплиной с другим заказчиком. Если на собесе просят одним предложением: AIOps отвечает на вопрос «как ML помогает держать прод», MLOps — «как держать в проде сам ML». Кто различает направление стрелки, тот вопрос прошёл.

Половина кандидатов на этом вопросе просто плавает: «ну, это всё про ИИ и операции». Отсутствие чёткой формулы «ML для Ops против Ops для ML» — маркер, что человек шёл на AIOps-позицию, не разобравшись, куда идёт.

Follow-up интервьюера: а нужен ли AIOps-инженеру MLOps? — да: модель детекта аномалий тоже дрифтует, требует переобучения и мониторинга. AIOps без MLOps-гигиены — это ноутбук с моделью, который сломается через месяц.

3. Четыре способности AIOps-платформы — что production-ready, а что маркетинг?

Канонический список: детект аномалий, корреляция событий, root cause analysis, автоматическая ремедиация. Сильный ответ не перечисляет их, а честно ранжирует по зрелости. Детект аномалий — самая зрелая часть: статистика и ML на временных рядах работают давно, задача понятна, инструменты есть от PromQL до готовых детекторов в APM-продуктах. Корреляция событий — тоже рабочая: дедупликация, группировка по времени, топологии и тексту сворачивает шторм алертов в горстку инцидентов, и именно на ней держится класс event-intelligence-продуктов. RCA — уже наполовину обещание: системы хорошо сужают круг подозреваемых (какой сервис, какое изменение), но «нашли первопричину кнопкой» — преувеличение; на практике это ранжированный список гипотез, который человек проверяет. Автоматическая ремедиация — самая рекламируемая и наименее автономная: в проде живут узкие сценарии (рестарт, скейл, откат) с апрувом или на хорошо изученных отказах, а «self-healing infrastructure» из презентаций — аспирация. Такой ответ показывает главное: кандидат отличает то, что можно внедрить в этом квартале, от того, что рисуют на слайдах.

Перечисляют все четыре с одинаковой уверенностью, будто всё это работает из коробки. Вопрос «что из этого ты реально доверил бы проду завтра?» вскрывает: кто не назвал детект и корреляцию первыми, а ремедиацию последней, тот знаком с темой по вебинарам.

Follow-up интервьюера: почему RCA сложнее детекта? — детект работает с одним сигналом, RCA требует связать много сигналов через топологию и причинность, а граф зависимостей в живой системе неполный и устаревает с каждым деплоем.

4. Чем адаптивный детект отличается от статических порогов?

Статический порог — правило «алерт, если CPU выше 80%»: число выбрал человек, оно одинаково в чёрную пятницу и в ночь на вторник. Адаптивный детект строит модель нормального поведения метрики — с учётом времени суток, дня недели, тренда — и алертит на отклонение от ожидаемого, а не от константы. Разница практическая. Порог не знает сезонности: выставишь по дневному трафику — проспишь ночную аномалию, которая в разы ниже порога, но в десять раз выше ночной нормы; выставишь по ночному — будешь просыпаться каждый полдень. Порог не знает тренда: метрика растёт вместе с бизнесом, и порог, честный полгода назад, сегодня орёт каждый день, пока его не «подкрутят» — обычно просто подняв, то есть ослабив. Адаптивная модель пересчитывает ожидание сама. Цена адаптивности, которую надо проговорить: модель сложнее объяснить дежурному, она может выучить деградацию как «новую норму», ей нужны данные и обслуживание. Поэтому зрелый ответ — не «пороги устарели», а разделение: для метрик с известной физикой (диск заполнен, сертификат истекает) пороги честнее и понятнее; адаптивность нужна там, где норма плавает.

Топят за ML-детект везде, как будто пороги — прошлый век. «Каким детектором ловить заполнение диска на 95%?» — порогом, и если кандидат тянет сюда нейросеть, он не различает задачи с известной семантикой и задачи с плавающей нормой.

Follow-up интервьюера: как адаптивная модель отличит инцидент от новой нормы после релиза? — сама — никак: ей нужен сигнал об изменениях. Поэтому детект без ленты деплоев и фича-флагов обречён либо алертить на каждый релиз, либо молча выучивать деградацию.

5. Какими метриками мерить успех AIOps?

Теми же, какими меряется эксплуатация, — до и после. Первая пара: MTTD и MTTR — время обнаружения и время восстановления. Если детект стал ловить инциденты раньше жалоб пользователей, MTTD падает; если корреляция и RCA сокращают путь до диагноза — падает MTTR. Обе метрики надо считать честно, по одинаковой методике до и после внедрения, иначе цифры рисуются сами. Вторая группа — качество алертинга: общее число алертов на дежурного за смену, доля actionable-алертов (на сколько отреагировали действием), доля шумовых, число ночных пробуждений. Если после внедрения AIOps алертов стало меньше, а пойманных инцидентов — не меньше, система работает. Третья — точность самого детекта: precision (сколько из сработок — настоящие проблемы) и recall (сколько настоящих инцидентов поймано), измеренные на размеченных исторических инцидентах. И четвёртая, которую забывают, — доверие: пользуются ли дежурные подсказками системы или закрывают их не глядя. Формально это доля инцидентов, где подсказка RCA была принята. Красивый детектор, которому никто не верит, имеет нулевой эффект — и эта метрика ловит именно такой сценарий.

Называют «точность модели» и останавливаются. Бизнесу всё равно на F1-score — ему важно, что инциденты находят раньше и чинят быстрее. Кандидат, который не переводит ML-метрики в MTTD/MTTR и число пробуждений, будет строить систему ради системы.

Follow-up интервьюера: MTTR упал после внедрения — как докажешь, что это заслуга AIOps, а не просто меньше инцидентов было? — нормировкой и разрезами: сравнивать по типам инцидентов, смотреть компоненты MTTR (время до диагноза отдельно), в идеале — контрольная группа команд без новой системы.

6. С чего начинать внедрение AIOps в компании?

Не с покупки платформы — с гигиены алертинга. Типовая картина «до»: сотни правил, накопленных годами, половина алертов не читается, у трети нет владельца, дежурные живут в режиме «закрыть всё утром». Если на это поставить ML-платформу, получится дорогой ускоритель шума: garbage in — garbage out. Порядок работ. Первое — инвентаризация: какие алерты есть, кто владелец, на какие реагировали действием за последние месяцы; всё, на что не реагировали никогда, — кандидаты на удаление или перевод в тикеты. Второе — базовые принципы алертинга: алертить на симптомы для пользователя, а не на каждую внутреннюю метрику — эта база разобрана в DevOps-подборке, и без неё дальше идти некуда. Третье — дешёвая автоматика без ML: группировка и подавление в Alertmanager, дедупликация — это убирает заметную часть шума конфигом. И только четвёртое — ML: один узкий пилот (детект аномалий на ключевом сервисе, корреляция для самой шумной подсистемы) с измеренным «до» и «после». Ответ «начнём с выбора вендора» — провал: платформа усиливает процесс, а не заменяет его.

Начинают с технологий: «развернём стек, обучим модели». Вопрос «а что у вас с алертами сейчас?» ставит в тупик. Внедрение AIOps поверх помойки алертов — самая частая причина провала таких проектов, и интервьюер проверяет, наступал ли кандидат на эти грабли хотя бы мысленно.

Follow-up интервьюера: как выбить время на чистку алертов, если бизнес хочет «ИИ уже в этом квартале»? — показать цифры: сколько алертов в неделю, на сколько реагируют. Доля шума в 90% — аргумент понятнее любой презентации: ИИ на этих данных выучит шум.

7. Когда AIOps не нужен?

Честный ответ на этот вопрос ценится выше энтузиазма. AIOps не нужен, когда масштаб проблемы меньше стоимости решения. Если у тебя десяток сервисов, три дежурных и двадцать алертов в неделю — твой AIOps называется «навести порядок в Grafana и Alertmanager»: человек ещё справляется с объёмом, и ML-слой не окупит своё обслуживание. Не нужен он и там, где не решена база: нет нормальной телеметрии, метрики без лейблов, логи без структуры — сначала observability, потом интеллект поверх неё. Не нужен для задач с известной семантикой: предсказание заполнения диска решается predict_linear в одну строку PromQL, истечение сертификата — экспортером и порогом; тянуть сюда обучаемые модели — резюме-driven development. И отдельная категория — организации, где алерты игнорируются культурно: если на страницу дежурного никто не реагирует, проблема не в детекте. Сигналы, что AIOps пора: дежурные не успевают читать алерты, инциденты находят пользователи раньше мониторинга, разбор инцидента — это час ручного листания дашбордов. Пока этих симптомов нет, лучший AIOps — простые правила, дисциплина и крепкая DevOps-база.

Кандидат на AIOps-позицию боится сказать «не нужен» и продаёт ML в любую щель. Интервьюер же проверяет инженерную трезвость: способность выбрать predict_linear вместо нейросети — плюс, а не минус.

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

Блок 2. Observability как фундамент

8. Метрики, логи, трейсы — что когда использовать?

Три сигнала с разной экономикой и разными вопросами, на которые они отвечают. Метрики — числовые ряды, дёшевы в хранении и запросах, отвечают на «что происходит»: latency растёт, ошибок 5%, очередь копится. По ним алертят и строят SLO — но они агрегированы, деталей конкретного запроса в них нет. Логи — события с произвольным контекстом, дороги в объёме, отвечают на «почему»: вот конкретная ошибка, вот стектрейс, вот параметры запроса. Трейсы — путь запроса через сервисы с таймингами каждого шага, отвечают на «где»: из 800 мс запроса 600 съела вот эта база на вот этом хопе. Рабочий цикл диагностики: метрика показала проблему → трейс локализовал сервис → лог объяснил причину. Отсюда и требование связности: из алерта по метрике должен быть путь к трейсам (exemplars), из трейса — к логам (общий trace_id). И обязательная оговорка про «у нас есть Grafana»: наличие дашбордов — не observability. Observability — свойство системы, позволяющее ответить на вопрос, который не был предусмотрен заранее; двадцать дашбордов с CPU — это мониторинг известного, а не наблюдаемость неизвестного.

Пересказывают «три столпа» как заклинание, но на сценарии «latency вырос, твои шаги?» не могут показать переход метрика → трейс → лог. Столпы, между которыми нельзя перейти, — это три силоса, а не observability.

Follow-up интервьюера: каким сигналом дороже всего злоупотреблять? — логами: писать всё подряд на info в проде — самый быстрый способ получить счёт за хранение, в котором нужного всё равно не найти. Уровни, структура и retention — до разговоров про ML.

9. OpenTelemetry — что это и зачем стандарт?

OpenTelemetry — открытый стандарт и набор инструментов для сбора телеметрии: единые API и SDK для метрик, трейсов и логов, протокол OTLP для их передачи и Collector — конвейер, который принимает, обрабатывает и маршрутизирует данные в любые бэкенды. Зачем стандарт — вопрос с историей: до OTel каждый вендор давал свой агент и свой формат; инструментировал приложение под один APM — переезд на другой означал переписывание инструментации. OTel разрывает эту связку: код инструментируется один раз стандартным SDK (плюс автоинструментация популярных библиотек), а куда слать — решается конфигурацией Collector'а. Сменил бэкенд — поменял exporter, код не трогал. Архитектурная роль Collector'а шире маршрутизации: батчинг, сэмплирование, фильтрация чувствительных данных, обогащение атрибутами (кластер, окружение, версия) — всё выносится из приложений в единую точку. Для AIOps это фундамент в буквальном смысле: модели корреляции и RCA требуют, чтобы телеметрия разных сервисов была в едином формате с едиными атрибутами и общим контекстом трейса. OTel semantic conventions дают именно это — одинаковые имена полей у всех, без чего кросс-сервисный анализ превращается в парсинг зоопарка.

Говорят «это как Prometheus, только новее» — мимо: Prometheus — бэкенд хранения метрик, OTel — стандарт сбора и доставки всех трёх сигналов, они дополняют друг друга. Путаница между слоями сбора и хранения — типовой провал.

Follow-up интервьюера: зачем Collector, если SDK может слать прямо в бэкенд? — центральная точка контроля: смена бэкенда, сэмплирование и фильтрация без передеплоя сотни сервисов, буферизация при недоступности хранилища. Прямая отправка — жёсткая связка, от которой OTel и уходил.

10. Кардинальность метрик — почему label с user_id кладёт Prometheus?

Кардинальность — число уникальных временных рядов, а ряд определяется комбинацией имени метрики и значений всех лейблов. Prometheus держит индекс и голову каждого активного ряда в памяти, поэтому его ёмкость меряется не количеством метрик, а количеством комбинаций. Лейбл с ограниченным словарём (status_code — десятки значений, method — единицы) умножает ряды на константу — это нормально. Лейбл с неограниченным словарём — user_id, request_id, session, полный URL с параметрами — порождает ряд на каждое уникальное значение: миллион пользователей — миллион рядов на каждую метрику с этим лейблом, помноженный на остальные лейблы. Память растёт, запросы деградируют, TSDB захлёбывается — классический cardinality explosion, и уронить им мониторинг проще, чем прод. Правило: в лейблы — только измерения с конечным, заранее оценимым словарём; всё уникальное — в логи и трейсы, они для этого и существуют. Диагностика: prometheus_tsdb_head_series, api-запросы по количеству рядов на метрику, топ «жирных» метрик. Защита: relabeling с дропом опасных лейблов на входе, лимиты на число рядов с таргета, ревью новых метрик как кода.

Знают слово «кардинальность», но не механику: почему именно память и почему комбинаторика лейблов перемножается. «Сколько рядов даст метрика с тремя лейблами по 10, 100 и 1000 значений?» — до миллиона, и кто не может это перемножить, тот с инцидентом кардинальности не сталкивался.

Follow-up интервьюера: нужна статистика по конкретным пользователям — как без user_id в лейблах? — из трейсов и логов аналитикой, либо агрегированные метрики по когортам (тарифу, региону). Prometheus — про агрегаты, per-user вопросы решаются другим хранилищем.

11. Структурированные логи — зачем JSON и trace_id в каждой записи?

Неструктурированный лог — строка для человека: «Failed to process order 12345 for user 67». Чтобы машина достала из неё order_id, нужен регекс, который сломается при первом изменении формата. Структурированный лог — JSON с полями: level, message, order_id, user_id, service, trace_id. Выгоды прямые: точный поиск и агрегация по полям вместо полнотекстового грепа, никакого парсинга на стороне пайплайна, стабильная схема, по которой можно строить метрики из логов и кормить ML-модели — детект аномалий по частотам событий работает только тогда, когда события можно надёжно различать. Ключевое поле — trace_id: он пробрасывается из контекста трейсинга в каждую запись и превращает логи из кучи строк в связную историю запроса. Инцидент: по алерту находишь медленный трейс, по trace_id одним запросом достаёшь все логи всех сервисов, через которые прошёл этот запрос, — минуты вместо часа сопоставления таймстампов на глаз. Практика внедрения: логгер с JSON-форматером и контекстными полями в шаблоне сервиса по умолчанию, договорённость об общих полях (единые имена — service, а не svc/app/name в трёх командах), запрет конкатенации переменных в message — переменное уходит в поля.

Соглашаются, что JSON — это хорошо, но не могут объяснить, зачем trace_id в логах, — а это половина ценности: без него метрики, логи и трейсы остаются несвязанными силосами, и кросс-сигнальная диагностика не работает.

Follow-up интервьюера: разработчики жалуются, что JSON-логи нечитаемы локально. — форматтер по окружению: локально — человекочитаемый вывод, в проде — JSON. Это решённая проблема любого зрелого логгера, а не аргумент против структуры.

12. Распределённый трейсинг: context propagation и сэмплирование head vs tail

Трейс — дерево спанов: каждый спан — операция с началом, длительностью и атрибутами, связанная с родителем. Чтобы дерево собралось, контекст (trace_id, span_id) должен путешествовать вместе с запросом — это context propagation: в HTTP — заголовок traceparent стандарта W3C Trace Context, в очередях — поля в метаданных сообщения. Библиотеки OTel пробрасывают контекст автоматически, но цепочка рвётся на всём нестандартном: самодельные очереди, батч-джобы, callback'и — и трейс превращается в обрубки; умение найти разрыв пропагации — практический навык. Вторая тема — сэмплирование, потому что писать 100% трейсов на большом трафике дорого и не нужно. Head-based: решение принимается в начале трейса (например, 1% случайно) — дёшево, предсказуемо, но решение принимается вслепую: медленный или ошибочный запрос с вероятностью 99% не попадёт в выборку. Tail-based: решение после завершения трейса, когда известны длительность и статус, — можно хранить все ошибки и всё медленное плюс маленький процент нормы; цена — буферизация всех спанов трейса в Collector'е до решения, это память и сложность. Для AIOps и разборов инцидентов tail-based ценнее: интересные трейсы — по определению редкие.

Рассказывают, что такое спан, но плывут на «как трейс собирается из спанов разных сервисов» — то есть не понимают propagation. И путают сэмплирования: «head экономнее» — да, но именно он выкидывает те самые аномальные запросы, ради которых трейсинг ставили.

Follow-up интервьюера: трейсы обрываются на границе с legacy-сервисом, который нельзя инструментировать — что делать? — хотя бы прокинуть заголовки насквозь без создания спанов, а участок закрыть спаном со стороны вызывающего. Дыра в трейсе с известными границами лучше двух несвязанных трейсов.

13. SLI, SLO и error budget — какое место они занимают в AIOps?

База — что такое SLI, SLO и бюджет ошибок — разобрана в DevOps-подборке; здесь — зачем это AIOps-инженеру. SLO — это формализованный ответ на вопрос «что считать проблемой», без которого детект аномалий повисает в воздухе: аномалия — отклонение от нормы, но не каждое отклонение стоит будить человека. SLI задаёт метрики, которые важны пользователю (доля успешных запросов, latency ниже порога), SLO — целевой уровень, а скорость сжигания бюджета ошибок (burn rate) — готовую рамку для алертинга: быстрое сжигание — пейдж, медленное — тикет. Для AIOps это фильтр приоритета: детектор может найти сотню аномалий в час, но эскалации заслуживают те, что бьют по SLI или предсказывают его деградацию. Отсюда рабочая связка: ML-детект находит аномалию в инфраструктурной метрике → корреляция связывает её с сервисом → система оценивает, угрожает ли это SLO, → и только тогда решает, пейдж это, тикет или запись в лог. Плюс SLO даёт разметку для оценки моделей: эпизоды нарушения SLO — это ground truth инцидентов, на которых можно replay'ем проверять, поймал бы детектор проблему раньше.

Рассказывают определения SLI/SLO, но не могут связать их с детектом: зачем детектору SLO? Ответ «чтобы отличать аномалию, которая волнует пользователя, от статистического курьёза» — и есть суть; без него AIOps алертит на всё подряд, только по-умному.

Follow-up интервьюера: аномалия есть, SLO не страдает — что делаешь? — не пейдж: тикет или запись в контекст. Но накапливаю: серия «безобидных» аномалий одного типа — материал для capacity planning и раннего сигнала деградации.

14. Recording rules — зачем предагрегация?

Recording rule — правило Prometheus, которое периодически вычисляет выражение и записывает результат как новую метрику. Зачем: тяжёлые запросы (агрегации по тысячам рядов, проценты ошибок по сервисам, квантили) при каждом открытии дашборда или проверке алерта считаются заново — это медленно и грузит TSDB. Recording rule считает один раз в интервал и хранит готовый результат: дашборды летают, алерты дёшевы, а у метрики появляется стабильное имя, на которое можно ссылаться из правил, дашбордов и ML-пайплайнов, не копируя выражение:

groups:
- name: service_aggregations
  interval: 30s
  rules:
  - record: service:http_requests:rate5m
    expr: sum by (service) (rate(http_requests_total[5m]))
  - record: service:http_errors:ratio_rate5m
    expr: |
      sum by (service) (rate(http_requests_total{code=~"5.."}[5m]))
      /
      sum by (service) (rate(http_requests_total[5m]))

Соглашение об именах — уровень:метрика:операция — сразу говорит, что и как агрегировано. Для AIOps предагрегация — это ещё и слой фичей: детектору аномалий нужен компактный набор осмысленных рядов (error ratio, p99 по сервису), а не сырые тысячи рядов с полной кардинальностью. Recording rules — дешёвый feature engineering прямо в Prometheus: модель читает готовые агрегаты, пайплайн не тащит сырьё.

Знают, что «это для ускорения дашбордов», но не видят вторую роль — стабильный контракт на данные для алертов и моделей. И забывают, что правило считается всегда, даже когда дашборд никто не смотрит: агрегировать всё подряд «на всякий случай» — тоже расход.

Follow-up интервьюера: чем recording rule отличается от алерта технически? — почти ничем: обе — периодически вычисляемые выражения; recording пишет результат в TSDB, алерт — порождает событие при непустом результате. Поэтому и живут в одних группах правил.

15. Почему без нормальной observability AIOps не взлетит?

Потому что ML не добывает информацию — он её концентрирует. Если в телеметрии нет сигнала, никакая модель его не извлечёт: garbage in — garbage out, и в AIOps это не поговорка, а главный режим отказа проектов. Разложи по слоям. Детект аномалий требует метрик с достаточной историей, стабильными лейблами и без дыр: детектор, обученный на метриках, которые перезатираются при каждом редеплое или меняют имена раз в квартал, учится шуму миграций. Корреляция событий требует общего словаря: если один сервис зовёт себя payments, второй payment-svc, а третий вообще не размечен, система не поймёт, что три алерта — про одну цепочку. RCA требует связности сигналов (trace_id в логах, exemplars в метриках) и топологии — без них «первопричина» вычисляется по совпадению времени, то есть гаданием. LLM-слой требует текстов: ранбуков, постмортемов, осмысленных описаний алертов — суммаризировать пустоту нельзя. Поэтому честная дорожная карта AIOps начинается со скучного: стандартизация лейблов и имён, структурные логи, трейсинг с нормальным сэмплированием, инвентарь сервисов с владельцами. Это 80% работы и 0% презентаций — но именно здесь решается, будет ли работать оставшийся ML.

Кандидат рвётся рассказывать про модели, а на вопрос «какие данные нужны и что с ними обычно не так» отвечает общими словами. Перечислить конкретные дефекты телеметрии — дыры, переименования, разнобой лейблов, отсутствие связности — может только тот, кто с реальными данными работал.

Follow-up интервьюера: как быстро оценить готовность телеметрии компании к AIOps? — аудит одним сценарием: возьми прошлый инцидент и попробуй восстановить его картину только по данным — от алерта до причины. Где застрял человек, там застрянет и модель.

Блок 3. Детект аномалий в метриках

16. Статические пороги — где работают, а где ломаются?

Порог — самый честный инструмент детекта: понятен, объясним, дёшев, срабатывает мгновенно. Работает там, где у метрики есть абсолютная семантика, не зависящая от времени и нагрузки: диск заполнен на 90% — плохо в любой день недели; сертификат истекает через неделю — факт; очередь не разгребается — объективно. Ломается на метриках, чья норма — функция времени и контекста. Первая причина — сезонность: трафик днём и ночью различается в разы, порог, честный для пика, слеп ночью, порог для ночи — истерит днём. Вторая — тренд: система растёт, и порог устаревает молча; его поднимают после каждого ложного срабатывания, и однажды поднятый «с запасом» порог пропускает настоящий инцидент. Третья — разнородность: единый порог на latency для тысячи эндпоинтов бессмыслен, а тысяча ручных порогов — неподдерживаема; это и есть точка, где ручной алертинг перестаёт масштабироваться. Зрелый ответ заканчивается стратегией: пороги — для метрик с физическим смыслом и для страховочного контура (совсем грубые границы, которые не должны нарушаться никогда), адаптивный детект — для метрик с плавающей нормой, и обе линии живут параллельно, а не заменяют друг друга.

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

Follow-up интервьюера: как поддерживать сотни порогов в актуальном состоянии? — генерировать из данных: пересчитывать по перцентилям истории раз в неделю скриптом. Это ещё не ML, но уже не ручной труд — и часто именно это решает 80% проблемы.

17. Z-score, скользящее среднее, EWMA — статистическая база детекта

Z-score — сколько стандартных отклонений точка отстоит от среднего: считаешь по окну истории среднее и сигму, точка с |z| больше трёх — кандидат в аномалии. Скользящее среднее сглаживает ряд и даёт базу для сравнения «текущее против ожидаемого»; EWMA — его версия с экспоненциальными весами, где свежие точки важнее старых: быстрее адаптируется к изменениям уровня и требует хранить одно число вместо окна. Это рабочие лошадки: дёшевы, объяснимы, реализуются хоть в PromQL, хоть в двадцати строках Python — и с них надо начинать, а не с нейросетей. Теперь ограничения, ради которых вопрос задают. Z-score предполагает симметричное, примерно нормальное распределение — а latency распределена с тяжёлым правым хвостом: среднее и сигма раздуваются от выбросов, и детектор слепнет ровно на той метрике, где нужнее всего. Лечится робастными аналогами: медиана вместо среднего, MAD вместо сигмы, или перцентильными границами. Среднее и сигма, посчитанные по окну с самим инцидентом, «заражаются» им — аномалия поднимает порог и маскирует продолжение. И все три метода не знают сезонности: вечерний пик для них — аномалия, пока окно не переучится. Отсюда следующий шаг — декомпозиция.

Называют z-score, но не знают его предпосылок: на «почему три сигмы не работают на latency» отвечают молчанием. Слова «тяжёлый хвост», «медиана», «MAD» отличают человека, который считал на реальных метриках, от человека, который читал статью.

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

18. Сезонность и STL-декомпозиция — как искать аномалии в метриках с ритмом?

Почти все бизнес-метрики дышат: суточный ритм, недельный (будни против выходных), у кого-то месячный и годовой. Детектор, не знающий ритма, либо алертит на каждый вечерний пик, либо загрублён до слепоты. Решение — разложить ряд на компоненты: тренд (медленное движение уровня), сезонность (повторяющийся паттерн) и остаток (то, что не объясняется первыми двумя). STL — классический метод такой декомпозиции (Seasonal-Trend decomposition using Loess), устойчивый к выбросам и допускающий медленное изменение сезонного паттерна. Ключевая идея для собеса: аномалии ищутся в остатках. Тренд и сезонность — это и есть модель нормы; вычел их — и на остатке снова работают простые методы, z-score или робастные границы, потому что остаток уже стационарен и без ритма. Провал вечернего трафика на 30% при норме пика — большой отрицательный остаток, хотя абсолютное значение всё ещё выше ночного. Практические детали: период сезонности задаётся явно (двойная сезонность — день плюс неделя — требует методов посложнее, MSTL или Prophet-подобных); истории нужно хотя бы несколько полных периодов; праздники и распродажи ломают паттерн и требуют календаря исключений. Это тот уровень, где детект уже полезен, но всё ещё объясним дежурному одной картинкой с тремя компонентами.

Говорят «модель учтёт сезонность» без механики. Вопрос «где именно ты ищешь аномалию после декомпозиции?» — контрольный: ответ «в остатках» знают те, кто делал; остальные начинают рассуждать про «отклонение от прогноза» размыто.

Follow-up интервьюера: чёрная пятница — трафик в пять раз выше любой нормы. Что делает твой детектор? — без календаря — паникует. Известные события подаются моделью как экзогенный сигнал или глушатся заранее поднятыми границами; «мы знали, что будет пик» должно быть машиночитаемым.

19. Isolation Forest — как работает и когда его брать?

Идея алгоритма красива и отвечает интуиции: аномалию проще изолировать. Строится ансамбль случайных деревьев: на каждом шаге выбирается случайный признак и случайная точка разреза. Нормальные точки сидят в плотных областях — чтобы отделить одну от соседей, нужно много разрезов; выброс одинок — его отрезает пара сплитов. Средняя глубина изоляции по ансамблю и есть anomaly score: чем короче путь, тем аномальнее точка. Никаких предположений о распределении, работает с многомерными данными, обучение и скоринг быстрые, из коробки в sklearn:

from sklearn.ensemble import IsolationForest
import pandas as pd

# фичи: значение метрики + контекст времени + лаги
X = df[["req_rate", "err_ratio", "p99_ms",
        "hour_sin", "hour_cos", "p99_ms_lag1"]]

model = IsolationForest(
    n_estimators=200,
    contamination=0.005,   # ожидаемая доля аномалий
    random_state=42,
).fit(X)

df["score"] = model.decision_function(X)  # ниже = аномальнее
df["is_anomaly"] = model.predict(X) == -1

Когда он хорош: многомерные аномалии — каждая метрика по отдельности в норме, а комбинация невозможна (трафик упал, CPU вырос); unsupervised-режим без разметки; сотни рядов, где нужен дешёвый универсал. Что важно понимать: сам по себе он не знает времени — временной ряд надо превращать в признаки (лаги, окна, кодирование часа через синус-косинус), иначе сезонный пик будет «аномалией». И contamination — ручка чувствительности, которую всё равно придётся крутить под свои данные.

Пересказывают «деревья изолируют выбросы», но не могут объяснить, почему короткий путь означает аномалию, и не знают, что на временных рядах алгоритм без feature engineering бесполезен — подают сырой ряд и удивляются результату.

Follow-up интервьюера: чем Isolation Forest лучше и хуже one-class SVM? — быстрее и стабильнее на больших данных, меньше чувствителен к масштабированию; хуже — на очень маленьких выборках и там, где граница нормы сложная и гладкая. На практике IF — дефолт, SVM — экзотика.

20. LSTM и автоэнкодеры для временных рядов — когда оправданы?

Принцип у обоих подходов общий — реконструкция или прогноз как модель нормы. Автоэнкодер учится сжимать и восстанавливать нормальные участки ряда: на нормальных данных ошибка реконструкции мала, на аномальных — велика, порог по ошибке даёт детектор. LSTM-вариант — прогнозирующий: сеть предсказывает следующие точки по окну истории, большая ошибка прогноза — аномалия; LSTM-автоэнкодер совмещает обе идеи для последовательностей. Сильные стороны: улавливают сложные нелинейные зависимости и взаимодействия многих метрик сразу — то, где статистика и деревья сдаются; эталонные работы вроде детекта на телеметрии космических аппаратов показали, что подход рабочий, а не бумажный. Теперь цена, и она — половина правильного ответа. Нужно много чистой истории «нормы» — если в обучающих данных были инциденты, сеть выучит их как норму. Обучение и инференс дороже статистики на порядки — умножь на сотни тысяч рядов и получи вопрос «а кто это всё обслуживает». Объяснимость около нуля: «ошибка реконструкции 0.7» дежурному ни о чём. Гиперпараметры, retraining, дрифт — полный MLOps-набор. Честный вывод: глубокие модели — точечный инструмент для немногих критичных многомерных сигналов, а не ковровое покрытие всей телеметрии; ковром идут статистика и лес.

Кандидат с ML-курсом за плечами тащит LSTM на всё подряд. Вопрос «сколько стоит скорить миллион рядов нейросетью каждую минуту и кто будет её переобучать» возвращает в реальность — и отсутствие этого расчёта в ответе выдаёт отсутствие продовой практики.

Follow-up интервьюера: в обучающем окне был инцидент — что будет и что делать? — модель выучит его как норму и промолчит при повторении. Чистить историю по журналу инцидентов или использовать робастные к загрязнению методы — обязательный шаг пайплайна.

21. Contextual anomalies — почему одно и то же значение бывает нормой и инцидентом?

Классификация аномалий во временных рядах трёхчастная, и её полезно назвать. Point anomaly — точка, аномальная сама по себе: latency 30 секунд аномальна всегда. Contextual anomaly — значение нормально в одном контексте и аномально в другом: тысяча запросов в секунду днём — вторник, та же тысяча в четыре утра — либо маркетинг забыл предупредить, либо ботнет; ноль заказов ночью — сон, ноль заказов в полдень — упавшие платежи. Collective anomaly — каждая точка в отдельности допустима, но последовательность аномальна: latency, растущая на 2% каждые пять минут три часа подряд, ни разу не пробьёт порог — а это утечка памяти, идущая к OOM. Практическое следствие: детектор, смотрящий на точки в отрыве от контекста, ловит только первый класс — самый редкий и самый очевидный. Контекст подаётся в модель явно: время как признаки (час, день недели — через периодическое кодирование), сезонная декомпозиция как способ «вычесть» контекст, сопутствующие метрики (нагрузка как контекст для CPU: 90% CPU при пиковом трафике — работа, при нулевом — майнер или цикл). Коллективные аномалии требуют окон и трендовых признаков — скорость и ускорение метрики, длина монотонного участка. Кто раскладывает вопрос на эти три класса, тот показывает системное понимание, а не набор трюков.

Знают только point anomalies — «выброс за три сигмы». Пример с утечкой памяти, которая никогда не даёт выброса, но убивает под, ломает такой ответ пополам: детект без учёта динамики пропускает целый класс реальных инцидентов.

Follow-up интервьюера: как поймать деградацию, размазанную на недели? — трендовые методы поверх агрегатов: сравнение недель между собой, наклон регрессии по окну, контроль бюджета SLO — медленные деградации видны на медленных масштабах, не в минутных данных.

22. Перцентили latency — почему среднее врёт?

Latency распределена несимметрично: большинство запросов быстрые, но правый хвост тянется далеко — кэш-промахи, GC-паузы, ретраи, медленные клиенты. Среднее по такому распределению — число, за которым не стоит ни один реальный запрос: тысяча ответов по 10 мс и десять по 5 секунд дают среднее около 60 мс — «всё отлично», при том что каждый сотый пользователь ждал пять секунд. Перцентили честнее: p50 — типичный опыт, p95/p99 — опыт худших 5% и 1% запросов, и именно хвост определяет восприятие сервиса — при десятках подзапросов на страницу с p99-задержкой сталкивается почти каждый пользователь, а не один из ста. Поэтому SLO формулируют через перцентили или долю запросов быстрее порога, а не через среднее. Инженерная часть: перцентили не агрегируются — среднее p99 по десяти инстансам не является p99 системы, и «average of p99» на дашборде — известный антипаттерн. Правильный путь — histogram: бакеты счётчиков агрегируются суммированием по инстансам, а квантиль считается по агрегату (histogram_quantile поверх rate по бакетам). Для детекта аномалий следствие прямое: следить надо минимум за p50 и p99 отдельно — сдвиг медианы и раздувание хвоста — разные болезни с разными причинами; детектор на среднем не увидит ни ту, ни другую до момента, когда увидят пользователи.

Знают «нужен p99», но не знают, что перцентили нельзя усреднять между инстансами, — и уверенно описывают дашборд с avg(p99). Вопрос «как получить p99 всего сервиса из десяти подов» отделяет пользователей Grafana от тех, кто понимает, что рисует.

Follow-up интервьюера: p99 в норме, пользователи жалуются — куда смотреть? — на p999 и на разрезы: перцентиль по всему трафику маскирует деградацию одного эндпоинта, региона или тяжёлого клиента. Агрегат в норме — сегмент в огне: разрезай по измерениям.

23. Как оценивать качество детектора аномалий?

Начни с матрицы ошибок в терминах он-колла. False positive — детектор кричит, инцидента нет: цена — разбуженный ночью человек, потраченный час и минус доверие; после десятка пустых сработок алерты этой системы закрывают не глядя, и она мертва независимо от метрик. False negative — инцидент был, детектор молчал: цена — инцидент нашли пользователи, репутация и деньги. Асимметрия цен — суть вопроса: она разная для разных систем (для страховочного контура критичен recall, для ночного пейджа — precision), и порог детектора — это бизнес-решение о балансе, а не техническая константа. Метрики: precision и recall на размеченных исторических инцидентах, но с поправками на специфику временных рядов. Точечное сравнение нечестно: детектор, поймавший инцидент на пятой минуте из тридцати, — успех, а не 25 пропущенных точек; поэтому считают по событиям (event-based) или с допуском по времени. Отдельно меряется время до детекта — поймать за минуту и за полчаса это разные детекторы при одинаковом recall. И практика, о которой забывают: оценка на живом потоке через shadow mode — детектор работает, но не алертит, его сработки складываются и еженедельно разбираются с дежурными; это единственный способ померить precision до того, как система начнёт будить людей.

Называют accuracy — мгновенный провал: при доле аномалий в доли процента детектор «всегда норма» имеет accuracy 99%+. И не проговаривают асимметрию цен FP/FN — а вопрос именно про неё: что дороже, зря разбудить или пропустить, зависит от контура, и это надо сказать.

Follow-up интервьюера: разметки инцидентов нет — как оценивать? — собрать прокси: журнал он-колла, постмортемы, эпизоды нарушения SLO; плюс shadow mode с разбором сработок дежурными — разметка рождается из эксплуатации, идеальной не будет никогда.

Блок 4. Логи и события

24. Как парсить неструктурированные логи в шаблоны? Идея Drain

Проблема: гигабайты свободного текста, в котором миллион строк порождён сотней мест в коде. Log parsing сводит строки к шаблонам: «Connection to 10.0.1.5 timed out after 30s» и «Connection to 10.0.2.7 timed out after 45s» — один шаблон «Connection to <*> timed out after <*>» с переменными. Шаблон — это лог-ключ, идентификатор события; переменные — его параметры. Drain — классический онлайн-алгоритм этой задачи: дерево фиксированной глубины, где строки маршрутизируются сначала по длине (числу токенов), потом по первым токенам, а в листе сравниваются с существующими шаблонами по доле совпадающих токенов; совпало выше порога — строка присоединяется к шаблону, а разошедшиеся позиции заменяются на wildcard; нет — рождается новый шаблон. Работает потоково, без предобучения, быстро — потому и стал стандартом де-факто, вокруг которого построены и опенсорс-реализации, и парсеры внутри коммерческих платформ. Зачем это AIOps: шаблоны превращают текст в события, которые можно считать — а дальше работает вся машинерия детекта: частоты шаблонов как временные ряды, новые шаблоны как сигнал, последовательности шаблонов как материал для моделей. Без парсинга анализ логов — это грep и удача.

Предлагают «регулярки» — на сотне сервисов с меняющимися форматами это неподдерживаемо, в чём и смысл автоматического парсинга. Или знают слово Drain, но не могут объяснить, как он понимает, где константа, а где переменная: расходящиеся между похожими строками позиции — и есть переменные.

Follow-up интервьюера: где Drain ошибается? — числа и идентификаторы в начале строки ломают маршрутизацию по первым токенам, многострочные записи (стектрейсы) требуют склейки до парсинга, а слишком щедрый порог похожести склеивает разные события в один шаблон.

25. Детект аномалий в логах — что вообще считать аномалией?

После парсинга в шаблоны у тебя есть три класса сигналов. Первый — новизна: появился шаблон, которого не было никогда. Новый тип ошибки после деплоя — самый ценный ранний сигнал из существующих; правило «новый лог-ключ в первые полчаса после релиза — уведомление владельцу» окупается быстрее любой нейросети. Второй — частоты: знакомые шаблоны в аномальных количествах. Ошибка ретрая, которая всегда шла десять раз в час, а теперь идёт тысячу; или наоборот — исчезновение шаблона (heartbeat-сообщение пропало — компонент умер молча). Частоты шаблонов — обычные временные ряды, к ним применим весь блок про метрики: сезонность, робастные границы, лес. Третий — последовательности: порядок событий нарушен. Идея DeepLog именно такая: LSTM обучается на последовательностях лог-ключей нормального периода и предсказывает, какие события вероятны следующими; реальное событие вне топа предсказаний — аномалия. Это ловит нарушения логики исполнения (транзакция без коммита, старт без инициализации), которые не видны ни в новизне, ни в частотах. Практическая лестница внедрения такая же, как везде: новизна и частоты — дёшево и сразу полезно; секвенционные модели — дорого, хрупко к изменениям кода и оправдано на критичных стабильных потоках.

На «как искать аномалии в логах» отвечают «искать слово ERROR» — уровень grep. Разложение на новизну, частоты и последовательности — та структура, которую ждут; DeepLog как пример секвенционного подхода — плюс, но без понимания, что это верх лестницы, а не вход.

Follow-up интервьюера: каждый деплой рождает новые шаблоны — как не утонуть в «новизне»? — связать с релизами: новые шаблоны в окне после деплоя маршрутизируются владельцу релиза как FYI, а не алерт; аномалия — новый шаблон без изменений рядом.

26. Дедупликация и группировка алертов в Alertmanager

Первый уровень борьбы с шумом — конфиг, а не ML, и его обязан знать любой AIOps-кандидат. Alertmanager делает три вещи. Группировка: алерты с общими лейблами склеиваются в одно уведомление — упали 40 подов сервиса, дежурный получает одно сообщение «40 алертов по payments», а не 40 пушей:

route:
  group_by: ["alertname", "service"]
  group_wait: 30s      # подождать, пока соберётся группа
  group_interval: 5m   # не чаще, чем раз в 5 минут — обновления группы
  repeat_interval: 4h  # напоминание о неисправленном
  routes:
  - matchers: ["severity=critical"]
    receiver: pagerduty
  - matchers: ["severity=warning"]
    receiver: slack-tickets

inhibit_rules:
- source_matchers: ["alertname=NodeDown"]
  target_matchers: ["severity=warning"]
  equal: ["node"]     # нода лежит — молчим про её поды

Дедупликация: один и тот же алерт от нескольких реплик Prometheus схлопывается по одинаковым лейблам. Ингибиция: сработавший алерт подавляет следствия — если нода мертва, алерты про каждый под на ней не нужны, причина уже запейджена. Тайминги — компромисс: больший group_wait — полнее группа, но позже уведомление. Понимание этих механизмов — лакмус: кто не выжал шумоподавление из бесплатного конфига, тому рано покупать «интеллектуальную корреляцию».

Кандидаты «в AIOps» не могут объяснить group_wait и inhibition — а интервьюер спрашивает их именно затем, чтобы проверить фундамент. Заявлять ML-корреляцию, не зная штатной группировки, — как продавать автопилот, не умея переключать передачи.

Follow-up интервьюера: чем inhibition отличается от группировки? — группировка склеивает однородные алерты в одно уведомление, ингибиция полностью подавляет следствия при активной причине. Первая уменьшает число сообщений, вторая — число сущностей, о которых вообще говорим.

27. Event storm — как гасить каскад алертов от одной причины?

Шторм — это когда одна причина порождает сотни следствий: умер коммутатор — недоступны стойки — сотни health-check'ов красные — тысячи алертов за минуты. Дежурный получает лавину, в которой сигнал о причине — одна строка среди тысяч строк о следствиях, и её никто не увидит. Гасится шторм слоями. Статический слой: зависимости, известные заранее, кодируются ингибицией — нода подавляет поды, канал связи подавляет всё за ним; это дёшево, но требует поддерживать правила руками. Динамический слой — корреляция: временная (алерты, вспыхнувшие в одном окне в несколько минут, с высокой вероятностью связаны — кластеризация по времени сжимает шторм в один инцидент), топологическая (алерты со связанных узлов графа зависимостей объединяются, даже если разнесены на минуты) и текстовая (похожие описания — кластеризация по содержимому). Event-intelligence-системы комбинируют все три и выдают вместо тысячи алертов один инцидент с тысячей связанных событий внутри. Третий слой — защита каналов: rate limiting уведомлений и агрегированные сообщения, потому что даже сжатый вдесятеро шторм способен положить вебхуки и утопить чат. И обязательное свойство: механизм не должен съесть причину — событие-родитель обязано остаться видимым на вершине группы, иначе подавление шторма превращается в подавление диагноза.

Рассказывают только про «отключить уведомления во время шторма» — это не гашение, а капитуляция: вместе с шумом глохнет и сигнал. Ответ без слоёв — ингибиция, временная и топологическая корреляция — остаётся на уровне «потерпеть и разгрести утром».

Follow-up интервьюера: два независимых инцидента случились одновременно — временная корреляция склеит их в один. Как защищаешься? — добавлять измерения: топология и текст разделяют то, что склеило время; плюс человеку даётся операция «разлепить» — корреляция обязана быть обратимой.

28. Topology-aware корреляция — зачем детекту граф зависимостей?

Потому что алерты живут не в вакууме, а на графе: сервисы зовут сервисы, стоят на нодах, ходят в базы через сети. Одновременные алерты «база деградирует», «API тормозит», «фронт сыпет таймаутами» — для системы без топологии это три инцидента; для системы с топологией — один: фронт зависит от API, API от базы, и алерт внизу стека объясняет алерты наверху. Это главный принцип: причина обычно ниже по графу зависимостей, чем симптомы, и корреляция сводится к поиску общего предка алертящих узлов. Откуда берётся граф — вторая половина ответа, и она труднее первой. Статические источники: service discovery, реестры сервисов, IaC и CMDB — дают костяк, но врут ровно настолько, насколько их поддерживают. Динамические: распределённый трейсинг (кто кого реально вызывает — из спанов), eBPF-наблюдение сетевых потоков, топология Kubernetes (под — нода — зона) — дают правду о фактических связях и обновляются сами. Зрелые системы строят граф из телеметрии непрерывно, потому что нарисованная руками карта устаревает к следующему спринту. Ограничение, которое стоит проговорить: граф говорит о связях, но не о причинности — база и API могут алертить из-за общей ноды, а не друг из-за друга; топология сужает круг подозреваемых, вердикт остаётся за анализом.

Идея «алерты связаны через зависимости» очевидна всем, а вопрос «откуда возьмёшь граф и как будешь поддерживать его актуальным» роняет большинство: ответ «попросим команды заполнить CMDB» означает, что через квартал корреляция будет работать по карте несуществующей системы.

Follow-up интервьюера: трейсинг покрывает 60% сервисов — что с графом для остальных? — гибрид: связи из трейсов там, где они есть, сетевые потоки и конфигурация — для остальных, плюс честная пометка уверенности ребра: корреляция по достоверному ребру и по предполагаемому — разные веса.

29. Корреляция алертов с изменениями — почему деплой подозреваемый номер один?

Потому что статистика инцидентов беспощадна: значительная часть инцидентов следует за изменением — релизом, конфигом, фича-флагом, миграцией, обновлением инфраструктуры. Система, которая при алерте первым делом отвечает на вопрос «что менялось рядом по времени и топологии», сокращает диагноз с часа до минут — и это самый дешёвый RCA из существующих. Механика: все изменения собираются в единую ленту событий — деплои из CI/CD, переключения фича-флагов, изменения конфигурации, миграции, работы у провайдера; каждое — с временем, автором, сервисом. Алерт прилетел — система накладывает его на ленту: сервис алертит, его последний деплой был семь минут назад — вот первая гипотеза с прямой ссылкой на дифф и кнопкой отката. Важно, что корреляция должна быть топологической, а не только временной: изменение в зависимости сервиса — такой же подозреваемый, как его собственный релиз. Технически это самая доступная часть AIOps: аннотации деплоев в Grafana, webhook из CI в ленту событий, лейбл версии в метриках — никакого ML, чистая дисциплина данных. И культурная часть: лента работает, только если в неё попадают все изменения, включая «я только конфиг поправил» — изменения мимо ленты становятся слепой зоной диагностики.

Кандидаты увлекаются моделями и пропускают самый сильный сигнал: на «алерт через пять минут после деплоя — что делаешь?» отвечают про анализ метрик вместо «смотрю дифф и готовлю откат». Изменения — первая гипотеза, модели — вторая.

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

30. NLP по тикетам и постмортемам — что полезного можно выжать?

Тикеты, алерты, переписка инцидентов и постмортемы — это годы эксплуатационного опыта в виде текста, который никто не читает целиком. NLP превращает архив в инструменты. Кластеризация похожих инцидентов: эмбеддинги описаний плюс кластеризация вскрывают повторяющиеся проблемы, размазанные по командам и месяцам, — двадцать тикетов «зависает выгрузка отчёта», закрытых рестартом, из разных очередей никогда не встретятся в одной голове, а в кластере они кричат о систематическом дефекте, который дешевле починить, чем рестартить двадцать первый раз. Поиск похожих при новом инциденте: дежурный получает «похожие прошлые случаи и что тогда помогло» — самый прямой перенос опыта, особенно для новичков в он-колле. Маршрутизация: классификатор по тексту тикета направляет его нужной команде, срезая круг «это не к нам». Извлечение структуры из постмортемов: причины, затронутые сервисы, действия — для аналитики «на что мы реально тратим инциденты». Честные ограничения: качество упирается в качество текстов (тикеты «всё сломалось, починили» некластеризуемы), нужна нормализация терминов (один сервис под тремя именами), а маленький архив в пару сотен тикетов не даст статистики. Начинать стоит с поиска похожих — он полезен с первого дня и не требует разметки.

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

Follow-up интервьюера: как заставить людей писать тикеты, пригодные для анализа? — не заставлять, а собирать автоматически: таймлайн, алерты и действия прикладываются к тикету машиной, человек пишет только выводы. Качество данных добывается инструментами, а не приказами.

Блок 5. RCA и автоматизация реакции

31. Автоматический RCA — из чего он складывается?

Root cause analysis машиной — это не одна модель, а сведение трёх источников знания. Первый — топология: граф зависимостей, по которому симптомы сводятся к общему предку; без него любая «первопричина» — совпадение по времени. Второй — история: прошлые инциденты, их причины и решения; новый инцидент сравнивается с архивом — похожая сигнатура алертов и метрик встречалась, причиной была исчерпанная пул-коннекция, вот тот постмортем. Третий — телеметрия в реальном времени: что аномально прямо сейчас во всех сигналах затронутого участка (метрики, свежие ошибки в логах, деградировавшие спаны) плюс лента изменений — деплои, флаги, конфиги. Выход честного автоматического RCA — не вердикт, а ранжированный список гипотез с доказательствами: «с вероятностью выше всего — релиз payments 12 минут назад (совпадение по времени и топологии, новые шаблоны ошибок в его логах), вторая гипотеза — деградация базы (рост latency запросов)». Каждая гипотеза кликабельна до сырых данных — дежурный проверяет, а не верит. Уровень зрелости индустрии стоит назвать честно: сужение с пятидесяти сервисов до трёх подозреваемых — рабочая реальность и огромная экономия; «система назвала точную причину» — пока рекламный слайд, человек из петли не выходит.

Описывают RCA как одну волшебную модель. Раскладка «топология + история + живая телеметрия + лента изменений» с честным выходом в виде гипотез, а не вердикта — тот скелет ответа, который отличает инженера от посетителя вендорских презентаций.

Follow-up интервьюера: система выдала неверную первую гипотезу — насколько это плохо? — терпимо, если гипотезы дешёвые в проверке и следующая — верная; смертельно, если дежурный слепо чинит первую. Поэтому доказательства при гипотезе обязательны — они делают проверку быстрой.

32. Корреляция — не причинность: как не обвинить невиновный сервис?

Главная методологическая ловушка автоматического RCA. Метрики двух сервисов упали одновременно — это корреляция, о причине она молчит: A мог сломать B, B мог сломать A, оба могла сломать общая причина — нода, сеть, база, релиз общей библиотеки, — или совпадение (в большой системе одновременные независимые события — норма, а не редкость). Система, честно называющая корреляцию причиной, регулярно обвиняет невиновных — и дежурный тратит время на ложный след, что хуже отсутствия подсказки: подсказка приходит с авторитетом машины. Как повышать достоверность. Направление зависимости: если A зовёт B, деградация B объясняет деградацию A, но не наоборот — топология превращает симметричную корреляцию в асимметричную гипотезу. Временной порядок: причина раньше следствия; лаг между аномалиями — слабое, но свидетельство. Механизм: гипотеза сильнее, если есть путь отказа — рост latency B и таймауты в логах A с именем B — это уже цепочка, а не совпадение. Контрфактика там, где возможна: канареечное сравнение, участки трафика мимо подозреваемого. И калибровка выдачи: система обязана сообщать уверенность и доказательства, а слово «причина» заменять на «кандидат» — лексика интерфейса формирует доверие и цену ошибки.

Кандидат кивает «корреляция не причинность», но не может назвать ни одного способа приблизиться к причинности — направление зависимостей, временной порядок, механизм отказа. Афоризм без инструментов — гуманитарный ответ на инженерный вопрос.

Follow-up интервьюера: оба сервиса деградировали строго одновременно, зависимости между ними нет — первая мысль? — общий ресурс: нода, зона, база, сеть, лимиты, общий релиз библиотеки или конфига. Одновременность без связи — почти всегда общий родитель, и искать надо его.

33. Уровни автоматизации реакции — от runbook по кнопке до self-healing

Лестница из четырёх ступеней, и подниматься по ней надо последовательно. Нулевая — документированный runbook: человек читает и делает руками; автоматизации нет, но есть формализованное знание — без него автоматизировать нечего. Первая — runbook по кнопке: диагностика и действие оформлены скриптом/джобой, человек принимает решение и жмёт; автоматика исполняет быстро и без опечаток в три ночи. Вторая — авто-ремедиация с апрувом: система сама распознаёт ситуацию, сама предлагает действие («под в CrashLoopBackOff после деплоя — откатить?»), человек подтверждает одним нажатием; решение ещё за человеком, вся подготовка — за машиной. Третья — автономная ремедиация: распознала — сделала — отчиталась; применяется к узким, хорошо изученным, безопасным сценариям с исчерпаемым набором исходов. Полная автономия на всём спектре инцидентов — аспирация: инциденты по определению содержат новое, а автомат хорош в известном; к тому же неудачная авторемедиация — это инцидент поверх инцидента, устроенный со скоростью машины. Признаки готовности сценария к следующей ступени: действие идемпотентно и обратимо, сработало руками десятки раз без сюрпризов, есть лимиты (не чаще N раз, не больше M объектов) и автоматический стоп при ухудшении. Движение по лестнице — это накопление доверия, а не установка софта.

Прыгают в «self-healing» через ступени: предлагают автономные действия для сценариев, которые ни разу не были даже кнопкой. Встречный вопрос «что будет, если твой авто-рестарт зациклится?» без ответа про лимиты и стоп-условия закрывает тему.

Follow-up интервьюера: какой процент инцидентов реально закрывается автономно в зрелых системах? — узкий: типовые деградации с известным лекарством. И это нормально — ценность не в проценте автономии, а в том, что типовое перестало будить людей, освободив их для нетипового.

34. Какие авто-действия безопасны, а какие — нет?

Критерий — не «просто/сложно», а три свойства: обратимость, идемпотентность, ограниченность последствий. Безопасный список: рестарт пода — обратим (под и так пересоздаваем), идемпотентен, худший исход — минус одна реплика на минуту; горизонтальный скейл вверх — обратим, ограничен квотами, худший исход — лишние расходы; откат канарейки — само действие спроектировано как обратимое, для того канарейку и делали; вывод ноды из ротации с сохранением форензики; включение деградированного режима (отключить тяжёлую фичу флагом). Общее у них: они не трогают данные и не могут сделать хуже необратимо. Опасный список: всё, что касается данных — миграции, чистки, «починка» консистентности скриптом; массовые операции — рестарт всех подов сервиса решением автомата превращает деградацию в даунтайм; действия с не до конца понятым состоянием — фейловер базы при флапающей сети (риск split-brain), «освобождение места» удалением файлов; каскадируемые действия — то, что триггерит другие автоматики. И системные предохранители для любого уровня: rate limit на действия, circuit breaker (после N срабатываний за час — стоп и эскалация человеку), проверка результата после действия с откатом при ухудшении, аудит каждого шага. Автоматика без предохранителей — это инцидент, ждущий расписания.

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

Follow-up интервьюера: авто-рестарт маскирует утечку памяти месяцами — как не потерять проблему? — каждое авто-действие оставляет след: тикет, счётчик, тренд. Рост частоты срабатываний — сам по себе алерт: автоматика лечит симптом и обязана сообщать о хронике.

35. Как AIOps встраивается в процесс управления инцидентами?

Процессная база — роли, коммуникация, порядок действий, когда прод лёг, — разобрана в DevOps-подборке; здесь — что меняет AIOps на каждом шаге, не меняя сам процесс. Обнаружение: детект поднимает инцидент раньше жалоб, а корреляция сразу склеивает связанные алерты — инцидент рождается один, а не пятью тикетами в трёх командах. Триаж: к инциденту машиной приложен контекст — затронутые сервисы, влияние на SLO, похожие прошлые случаи, изменения рядом; оценка серьёзности занимает минуты вместо обзвона. Диагноз: ранжированные гипотезы RCA с доказательствами — стартовые точки для команды. Коммуникация: авто-таймлайн (алерты, действия, деплои — с точным временем) снимает с людей ведение хронологии, статусы для стейкхолдеров генерируются из него. Разрешение: кнопочные ремедиации под рукой у дежурного. Постмортем: готовый таймлайн и данные вместо археологии по чатам. Ключевой принцип встраивания: AIOps ускоряет шаги процесса, но не подменяет ответственность — инцидент-коммандер остаётся человеком, решения фиксируются за людьми, а рекомендации системы имеют статус рекомендаций. Проекты, где «ИИ теперь ведёт инциденты», умирают при первой же ошибке системы; проекты, где ИИ сокращает каждый шаг человеческого процесса, приживаются.

Рассказывают про AIOps как замену процесса: «система сама всё найдёт и починит». Интервьюер слышит человека, не жившего в он-колле: инцидент — это ещё координация, коммуникация и ответственность, и они не автоматизируются моделью.

Follow-up интервьюера: система склеила в один инцидент то, что оказалось двумя, — кто и как это чинит по процессу? — дежурный разлепляет руками (операция обязана существовать), а случай уходит в разбор качества корреляции — фидбек-петля от инцидентов к настройкам системы.

36. Декомпозиция MTTR — где именно AIOps экономит время?

MTTR — сумма фаз, и лечить её целиком — как лечить «плохое самочувствие». Раскладка: детект (от начала проблемы до сигнала) → триаж (от сигнала до «этим занимаются нужные люди») → диагноз (от начала работы до понимания причины) → фикс (от понимания до восстановления) → верификация. Меряй фазы отдельно — и увидишь, куда уходит время; в большинстве команд самая жирная фаза — диагноз: поиск причины съедает больше времени, чем само исправление, которое часто сводится к откату или рестарту. И именно диагноз AIOps сокращает сильнее всего: корреляция сужает поле поиска, лента изменений даёт первую гипотезу, RCA ранжирует остальные, поиск похожих инцидентов приносит прошлый опыт — час листания дашбордов сжимается в минуты проверки готовых гипотез. Детект — вторая по отдаче фаза: адаптивные модели ловят деградацию раньше порогов и раньше пользователей. Триаж ускоряется корреляцией и авто-маршрутизацией. А вот фикс почти не ускоряется — он упирается в зрелость деплоя: скорость отката, фича-флаги, канарейки; это территория CI/CD, не ML. Практический вывод для внедрения: сначала измерь фазы своих инцидентов — если у тебя болит фикс (откат занимает час), покупать RCA-платформу бессмысленно, чини пайплайн.

Говорят «AIOps снижает MTTR» как мантру, не раскладывая на фазы. Вопрос «какую фазу твоего MTTR AIOps не сократит никак?» — контрольный: ответ «фикс, он про зрелость деплоя» показывает, что кандидат понимает границы инструмента.

Follow-up интервьюера: как честно измерить фазу диагноза? — по таймлайну инцидентов: от «взяли в работу» до первого верного вывода о причине (фиксируется в постмортеме). Ручной учёт врёт, поэтому таймстампы должны собираться инструментами инцидент-менеджмента.

37. Как измерить эффект от внедрения AIOps, чтобы поверил и бизнес, и команда?

Проблема измерения: инциденты нестационарны — их число и тяжесть плавают сами по себе, и «MTTR упал на 20% после внедрения» может означать что угодно, включая спокойный квартал. Честные подходы. Контролируемое сравнение: если дежурных команд несколько, включи систему части команд (или части сервисов) и сравнивай динамику с контрольной группой — это максимально близко к A/B, доступному в эксплуатации. Попарное сравнение инцидентов: сопоставимые по типу инциденты до и после — сколько занял диагноз; типизация убирает часть шума. Прокси-метрики с быстрой обратной связью: время до первой верной гипотезы (из таймлайнов), доля инцидентов, где подсказка системы была использована (принятые гипотезы, клики по похожим случаям), число алертов и пробуждений на дежурного, доля инцидентов, обнаруженных системой раньше людей и жалоб. Эти метрики двигаются за недели, а не кварталы, и меньше зависят от везения. Субъективная, но важная: опрос дежурных — стало ли легче; система, которую команда саботирует, не покажет эффекта ни в одной метрике. И дисциплина честности: зафиксируй метрики и методику до внедрения — пост-фактум подобранные показатели всегда «подтверждают успех», это знает каждый, кто читал вендорские кейсы.

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

Follow-up интервьюера: почему «время до первой верной гипотезы» — хорошая метрика? — она изолирует именно тот шаг, который система обещает ускорить, измерима по таймлайну и не зависит от длительности фикса, на которую AIOps не влияет.

38. Доверие дежурных к автоматике — почему оно главный ресурс и как его не сжечь?

Любая AIOps-система живёт ровно до тех пор, пока дежурные ей верят. Доверие несимметрично: строится месяцами, сгорает за пару эпизодов — три ложных ночных пейджа, одна уверенно-неверная гипотеза RCA в критичный момент — и команда возвращается к ручному разбору, а система продолжает работать в пустоту, что бы ни показывали её метрики. Инженерные следствия. Внедрение через shadow mode: система сначала наблюдает и пишет, что бы она сказала; команда еженедельно разбирает её сработки без единого пейджа — точность становится видимой до того, как система получает право будить. Постепенное повышение прав: сначала аннотации в существующих алертах, потом свои тикеты, потом пейджи, потом кнопки действий — каждый шаг после подтверждённой точности предыдущего. Объяснимость каждого срабатывания: почему разбудили — какая метрика, насколько от нормы, что рядом менялось; «модель так решила» — формулировка, убивающая доверие быстрее ошибок. Калиброванная уверенность: система, различающая «уверен» и «предполагаю», прощается за ошибки в «предполагаю»; система, всегда уверенная, — нет. Дешёвый фидбек: кнопка «мимо» на каждой подсказке, и видимая реакция на этот фидбек — люди верят системе, которая исправляется. И правило эксплуатации: каждый ложный пейдж разбирается как инцидент качества системы, а не пожимание плечами.

Тема доверия у кандидатов отсутствует как класс: рассказывают про модели, а на «почему хорошую систему отключили через два месяца» отвечают недоумением. Кто пережил внедрение автоматики в он-колл, тот начинает с доверия, а не с архитектуры.

Follow-up интервьюера: команда игнорирует подсказки системы, хотя точность высокая — что проверишь? — форму подачи: в том ли канале, в тот ли момент, не тонут ли подсказки в шуме, требуют ли лишних кликов. Точность без эргономики не работает — подсказка должна быть дешевле игнорирования.

Блок 6. Инструменты и платформы

39. Prometheus + Alertmanager + Grafana — что умеет базовый стек и где его потолок?

Базовый стек закрывает мониторинг метрик целиком: Prometheus собирает и хранит ряды, PromQL считает всё от rate до квантилей, recording rules дают предагрегацию, Alertmanager — маршрутизацию, группировку и подавление, Grafana — визуализацию поверх этого и соседних источников. На этой базе строится больше «AIOps», чем принято думать: предсказания через predict_linear, динамические границы через квантили по истории (сравнение с тем же часом прошлой недели), алерты на отклонение от сезонной нормы, посчитанной recording rule'ами. Потолок начинается там, где нужен анализ между сигналами и между системами. Prometheus не знает про логи и трейсы — корреляция «метрика упала, в логах новые ошибки, трейс показывает виновника» собирается человеком в голове. Alertmanager группирует по лейблам, но не умеет топологию: «эти сорок алертов — один каскад от умершей базы» он не скажет. Нет ленты изменений, нет истории инцидентов, нет обучаемых моделей — сложные сезонности и многомерные аномалии в PromQL не выражаются. И нет памяти: каждый инцидент разбирается с нуля, опыт прошлых живёт в головах. Правильная рамка: стек — обязательный фундамент и источник данных для любого AIOps-слоя, а «потолок» — это не его недостаток, а определение места, где начинается следующий слой.

Кандидаты либо недооценивают стек («для AIOps нужна платформа») — не выжав из PromQL и Alertmanager даже половины, либо переоценивают («нам хватает Prometheus») — не видя, что кросс-сигнальную корреляцию у них выполняет уставший человек в три ночи.

Follow-up интервьюера: как сделать «сравнение с прошлой неделей» в чистом PromQL? — offset 1w: текущее значение против значения неделю назад, порог на относительное отклонение. Грубая сезонная модель без единой строчки ML.

40. Anomaly detection в готовых продуктах — что у них под капотом?

Datadog: anomaly monitors — детект отклонений от нормы с учётом сезонности (алгоритмы от простых robust-границ до сезонных моделей — выбираются под характер метрики), forecast-мониторы — предсказание «метрика пересечёт порог через N часов», Watchdog — фоновый слой, который сам сканирует телеметрию и подсвечивает аномалии, не дожидаясь настроенных мониторов. Elastic ML: аномалии в данных Elasticsearch — временные ряды поверх логов и метрик, выявление редких сообщений, population-анализ (сущность ведёт себя не как популяция — один хост не как все хосты), джобы настраиваются по полям и агрегациям. Grafana Machine Learning (в облачной версии): обучение модели нормы для метрики и алерты на выход за прогнозный коридор. Общее под капотом у всех: статистические и лёгкие ML-модели временных рядов — декомпозиция сезонности, робастные границы, прогноз с доверительным интервалом; никакой магии, тот же арсенал из блока про детект, но упакованный: без кода, с UI и с обслуживанием на стороне вендора. Что остаётся на тебе, и это главная часть ответа: выбор метрик (детект на мусорной метрике даёт мусор в красивой обёртке), настройка чувствительности, разбор срабатываний и встраивание в процесс. Продукт снимает ML-инжиниринг, но не снимает инженерию алертинга.

«Включим Watchdog, и будет AIOps» — вера в кнопку. Вторая крайность — снобизм «там просто статистика»: да, и это нормально; вопрос не в глубине моделей, а в том, что упакованная статистика с обслуживанием часто выгоднее самописной нейросети без него.

Follow-up интервьюера: чем anomaly monitor отличается от forecast monitor и когда какой? — аномалия — «сейчас не как обычно» (реактивный), прогноз — «скоро пересечём порог» (проактивный, для ёмкости: диск, квоты, лимиты). Разные вопросы — разные мониторы.

41. Event intelligence: BigPanda, Moogsoft, ServiceNow ITOM — когда этот класс оправдан?

Класс продуктов, живущий на слое между источниками алертов и людьми: принимают события отовсюду (Prometheus, Zabbix, облачные мониторинги, APM, железо), нормализуют в единый формат, дедуплицируют, коррелируют по времени, топологии и тексту — и выдают инциденты вместо алертов, с маршрутизацией в дежурства и тикеты. ServiceNow ITOM добавляет сюда CMDB и топологию из discovery, плюс интеграцию с ITSM-процессами — сила именно в связке «события + карта инфраструктуры + процесс». Когда класс оправдан: зоопарк источников мониторинга (энтерпрайз с наследием: пять систем мониторинга из трёх эпох, и заменить их одним стеком нереально), большие объёмы событий через центральный NOC или несколько дежурных линий, потребность в сквозной картине «событие → инцидент → тикет → изменение». Тогда покупка слоя корреляции дешевле, чем писать его самим. Когда не оправдан: один стек (Prometheus + Alertmanager закрывают группировку конфигом), одна-две команды дежурных, алертов десятки в день — платформа корреляции поверх этого будет дорогим способом переименовать алерты в инциденты. И универсальное условие из первого блока: если алерты — помойка, event intelligence отфильтрует шум лишь частично, а платить за него придётся полностью; чистка правил алертинга даёт тот же эффект бесплатно.

Не могут очертить нишу: либо «это для всех» (нет — малым стекам он избыточен), либо «это легаси для энтерпрайза» (нет — при пяти источниках событий и NOC он решает реальную боль). Ответ без условий применимости — не ответ.

Follow-up интервьюера: чем корреляция такой платформы лучше Alertmanager? — измерениями: Alertmanager группирует по равенству лейблов одного источника; платформа связывает события разных систем по времени, топологии и похожести текста — то, что лейблами не выражается.

42. Build vs buy в AIOps — когда собирать своё, а когда покупать?

Решение принимается по трём осям. Ось задачи: узкие, хорошо очерченные задачи — предсказание ёмкости, детект на ключевых метриках, корреляция с деплоями — собираются из открытых компонентов быстро: PromQL, Prophet или sklearn в кроне, вебхуки; широкие платформенные задачи — единый слой корреляции над зоопарком источников, управление инцидентами с ML-подсказками — это годы разработки, и покупка честнее. Ось команды: своё решение требует не «написать», а «владеть» — переобучение, дрифт, дежурство по самой системе, документация; если некому владеть, самописный AIOps умрёт вместе с энтузиастом, который его написал. Ось данных: коробочные продукты сильны на типовых данных и слепы к специфике; если твоя ценность — в уникальных данных (свой поток событий, своя топология, свои постмортемы), интеграционный слой всё равно писать тебе, и вопрос «build vs buy» превращается в «сколько своего кода вокруг покупки». Практический паттерн зрелых команд — гибрид: телеметрия и алертинг — открытый стек, тяжёлый ML — покупается или берётся из managed-сервисов, а клей — корреляция с изменениями, доменные правила, интеграция с процессами — свой, потому что он и есть конкурентное знание твоей эксплуатации. И тест на трезвость: посчитай TCO своего на три года вперёд, включая владение, — цифра лечит романтику.

Ответ-крайность в любую сторону: «всё пишем сами, вендоры — переплата» (кто будет владеть через год?) или «покупаем платформу, она всё умеет» (кто интегрирует её с вашими данными?). Отсутствие слова «владение» в ответе — главный маркер незрелости.

Follow-up интервьюера: что в AIOps почти всегда придётся делать самим, что бы ни купили? — данные и процесс: качество телеметрии, лента изменений, разметка инцидентов, встройка в он-колл. Продукты это потребляют, но не создают.

43. Сколько стоит хранить телеметрию — retention, downsampling и приоритеты

Телеметрия — это деньги: хранилище, диски, лицензии (у части вендоров тариф — за объём или число рядов), плюс скрытая цена — медленные запросы по разбухшим данным. Взрослый ответ строится вокруг того, что ценность точки данных падает со временем, а стоимость хранения — нет. Отсюда инструменты. Retention-политики: сырым метрикам секундного-минутного разрешения — недели (столько живёт их диагностическая ценность), дальше — удаление или понижение разрешения. Downsampling: старые данные агрегируются в пятиминутные и часовые точки — тренды и ёмкостное планирование не требуют секунд; Thanos/Mimir делают это штатно, храня min/max/avg/count, чтобы агрегаты не врали. Разделение по важности: SLI ключевых сервисов и данные для обучения моделей — длинный retention, отладочные метрики — короткий; то же с логами: debug — дни, ошибки и аудит — по требованиям. Контроль на входе дешевле контроля хранения: кардинальность, сэмплирование трейсов, уровни логирования — лишнее выгоднее не собирать, чем хранить. Для AIOps есть конфликт, который надо назвать: моделям сезонности нужна история в месяцы полного разрешения — значит, ряды-фичи для моделей объявляются явно (recording rules) и хранятся долго, а сырьё вокруг них живёт коротко. Хранить всё вечно «на всякий случай» — не стратегия, а отсутствие решения.

Никогда не считали стоимость: на «сколько стоит ваш мониторинг в месяц» — тишина. И не видят конфликта «ML хочет длинную историю — бюджет хочет короткий retention», который решается предагрегацией нужных рядов, а не хранением всего.

Follow-up интервьюера: почему downsampling должен хранить min и max, а не только среднее? — среднее сглаживает пики: всплеск latency до 10 секунд внутри часа исчезнет в часовом avg. Для разбора инцидентов прошлого экстремумы важнее среднего.

44. Дешёвый AIOps без ML-платформ: predict_linear и предсказание «диск кончится через N часов»

Самый рентабельный «интеллект» в мониторинге — линейная экстраполяция, встроенная в PromQL. predict_linear строит регрессию по окну истории и предсказывает значение через заданное время:

# алерт: диск закончится в ближайшие 4 часа
# (по тренду последних 6 часов)
- alert: DiskWillFillIn4Hours
  expr: |
    predict_linear(
      node_filesystem_avail_bytes{mountpoint="/data"}[6h], 4 * 3600
    ) < 0
  for: 30m
  labels:
    severity: warning
  annotations:
    summary: "Диск {{ $labels.instance }} заполнится ~через 4 часа"

Разница с порогом «диск заполнен на 90%» принципиальная: порог говорит о состоянии, предсказание — о времени до проблемы. Диск на 91%, стоящий так месяц, — не проблема; диск на 60%, набирающий по 10% в час, — проблема через четыре часа, и порог его проспит до ночи. for: 30m отсекает краткие всплески записи. Тот же приём работает для всего монотонного: место в базе, инodes, рост очереди, исчерпание пула коннекций, квоты. Ограничения честные: линейная модель — для линейных трендов; на пилообразных метриках (лог-ротация) и резких изменениях режима она врёт, окно надо подбирать под характер метрики. Но класс задач «ресурс кончается» она закрывает бесплатно — и кандидат, который начинает AIOps с этого, а не с покупки платформы, демонстрирует правильный порядок ценностей.

Кандидаты с «AIOps» в резюме не знают predict_linear — и предлагают обучать модель для задачи, которая решается одной строкой PromQL. Обратный провал: не могут назвать ограничения линейности и предлагают predict_linear на пилообразную метрику.

Follow-up интервьюера: почему окно 6 часов, а не 30 минут? — короткое окно ловит шум (один всплеск записи — ложный прогноз), длинное — сглаживает реальные изменения тренда. Окно должно быть в несколько раз больше горизонта предсказания — и подбирается по метрике.

45. Открытые стандарты против vendor lock-in — что это значит для телеметрии?

Lock-in в observability устроен коварнее, чем в других слоях: он входит через агенты и форматы. Проприетарный агент вендора инструментирует приложения его SDK, шлёт в его формат, алерты и дашборды живут в его платформе — и через три года «сменить APM» означает перетрогать каждый сервис компании; на этом и держатся ценники продлений. Открытые стандарты режут связку по слоям. Сбор: OpenTelemetry — инструментация кода вендор-нейтральна, точка выбора бэкенда сдвигается в конфиг Collector'а; поменять вендора — поменять exporter. Форматы и протоколы: OTLP, формат экспозиции Prometheus (де-факто стандарт метрик, поддержан всеми), у логов — структурный JSON, который переживёт любой бэкенд. Запросы: PromQL стал lingua franca — совместимость с ним заявляют и коммерческие TSDB, что упрощает переезд дашбордов и правил. Что остаётся невыносимым даже со стандартами, и это честная часть ответа: исторические данные (миграция архивов телеметрии почти никогда не окупается — обычно живут параллельно до истечения retention), настроенные алерты, дашборды, ML-конфигурации и, главное, привычки команды. Поэтому стратегия — не «никаких вендоров», а «вендор заменяем на каждом слое»: инструментация стандартная, данные в открытых форматах, а платить вендору можно — за анализ и удобство, то есть за то, что реально его.

Лозунг «только опенсорс» вместо анализа, где именно живёт lock-in. Правильная рамка — какие слои (инструментация, транспорт, хранение, анализ) фиксируются стандартами, а на каких вендор допустим, потому что заменяем без перетрогивания кода.

Follow-up интервьюера: компания уже на проприетарном агенте — как слезать без остановки мира? — постепенно: OTel в новые сервисы и шаблоны, Collector с двойной отправкой на переходный период, миграция по командам. Big bang в телеметрии не выживает.

46. Как выбрать пилотный use case для AIOps?

Пилот решает не техническую задачу, а политическую: заработать доверие к подходу. Отсюда критерии выбора. Измеримая боль: подсистема, где шум алертов или долгий диагноз болят сейчас и это видно в цифрах (пробуждения за месяц, часы на разбор), — эффект пилота должен быть виден без микроскопа. Хорошие данные: у выбранного сервиса телеметрия уже приличная — пилот не должен начинаться с полугода наведения порядка; для того и выбираем участок, где фундамент есть. Ограниченный масштаб: одна команда, один класс задач (например, детект аномалий на SLI трёх ключевых сервисов, или корреляция алертов одной шумной подсистемы) — не «внедрим платформу на всё». Дружественная команда: дежурные, готовые давать фидбек и разбирать сработки, — половина пилота, скептиков убеждают результатом, а не участием. Быстрая петля: недели до первых данных о точности, квартал до выводов. И заранее зафиксированные критерии успеха и провала: «снизить ночные пейджи на X% при неувеличении пропусков» — записано до старта, вместе с решением, что делаем при провале. Типовые анти-паттерны выбора: самый сложный инцидент года (редкий, не повторится — нечего мерить), самая политически важная система (цена ошибки пилота максимальна) и «всё сразу» (не взлетит и дискредитирует тему на годы).

Выбирают пилот по эффектности, а не по измеримости: «предскажем крупные аварии» — их единицы в год, статистики не будет. Пилот на частой, скучной, измеримой боли (шум, медленный триаж) проигрывает в презентации и выигрывает в реальности.

Follow-up интервьюера: пилот удался — что чаще всего ломается при масштабировании? — предпосылки: у других команд грязнее данные, другие процессы и нет энтузиазма. Масштабирование — это тираж не модели, а гигиены данных и процесса, и стоит дороже пилота.

Блок 7. ML-инжиниринг для AIOps

47. Где брать разметку для обучения — и почему её почти нет?

Больная точка всего AIOps: supervised-модели хотят примеры «это инцидент / это норма», а чистой разметки в эксплуатации почти не существует. Кажется, что источник есть — тикеты и журнал инцидентов, — но эта разметка грязная по построению: зафиксированы только замеченные инциденты (пропущенные размечены как «норма» — и модель научится их пропускать), время начала в тикете — время обнаружения, а не начала проблемы (сдвиг разметки на самом важном участке), тяжесть и категории заполнены как попало, а мелкие деградации не тикетируются вовсе. Плюс дисбаланс: аномалий — доли процента, и любой наивный классификатор выродится в «всегда норма». Отсюда стратегия индустрии: основа — unsupervised (детект отклонений от нормы не требует меток аномалий, только более-менее чистую норму), поверх — semi-supervised и human-in-the-loop: сработки детектора разбираются дежурными, каждый вердикт «правда/мимо» становится меткой, и разметка накапливается как побочный продукт эксплуатации — дешёвый фидбек в интерфейсе (одна кнопка) важнее любых кампаний по разметке. Историческая разметка добывается из постмортемов и эпизодов нарушения SLO — немного, но хватает для оценки моделей (replay), если не для обучения. И правило гигиены: время начала инцидента для оценки детекта уточняется по данным, а не берётся из тикета.

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

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

48. Дрифт в AIOps: система меняется каждый деплой — что делать с моделью нормы?

В классическом ML дрифт — постепенное расползание данных; виды дрифта и способы детекта разобраны в MLOps-подборке. В AIOps он злее и быстрее: сама система, чью «норму» выучила модель, меняется десятки раз в неделю — деплой сдвигает базовый уровень latency, автоскейлинг меняет профиль CPU, миграция трафика перекраивает пропорции, новый клиент меняет паттерн нагрузки. Модель нормальности устаревает не за кварталы, а за дни, и у устаревания два симптома: волна ложных срабатываний (норма уехала, модель не заметила) или молчание на реальной проблеме (модель успела выучить деградацию как норму). Что с этим делать. Retraining по расписанию: короткие окна обучения и частое переобучение — стандарт для AIOps; модель, обученная на свежих неделях, следует за системой сама. Событийное переобучение: деплой сервиса — сигнал сбросить или переучить его модели, лента изменений здесь снова обязательна. Карантин инцидентов: окна подтверждённых проблем исключаются из обучающих данных, иначе следующая модель считает инцидент нормой. Мониторинг самой модели: доля срабатываний, распределение скоров, доля подтверждённых — выход за коридор означает «модель устарела» и сам является алертом. Это и есть MLOps для AIOps: модели детекта — такой же прод, с пайплайном, версионированием и мониторингом качества.

Переносят из классического ML привычку «переобучаем раз в квартал» — в инфраструктуре, которая меняется ежедневно, это музейная модель через месяц. Не знают про карантин инцидентов — и их пайплайн честно обучает каждую следующую модель на прошлых авариях как на норме.

Follow-up интервьюера: частое переобучение на свежих данных — а если деградация ползёт неделями и попадает в каждое окно обучения? — держать два горизонта: быстрая модель для острых аномалий и медленная (или сравнение с давним baseline) для ползучих — одна модель оба масштаба не закрывает.

49. Объяснимость алерта — что должен увидеть дежурный?

Разбуженный в три ночи человек имеет право на ответ «почему», и у этого права инженерная форма. Минимальный набор в каждом ML-алерте: какая метрика и какой сервис; факт против ожидания — «p99 550 мс при ожидаемых 120±40 для этого часа» (число, а не «скор 0.93»); картинка — график с коридором нормы и точкой срабатывания, вшитый прямо в уведомление; вклад признаков для многомерных моделей — какие метрики потянули скор (для леса и линейных моделей — штатно, для нейросетей — SHAP-подобные методы, и их цена — аргумент в пользу простых моделей в алертинге); контекст — что менялось рядом (деплой, флаг), похожие прошлые случаи; и ссылка в один клик к сырым данным. Такой алерт проверяется за минуту; алерт «anomaly detected, score 0.93» проверяется через недоверие и раздражение. Есть и вторая роль объяснимости, которую называют редко: она нужна для отладки самой системы — разбирать ложные срабатывания можно только у модели, которая объясняет свои решения; чёрный ящик не дебажится, он только перевзвешивается вслепую. Отсюда практическое правило выбора моделей для он-колла: между моделью на 2% точнее и моделью, объяснимой дежурному, для алертинга выбирается вторая — потому что точность без доверия не конвертируется в MTTR.

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

Follow-up интервьюера: модель-ансамбль точнее на 5%, но вклад признаков из неё не достать — берёшь в пейджинг? — в пейджинг — нет, в фоновые тикеты и подсказки — можно: требования к объяснимости растут с ценой действия, которое алерт вызывает.

50. Онлайн против батч-скоринга телеметрии — как выбирать?

Два режима с разной экономикой и разной задержкой. Онлайн (стриминговый) скоринг: точки оцениваются по мере поступления — детект срабатывает через секунды-минуты после аномалии; это обязательный режим для всего, что пейджит: инцидент, найденный часовым батчем, — это час форы, подаренный проблеме. Требования соответствующие: модель должна скорить дёшево (миллионы точек в минуту — поэтому в онлайне живут EWMA, лёгкая статистика, заранее обученные деревья, а не тяжёлые сети), состояние — компактное (скользящие статистики, а не полное окно), инфраструктура — потоковая (обработка на лету у источника или в стриминг-пайплайне). Батч: скоринг периодикой — часами или сутками; годится для медленного: ёмкостное планирование, еженедельные отчёты об аномалиях, ретроспективный анализ, поиск ползучих деградаций, и там же живёт обучение моделей — тяжёлое по определению. Стандартная архитектура — гибрид: батч обучает и калибрует модели на истории, публикует их (параметры границ, сезонные профили — хоть recording rule'ами, хоть моделью в реестре), онлайн-слой дёшево применяет опубликованное к живому потоку. Разделение снимает конфликт «тяжёлое обучение против дешёвого применения» — и вопрос на собесе обычно проверяет именно понимание этого разделения, а не термины.

Не делят задачу на «обучение — тяжёлое, редкое» и «применение — дешёвое, постоянное»: предлагают либо гонять обучение на каждой точке, либо детектить инциденты суточным батчем. Гибрид «batch обучает — online применяет» — ожидаемый каркас ответа.

Follow-up интервьюера: где физически считать онлайн-скоринг — у источника или централизованно? — дешёвые правила и статистики — ближе к источнику (меньше трафика и задержки), модели с общим контекстом — централизованно. Критерий — сколько контекста нужно решению.

51. Фичи для временных рядов: sliding window, лаги и утечка будущего

Табличные модели не понимают время — его переводят в признаки. Основной приём — скользящее окно: для каждой точки считаются статистики по последним N минутам — среднее, медиана, std, min/max, перцентили; окон несколько (5 минут, час, сутки), чтобы модель видела и острое, и фоновое. Лаги — значения метрики в прошлые моменты: минуту, час, сутки, неделю назад; лаг на период сезонности — дешёвый способ дать модели сезонность без явной декомпозиции (значение против «того же времени вчера/неделю назад»). Разностные признаки — скорость и ускорение изменения, длина монотонного участка: они ловят тренды и ползучие деградации. Календарные — час, день недели, праздники, через синус-косинус для цикличности. Контекстные — соседние метрики (нагрузка как контекст CPU). Главная техническая ловушка — утечка будущего: при обучении на истории признаки для точки t обязаны считаться только по данным до t; окно, случайно центрированное на точке (захватывает будущее), или нормализация по статистикам всего датасета дают модель, которая блестит на бэктесте и слепнет в проде, где будущего в фичах нет. Отсюда же правило валидации: сплит только по времени (train — прошлое, test — будущее), никакого случайного перемешивания точек ряда — иначе оценка врёт по построению.

Перечисляют фичи, но не знают про утечку будущего и валидируют случайным сплитом — на собесе это ловится вопросом «как делишь train/test для временного ряда?». Ответ «случайно, 80/20» — диагноз: модель кандидата никогда не работала в проде так, как на его графиках.

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

52. Replay на исторических инцидентах — как проверить модель до прода?

Replay — прогон детектора по архивной телеметрии так, как будто она поступает в реальном времени, с проверкой против известных инцидентов: поймала бы модель прошлый год аварий, насколько раньше человека и сколько бы налгала между ними. Это главный офлайн-тест AIOps-системы, и у него строгие правила. Честная симуляция времени: модель видит данные только «до текущего момента» реплея — включая собственное переобучение по расписанию; прогнать модель, обученную на всём годе, по этому же году — самообман из прошлого вопроса. Метрики по событиям: поймала/пропустила инцидент, опережение (насколько раньше фактического обнаружения — это прямой прогноз выигрыша MTTD), и число срабатываний вне инцидентов — оценка будущего шума; последняя цифра важнее всего для доверия: «поймала 9 из 10 инцидентов» бессмысленно без «и дала 400 ложных сработок за тот же период». Ограничения replay, которые надо проговорить: разметка неполна (пропущенные тогда инциденты числятся нормой — реальный precision будет выглядеть хуже, часть «ложных» сработок — непойманные тогда проблемы), телеметрия могла измениться с тех пор, и replay не меряет человеческий фактор — доверие и эргономику. Поэтому пайплайн приёмки трёхступенчатый: replay → shadow mode на живом потоке → ограниченный прод. Каждая ступень дешевле следующей и режет риск до неё.

Проверяют модель кросс-валидацией на перемешанных точках и приносят «97% точности». Отсутствие идеи replay — с честной симуляцией времени и метриками по событиям — означает, что первый реальный тест системы пройдёт на живых дежурных.

Follow-up интервьюера: replay показал: модель ловит инциденты на 20 минут раньше людей, но даёт 30 сработок в неделю — решение? — не в пейджинг: тюнинг порога с пересчётом кривой «опережение против шума», и в shadow mode. Пейдж получает только конфигурация, чей шум переживут дежурные.

Блок 8. LLM в эксплуатации

53. Суммаризация инцидента LLM — где это реально работает?

Инцидент генерирует поток текста: сотни алертов, чат воронки, лента деплоев, действия дежурных. Суммаризация — самое зрелое применение LLM в эксплуатации, потому что задача чисто языковая, ошибка нефатальна и проверяема человеком. Сценарии. Передача смены: дежурный уходит в разгар долгого инцидента — LLM собирает из чата и таймлайна выжимку «что случилось, что проверили, что исключили, что делаем сейчас»; приходящий читает две минуты вместо прокрутки трёхчасового чата. Статусы для стейкхолдеров: раз в полчаса — человеческим языком без жаргона, из того же таймлайна; рутинная и ненавистная работа коммандера уходит машине. Черновик постмортема: хронология, участники, действия — скелет документа генерируется из данных, человек добавляет анализ и выводы; постмортемы начинают писаться, потому что исчез самый нудный шаг. Условия работоспособности: суммаризация — производная от данных; если таймлайн не собирается автоматически, а чат инцидента размазан по трём каналам и личкам, суммировать нечего — снова упираемся в фундамент, а не в модель. И дисциплина: сводка помечается как машинная, ключевые факты (время, сервисы, версии) дежурный проверяет по ссылкам на источники — галлюцинация в статусе для VP стоит дороже, чем сэкономленные десять минут.

Продают суммаризацию как «ИИ ведёт инцидент». Нет — ИИ ведёт протокол инцидента; решения и координация остаются людям. И забывают про фундамент: LLM суммирует только то, что попало в данные, — дисциплина «всё в один канал, таймлайн автоматом» первична.

Follow-up интервьюера: сводка перепутала два сервиса с похожими именами — как снижать такие риски? — грундинг: факты в сводке цитируют источник (ссылка на алерт/сообщение), сущности сверяются со справочником сервисов, а шаблон сводки требует «не уверен — не пиши».

54. RAG по ранбукам и постмортемам — как алерту найти свой ранбук?

Классическая боль: ранбуки есть, но в вики их сотни, и в три ночи никто не ищет — чинят по памяти. RAG (retrieval-augmented generation) решает именно это: по тексту алерта и контексту (сервис, симптомы, метрики) из базы знаний достаются релевантные куски — ранбуки, похожие постмортемы, страницы архитектуры, — и LLM собирает из них ответ «что это может быть и что делать», с цитатами и ссылками на источники. Как устроен конвейер RAG и где он ломается технически — разобрано в MLOps-подборке; здесь — эксплуатационная специфика. Чанкинг по структуре: ранбук режется по шагам и разделам, а не по числу символов, иначе retrieval приносит половину команды без контекста. Метаданные — сервис, компонент, severity — фильтруют поиск до векторного сравнения: ранбук чужого сервиса с похожими словами — главный источник опасных подсказок. Свежесть: устаревший ранбук хуже отсутствующего — команда из него может добить систему; значит, индекс перестраивается при изменении вики, у документов есть владельцы и дата ревизии, а просроченные помечаются прямо в выдаче. И громкое правило: LLM отвечает только по найденному, с обязательными ссылками; «из головы» модель в он-колле не советует — если retrieval пуст, честный ответ «подходящего ранбука нет» ценнее сгенерированной уверенности.

Рисуют «зальём вики в векторную базу — и готово». Провалы живут в деталях: чанкинг ломает шаги инструкций, поиск тащит чужие ранбуки, индекс отстаёт от вики. Кто не называет свежесть и фильтрацию по сервису — делал демо, но не эксплуатировал.

Follow-up интервьюера: как измерить, что RAG-подсказки помогают, а не мешают? — приземлённо: доля инцидентов, где дежурный открыл предложенный документ и подтвердил полезность; время до первого верного действия. Клики и фидбек, а не красота демо.

55. LLM-агент для диагностики: цикл ReAct на инциденте

Агент отличается от чат-бота тем, что действует: у LLM есть набор инструментов — запросить метрики, поискать в логах, достать список последних деплоев, прочитать статус подов — и цикл ReAct: рассуждение (какая гипотеза?), действие (какой запрос её проверит?), наблюдение (что вернули данные?), уточнение — и так до вывода. На инциденте это выглядит как младший дежурный: «ошибки начались в 14:02 → проверю деплои — был релиз payments в 13:58 → проверю его логи — новые исключения тайм-аута к базе → проверю latency базы — в норме → гипотеза: в релизе снижен тайм-аут коннекта; проверьте конфиг диффа». Исследования это подтверждают: Microsoft Research на задачах анализа причин инцидентов показал, что агенты с доступом к инструментам дают заметно более точные фактически выводы, чем модели, рассуждающие без данных, — что интуитивно: гипотезы, проверенные о телеметрию, лучше гипотез из головы. Честные ограничения: агент ходит кругами на нетипичных инцидентах, жжёт время и токены на тупиковых ветках, наследует все дыры телеметрии и способен уверенно остановиться на правдоподобно-неверной гипотезе. Поэтому его выход — те же ранжированные гипотезы с трассой проверок (каждый шаг агента логируется и воспроизводим), а не вердикт; и поэтому его инструменты — строго читающие, о чём следующий вопрос.

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

Follow-up интервьюера: чем трасса действий агента ценна помимо отладки? — это готовый черновик расследования для человека: какие гипотезы проверены и отброшены с доказательствами. Даже неверный вывод агента экономит время, если трасса честная — дежурный не перепроверяет отброшенное.

56. Почему LLM-агенту в проде сначала дают только read-only доступ?

Потому что цена ошибки асимметрична до смешного. Читающий агент в худшем случае потратит токены, нагрузит API запросами и предложит неверную гипотезу — всё это переживаемо и лечится лимитами. Пишущий агент в худшем случае «починит» прод: рестартнёт не то, откатит не тот релиз, масштабирует не туда — со скоростью машины и уверенностью языковой модели; инцидент, устроенный автоматикой поверх инцидента, — худший жанр ночи. Плюс специфические риски LLM, которых нет у скриптовой автоматики: недетерминизм (одинаковый вход — разные решения), уязвимость к prompt injection — злонамеренный текст в логах или тикете, который агент прочитал инструментом, может стать для него инструкцией; пока агент read-only, инъекция портит гипотезу, а не прод. Поэтому лестница доверия здесь та же, что у любой автоматизации реакции, только строже: read-only диагностика → предложения действий с исполнением человеком → действия из белого списка безопасных (обратимых, ограниченных) с апрувом → и лишь на выстраданном доверии — узкая автономия с circuit breaker'ами. Каждая ступень подкрепляется статистикой предыдущей: сколько гипотез подтвердилось, сколько предложенных действий человек принял без правок. Read-only — это не недоверие технологии, а нормальный onboarding: новому человеку в команде прод-доступ тоже не выдают в первый день.

«Дадим агенту kubectl, но скажем быть осторожным» — промпт не является границей безопасности. Границы — это права доступа, белые списки инструментов и апрувы; кто предлагает ограничивать агента инструкцией, тот не слышал про prompt injection.

Follow-up интервьюера: что опаснее для пишущего агента — галлюцинация или инъекция? — инъекция: галлюцинация случайна, инъекция направленна — атакующий, способный подложить текст в логи или тикет, получает канал управления агентом. Поэтому и права, и фильтрация того, что агент читает.

57. Галлюцинации в эксплуатации — почему уверенная неправда опаснее «не знаю»?

Галлюцинация — правдоподобный, связный, уверенный текст, не соответствующий реальности: несуществующий флаг конфигурации, выдуманная команда, ссылка на «похожий инцидент», которого не было. В обычном чате это неловкость; в эксплуатации — направленное движение в стену: дежурный в три ночи устал, контекста мало, а подсказка выглядит профессионально — идеальные условия, чтобы ей поверить. Уверенная неправда хуже «не знаю» по механике: «не знаю» оставляет человека на его собственном пути диагностики, неправда уводит с пути — время горит на проверку ложного следа, а доверие к системе после вскрытия сгорает насовсем, включая её будущие верные подсказки. Инженерные меры. Грундинг: каждый факт в ответе привязан к источнику — цитата из ранбука, ссылка на алерт, вывод инструмента; утверждения без источника интерфейс помечает как предположения. Валидация исполнимого: команды и запросы из ответов прогоняются через синтаксическую проверку и сверку с реальной схемой (существует ли такой флаг, такой сервис, такая метрика) до показа человеку. Калибровка отказа: системе разрешено и предписано отвечать «данных недостаточно» — и этот ответ не штрафуется метриками продукта, иначе оптимизация сместит её в сторону уверенного вранья. И культура на стороне людей: подсказка LLM имеет статус гипотезы коллеги-джуна — проверяемой, а не исполняемой.

Называют галлюцинации «болезнью роста, модели скоро починят» — и не предлагают ни одной архитектурной меры. Грундинг с источниками, валидация команд против реальной схемы, право на «не знаю» — обязательный минимум ответа; надежда на следующую версию модели — не мера.

Follow-up интервьюера: как измерять частоту галлюцинаций своей системы? — выборочный аудит: регулярная ручная проверка случайных ответов против источников плюс автоматическая сверка извлекаемых фактов (команды, имена сервисов, номера версий) со справочниками. Метрика без измерения — лозунг.

58. Guardrails для LLM в эксплуатации — из чего состоит обвязка?

Guardrails — это не промпт «веди себя хорошо», а инженерные ограничения вокруг модели, работающие независимо от её поведения. Слои. Ограничение инструментов: агент видит только явный белый список тулов, каждый тул — с собственной проверкой аргументов (запрос метрик — можно, произвольный shell — не существует как опция); опасных инструментов нет в наборе, а не «запрещены промптом». Права: сервисный аккаунт агента — минимальные привилегии, read-only по умолчанию, скоупы по командам и окружениям; прод и стейджинг — разные агенты с разными правами. Апрув на действия: любые изменяющие операции — через подтверждение человеком, с показом того, что именно будет выполнено, дословно. Лимиты: rate limit на вызовы инструментов, бюджет токенов и времени на сессию, circuit breaker — серия ошибок или странное поведение останавливает агента и эскалирует человеку. Фильтрация входа и выхода: то, что агент читает из логов и тикетов, — санитизируется от инъекций; то, что отвечает, — проверяется на секреты и PII до показа и до записи в чаты. И аудит всего: каждый промпт, каждый вызов инструмента, каждый ответ — в журнал; без полной трассы невозможен ни разбор инцидента с участием агента, ни доказательство его невиновности. Проверочный вопрос к любой обвязке: что произойдёт, если модель поведёт себя худшим образом? Если ответ зависит от модели — guardrails нет.

Сводят guardrails к системному промпту. Промпт — пожелание; границы — это права, белые списки, апрувы, лимиты и аудит, работающие снаружи модели. Формула «безопасность не должна зависеть от поведения модели» — та рамка, которую ждут.

Follow-up интервьюера: зачем аудит запросов агента, если он read-only? — read-only агент читает чувствительное: логи с данными, конфиги, топологию. Аудит отвечает «что модель видела и куда это ушло» — это уже вопрос безопасности данных, не действий.

59. Как оценивать пользу LLM в он-колле — без вау-эффекта?

Демо LLM-ассистента впечатляет всегда; вопрос в том, что останется через квартал эксплуатации. Метрики пользы — те же, что у всего AIOps, приземлённые на шаги, которые LLM обещает ускорить. Время до первой верной гипотезы: главный кандидат — если ассистент реально помогает диагнозу, эта фаза сжимается; меряется по таймлайнам инцидентов, «верность» гипотезы фиксируется постмортемом. Принятие: доля подсказок, которые дежурные открыли, использовали, подтвердили; доля сгенерированных сводок, отправленных без правок против переписанных; agentic-метрика — доля предложенных действий, одобренных человеком. Экономия рутины: время на статусы, передачи смены, черновики постмортемов — до и после; это скучные минуты, но их много и они честно считаются. Обратная сторона, обязательная в балансе: время, потраченное на ложные следы от неверных подсказок (из разборов), частота фактических ошибок по аудиту, инциденты с участием ассистента. И контроль новизны: первые недели метрики завышены любопытством, поэтому смотреть надо устойчивое плато через месяц-два, а не пик первой недели. Антиметрики, на которые не смотреть: число запросов к ассистенту (мерит любопытство), субъективный «вау» руководства после демо, количество сгенерированного текста. Дисциплина та же, что в вопросе про эффект AIOps: метрики и методика фиксируются до внедрения, иначе успех будет «доказан» при любом исходе.

Меряют вовлечённость: «команда сделала тысячу запросов к боту» — это метрика новизны, а не пользы. Отличие «времени до верной гипотезы» от «числа запросов» — ровно то различие между результатом и активностью, которое проверяется этим вопросом.

Follow-up интервьюера: ассистент полезен сеньорам, но джуны слепо верят его подсказкам — что делать? — обучение и интерфейс: статус гипотезы, обязательные источники, чек «что ты проверил сам» в процессе. Проблема не уникальна для LLM — так же слепо верят и уверенным сеньорам.

60. ЧатОps с LLM: ассистент в канале инцидента — как встроить и на чём он стоит?

ЧатОps — работа с инфраструктурой из чата; LLM превращает его из набора команд в диалог: в канале инцидента ассистент отвечает «что с latency у payments за час?», строит график, достаёт последние деплои, находит похожий инцидент и по команде готовит сводку для передачи смены. Интеграционная механика: бот в мессенджере → LLM с инструментами (метрики, логи, деплои, тикеты, RAG по ранбукам) → ответы в тред, с источниками; контекст треда — часть промпта, поэтому ассистент понимает «а теперь то же по базе» без повторения всего вопроса. Ценность — нулевое трение: дежурный не переключается из канала, где и так живёт инцидент, а все ответы ассистента автоматически становятся частью общего таймлайна — их видит вся смена, а не один человек в личке. На чём это стоит инфраструктурно: под ассистентом — обычный LLM-сервинг со своими вопросами стоимости, латентности и пропускной способности; что там внутри — от vLLM и continuous batching до выбора между self-hosted и API — это уже территория MLOps, и AIOps-инженеру полезно понимать соседний цех хотя бы на уровне ограничений: латентность ответа ассистента в инциденте — тоже SLO. Всё остальное из блока применяется без скидок: инструменты read-only, guardrails, аудит, источники в ответах. И последний штрих: вопросы про LLM в эксплуатации — новые, интервьюеры сами нащупывают глубину, поэтому честное «вот это работает, вот это пока хайп» здесь выигрывает так же, как на любом собесе выигрывает честность.

Описывают чат-бота в вакууме: без источников в ответах, без записи в таймлайн, без понимания, что под ним сервинг с латентностью и ценой. Связка «чат → инструменты → таймлайн инцидента» и знание своих зависимостей от MLOps-слоя — признак системного взгляда.

Follow-up интервьюера: почему ассистент в общем канале лучше, чем в личке у каждого? — общий контекст: ответы видны всем, не задаются повторно, попадают в таймлайн и в постмортем. Знание, добытое в личке, для инцидента потеряно.