Як пояснити Webhook Retry Storm Incident в англійській мові

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

Ключовий словник

** Повторна спроба (громове стадо) ** — ситуація, коли багато невдалих запитів повторюються одночасно, і ці повторні спроби самі по собі спричиняють нові помилки, посилюючи початкову проблему.

• “Що почалося як короткий блиск перетворилося на шторм повторних спроб, коли тисячі повторних спроб webhook в черзі були запущені знову в один момент.” *

** Експоненційне відновлення ** — стратегія повторних спроб, за якої час очікування між спробами збільшується після кожної невдачі, призначена для зменшення навантаження на систему, що має проблеми. “Їхній клієнт webhook не використовував експоненційне відключення, тому кожна повторна спроба відбувалася з фіксованим інтервалом, що зберігало тиск на нашу кінцеву точку постійним.”

** Ідентичність ** — властивість, за якої обробка одного і того ж запиту декілька разів має такий самий ефект, як і обробка цього запиту один раз, що є критичним для систем, які отримують повторні спроби webhooks.

• “Оскільки наш обробник webhook не був повністю ідемпотентним, деякі повторні спроби подій були оброблені двічі, що призвело до створення дублікатів записів.” *

** Backpressure ** — механізм для сигналізації відправнику, що він повинен сповільнити або зупинити надсилання, замість того, щоб безмовно відкидати або відкладати все у чергу.

• “У нас не було зворотного тиску, тому замість того, щоб сказати відправнику сповільнити, ми просто продовжували приймати запити, поки черга не збільшилася.” *

** Черга мертвих листів ** — окрема черга, у якій повідомлення, які неодноразово зазнають невдачі у обробці, буде перенаправлено, щоб перервати повторні спроби обробки повідомлень на неограничений час і перевірити їх пізніше.

• “Неуспішні доставки webhook тепер буде перенаправлено до черги мертвих листів після трьох спроб, замість безкінечно повторювати їх і додавати до завантаження.” *

Пояснення кореневої причини

• «Всі спроби webhook партнера вниз по течії приземлилися в тому ж вікні декількох секунд, і наша кінцева точка не могла поглинути цей концентрований вибух»
• «Це не був один поганий запит — це була петля зворотного зв’язку: наші повільні відповіді викликали більше повторних спроб, і ці спроби зробили наші відповіді ще повільнішими»
• «Логіка повторних спроб на стороні партнера не відступала між спробами, тому навантаження на нашу кінцеву точку залишалося високим, а не зменшувалося після перших невдач»

Повідомлення про ліквідацію

• «Ми додали обмеження швидкості на кінцевій точці webhook, тому стрілка повторних спроб в черзі і обробляється поступово, а не перевантажує службу відразу»
• «Ми тепер повертаємо 429 з заголовком Retry-After, тому добре поводяться клієнти точно знають, скільки чекати, перш ніж спробувати знову»
• «Неуспішні доставки пересуваються в чергу мертвих листів після трьох спроб, тому клієнт, що бореться, припиняє додавати навантаження на неопределенный срок»

Захист від повторення

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

Професійні поради

1. ** Назвіть петлю зворотного зв’ язку явно. ** Сказавши « наші повільні відповіді спричинили більше повторних спроб, які зробили відповіді повільнішими », ви зробите самопідсилюючуся помилку зрозумілою, а не залишите зацікавлених осіб здивованими, чому невеликий пік став великим відключенням.
2. ** Розрізняйте тригер від підсилювача. ** Початкова помилка і поведінка повторної спроби, яка перетворила її на шторм, є двома окремими речами — пояснення обох запобігає перебільшенню неправильного виправлення.
3. ** Надати конкретні рекомендації щодо поведінки клієнта. ** Надання партнерам конкретних рекомендацій щодо відмови (а не просто « будь ласка, повторіть спробу більш акуратно ») дає їм щось, що можна використовувати, і зменшує ймовірність повторення інциденту.

Практичні вправи

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

Зв’язані ресурси

• Як обговорювати інцидент з висиланням Kubernetes Pod англійською мовою

Національний склад: Національний склад: Виступи на міжнародних змаганнях

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

Поширеною пасткою є використання надмірно технічного жаргону без контексту. Наприклад, замість того, щоб сказати «Експоненціальний алгоритм відновлення не зміг зблизитися», спробуйте щось на зразок: «Ми пережили значне збільшення запитів, які намагалися з’єднатися з нашою службою, що призвело до затримок для користувачів. Система автоматично намагалася з’ єднатися знову декілька разів — цей процес відомий як повторна спроба — але вона не змогла розв’ язати початкову проблему достатньо швидко. « Зверніть увагу, як ми замінили щільний технічний термін поясненням того, * що * відбувається і його ефекту. Аналогічно, під час обговорення кореневої причини, уникайте фраз на зразок « каскадної помилки ». Замість цього скористайтеся фразою « Проблема виникла внаслідок тимчасового перевантаження нашого вищестоячого сервісу, яке спричинило ланцюгову реакцію, що вплинула на обробку webhook ». Це дозволить вашій аудиторії зрозуміти суть проблеми без необхідності глибоких технічних знань.

Крім того, звертайте увагу на структуру речення і активний голос. Пасивні конструкції можуть затемнити відповідальність. Замість того, щоб сказати « Було визначено, що логіка повторних спроб була недостатньою », скажіть прямо: « Наше дослідження показало, що поточна логіка повторних спроб не була достатньо надійною для обробки несподіваного підйому запитів. » Це демонструє власність і ясність. Під час документування інциденту використовуйте точні дієслова, такі як * визначено *, * вирішено *, * реалізовано * і * перевірено * - вони сильніші, ніж нечіткі терміни, такі як «виправлено» або «розглянуто». Розгляньте, як ви б сформулювали коментар на перегляд коду: «Ця частина могла б отримати користь від яснішої документації щодо обмежень механізму повторних спроб. Зокрема, додавання коментаря, що пояснює потенціал каскадних повторних спроб у сценаріях високої навантаження, поліпшить підтримку. ”

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