Що таке Політика повторних спроб вебхуків?

Політика повторних спроб вебхука — це набір правил, які система вебхуків використовує для визначення того, чи слід повторно надсилати вебхук у разі невдачі. Ця конфігурація визначає системне обмеження на кількість спроб, паузу між кожною спробою, критерії невдачі та умови для припинення. У більшості політик застосовується експоненційна затримка, щоб запобігти спробам у короткі проміжки часу, тоді як події, що постійно завершуються невдачею, надсилаються до черги «мертвих» повідомлень.

Політики повторних спроб є важливим фактором, враховуючи, що мережі та сервіси можуть відрізнятися за надійністю. Завершення передачі даних під час збоїв у мережі або сервісі при доставці залежить від наявності активної політики повторних спроб. Політика повторних спроб запобігає втраті даних через збій доставки, забезпечуючи повторну спробу, якщо приймаючий кінець не повертає відповідь 2xx.

Коли спроба доставки події стикається з проблемою, політика системи зазвичай обробляє це шляхом аналізу HTTP-коду стану. Після цього вводиться пауза, відповідно до розкладу повторних спроб, перш ніж передача події буде повторена. Це компоненти:

•       Умови спрацьовування: точні HTTP-статуси, що викликають повторну спробу.
•       Розклад повторних спроб: інтервали часу між спробами, зазвичай експоненційна затримка або значення, витягнуте із заголовка Retry-After.
•       Відображення збоїв: це включає функції, які дозволяють виявлення проблем без негайного вирішення, таких як індикація часу наступної спроби.
•       Спостережуваність та ідемпотентність: журнали, метрики та інструменти відтворення для аналізу збоїв, разом з ідемпотентною обробкою для поглинання дублікатів.

Більшість стратегій повторних спроб передбачають затримку в інтервалі між спробами. Та, що найчастіше застосовується, це експоненційний відступ; він подовжує період очікування з кожною спробою, що, в свою чергу, знижує навантаження на отримувача, який має якусь проблему.

Це означає:

•       Експоненційний відступ: це техніка, за якої повторні спроби розділяються дедалі довшими проміжками часу.
•       Додавання джиттера: зміна часу очікування випадковим елементом, щоб уникнути одночасних сплесків повторних спроб. Twilio Event Streams впроваджує ідею джиттера, щоб уникнути ефекту “шаленої орди”.
•       Багаторівневі повторні спроби: негайні, короткострокові, довгострокові та черга недійсних повідомлень.

Ця черга призначена для подій, які використали свої налаштовані процеси повторних спроб, не досягнувши статусу «завершено». Ці події зберігаються у визначеному місці, що дозволяє досліджувати їхні особливості, спостерігати за їхньою послідовністю або вирішувати їх відповідно до обставин.

Замість сліпого копіювання агресивних політик повторних спроб, хороший дизайн повторних спроб враховує, коли система може бути перевантажена надмірною кількістю повторних спроб. Тобто, це передбачає ретельне обмірковування лімітів повторних спроб та інтервалів часу.

•       Віддавайте перевагу експоненційній затримці з додаванням джиттера.
•       Встановіть чітко визначені ліміти повторних спроб та критерії зупинки.
•       Встановіть однозначні правила кодів стану, які визначатимуть, які поставки будуть повторені, а які ні.
•       Ключі ідемпотентності пов'язані з послідовним управлінням повторною обробкою.

Практики моніторингу пов'язані з виявленням розбіжностей у доставці конвеєра на ранній стадії. Відстежуйте метрики, що вказують на проблеми, а потім автоматично сповіщайте за допомогою сповіщень і пов'язуйте їх з інструментами, що використовуються для роботи.

•       Панелі приладів: огляд стану доставки за останній період часу.
•       Ручний повторний запуск: опція, яка дозволяє повторно надсилати події після усунення основної причини.
•       Ранбуки: вони представляють заздалегідь визначені дії для чергових інженерів, призначені для керівництва процесом усунення несправностей.

•       Процес методичного повторного надсилання невдалих доставок має на меті вирішити випадки, коли події інакше можуть залишитися необробленими.
•       Це сприяє зменшенню ймовірності втрати даних подій під час короткочасних перебоїв та затримок доставки.
•       Інтеграції зазвичай відновлюються після коротких періодів збоїв, а пов'язані з ними проблеми часто є тимчасовими, а не спричиняють тривалих простоїв.
•       Послідовна доставка критично важливих даних, таких як замовлення та платежі, є фактором, що впливає на рівень довіри до інтеграцій.