Инциденты с доказательствами, подтверждением получения и заметками

Жизнь одного инцидента

Инцидент начинается, когда сбой подтверждён, а не когда не прошла первая проверка. В этот момент в инциденте записываются причина (код ответа, таймаут, ошибка сертификата, пропущенный 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 для команд, которые уже живут в нём. Механика эскалации описана на странице эскалации оповещений. Сайт, который мерцает, намеренно сворачивается в один инцидент с несколькими сменами состояния, чтобы плохие пять минут были одним оповещением, а не сорока. Почасовые лимиты оповещений на тарифах также защищают обработчик и вашу почту, если случится что-то действительно патологическое.