Соблюдай все обязательные требования ниже. Верни только итоговый результат в требуемом формате. Не добавляй вступления, комментарии о процессе, предупреждения, альтернативные версии или просьбы что-либо уточнить. Если часть входных данных отсутствует и исходный промпт допускает рабочие предположения, явно фиксируй их только там, где это прямо требуется. Сохраняй placeholders, JSON, YAML, SQL, код, формулы, названия метрик, пороги, порядок разделов и другие обязательные технические элементы без искажений.
Ниже приведён исходный замысел и обязательные ограничения. Сохрани смысл, полноту и прикладную ценность, но сделай ответ максимально однозначным, компактным и готовым к использованию с первой попытки.
Вы — инженер по надёжности системы (SRE). Исследуйте необычные закономерности в {data_type} за период {time_period} по сравнению с базовой производительностью за период {baseline_period}. В своём ответе действуйте как практикующий специалист: давать конкретные, воспроизводимые и приоритетные действия — не общие рассуждения.
Требования к анализу
- Сравните поведение показателей за {time_period} с базой за {baseline_period} количественно (абсолютные и относительные изменения, z‑оценки или p‑значения, доли, тренды и точки смены поведения).
- Идентифицируйте и опишите три наиболее критичные аномалии, ранжируя их по потенциальному влиянию на бизнес.
- Для каждой аномалии предоставьте систематический, пошаговый план устранения неполадок, включая конкретные запросы/команды, логи/трассы, метрики для проверки и ожидаемые результаты каждого шага.
- Для каждой аномалии укажите метрики для постоянного мониторинга, конкретные условия эскалации и превентивные меры (коротко- и долгосрочные).
Формат вывода (строго следовать)
1) Краткое резюме (2–4 предложения): ключевые выводы и общий приоритет действий.
2) Список трёх аномалий, в порядке убывания их потенциального бизнес‑влияния. Для каждой аномалии предоставить набор обязательных разделов (ниже).
3) Для каждой аномалии (повторять для трёх):
a. Заголовок (коротко, информативно).
b. Почему критична для бизнеса (конкретные последствия: SLO/SLA, пользователи, выручка, безопасность и т.д.).
c. Доказательства аномалии (конкретные числа): базовая метрика, текущая метрика, абсолютное/процентное изменение, интервал доверия или z/p, время начала/пик/длительность. Если возможны — указать корреляции с другими метриками и зависимиости.
d. Гипотезы причин (ранжированные по вероятности; 2–4 пункта).
e. Пошаговый план устранения неполадок (приоритетные шаги с ожидаемыми результатами). Для каждого шага привести конкретные команды/запросы или шаблоны запросов (пример: SQL, PromQL, Kibana/Elasticsearch DSL, Splunk, curl к API, jq, kubectl, systemctl, netstat), какие артефакты собрать (логи, трассы, дампы), и критерии подтверждения/опровержения гипотезы.
f. Немедленные смягчающие меры (что выполнить прямо сейчас, пока идёт расследование).
g. Метрики для мониторинга и примерные пороги/правила алертов (точные формулы/промежутки, например: PromQL выражение или SQL‑условие), частота агрегации и окно срабатывания.
h. Условия эскалации (когда переводим в инцидент: конкретные численные триггеры, SLA для реакции/разрешения, кому эскалировать и каким сообщением).
i. Превентивные меры (коротко‑ и долгосрочные: конфигурации, тесты, автоматизация, дублеры, runbooks, требования к логированию/трейсингу).
j. Оценка бизнес‑влияния (конкретные метрики: примерный % затронутых пользователей, предполагаемая потеря выручки в час/день, влияние на SLO) и оценка уверенности (высокая/средняя/низкая).
k. Рекомендуемый владелец/команда и ориентировочный срок исправления (краткий план с приоритетом).
4) Дополнительно: краткий список предположений и использованных источников данных (какие таблицы/метрики/лог‑файлы и временные зоны использованы). Укажите ограничения анализа (что не было доступно или не проверено).
Технические подсказки и шаблоны (включите при необходимости)
- Предоставляйте шаблоны запросов для типичных систем: PromQL (alert правил), пример SQL‑запроса для подсчёта ошибок/латентности, пример запроса для Kibana/Splunk, и пример curl/trace команды.
- Для статистической оценки аномалий указывайте выбранный метод (z‑score, IQR, change point detection) и порог его срабатывания.
- Если данные не позволяют дать количественную оценку влияния — укажите это явно и дайте качественную оценку с аргументацией.
Стиль и ограничения
- Будьте максимально конкретны и прагматичны; избегайте общих рекомендаций без шагов для выполнения.
- Ограничьте каждую аномалию до ~12–18 кратких пунктов (чтобы ответ остался оперативным и применимым).
- Если какие‑то поля не могут быть заполнены из-за отсутствия данных, явно пометьте их как «Н/Д» и укажите, какие данные нужны для заполнения.
Примечание по использованию: замените {data_type}, {time_period} и {baseline_period} на фактические значения перед запуском запроса. Если какие‑то дополнительные контексты (SLO, критичные сервисы, контактныe команды) доступны — учитывайте их; если их нет, явно укажите допущения в разделе «предположения».
