Как обеспечивается надежность и ответственность в дежурствах

Что проверяют

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

Как отвечать

Опирайтесь на свою практику и называйте свои цифры: частоту алертов, время реакции, сколько человек в ротации. Каркас можно строить так:

• кто и когда: ротация на неделю, основной и запасной дежурный, передача смены с перечнем открытых проблем, понятная эскалация, если дежурный не ответил за N минут;
• как узнаём о проблеме: алерты на симптомы, которые чувствует пользователь (ошибки, латентность, SLO), а не на каждый скачок CPU. В .NET это health checks через AddHealthChecks() и MapHealthChecks, метрики и трейсы через OpenTelemetry, структурные логи через Serilog или встроенный ILogger, дальше Prometheus, Grafana или аналог;
• что делаем: runbook на каждый алерт, первым шагом снижение ущерба (откат релиза, фича-флаг, переключение трафика), и только потом поиск причины;
• что после: постмортем без поиска виноватых, задачи в бэклог с владельцем, пересмотр алертов, которые будили зря;
• ответственность: дежурный отвечает за реакцию и коммуникацию, а не обязан починить всё сам, и за ночные выходы положен отгул или доплата.

Если дежурств у вас не было, скажите об этом прямо и расскажите, как разбирали инциденты на проде в рабочее время или что сделали бы в первые 15 минут. Выдуманный опыт разваливается на первом уточнении про конкретный алерт.

Где спотыкаются

Рассказывают историю героя, который ночью в одиночку поднял прод. Интервьюер слышит другое: процесса нет, знания в одной голове.

Приводят круглые проценты вроде «простой снизился на 30%» без метрики, периода и базы сравнения. Это звучит как шаблон, и первый же вопрос «как считали?» ставит в тупик.

Начинают с поиска причины вместо восстановления сервиса или чинят прямо на проде без согласования и без возможности откатиться.