1. Почніть із наявного моніторингу доступності та відкрийте його налаштування сповіщень
Якщо перевірка вже працює, ви вже на півдорозі. Тепер завдання не в тому, щоб налаштовувати моніторинг доступності сайту з нуля; потрібно перетворити цю перевірку на механізм, який повідомить потрібну людину в потрібний момент.
Відкрийте монітор, за яким хочете стежити уважніше, і знайдіть налаштування сповіщень, правила повідомлень або параметри інцидентів. Точна назва може відрізнятися, але мета одна: пов’язати активний монітор із дією, коли з’являється простій, а налаштування сповіщень про простій мають бути зрозумілими й однозначними.
Саме тут інструкція про те, як налаштувати сповіщення про простій Astrina крок за кроком, стає по-справжньому практичною. Ви не перебудовуєте монітор. Ви вирішуєте, що має статися після того, як перевірка не пройде двічі, п’ять разів або на тому етапі, коли ваша команда хоче отримати попередження.
Починайте лише з однієї служби. Якщо одночасно недоступні головна сторінка, сторінка входу та сторінка оформлення замовлення, для старту достатньо одного монітора. Так перше сповіщення буде простим, а прості сповіщення читають.
Перевірте поточну назву монітора, цільову URL-адресу та частоту запуску перед тим, як чіпати сповіщення. Позначка на кшталт «Prod Login» краща за «Check 1», бо ваша скринька зі сповіщеннями буде менш заплутаною о 2:14 ночі.
2. Оберіть умови простою, які мають запускати сповіщення
Серце налаштування — це тригер. Вам потрібні пороги сповіщення про простій, які відповідають саме цій службі, а не загальне правило, скопійоване звідкись.
Один із поширених тригерів — це послідовні збої. Два невдалі запуски перевірки можуть бути достатніми для невеликого внутрішнього інструменту, тоді як платіжна сторінка для клієнтів може потребувати трьох або більше, перш ніж почати сповіщати. Кількість має значення, бо одиничний випадковий збій не повинен будити чергового інженера, якщо служба й так нестабільна.
Також важливими можуть бути стрибки часу відповіді. Сайт може й далі повертати 200 OK, але фактично бути зламаним, якщо сторінка завантажується надто довго, особливо під час оформлення замовлення. Повільно — це не те саме, що недоступно, але для користувачів це часто виглядає як збій.
Варто стежити й за шаблонами кодів статусу. Відповідь із серії 500 зазвичай потребує уваги швидше, ніж 404, тоді як 401 на приватній панелі може означати лише те, що сторінка захищена. Хитрість у тому, щоб зіставити шаблон коду з очікуваною поведінкою служби.
Оберіть найточніший тригер, який відповідає цій службі. Якщо монітор налаштований на головну сторінку без входу, 403 зазвичай варто перевірити. Якщо це staging-середовище, той самий код може бути просто шумом. Одне правило не підходить для кожної кінцевої точки.
Не робіть поріг занадто чутливим. Монітор, який надсилає сповіщення після першої ж пропущеної перевірки, може стати марним уже за тиждень. Але й занадто суворим його робити не варто. Якщо реальний простій може тривати 10 хвилин, перш ніж хтось про нього дізнається, поріг занадто повільний для трафіку клієнтів.
3. Налаштуйте канали сповіщень і спрямовуйте їх до потрібних людей
Оберіть, куди саме має надходити сповіщення. Електронна пошта підходить для невисокої терміновості, але чат, SMS або інший канал сповіщення часто краще підходить для активного реагування на інцидент. Мета в тому, щоб хтось побачив сповіщення, поки простій ще триває.
Спрямовуйте кожне сповіщення до тієї команди, яка може щось зробити. Помилка бази даних не повинна потрапляти лише в чат маркетингу. Збій у процесі оформлення замовлення не має чекати в загальній скриньці, де троє людей припускають, що відповідальний хтось інший.
Окремо продумайте покриття поза робочим часом. Якщо денна команда отримує перше сповіщення, а нічна — друге, зафіксуйте це в примітках до монітора. Інакше після робочого дня сповіщення зайде в глухий кут.
Один монітор може надсилати сповіщення в кілька місць, але це не означає, що так і слід робити. Для багатьох команд достатньо двох каналів: одного основного отримувача і одного резервного. Занадто багато точок надходження можуть створити неправильний шум.
Подумайте про людину, яка отримає повідомлення о 1:00 ночі. Їй потрібні назва служби, URL, що не працює, і останній відомий стан. «Щось не працює» — це не сповіщення; це загадка.
4. Розділіть сповіщення для продакшну, технічного обслуговування та тестів
Сповіщення для продакшну та staging не повинні змішуватися в один потік. Заплановане техобслуговування, перевірки staging-середовища та вікна розгортання можуть створювати хибні спрацьовування, якщо змішати їх в один потік сповіщень. Саме тут акуратне налаштування сповіщень економить час.
Якщо розгортання заплановане на 15 хвилин, заглушіть пов’язаний монітор на цей проміжок. Якщо staging перевіряється кожні 5 хвилин, тримайте його в окремій групі, щоб він не міг викликати сповіщення для продакшн-команди. Мета не в тому, щоб приховати проблеми; а в тому, щоб тестовий шум не виглядав як реальна аварія.
Це відрізняється від базового налаштування моніторингу доступності сайту, де перше питання лише в тому, чи доступна сторінка. Сповіщення працюють вибірковіше. Вони ставлять друге запитання: чи потрібно прямо зараз переривати людину?
Використовуйте назви, які явно показують поділ. «Prod API», «Staging API» і «Maintenance Test» краще, ніж три майже однакові позначки. О 3-й ночі зрозуміла назва заощаджує більше часу, ніж будь-яка оригінальна схема неймінгу.
Вікна техобслуговування мають бути обмежені в часі. Якщо ви заглушили перевірку на 2 години й забули увімкнути її назад, система сповіщень стане сліпою. Це невдала угода, навіть якщо початкове розгортання пройшло добре.
Невелике зауваження: хибні спрацювання здаються нешкідливими, доки не повторяться тричі за тиждень. А потім усі починають ігнорувати четверте сповіщення. Ось у чому справжня ціна.
5. Налаштуйте час ескалації, щоб сповіщення про простій були дійовими
Ескалація — це момент, коли монітор перетворюється на процес реагування на інцидент. Ви можете відкласти перше сповіщення, повторити його через заданий інтервал або передати іншому відповідальному, якщо простій триває.
Спершу вирішіть, хто має отримати перше повідомлення. Ця людина повинна мати змогу діяти без пошуку контексту. Якщо перший відповідальний не може змінити стан служби, сповіщення адресоване не туди.
Потім визначте, що станеться після першого сповіщення. Повтор через 10 хвилин може мати сенс для впертого простою, тоді як другий маршрут до резервного інженера краще підійде невеликій команді, яка чергує разом. Час має відповідати тому, як швидко ваша команда зазвичай реагує, а не тому, як швидко ви хотіли б, щоб вона реагувала.
Ескалація — це не спам. Два повідомлення можуть бути корисними, якщо друге дістається іншій людині з іншим рівнем повноважень. Шість копій в одну й ту саму скриньку лише привчають людей перестати читати.
Будьте конкретними щодо наслідків затяжного простою. Якщо перше сповіщення пропустили, куди піде наступне: менеджеру, на службовий телефон чи в спільний канал інцидентів? Зафіксуйте послідовність у примітках до монітора, щоб нікому не доводилося гадати під тиском.
Тут допомагає одне правило: якщо служба працює для клієнтів, ескалація має бути коротшою. Якщо це внутрішній звіт, який може почекати, час можна зробити довшим. Та сама платформа, але інша терміновість.
6. Перевірте одне сповіщення від початку до кінця контрольованим тестом простою
Перш ніж довіряти сповіщенню в продакшні, перевірте його повністю від початку до кінця. Вам потрібно переконатися в трьох речах: монітор спрацьовує тоді, коли очікується; поріг спрацьовує тоді, коли очікується; а сповіщення доходить до потрібної людини.
Використовуйте контрольований тест, а не справжній збій. Тимчасова зміна URL, тестова кінцева точка або вікно техобслуговування можуть бути достатніми, щоб безпечно запустити монітор. Мета — побачити, як працює весь ланцюжок, не ламаючи щось важливе лише заради перевірки.
Це крок, який багато команд пропускають. А потім перший реальний інцидент стає першим реальним тестом, і це дуже неприємний спосіб дізнатися про помилки маршрутизації.
Уважно стежте за таймлайном. Якщо перевірка падає о 10:00, сповіщення не має з’явитися о 10:17, якщо такий поріг не був виставлений навмисно. Якщо воно приходить не в той чат, виправте це до наступного інциденту, а не після нього.
Запишіть, що сталося під час тесту. Проста нотатка з назвою монітора, використаним тригером, отримувачем і будь-якою затримкою допоможе потім, коли хтось запитає, чому сповіщення спрацювало двічі. Число 2 важливіше за нечіткий спогад.
Якщо ви ще будуєте сам монітор, можливо, спершу варто налаштувати агент. Шлях налаштування зі * може допомогти, коли перевірці потрібна свіжа інсталяція, а потім зверху можна додати налаштування сповіщень без здогадок.
7. Переглядайте історію сповіщень і коригуйте пороги після реальних інцидентів
Перші кілька сповіщень навчають краще, ніж тиждень планування. Переглядайте їх після реальних інцидентів і шукайте закономірності: повторні хибні спрацьовування, занадто пізні сповіщення або сповіщення, що потрапили не до тієї команди.
Якщо короткий збій мережі на 2 хвилини викликав сповіщення, підвищте поріг. Якщо простій на 12 хвилин дав лише одне повідомлення без ескалації, скоротіть затримку або додайте повторний маршрут. Кожен реальний інцидент дає вам одну точку даних, і однієї точки вже може бути достатньо, щоб виправдати невелику зміну.
Тут ворогом є шум. Занадто багато малокорисних сповіщень роблять людей повільнішими в реакції, а це може перетворити короткий простій на довший. Занадто мало сповіщень працюють так само, тільки в інший бік. Правильний баланс не є сталим назавжди.
Звертайте увагу на коди статусу, час доби та службу, на яку вплинуло. Сторінка входу, що двічі не працює в будні, може потребувати жорсткішого порогу, ніж та сама сторінка у вихідні з низьким трафіком. Контекст важливий, бо ціна переривання не однакова щогодини.
На початку тримайте цикл перегляду коротким. Після перших 3–5 сповіщень за потреби відкоригуйте примітки до монітора, список отримувачів і час ескалації. Такий невеликий перегляд може запобігти тому, щоб шумне сповіщення стало частиною щоденного життя.
Якщо ви також відстежуєте пов’язані шляхи користувача, наприклад оформлення замовлення, корисно порівнювати, що говорить сповіщення, з тим, що реально бачили користувачі. Сповіщення на рівні сторінки та огляд на рівні сесії часто показують різні частини однієї історії, і astrina session replay для перевірки оформлення замовлення може допомогти легше помітити цю різницю.
І ще одна практична порада: вносіть зміни назад у сам монітор, а не лише в чат. Коментар у Slack зникає в стрічці. Монітор залишається.
