ru.taskurotta.service.recovery.FailMap.md Maven / Gradle / Ivy

Go to download
# Наша цель

Ломаться может везде. Мы должны быть к этому готовы и реагировать как можно быстрее.

# Наши задачи

Есть три причины по которым мы можем ломаться:

1. Внешнее окружение. Актер берет задачу и не приносит ответ.
2. Внутреннее окружение. Отсутствует связь с монгой или ораклом, проблемы с файловой системой и т.д.
3. Пытаясь восстановить процесс мы можем его сломать нарушив консистентность между сущностями процесса.

Есть еще логическая поломка процесса в результате программной ошибки. Для их исправления необходим перезапуск одного
или нескольких процессов с начала или с определенной задачи.

У нас есть следующие способы исправить ситуацию:

1. В случае ошибок во внешнем или внутреннем окружении мы должны уметь эффективно восстанавливать консистентность
между сущностями процесса. Делать надо это автоматически.
2. Чтобы не сломать консистентность сущностей во время выполнения процесса или его восстановления необходимо все
чувствительные операции выполнять атомарно с проверкой состояния изменяемой сущности.
3. Надо предоставить средства для быстрого массового восстановления по команде оператора. Например после полной
потери данных или большого сбоя.
4. Надо предоставить средства для расширенного поиска (отбора процессов) по различным критериям и их перезапуска с
нуля или с определенной задачи.

# Решение для пункта 1 - сбои во внешнем и внутреннем окружении

- Для каждого типа актера вводится настройка WorkerTimeout. Перед отдачей задачи актеру у сущности Decision отмечается
время когда необходима реакция процесса восстановления. Поле recoveryTime.
- Для каждого типа процесса вводится настройка ProcessTimeout. При регистрации у сущности Process отмечается время
когда необходима реакция процесса восстановления. Поле recoveryTime.
- Для каждого типа процесса вводится настройка IdleProcessTimeout. При любом изменении сущности Graph отмечается
когда необходима реакция процесса восстановления. Поле recoveryTime.

note: При регистрации процесса мы должны сделать минимум - сохранить сущность Process и ответить положительно клиенту
 в случае успеха. Иначе мы можем сломаться дальше при регистрационных действиях, клиенту ответим ошибкой а сами не
 будем знать по какой причине процесс находится в таком неконсистентном состоянии и что с ним делать. При этом нам
 надо как можно раньше среагировать и проверить процесс что с ним все в порядке. Для этого предлагается выставлять
 ему более раннее время для проверки процессом восстановления. Например равное IdleProcessTimeout.

И так - у нас три сущности обладают метками времени. Для каждой из них мы запускаем свой процесс обработки.

## Обработка Decision

Выборка:

- Выбираем сущности Decision которые находятся в состоянии "в работе" и у которых значение recoveryTime в прошлом.

В каких случаях задача попадает под анализ:
- Отдали актеру задачу а он не сообщил о решении в указанный срок.
- Актер сообщил о решении но мы его не смогли сохранить из за отсутствия связи с БД.

Наши действия:

- Атомарно перевести задачу в состояние "в очереди" с проверкой что она все еще находится в состоянии "в работе". Т.е
. не смогла например успеть завершиться за время анализа. При этом необходимо сменить ключ приема результата "pass"
чтобы не принять в будущем старый результат.
- Отправляем задачу в очередь повторно.
- Изменяем значение recoveryTime у сущности Graph. (под вопросом)
- Увеличиваем общий счетчик workTimeoutCounter. (на счетчики реагирует мониторинг)
- Увеличиваем счетчик workTimeoutCounter для данного актера.

Исключения (надо план действий на каждое):

1. На момент анализа невозможно получить описание задачи из за ошибки доступа к БД.
2. Отсутствует описание задачи в БД (сущности Task). Невозможно ее поставить повторно в очередь.
Действие: Процесс помечается как неконсистентный или автоматически перезапускается?

Порядок реализации:
- добавляем свойство recoveryTime в сущность Decision
- реализуем переодический поиск по этому свойству. Увеличиваем текущее значение таймаута на процесс.
- тут останавливаемся. переходим к реализации recoveryTime для Graph
- добавляем установление разного значения recoveryTime в зависимости от значения в мапе ActorPreferences

нужно ли эту реализацию делать для hz и для памяти? Может нам уже от них отказаться? Монгу поставить на рабочую
машину для тестирования совсем не проблема.

