Англійська назва Sentry Error Tracking

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

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

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

** Fingerprint ** — значення, яке Sentry використовує для визначення того, які події належать до однієї проблеми, типово отримане з трасування стека, але його можна налаштувати.

• « Ці дві помилки мають різні повідомлення, але один і той же відбиток пальця, тому Sentry правильно згрупував їх у одну проблему. » *

** Бредкрупп ** — слід подій (клацання, навігація, виклики API), які призвели до помилки, записаний автоматично, щоб допомогти вам відтворити дії користувача.

• “У стрічці показано, що користувач подав форму двічі за секунду — саме це спричинило помилку дублювання запиту.” *

** Випуск ** — мітка розгортання (зазвичай, рядок git SHA або версії), яку Sentry пов’ язує з подіями, що надає вам змогу побачити, яке з розгортань впровадило або виправило проблему. “Ця проблема почала з’ являтися відразу після випуску v2.4.1 — давайте перевіримо, що змінилося в цьому відмінності.”

** Регресія ** — проблема, яку Sentry позначила як вирішену, але яка з’ явилася знову у пізнішому випуску, автоматично відкриється знову і буде позначено прапорцем для уваги.

• “Sentry позначило це як регресію, оскільки це було виправлено у попередньому випуску, але тільки- но з’ явилося у сьогоднішньому розгортанні.” *

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

• “Трактування стека було безглуздо, поки ми не завантажили карти джерел — тепер він вказує прямо на поточний рядок у файлі TypeScript.” *

Звичайні фрази

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

Приклади висловлювань

Виправлення проблеми у стані готовності: “Ця проблема з’явилася відразу після вчорашнього випуску, впливає на близько двох відсотків сеансів, і всі відомості про неї показують, що вона відбувається відразу після певного часу виклику API - я думаю, що це регресія від зміни логіки повторних спроб.”

Звітування про проблему групування:

• « Sentinel об’ єднує три дійсно різні вади в одну проблему, оскільки вони мають спільний відбиток з загального повідомлення про помилку — чи можемо ми додати нетипове правило відбитків, щоб розділити їх? » *

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

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

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

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

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

Переклади: «Переклади з англійської мови» (англ

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

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

Крім того, зверніть увагу на активний голос проти пасивного голосу. Використання « was caused by » часто є менш прямим, ніж « caused by ». Активний голос сприяє ясності і відповідальності. Аналогічно, коли ви описуєте вплив випуску, замість того, щоб сказати « Випуск пов’ язано з проблемами », краще сказати: « Недавній випуск збігся зі збільшенням кількості повідомлень про помилки ». Це ненадовго переносить увагу на сам випуск як на потенційний фактор. Нарешті, не бійтеся використовувати більш точний словник - «ескаляція» часто є кращим, ніж «залучити когось», а «відтворювати» має набагато більшу вагу, ніж «зробити так, щоб це сталося»

sentry-cli events show --id 123456789 --fields payload.steps

Ця команда, за допомогою інструменту sentry-cli, демонструє практичний сценарій. Це не просто * перегляд * даних про помилку; це опис його характеристик колегі: « Я бачу ряд кроків у цьому випадку, які вказують на те, що проблема виникла у потоці автентифікації користувача ». Сама команда є просто механізмом для збору і повідомлення технічних деталей, але мова, яку використовують при поясненні результатів — « ряд кроків », « початок у » — є ключем до ефективного спілкування.