Вопросы к оркестратору (чек-лист)
Здесь просто список специфических вопросов для оценки оркестраторов (в дополнение к общеизвестным).
- Если падает задача, то DAG стартует заново? Или продолжаются попытки реализации сценария?
- Есть ли у задачи настройка, которая определяет возможность безопасной параллельной обработки очереди задачи?
Очередь появляется при возникновении долга (например, неработоспособности сервиса). Допускаемая обработка очереди задачи: последовательная, параллельная (с возможностью задать ключ и ограничение по количеству работающих экземпляров); - Есть ли у задачи настройка, которая позволяет не накапливать очередь запусков?
Очередь появляется при возникновении долга (например, неработоспособности сервиса). Для сервисов, которые при успешном запуске закрывают весь накопившийся долг, не нужно образовывать очередь ожидания запусков. Максимум 1 запуск может быть в очереди, и только при условии, что предыдущий запуск не завершился. По сути, требуется вариант завершения сценария с учетом оценки долга. - Если ли у DAGа персистентный уникальный идентификатор запуска (сохраняющийся после перезапуска), который можно передавать в сервисы из задачи?
Используется, если нужно гарантировать строго однократное выполнение функции. - Можно ли использовать вместо конечной задачи другой DAG?
Чтобы исключить бойлерплейт. - Можно ли настроить схему повторных попыток запуска проваленных задач?
Первый перезапуск сразу, потом регрессия, потом через фиксированный интервал. - Можно ли настроить схему уведомлений после некоторого количества неудачных попыток выполнить задачу (например, после 5-го и 6-го отказа в серии)?
- Можно ли настроить уведомление об успешном выполнении задачи после серии отказов?
В предыдущей статье Введение в проблематику я познакомил вас с техническим состоянием системы, структурой департамента и метриками, которые можно снимать с продукта. Если вы ещё не читали, то рекомендую начать именно с неё, чтобы понимать контекст: как у нас устроена орг. структура, в чём специфика нашего продукта и в каком состоянии была система.
Если вы хотите взять под контроль хаос и перестать тонуть в срочных задачах, познакомьтесь с методом 4 квадрантов — он помогает выстроить ясную систему приоритетов и в перспективе навсегда забыть о постоянных авралах.
Давайте разберёмся по пунктам, почему «Спасибо» — ваш скрытый козырь и как сделать так, чтобы пользователь после отправки формы не просто радовался успешной заявке, но и мог совершить у вас новый шаг (а, может, и не один).
Чем регулярные задачи отличаются от нерегулярных и нужно ли учитывать регулярные? В чем особенность задач без конкретного дедлайна? Как в приложении Obsidian внедрить чек-листы открытия и закрытия дня, планировать регулярные и несрочные задачи?
На конференции TeachLeadConf после доклада (видео) мне был задан вопрос про гарантию отправки сообщений в брокер. Если коротко, то вопрос можно сформулировать так: "Как гарантировать отправку сообщений, сохранив их порядок?" Оригинальная формулировка была не столь понятна для меня, поэтому пришлось ответить позже в закрытом чате конференции. Поскол…
Наличие готового алгоритма сильно разгружает голову. Надо один раз запарится над ним, обновлять по мере необходимости, и он будет годами экономить энергию и время.
Plus-подписчикам начали выдавать доступ к модели GPT-4.5, но не всем сразу – запуск планируется в течение 1–3 дней.
«Эта задача очень срочная, и не забывайте про вчерашние запросы — они мне нужны в первую очередь». Как часто вы слышали такое от заказчика? В статье обсудим, почему не работают приоритеты и как использовать Cost of Delay, чтобы определить очередность задач.