Недавно мы создали платформу оркестровки, которая извлекает данные для нескольких клиентов из нескольких источников. Сначала все было хорошо. Никаких отказов было меньше, и если какая-либо работа не удалась, ее было легко отладить. Когда у нас появилось больше конфигураций, фреймворк стал более подверженным ошибкам. Иногда это были неправильные конфигурации, а иногда именно полезная нагрузка приводила к сбою задания. Фреймворк оркестрации работает в два этапа. На первом этапе все процессы вставляются в базу данных, а на втором этапе эти задания выполняются для извлечения данных. Эти два шага выполняются независимо и в разное время.
Чтобы проверить, все ли процессы были выполнены успешно, мне пришлось дважды и в разное время запросить базу данных. Первый запрос проверяет, все ли процессы вставлены в базу данных. У меня был сложный запрос, состоящий из нескольких объединений, который дал мне ожидаемое количество процессов, которые должны быть вставлены в базу данных в определенный день, поскольку у нас есть разные типы расписания. Мне пришлось сохранить результат этого запроса в таблице Excel, и каждый день мне приходилось проверять задания, которые были вставлены в этот день с помощью первого запроса. Раньше это упражнение стоило мне полчаса в день, и, кроме того, мне приходилось повторять то же упражнение и для потребительского процесса. Проделав это в течение нескольких дней, я понял, что мне нужен какой-то процесс, который мог бы сделать эту проверку за меня. Я разобрался с архитектурой, но важный вопрос заключался в том, как я должен быть уведомлен о сбоях? Я думал о создании портала, но снова нужно посетить портал, чтобы увидеть, что происходит в структуре. Мне нужно было место, где каждый из команды мог видеть предупреждения, не прилагая особых усилий, и я мог думать только об одном месте, Slack.
Решение
Реализовать это было довольно просто. Единственное, о чем мне нужно было позаботиться, - это график работы. У нас есть разные графики, такие как ежедневные, еженедельные и ежемесячные ... Мне просто нужно было проверить, есть ли у процесса недельное расписание, тогда разница между временем создания процесса и текущим днем полностью делится на семь. Если модуль равен 0, то процесс должен быть выполнен сегодня, если нет, игнорировать.
Что-то вроде этого.
`
// function isToBeExecutedToday
const today = moment().startOf(“day”);
const difference = moment(today).diff(moment(result.rCreTime).startOf(“day”), “days”);
if (difference % Constant.DIVIDE_BY === 0) {
return true;
}
return false;
Я придумал сервис узла, который имеет две точки входа: одну для производителя и одну для потребителя. Задания Cron выполняют эти сценарии в указанное время. Это полностью не имеющий состояния сервис с абсолютно нулевым интеллектом. В нем нет данных о предыдущих казнях. Его единственная задача - отправлять уведомления слабину при срабатывании. В нем по-прежнему меньше 150 строк кода, написанного на машинописном тексте. Единственное, что мне нужно было настроить, это Slack API. Я создал отдельный канал для логов и создал веб-перехватчик в приложении Slack.
Это позволило нам быстро реагировать на сбои. Теперь нам не нужно беспокоиться о проверке, нам просто нужно проверить журналы, если произойдет сбой. Автоматизация действительно помогает. Хотя для автоматизации этого процесса потребуется некоторое время, в долгосрочной перспективе это определенно сэкономит вам тысячи часов.
Надеюсь, вам эта статья показалась интересной.
