# Урок 26. Отладка упавших процессов в хитман

{% include [note-alert](../_includes/onboarding-alert.md) %}

Общий сценарий решения проблем с вычислительным конвеером можно описать так:
1. Узнать о том, что с конвеером что-то не так.
1. Найти место, где поведение отклонилось от ожидаемого, и понять характер проявления отклонения.
1. В зависимости от характера проявления искать причину возникновения отклонения нужным способом.
1. В зависимости от причины предпринять действия по устранению будущих отклонений.
Отклонения от поведения вычислительных конвееров бывают разные. Видимое расхождение с ожиданиями может проявиться одним из способов:
- Процесс неожиданно упал с ошибкой.
- Процесс выполняется сильно дольше ожидаемого времени (проще говоря, тормозит).
- Процесс не запустился / отсутствуют данные для запуска следующего процесса в конвеере.

> Перед началом урока заведите себе папку для экспериментов `<yourStaffLogin>` в [/onboarding/playground](https://nirvana.yandex-team.ru/browse/resolve?path=%2Fonboarding%2Fplayground). Вся дальнейшая работа с сущностями в уроке будет вестись в ней.

> : TODO конвеер из 2 Нирвана-реакций и n промежуточных артефактов. "Сбоить" должны разные звенья для разных сценариев. Для этого нужно предусмотреть 3 варианта работы конвеера, чтобы в каждом варианте проявлялась проблема нового типа.

## Шаг 1. Настроим уведомления на показатели процесса {#alert}

> : нужны уведомления на падение и на долгую работу.
> - Уведомление на долгую работу не начнет работать без накопленной статистики по нормальным запускам (нам ведь нужно как-то узнать, сколько обычно работает реакция) - непонятно, как заставить алерт сработать.
> - Для обнаружения незапуска по-хорошему нужен график в Соломоне на количество запусков в статусах и алерт на нем (как, например, [делает Логфеллер](https://solomon.yandex-team.ru/admin/projects/logfeller/alerts/acf12477-685d-4102-a6b8-f4ff8cab45ae)). Но в рамках урока это довольно сложно настроить. Кроме того, срабатывание алерта обычно привязано к ожидаемому времени запуска реакции (т.е. алерт загорается, если с текущего времени минус оффсет во временном окне нет запуска с определенной датой). Это хорошо работает, если поток запусков стабильный и нужно ловить дыры, но плохо подходит для проверки факта одноразового незапуска. В общем, непонятно, как стриггерить не ложное срабатывание.

## Шаг 2. Локализуем причину падения процесса. {#failed}

> : через триггер вызвать вариант выполнения, приводящий к сбою первой реакции. Должно прийти уведомление о падении.

## Шаг 3. Локализуем причину тормозов процесса. {#slooow}

> : через триггер вызвать вариант выполнения, приводящий к долгому выпонению первой реакции. Должно прийти уведомление о долгом выполнении.

## Шаг 4. Локализуем причину незапуска процесса. {#not-started}

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