Інциденти з доказами, підтвердженням отримання й нотатками

Життя одного інциденту

Інцидент починається, коли збій підтверджено, а не коли не пройшла перша перевірка. У цей момент в інциденті записуються причина (код стану, таймаут, помилка сертифіката, пропущений heartbeat), регіони, що його підтвердили, перші рядки відповіді, визначена IP-адреса і, якщо вдається встановити, залучений зовнішній провайдер. Контакти отримують сповіщення, сторінка статусу перемикається, і починається хронологія. Вона завершується, коли відновлення підтверджено так само, а сповіщення про відновлення вказує, скільки тривав збій.

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

Підтвердження отримання — звідки завгодно

Підтвердження отримання повідомляє системі, що людина взяла інцидент на себе. Це можна зробити зі сторінки інциденту, за посиланням у листі зі сповіщенням, через API або в Telegram відповіддю /ack. Команда Telegram підтверджує останній відкритий інцидент облікового запису, до якого підключено чат: це зручно тихої ночі й варто пам’ятати, коли одночасно зламано дві речі.

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

Докази, що витримують розмову з клієнтом

Сенс запису фрагмента відповіді та IP-адреси в тому, що суперечки про те, що сталося, закінчуються швидко. Сторінка 503 від балансувальника хостингу виглядає інакше, ніж фатальна помилка PHP, а IP-адреса, що різниться між регіонами, свідчить про проблему DNS або CDN. Вигляд інциденту показує це по кожному регіону, а API повертає ті самі поля, зокрема confirmedBy і масив evidence з кодом стану, часом, IP та фрагментом тіла відповіді. Приклад форми: інцидент на 130 секунд, підтверджений кількома регіонами, у кожного 503 і відповідь за 412 мс, отримання підтверджено через 50 секунд після відкриття.

Нотатки та історія для клієнта

Нотатки — для людської частини: «хостинг перезапустив PHP-FPM», «клієнт завантажив зображення по 40 МБ». Вони з’являються в хронології інциденту й у щомісячному звіті, що перетворює технічну подію на те, що можна пояснити. Додавати їх можна в застосунку або запитом POST до адреси нотаток інциденту, тож автоматичний ранбук може лишити слід про те, що він зробив.

Для публіки: інциденти, відкриті моніторами, самі з’являються на сторінці статусу, а ви можете публікувати ручні інциденти з оновленнями для проблем, яких монітори не бачать, — наприклад, збій платіжного провайдера, що не ламає ваші адреси. Ці оновлення надходять підписникам e-mail і в RSS-стрічку. Налаштування — на сторінці сторінок статусу.

Десятихвилинний щотижневий огляд

Інциденти стають корисними, коли дивишся на них гуртом. Раз на тиждень відкрийте список і перевірте три речі: які монітори відкрили найбільше інцидентів, які інциденти так і не підтвердили до отримання і в яких немає нотатки. Монітори, що постійно повертаються, зазвичай вказують на справжню слабкість — замалий хост чи нестабільне cron-завдання. Непідтверджені інциденти, що самі відновилися, часто означають, що сповіщення йдуть не тому контакту. Порожній стовпець нотаток — підказка написати два рядки до відправки щомісячного звіту, поки ви ще пам’ятаєте, що було виправлено.

Де це навмисно скромно

Це робота з інцидентами для невеликої команди чи агенції, а не платформа реагування на інциденти. Немає календарів чергувань із ротацією, власної автоматизації ранбуків і шаблонів постмортемів. Що є: затримки для кожного контакту, другий контакт у Telegram або e-mail на Pro і PagerDuty на Agency для команд, які вже живуть у ньому. Механіку ескалації описано на сторінці ескалації сповіщень. Сайт, що мерехтить, навмисно згортається в один інцидент із кількома змінами стану, щоб погані п’ять хвилин були одним сповіщенням, а не сорока. Погодинні ліміти сповіщень на тарифах також захищають обробник і вашу поштову скриньку, якщо станеться щось справді патологічне.