Як пояснити Retry Storm, викликану помилкою клієнта в англійській мові
Дізнайтеся, як пояснити англійською мовою інцидент, коли клієнт з вадами агресивно повторював спроби і перевантажив вашу службу — чітко відокремивши причину на стороні клієнта від наслідків на стороні служби.
Бум повторних спроб, викликаний вадами клієнта іншої людини, є незручним інциденту, який важко пояснити, оскільки ваша служба була перевантажена, але справжній дефект знаходився у коді, який не належить вам і який ви не можете виправити безпосередньо. Англійська мова повинна описати механізм достатньо точно, щоб команда клієнта розуміла, що саме змінювати, одночасно точно представляючи роль вашої власної служби — включаючи будь-де, де їй не вистачало захисту, який вона повинна була мати.
Ключовий словник
** Повторення спроби** — спосіб, за якого одна помилка в початковому потоці множиться на більше запитів, ніж початковий обсяг, оскільки кожен невдалий виклик викликає одну або більше повторних спроб, які самі по собі можуть зазнавати невдачі і повторюватися знову. “Одне розгортання спричинило приблизно 2% помилку, але повторна спроба перетворила це на 400% пік загального обсягу запитів протягом дев’яносто секунд, тому що клієнт повторював кожен невдалий виклик до п’яти разів без відновлення.”
** Відновлення з боку клієнта ** — стратегія затримки з боку виклику, яка збільшує час очікування між повторними спробами, чого тут не вистачає і що є головною річчю, яку команда клієнта повинна додати.
- “Клієнт не мав жодного відновлення з боку клієнта — кожна повторна спроба здійснювалася протягом мілісекунд від останньої, що є конкретною помилкою, яка перетворила незначний промах у повний відключення.” *
** Каскадне перевантаження ** — спосіб, за якого перевантаження служби може призвести до аварій у не пов’ язаних службах, які залежать від неї, розширюючи вплив за межі початкової точки аварії. “Оскільки наша служба ділить пул з’ єднань з двома іншими внутрішніми API, шторм повторних спроб спричинив каскадне перевантаження — ці неспоріднені служби також почали перевищувати тайм- аут, хоча вади взагалі не було в їх коді.”
** Обмеження швидкості (на стороні сервера) ** — захисний елемент керування на службі отримання, який обмежує кількість запитів, які один клієнт може зробити у заданому вікні, що могло б обмежити вплив, навіть якщо б була присутня помилка клієнта. “У нас не було обмеження швидкості на стороні сервера на клієнта в той час, що означало, що один неправильно поводячийся клієнт міг споживати потужність, яку повинні були ділитися всі наші клієнти - це прогалина з нашої сторони, відокремлена від їхньої помилки.”
Звичайні фрази
- Цей інцидент був викликаний помилкою повторної спроби на стороні клієнта, яка викликала повторну спробу збільшення і перевантаження нашого сервісу
- «Клієнт повторював спроби без будь-якого відновлення з боку клієнта, відправляючи кожну спробу майже відразу після попередньої невдачі»
- «Це перетворилося на каскадне перевантаження, що впливає на [іншу службу], яка ділиться інфраструктурою з зачепленою службою»
- «З нашої сторони, у нас не вистачало обмеження на клієнта, яке б містило вплив навіть з присутністю помилки повторення спроб»
- «Ми рекомендуємо команді клієнта додати експоненціальне відключення і обмеження повторних спроб, і ми додаємо обмеження швидкості з нашої сторони як додатковий виправлення»
Приклади висловлювань
Пояснення механізму для нетехнічного користувача:
- “У програмі партнера була помилка, яка змушувала її повторювати невдалі запити занадто агресивно і занадто швидко. Через це невеликий хікк на нашому кінці перетворився на набагато більший пік в трафіку, ніж він повинен був - як чесна помилка однієї людини, що повторюється сотні разів на секунду. ”*
Опис ефекту підсилення для інженерної аудиторії: “Клієнт повторював кожен невдалий запит до п’яти разів без відновлення і без тремтіння, тому 2% базовий рівень помилок перетворився на 400% пік обсягу приблизно за дев’яносто секунд - це повторення спроб, і це те, що насправді спричинило відключення, а не початкові помилки.”
Власник прогалини на стороні обслуговування, чесно кажучи, разом з вадами клієнта:
- “Для зрозумілості, причиною виникнення root- тригера була помилка клієнта, пов’ язана з повторними спробами, але ми також не мали обмеження швидкості на клієнта, що є прогалиною з нашої сторони. Ми виправляємо обидва — клієнт додає відступ, і ми додаємо обмеження швидкості, тому це не може статися знову, незалежно від того, що робить будь-який клієнт. “*
Професійні поради
- Поясніть повторне підсилення з конкретним числом до і після, коли це можливо — “2% помилок стали 400% піком обсягу” набагато переконливіше для обох аудиторій, ніж сказати, що повторні спроби “зробити це гірше”
- Назвемо відсутність ** backoff на стороні клієнта ** конкретно як виправний дефект - це дає команді клієнта однозначний, дієвий виправлення, а не нечітку інструкцію «бути обережнішими з повторними спробами»
- Згадуйте будь- які ** каскадні перевантаження ** чесно, навіть якщо це робить інцидент більшим — приховування розширення, щоб інцидент виглядав меншим, підриває довіру, коли повний обсяг стає ясним пізніше.
- Визнайте відсутність ** обмеження швидкості на стороні сервера ** як вашу власну помилку, навіть якщо вада не була вашою — прийняття відповідальності за вашу сторону виправлення, разом з наданням назви їхній, збереже розмову у співпраці, а не конфронтації.
- Пропонуйте виправлення з обох сторін одночасно — відключення клієнта і обмеження швидкості з боку сервера є допоміжними, а не альтернативними, і представлення обох показує, що виправлення є стійким, навіть якщо одна сторона повільно надсилає свою версію.
Практичні вправи
- Напишіть речення, у якому буде пояснено повторення посилення за допомогою конкретного числа до і після.
- Опишете сценарій каскаду перевантаження у двох реченнях, назвавши конкретну службу, на яку це впливає.
- Запропонуйте два допоміжних виправлення — одне з боку клієнта, одне з боку сервера — для гіпотетичного випадку шторму повторних спроб.
Наприклад, слово «перевірка» (англ. check) означає перевірку правильності мови
Добре, давайте припустимо, що ви щойно провели годину в безсонні, зневаджуючи. Програма клієнта безперервно повторює спроби виконання запитів, що спричиняє каскадні помилки у вашій системі. Спочатку це здавалося простою проблемою обмеження швидкості, але подальші дослідження виявили, що клієнтський код містить помилкову логіку повторних спроб, яка не враховує потенційні мережеві хіки або навантаження сервера. Служба тепер бореться під вагою цих агресивних повторних спроб. Тепер вам потрібно ефективно повідомити про цю ситуацію — не просто коротким повідомленням Slack, а ясним і дійсним поясненням для вашої команди.
Однією з ключових областей, де не-рідні англомовні часто борються, є визначення кореневої причини проти симптому. Спокуса відразу ж звинуватити клієнта, що може звучати обвинувачуючим і непродуктивним. Замість цього, зосередьтеся на описі чого ви спостерігали і чому це відбувається. Використовуйте точну мову навколо технічних концепцій — уникайте жаргону, якщо це можливо, і завжди пояснюйте терміни, якщо це необхідно. Наприклад, замість того, щоб сказати « клієнт не працює », спробуйте сказати « Ми спостерігаємо велику кількість повторних спроб, які походять від клієнтської програми ». Хорошою точкою відліку є опис проблеми як несподіваної взаємодії між системами. Ви можете сказати: «Ми виявили ситуацію, коли клієнтська програма неодноразово намагається з’єднатися, що призводить до збільшення навантаження на нашу службу»
Розгляньте, як ви можете задокументувати це у описі запитів на звантаження або під час перегляду коду. Замість « Бум повторних спроб клієнта » спробуйте щось на зразок: « Спостерігалося значне збільшення помилок HTTP 503, пов’ язане з високою частотою запитів від клієнта X. Початковий аналіз показує, що внутрішній механізм повторних спроб клієнта неадекватно обробляє перехідні умови мережі, що призводить до непотрібного навантаження на наші сервери. Ми досліджуємо, чи є підстави для зміни стратегії повторних спроб на стороні клієнта. ” Цей підхід чітко відокремлює спостережену поведінку (« шторм повторних спроб ») від потенційної основної причини (логіка на стороні клієнта). Крім того, він відкриває діалог - “Ми розслідуємо…” - а не видає остаточний вердикт.
Нарешті, обговорюючи це з колегами, використовуйте такі фрази, як: «З нашої точки зору» або «Засноване на наших даних моніторингу», щоб з повагою встановити вашу точку зору і продемонструвати, що ви провели ретельний аналіз. Не припускайте, що всі розуміють технічні деталі; активно пропонуйте контекст і пояснення. Пам’ятайте, ефективне спілкування не просто про передачу інформації - це про будівництво розуміння і співпрацю в напрямку рішення.