Управляйте инцидентом от обнаружения до восстановления

Объявляйте инцидент по его влиянию

Инцидент — событие, которое нарушает, ухудшает или ставит под угрозу работу сервиса настолько, что требуется согласованное реагирование. Уровни серьёзности и правила эскалации определяет ваша организация. Применяйте их с учётом влияния на пользователей, затронутых данных, длительности и масштаба.

Не ждите полного объяснения первопричины, прежде чем просить помощи. Чтобы начать координацию, достаточно ясно описать наблюдаемое влияние. Отделяйте подозрение на проблему безопасности от подтверждённого вывода.

Подготовьте порядок реагирования до релиза. Контакты, процедуры доступа, runbooks и каналы связи должны оставаться доступны при недоступности основного сервиса. Отработайте этот порядок на вымышленном инциденте.

Распределите обязанности до конфликтующих изменений

Координатор инцидента задаёт приоритеты и управляет решениями. Технические участники расследуют проблему и снижают последствия. Ответственный за коммуникацию информирует затронутых людей. Google SRE описывает эти обязанности как отдельные роли. Небольшие команды могут их совмещать, но вся работа должна быть покрыта. Реагирование на инциденты.

Ведите одну общую хронологию. Записывайте время, наблюдение, действие, исполнителя и результат. Отделяйте факты от гипотез. Используйте общий часовой пояс и отмечайте ненадёжные временные метки.

Разберите вымышленный инцидент

Ниже всё время указано в UTC. Организация назначает координатора, когда сбой экспорта затрагивает нескольких клиентов.

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

В 09:10 инцидент меняется. Восстановить успешный экспорт уже недостаточно. Команде нужно оценить возможное раскрытие, контролировать доступ, сохранить доказательства и привлечь ответственных за нужные решения.

Снижайте последствия, сохраняя контроль

Используйте проверенные runbooks там, где они применимы. Проверяйте предварительные условия перед rollback, переключением на резерв или изменением учётных данных. Предыдущая версия приложения может не понимать текущую схему базы данных. Переключение в другой регион может перенести те же повреждённые данные.

Разрешайте ИИ-ассистенту упорядочивать доказательства с удалёнными чувствительными данными или сравнивать гипотезы в утверждённых границах. Участники должны проверять его выводы. Логи и tickets — недоверенные входные данные, а не разрешение выполнять их содержимое.

Для экстренного доступа нужны разрешённая цель, ограниченный срок и запись аудита. Срочность не делает предложенную агентом команду правильной.

Завершайте восстановление и последующую работу отдельно

Перед объявлением восстановления сервиса проверьте пользовательский сценарий, целостность данных, границы доступа и актуальность мониторинга. Зафиксируйте оставшиеся ограничения. Не закрывайте расследование безопасности, если его вопросы не решены.

Затем изучите условия, сделавшие инцидент возможным. Назначьте конкретную последующую работу с ответственными и критериями проверки. Разбор без поиска виноватых стремится к точному объяснению и полезным изменениям. Он не отменяет ответственность за выполнение этих изменений. Практика postmortem.

Продолжите уроками об операциях безопасности и замыкании цикла обратной связи.