---

Уверенное знание SQL.
Опыт работы с BI-системами (Power BI, Qlik Sence, Visiology, Навигатор) (Power BI, Qlik Sence, Visiology, Навигатор, Tableau) на уровне внедрения и поддержки.
Понимание принципов работы DWH, ETL/ELT-процессов.
Знание основ статистики и методов анализа данных.
Знание Python для анализа данных будет преимуществом, знание Java script на начальном уровне так же будет преимуществом.
Знание основ ведения Каталога данных (OpenMetadata, DataHub или аналоги).
Навыки визуализации данных, коммуникации и презентации результатов.

Реально пользуешься ИИ-ассистентами (Claude, ChatGPT) в ежедневной работе; понимаешь разницу между обычным чатом и агентом и как влияют промпты на ответы ИИ чатов.

Пользуешься Claude Code / Codex и понимаешь, что это и как работает — что такое skills, hooks, MCP.

Знаешь SQL и Python / TypeScript чтобы создавать интерактивные бизнес-дашборды.

Находишь общий язык с очень разными людьми. Объясняешь технические вещи доступно и убеждаешься, что собеседник понял объяснение.

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

Замечаешь проблему раньше, чем тебя попросят её решить.

веренное владение Groovy (ScriptRunner).

Глубже понимаешь skills, hooks, MCP — пишешь свои skills / MCP.

Знакомство с автоматизацией / ETL: n8n, Make, Apache NiFi и т.п.

---
превращает хаос в список дел, а путаницу - в чёткие заметки.Ни одна идея, поручение или уточнение не должно потеряться по пути из голоса в “задачу”.


Настраиваю контроль цепочек в Bitrix24/Jira/Notion: кто отвечает, что сделано, что в просрочке.
Внедряю чек-листы для типовых операций (встречи, travel, договоры) — меньше ошибок и пропусков.

Автоматизирую напоминания о встречах и дедлайнах через календарь/планировщик - настраиваю единый поток: входящее → задача → дедлайн → статус в CRM/таск-трекере.


----

пример 
Напишите, пожалуйста, пример вашей постановки или инструкции (со всеми шагами, не краткое описание).

Если у вас NDA - можно самостоятельно придумать кейс для постановки и описать его подробно.



Инструкция по расследованию инцидента

Цель
За 10-20 минут определить что именно сломалось (endpoint/процесс/сегмент), когда началось и собрать пакет доказательств для RCA/фикса.

Шаг 1. Откройте дашборды качества в Grafana/Superset
Откройте дашборд (Errors/Timeouts/Latency/External deps).
В правом верхнем углу задайте период Last 15 min (если шумно - до 30-60 min).

Посмотрите:

1) Errors 4xx/5xx - долю ошибок по ключевым endpoint’ам/процессам (включите фильтры endpoint/process, если есть)
2) Timeouts - долю таймаутов и где она растет
3) Latency - p95/p99 за тот же период и тренд (важно смотреть p95/p99, не среднее)
4) External deps (если есть панели) - какой внешний сервис ухудшился

Результат шага - список endpoint’ов/процессов, где рост ошибок/таймаутов/latency.

Шаг 2. Сравните с baseline и зафиксируйте старт интервала
Если на дашборде есть baseline - используйте. Если нет - определите “фон” визуально/по данным.

Зафиксируйте:

1) Время начала и интервал проблемы (по минутам)
2) Затронутые endpoint’ы/процессы
3) Если доступно - сегменты (service_instance, канал/сегмент клиента)

Результат шага - “с ___ до ___ выросло X на endpoint Y (segment Z)”.

Шаг 3. ClickHouse: первичный поиск и выборки

Соберите 2 окна:

W_current = 10-15 минут
W_baseline = 7 дней или “тот же час”

Группировка: endpoint + error_code + сегмент (service_instance, если есть).
Сфокусируйтесь на ключевых error_code и таймаутах.

Результат шага - топ-сегменты по error_rate_current и timeout_current.

Шаг 4. Отсейте шум, выделите аномалии

Для каждого сегмента посчитайте:

requests_current
errors_current и timeout_current
error_rate_current и baseline_rate

При необходимости - отдельно по таймаутам.
Установите минимальный порог min_requests/min_events, чтобы не анализировать статистический мусор.

Результат шага - топ N сегментов (обычно 5-10) с максимальным отклонением.

Шаг 5. Score аномалии и short-list

Отсортируйте сегменты по score = (error_rate_current / baseline_rate) (или разность в pp).

Сформируйте short-list:

endpoint
error_code
сегмент (service_instance/другой разрез)
примерная величина отклонения

Результат шага - “сломалось A по error_code B у инстанса C”.

Шаг 6. Классификация причины по логам (первичная)

Для топ-сегментов откройте примеры логов/трейсов и проверьте, что изменилось:

релиз/конфигурация - деплой/миграция/настройка в момент старта
внешние зависимости - рост ошибок/таймаутов интеграций
контракт/данные - новые error_code, ошибки валидации, “отсутствует поле …”
деградация - рост latency p95/p99 и концентрация на отдельных инстансах

Результат шага - первичная гипотеза вероятной причины.

Шаг 7. RCA-пакет (черновик для команды)

Подготовьте заметку:

резюме “что/где/когда”
метрики (error_rate, timeout_rate, p95/p99) по интервалу
топ-сегменты (endpoint + error_code + сегмент)
50-200 примеров логов без персональных данных
ссылки на графики Grafana/Superset
предварительная гипотеза и что проверить в первую очередь

Результат шага - материал для RCA/разработчиков.

Шаг 8. Оформите тикет для разработчиков/техподдержки (Jira)

Структура тикета:

1. Симптом: “с -- по -- вырос error_code X на endpoint Y (segment Z)”
2. Доказательства: агрегаты + ссылки на графики + примеры логов
3. Что ожидаем: error_rate/timeout_rate вернутся к baseline, стабилизация p95/p99
4. Критерий проверки: какой дашборд и какие значения/пороги смотреть

Результат шага - тикет, который можно закрывать по метрикам.

Шаг 9. После фикса - контроль

После хотфикса вернитесь к шагам 1-2 и проверьте, что отклонение ушло.
При необходимости повторите ClickHouse-анализ только для затронутых сегментов.
Добавьте итог в тикет и обновите инструкцию, если появился новый маркер.

Шаг 10. Если повторяется - улучшите мониторинг

Добавьте/настройте алерт:

новые правила по error_code/endpoint
более точные разрезы (service_instance, external dependency)
подсказки в runbook “где искать первопричину”.