Используй только переданные placeholders и значения в фигурных скобках. Если данных не хватает, явно помечай допущения вместо выдуманных значений.
Вы — инженер по реагированию на инциденты (SRE / ML Ops). Вам дают заполнить шаблон для критического инцидента. Вставьте значения для следующих полей: {model_type}, {business_context}, {incident_type}, {performance_metric}, {platform}, {data_source}.
Сформируйте системный, воспроизводимый план устранения неполадок по инциденту "модель {model_type}, обслуживающая {business_context}, испытывает {incident_type}, что влияет на {performance_metric}. Модель работает на {platform} и обрабатывает данные из {data_source}." План должен содержать чёткие, выполнимые шаги, которые можно напрямую передать командам. Ответ должен быть структурирован и содержать ровно следующие разделы в указанном порядке.
Формат вывода (обязательно):
- Нумерованный список разделов 1–5.
- В каждом разделе — маркированные или нумерованные пункты. Для каждого пункта укажите: действие, ответственный ролью (например: ML engineer / data engineer / SRE / product manager), приоритет (P0/P1/P2), целевое время выполнения (ETA: минуты/часы), конкретные артефакты/логи/метрики для сбора, критерии валидации/успеха, и точные команды/запросы или шаблоны запросов (если уместно для {platform}).
Требуемые разделы и содержание:
1) Немедленные шаги для локализации и стабилизации (Containment & Triage)
- Перечислите краткие, приоритетные действия для немедленной локализации источника ухудшения {performance_metric} и снижения воздействия на {business_context}.
- Для каждого действия укажите: кто выполняет, приоритет, ETA, какие метрики/логи/трейсы собирать (точные имена метрик, шаблоны лог-запросов), команды/консоли/SQL-примеры для сборки данных на {platform}, какие оперативные переключатели/фичи/трафик-правила применить для смягчения последствий.
- Укажите критерии, при которых можно откатиться от шага или продолжить эскалацию.
2) Методика локализации (How to isolate the fault)
- Шаги для поэтапного исключения компонентов (данные, модель, предобработка, инференс-слой, инфраструктура {platform}, внешние сервисы).
- Контрольный список гипотез (с приоритетом) и точные тесты/запросы для проверки каждой гипотезы (например, сравнение входных данных текущего периода vs эталона, проверка дистрибуции, задержек запросов, утечек памяти и пр.).
- Какие артефакты/снимки/дампы необходимо сохранить для последующего RCA (логи, модели, версии данных, метрики, конфиги).
3) Методология анализа первопричин (RCA)
- Описание пошагового процесса RCA: сбор данных, формирование и ранжирование гипотез, экспериментальная проверка, статистические/контрольные тесты (например, A/B, drift detection), и критерии подтверждения/опровержения гипотез.
- Перечень конкретных данных и временных окон для анализа (например: последние N часов, до/после релиза X), и метрик корреляции/методов детекции дрейфа (KS-test, PSI, feature importance drift и т.п.).
- Как документировать выводы: минимальный набор полей в RCA-репорте (коренная причина, доказательства, уровень уверенности, рекомендованные исправления, долгосрочные действия).
4) Действия по устранению (Remediation)
- Разделите на краткосрочные (workarounds, mitigations) и долгосрочные (код/модель/данные/архитектура) меры.
- Для каждого действия укажите: шаги реализации, ответственные роли, приоритет, ETA, критерии валидации (как измерить восстановление {performance_metric}), требования к тестированию перед развёртыванием (какие тесты и пороги).
- Если возможен rollback/фолбек — дайте точный план отката (шаги, проверка успешности), и точки принятия решения.
5) Превентивные меры и follow-up
- Конкретные изменения в мониторинге, alerting (какие метрики и пороги), автоматизации тестирования данных и моделей, CI/CD-процессы, регламенты валидации релизов и контрольные прогресс-метрики.
- Планы аудита/валидации данных из {data_source}, регрессионного тестирования модели, процедур предрелизного контроля на {platform}.
- Шаблон постинцидентного отчёта и список обязательных пунктов для ретроспективы (включая timeline, root cause, исправления, owners, due dates).
Ограничения/требования к стилю:
- Ответ краткий, деловой, ориентирован на исполнение; не добавляйте общие рассуждения.
- Используйте роль-местозаполнители для ответственных (не конкретные имена).
- Там, где нужно — вставляйте шаблоны команд/запросов с явными местами для подстановки (например: "kubectl logs <pod> -n <ns>", "SELECT ... WHERE timestamp BETWEEN <t1> AND <t2>").
- Не включайте постороннюю информацию за пределами разделов 1–5.
