➡️ Закрыт ли инцидент? Разберем ситуацию: инцидент вроде пофиксили, система работает, алерты затихли. Но пользователи ещё жалуются, данные подпорчены, в логах бардак, а команда на нервах. Возникает вопрос: когда же реально можно закрыть тикет? ⚡️Критерии закрытия инцидента Восстановлено основное бизнес-функциональное состояние Система отвечает на ключевые запросы в рамках целевых SLA/SLO (latency, error budget). Если P0-инцидент звучал как «платежи не проходят», значит, платежи должны успешно проходить хотя бы в 99% случаев. Нет активных алертов и деградаций Golden signals в норме. Нет новых ошибок, связанных с инцидентом. Мониторинг остаётся «зелёным» минимум 1–2 часа (для P0/P1). Все заинтересованные стороны подтвердили OK Product Owner, бизнес и поддержка должны явно сказать: «Пользователи довольны, жалоб нет». Без этого формального go закрывать инцидент рано. ⚡️Важно: последствия ≠ инцидент Восстановление — это отдельный поток работы: · Инцидент: база упала → failover сработал → CLOSED · Post-incident: репликация отстаёт на 2 часа → в backlog · Post-incident: потеряно 500 транзакций → ручной парсинг логов · Post-incident: команда выгорела → 1on1 и ротация Прикрепил для вас чеклист, который хорошо помогает отделить ситуации «мы снова в строю» от «мы действительно закрыли инцидент». Поделитесь, как у вас принято определять момент закрытия?