Настройки актера и значения по умолчанию:
- acceptFirst: true
Флаг определяет нужно ли принимать первое пришедшее решение по задаче или последнее. По умоланию принимается первое.
При выключении используется псевдоуникальное значение UUID (поле pass) передоваемое актеру вместе с задачей и
ожидаемое от него при получении решения.
- workTimeout: 1 minutes
- restartAfterWorkTimeout: true
Можно указать false - тогда по задаче будет создано решение с ошибкой. Процесс либо встанет, либо его сможет обработать
 координатор, в том числе, указав политику повторения.
- taskTimeout: 0 minutes
- forceFinishAfterTaskTimeout: false
По умолчанию таймаут на выполнение задачи отключен. Его включение приведет к необходимости делать доп завись времени
 отслеживания в БД в момент укладки задачи в очередь. Если в момент срабатывания таймаута задача находилась в очереди,
 то она не уйдет актеру. Ключ forceFinishAfterTaskTimeout = true заставит аварийно (с ошибкой) завершить задачу даже
 если она находится в работе у актера. Иначе время таймаута будет сдвинуто на ожидаемое максимальное время завершения
 задачи (в соответствии с workTimeout).

## Обработка Graph

Выборка:
- Выбираем сущности Graph у которых recoveryTime в прошлом.

note: у Graph сейчас нет состояния. Надо его либо вводить (+1 индекс в БД) либо выставлять значение recoveryTime в
Long.MAX_VALUE (ухудшение работы индекса?)

В каких случаях Graph попадает под анализ - долго нет изменений в процессе:

1. Сервер суслика был выключен, задачи не раздавались
2. Нет актеров необходимых для работы процесса
3. Актеры не справляются с количеством задач в очереди
4. Приняли решение по задаче но не смогли отправить на анализ в Graph
5. Получили результат анализа выполненной задачи в Graph а отправить задачу в очередь не смогли.
6. При восстановлении изменили состояние задачи на "в очереди" а в очередь положить не смогли.
7. Процесс зарегистрировали, создали граф, а дальше не смогли зарегистрировать стартовую задачу и положить ее в очередь.

Процесс проверяется на консистентность. После проверки процесса у сущности Graph изменяется значение recoveryTime
чтобы спланировать проверку в будушем. Это значение так-же изменяется всегда при обработки решения задачи (при
изменении сущности Graph):

1. По очередям задач отсутствует статистика получения из них элементов. Значение lastPolledTime == 0. Процесс
выбоки Graph для анализа нужно стартовать чуть позже старта сервера.
2. Значение lastPolledTime по соответствующим очередям == 0
3. Если задачу еще не рестартовали, то взять из графа время созревания задачи и сравнить с lastPolledTime. Если ее
уже рестартовали - то взять время последнего старта и сравнить с lastPolledTime.
4. Задача с статусе FINISH а в графе в списке не завершенных. Нужно попробовать выполнить анализ графа.
5. В графе задача в списке выполненных а решения по ней нет или оно в статусе QUEUE. См. условия по пункту 3. В
случае если актеры справляются - необходимо поместить задачу в очередь и изменением времени последнего старта.
6. тоже что пункт 5.
7. тоже что пункт 5 но дополнительно отсутствует сущность Task с БД.


## Обработка Process

- Получили все задачи но не смогли выставить состояние "завершен".

# Решение для пункта 2 - обеспечение консистентности между сущностями процесса
# Решение для пункта 3 - массовое восстановление данных

## Восстановление сломанных задач

Это у нас есть.
Необходим переход к модели сломанных задач а не процессов.
Нужно иметь возможность отслеживать результат запуска. Например помещать в конец (и в середину) очереди процессов на
анализ Операции, которые не выполняют анализ а отмечают прогресс выполнения задания оператора консоли.

Еще вариант - любая операция на анализ процесса может быть приписана к источнику ее появления. Источник может быть как
"Автоматическое восстановление", так и "Задача оператора консоли номер #". Во втором случае можно увеличивать
соответствующие счетчики в бд чтоб оператор видел прогресс

## Принудительный полный анализ всех или выбранного типа процессов на консистентность

Анализ может занять продолжительное время.
Желательно выбирать приоритет для процессов если нужно запустить анализ по нескольким типам
Нужно иметь возможность отслеживать прогресс и результат


# Решение для пункта 4 - интеллектуальный поиск и восстановление по шаблонам