Роль SRE в Incident Management

Ключевая цель SRE в IM: не просто устранение сбоев, а системное повышение надежности: анализ конкретного инцидента, анализ трендов по дашборду, анализ исторических данных, автоматизация, выставление задач на доработку и тп.

SRE не чинит каждый иницидент, не участвует в процессе во время medium/low, для этого есть L2/L3.

Это не "чинитель инцидентов", это "продумыватель, как сделать так, чтобы они не повторялись".

1. Как узнает об инциденте:

  • CRIT: SRE должен узнавать о таком инциденте автоматически через систему алертов. Эскалация от L3 является резервным способом - например, возможный сбой в системе оповещения.

  • HIGH: SRE может узнавать как через алерты, так и в результате эскалации от команды L3/L2, когда исчерпаны их полномочия или возможности для диагностики/решения.

  • Medium/Low - присутствие не требуется, эскалация не требуется.

2. Действия SRE в зависимости от уровня инцидента

CRIT: полная или значительная деградация сервиса

  • Немедленный ответ: Автоматически поднят по алерту (on-call). Время на ответ регламентировано (например, < 5 минут).

  • Роль: Принимает роль Incident Commander (IC) или Key Responder. Его задача — координация работ, а не обязательно прямое исправление.

  • Действия:

    1. Немедленно подтверждает инцидент и начинает его ведение.

    2. Определяет канал для коммуникации.

    3. Оценивает воздействие и масштаб.

    4. Привлекает необходимые команды (L3, сетевые инженеры, БД и т.д. - кого считает нужным. Его требование является обязательным для всех).

    5. Фокусирует команду на снижении ущерба и восстановлении сервиса (mitigation), и только после восстановления - на поиске корневой причины. Сначала чиним, потом оформляем.

    6. Обеспечивает регулярный (например, каждые 15 мин) апдейт в выбранном канале для заинтересованных.

    7. После восстановления сервиса инициирует/контролирует процесс написания postmortem (который пишет решавший инц, не SRE) и проверяет потом его полноту, тайминги и тп, чтобы постмортем был полезен.

HIGH: Существенная деградация второстепенной функции

  • Ответ: В течение регламентированного времени (например, < = 30 минут). Может быть поднят по алерту или эскалации.

  • Роль: Key Responder или Technical Lead.

  • Действия:

    1. Если стандартные процедуры не сработали - эскалирует проблему внутри команды SRE или к командам разработки.

    2. Участвует в пост-обработке инцидента для определения корректирующих действий и контролирует их.

MEDIUM: Незначительная проблема, частичная деградация

  • Ответ: В рабочее время (в течение рабочего дня).

  • Роль: Resolver.

  • Действия:

    1. Изучает инцидент в рамках текущих задач.

    2. Обновляет документацию и Runbooks при выявлении новых сценариев.

    3. Думает про долгосрочное решение, а не про "костыль".

LOW: Несущественная проблема, не влияющая на сервис

  • Ответ: Обрабатывается в рамках обычного рабочего процесса.

  • Роль: Может быть обработан любым членом команды SRE.

  • Действия:

    1. Фиксируется как задача (task).

    2. Изучается и исправляется при наличии ресурсов.

    3. Часто используется для улучшения мониторинга и предотвращения эскалации подобных проблем в будущем.

Критический факт: Все эти процедуры, роли и пороги срабатывания должны быть формализованы в документации по управлению инцидентами (Incident Management Process). SRE обязан действовать в рамках этого регламента.