Як пояснити Message Queue Backlog англійською мовою

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

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

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

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

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

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

• “Близько п’ яти відсотків цих повідомлень потрапляють до черги мертвих листів через неправильно сформований вміст, і нам потрібно розглядати їх окремо від самого затримки.” *

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

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

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

Що потрібно змінити?

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

Перевірка спільного виправлення

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

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

1. ** Розрізняти глибину черги від затримки користувача. ** Вони вимірюють подібні, але різні речі, і повідомлення про неправильну звітність може зробити інцидент більш або менш критичним, ніж він насправді є, залежно від обробки у реальному часі.
2. ** Вкажіть, чи є причиною збільшення кількості повідомлень або повільніша обробка. ** Для цих випадків потрібні зовсім різні виправлення — перший вимагає збільшення пропускної здатності або обмеження обсягу передавання, другий вимагає виправлення коду або інфраструктури — об’ єднання цих двох виправлень марнує час.
3. ** Якщо це необхідно, обов’ язково згадуйте про чергу мертвих листів. ** Відокремлення справді застряглих, неправильно сформованих повідомлень від здорового затримки запобігає команді приймати за звичайне, що вся затримка буде виведено з ладу, коли прохідність буде покращено.

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

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

Наприклад, мова йде про мовлення з ненаціональними носієм мови

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

Ключовим є те, щоб розглядати проблему з точки зору впливу, а не просто обсягу. Замість « Черга переповнена » ви можете сказати щось на зразок « Я бачу значне збільшення кількості повідомлень у черзі. Це впливає на нашу затримку обслуговування - ми спостерігаємо середній час відповіді, що перевищує [конкретну ціль], що впливає на досвід користувача. Чи можемо ми дослідити, чи споживачі не відстають від темпів виробництва повідомлень? » Помітили зміну? Ми ввели такі терміни, як «значне збільшення», «вплив затримки обслуговування» і «середній час відповіді» - фрази, які часто використовуються в технічних дискусіях, але важливі для чіткого спілкування, особливо при обговоренні показників продуктивності.

Інша корисна формулювання включає в себе визнання потенційних факторів, що сприяють. Не відразу звинувачуйте, а досліджуйте можливості. Повідомлення Slack до команди може бути таким: «Команда, я помітив значне відставання у формуванні черги. Похоже, что группа потребителей пытается обрабатывать сообщения так же быстро, как они генерируются. Ми повинні дослідити, чи є якісь вузькі місця - можливо, масштабування проблем з клієнтськими екземплярами, або зміна в структурі повідомлення, що вимагає більше часу обробки. “Використання “змагатися з обробкою” є м’якшим, ніж “клиєнти не можуть поспішати”, і оформлення його як дослідження, а не звинувачення заохочує співпрацю. Використання таких фраз, як «в’язкі місця» і «структура повідомлень» демонструє глибше розуміння потенційних викликів системи.

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