> Как принимается решение, кому звонить при проблемах в нерабочее время (Go)

Короткий ответ

Решение принимается на основе заранее определённой эскалационной матрицы (escalation matrix) и ротации on-call инженеров. Приоритет отдаётся severity инцидента: для критичных проблем (S1/S2) звонок идёт дежурному инженеру, затем тимлиду, затем техническому директору. Для некритичных - только в рабочее время через тикет-систему. Автоматизация через PagerDuty или аналоги позволяет маршрутизировать вызовы по расписанию и эскалировать, если ответа нет в течение заданного времени.

Подробное объяснение

Процесс принятия решения о звонке в нерабочее время строится на нескольких ключевых компонентах:

Определение severity инцидента. Каждая команда фиксирует критерии для каждого уровня критичности. Например, S1 - полная недоступность сервиса или потеря данных, S2 - деградация для значительной части пользователей, S3 - локальные проблемы, S4 - косметические баги. Для S3/S4 звонок не выполняется - достаточно тикета.

On-call ротация. Назначается дежурный инженер на неделю или день. Расписание хранится в системе мониторинга и автоматически подхватывается при алерте. Ротация покрывает все часовые пояса, где есть пользователи.

Эскалационная цепочка. Если дежурный не отвечает в течение 10-15 минут, система автоматически переводит вызов на следующего в цепочке: senior инженер → тимлид → руководитель направления. Каждый уровень имеет свой таймаут.

Каналы коммуникации. Первичный канал - телефонный звонок через PagerDuty или SMS. Если звонок не принят, отправляется push-уведомление в мобильное приложение. Параллельно создаётся инцидент в трекинговой системе (Jira, Opsgenie) с полным контекстом: алерт, логи, метрики.

Критерии для звонка. Звонок выполняется только если алерт соответствует заранее настроенному правилу: порог по latency, error rate, недоступность healthcheck, превышение лимитов по CPU/memory. Все остальные алерты идут в чат дежурной смены без звонка.

Решение принимает система, а не человек. Автоматизация исключает субъективность: если алерт сработал по правилу - звонок обязателен. Человек может только отключить алерт на время плановых работ через maintenance window.

На практике

В Go-проектах обычно используется связка Prometheus + Alertmanager + PagerDuty. Alertmanager группирует алерты, дедуплицирует их и отправляет в PagerDuty с severity. PagerDuty управляет ротацией и эскалацией.

Конфигурация ротации хранится в коде (Infrastructure as Code), чтобы изменения проходили code review. Например, в Terraform описывается расписание on-call, а в YAML-файлах - правила алертов.

Важный аспект - runbook для каждого типа инцидента. Дежурный инженер должен иметь пошаговую инструкцию: как диагностировать, какие метрики смотреть, какие команды выполнить, к кому обращаться за помощью. Runbook хранится в репозитории рядом с кодом.

Также практикуется "follow the sun" модель для распределённых команд: дежурство передаётся между регионами по часовым поясам, чтобы инженер не работал ночью чаще, чем раз в несколько недель.

Как отвечать на собеседовании

Начните с определения severity и эскалационной матрицы - это показывает системное мышление. Затем упомяните автоматизацию через PagerDuty и интеграцию с мониторингом. Подчеркните, что решение принимает система по заранее заданным правилам, а не человек в моменте - это ключевой принцип.

Расскажите про runbook и ротацию. Упомяните, что для Go-проектов важна наблюдаемость: метрики, трейсы, логи - без них невозможно корректно настроить алерты. Если спросят про trade-off, отметьте: слишком много звонков - выгорание команды, слишком мало - риск пропустить критичный инцидент. Баланс достигается регулярным пересмотром правил алертов.

Приведите пример из практики: как вы настраивали алерт на p95 latency и почему выбрали именно этот порог. Это покажет глубину понимания.

Что проверяет интервьюер

Интервьюер оценивает:

• понимание жизненного цикла инцидента: от алерта до постмортема
• умение проектировать надёжные системы с учётом человеческого фактора
• знание инструментов observability и incident management
• способность формализовать процессы: severity, эскалация, ротация
• понимание trade-off между автоматизацией и ручным контролем
• опыт работы с Go-экосистемой: Prometheus, Grafana, OpenTelemetry

Также проверяется, насколько кандидат осознаёт ответственность дежурного инженера и умеет минимизировать ложные срабатывания. Хороший ответ показывает, что кандидат думает о долгосрочной устойчивости процесса, а не только о технической стороне.

Типичные ошибки

• Ответ "звоним всем подряд" - отсутствие структуры и эскалации
• Игнорирование severity: "всегда звоним, если что-то упало"
• Отсутствие упоминания runbook - признак, что кандидат не сталкивался с реальными инцидентами
• Фокус только на инструментах без описания процесса принятия решения
• Неучёт человеческого фактора: выгорание, ошибки при недостатке сна
• Утверждение, что звонок - единственный канал, без упоминания эскалации по таймауту
• Отсутствие связи с Go-стеком: кандидат не знает, как настроить алерты в Prometheus или какие метрики важны для Go-сервисов (goroutine leak, GC pause, HTTP latency)