Як перевірити доставку сповіщень в Astrina

Підтвердіть, який тип сповіщення ви хочете протестувати

Починайте з одного типу сповіщення, а не з чотирьох. Email, вбудовані сповіщення, webhook і командні сповіщення не виходять з ладу однаково, тож чистий тест починається з чіткого визначення одного шляху, який ви хочете перевірити, а саме з перевірка сповіщень Astrina.

Якщо ви перевіряєте email, питання в доставці. Якщо ви перевіряєте webhook, питання в тому, чи прийняв endpoint запит і чи повернув очікувану відповідь. Якщо ви перевіряєте командне сповіщення, питання в тому, чи були в маршруті правильні люди або правильний канал. Саме тому важливо одразу розуміти, як протестувати webhook в Astrina, якщо саме він є вашим сценарієм.

Багато команд плутають це, бо сповіщення начебто “працює” десь в іншому місці. Webhook може спрацювати успішно, а вхідні листи залишаться порожніми. Канал у стилі Slack може загорітися, а конкретний отримувач так і не отримає нічого. Саме тому тест має бути вузьким, особливо коли користувачі пишуть, що не приходять сповіщення Astrina.

Якщо ви керуєте кількома об’єктами, підхід той самий, що й перевіряти кожен сайт, який ви ведете, один за одним, а не припускати, що перший результат каже вам усе. Один шлях сповіщення. Один очікуваний пункт призначення. Одна умова тесту.

Запустіть у Astrina малоризикову тестову подію

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

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

Зробіть подію легкою для відкату. Якщо для тесту потрібен довгий rollback, це вже не малоризиковий тест. Одна команда, з якою я працював, використала оновлення “відомо хороших” сторінок о 10:00, а потім відкотила його о 10:05. П’ятихвилинне вікно показало, чи живий конвеєр сповіщень, не перетворюючи ранок на пожежне навчання.

Потрібна точка відліку для того, як Astrina поводиться в різних продуктах? Ви можете порівняти налаштування з astrina, якщо сповіщення пов’язане з SEO-перевірками, адже подія має відповідати правилу, яке повинно спрацювати. Якщо подія й правило не збігаються, тест нічого не доводить.

Перевірте, чи Astrina зафіксувала подію

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

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

Тут важливий час. Порівнюйте з моментом тесту, а не з формулюванням “десь сьогодні вранці”. Якщо подію створено о 14:12, а в логах немає нічого поблизу 14:12, це вже підказка. Якщо подія з’являється із затримкою, ця затримка може пояснити, чому сповіщення прийшло пізно або не прийшло взагалі.

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

Перевірте статус доставки сповіщення в Astrina

Коли подія вже є, перевірте, як Astrina класифікувала саме сповіщення. Шукайте статус на кшталт sent, queued, skipped або failed. Ці позначки показують, де процес зупинився, і вони корисніші за здогадки.

Статус queued означає, що Astrina прийняла сповіщення, але ще не завершила доставку. Статус sent зазвичай означає, що Astrina передала сповіщення до каналу призначення. Статус skipped часто вказує на умову правила, яка не була виконана, або на пригнічення, що не дало сповіщенню спрацювати. Статус failed — той, який зазвичай варто перевірити першим.

Не припускайте, що “sent” означає “received”. Це означає лише, що система спробувала. Невелика деталь, велика різниця.

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

Переконайтеся, що пункт призначення його отримав

Тепер перевірте сам пункт призначення. Для email шукайте у вхідних, спамі, папці небажаних і в будь-якому відфільтрованому архіві. Для командного чату перевірте вимкнені треди, згорнуті канали або налаштування сповіщень, які приховують повідомлення без згадок. Для webhook перегляньте журнал прийому на стороні endpoint і підтвердьте, що запит надійшов із очікуваною міткою часу.

Цей крок спочатку ловить очевидні промахи. Повідомлення в спамі — це не те саме, що невдала відправка. Вимкнений канал — не те саме, що зламане сповіщення. Журнал webhook, який повертає 200, не доводить, що тіло було правильним, але доводить, що пункт призначення побачив запит.

Використовуйте точне ім’я отримувача, якщо воно є. Якщо сповіщення мало піти на “[email protected]”, не перевіряйте особисту скриньку й не вважайте справу завершеною. Якщо маршрут був на конкретний канал Slack, відкрийте саме цей канал, а не загальну стрічку. Один пункт призначення.

Для команд, що порівнюють шляхи сповіщень між продуктами, може допомогти перегляд astrina, тому що там сповіщення часто обговорюються разом із пов’язаними завданнями моніторингу. Але суть перевірки все та сама: чи справді пункт призначення отримав сповіщення, так чи ні?

Зіставте результат тесту з налаштуваннями сповіщення

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

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

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

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

Повторіть перевірку з другим шляхом сповіщення

Запустіть ще один тест іншим маршрутом. Використайте іншого отримувача, іншу скриньку або інший endpoint webhook. Це найпростіший спосіб зрозуміти, проблема в одному каналі чи в самій системі сповіщень.

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

Тримайте другий тест простим. Не змінюйте подію, правило й пункт призначення одночасно. Інакше чиста перевірка перетвориться на ворожіння. Однієї зміни за раз достатньо.

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

Зафіксуйте результат і вирішіть наступну дію

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

Якщо подію зафіксовано, сповіщення надіслано, а пункт призначення нічого не отримав — у вас проблема з доставкою. Якщо подія не з’явилася взагалі — проблема з тригером. Якщо подія з’явилася, а сповіщення було skipped — проблема з правилом. Це три різні виправлення, а не одне.

Коли в маршруті є webhook, збережіть журнал прийому або код відповіді. Коли в маршруті є email, збережіть тему листа і папку, де ви його знайшли. Коли в маршруті є командні сповіщення, збережіть назву каналу і те, чи були сповіщення вимкнені. Маленькі докази потім вирішують усе.

Якщо потрібно ескалювати проблему, надішліть точні деталі тесту замість фрази “сповіщення не працюють”. Додайте дію, мітку часу, тип сповіщення та результат кожного кроку. Цього достатньо, щоб хтось інший міг відтворити Як перевірити, чи працюють сповіщення Astrina, не починаючи з нуля.

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