Возможно, вы знаете таких программистов, которые никогда не сталкивались с такой практикой, как «дежурства». Я до определённого момента в своей карьере тоже, думал, что знаю такого (конкретно — себя). Но всему приходит своё время, и на одной из работ пришлось подежурить и мне. До того момента, я только слышал от других об их недовольстве дежурствами. Все рассказчики, как анекдот, повторяли одну и ту же историю про ночные звонки дежурному, который не может проснуться. Этой статьёй хочу добавить немного красок на холст, чтобы у соискателей стало немного больше понимания о том, что можно спросить на собеседовании и как можно интерпретировать ответы на эти вопросы.

Как я понимал «идеальное дежурство» програмиста, работающего 5 дней в неделю по 8 часов:

Вариант № 1:
Программист назначается «дежурным» на время с 9 до 18 (ну, или в те часы, когда он работает). Если какая‑то экстренная ситуация требует внимания дежурного за пределами рабочего времени, это время согласовывается с ним, фиксируется и оплачиваеся деньгами или отгулами (читаем ТК РФ).

Вариант № 2:
Программист назначается «дежурным» на «сутки через трое». т. е. работает 24 часа, а потом 72 часа отдыхает от работы (тоже соответствует ТК РФ).

Что должен делать дежурный программист на идеальном дежурстве:

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

2) Если приложение перестаёт нормально работать, дежурный:

• пробует устранить проблему (исправить что‑то, что он может оперативно исправить),

• фиксирует симптомы неполадки (например, оформляет задачу на исправление ошибки),

• привлекает к устранению проблемы тех, кто может помочь её быстро устранить.

3) Если это не мешает поддержанию работоспособности системы, дежурный может заниматься деплоем (да‑да, ещё не вымерли конторы, в которых деплой делается руками человека).

Чем должен быть обеспечен дежурный:

1) Конечным набором инструментов, с помощью которых он сможет выполнять свои обязанности (пищалки‑уведомлялки, дашборды, права доступа ко всему, к чему ему может понадобиться доступ).

2) Инструкциями о том, что делать в каждой нештатной ситуации, если такие уже случались ранее.

Чем не должен заниматься дежурный программист:

Если коротко — он не должен делать то, что напрямую не относится к обязанностям «пожарного»

1) Выполнять обязанности штатной техподдержки:

• «У нас тут пользователь спрашивает, почему у него нет доступа к тому, к чему у него не должно быть доступа. Разберитесь, пожалуйста?»

• «Мы тут хотим с вами интегрироваться. Расскажите, как это сделать?»

• и т. п.

2) Выполнять обязанности девопс, тем более, если у него нет для этого ни инструментов, ни доступов.

3) Выполнять свои основные рабочие задачи, которыми занимается, когда не «дежурит».

4) Подменять собой автоматику. Если в инструкции написано что‑то вроде «при увеличении времени отклика — перезапустить приложение», то делать это должна автоматика, а не живой человек.

Как проходили мои дежурства:

1) Дежурный работал 24/7. Буквально, в течение недели дежурному нельзя было:

• отвести/забрать ребёнка из садка, школы, спортивной секции, поликлиники,

• вообще отходить от рабочего компьютера дальше, чем на расстояние, с которого он сможет добежать до него за 10 минут,

• спать. Точнее, спать он может, но должен уметь в течение 10 минут проснуться по зову пищалки‑оповещалки,

• есть. Смотрим правило про 10 минут,

• в туалет и душ — тоже можно не дольше 10 минут.

Можно подумать, что преувеличиваю про спать, есть, туалет и душ. Но, когда я спрашивал про строгость соблюдения «правила 10 минут», то мне все, от начальника до коллег, на полном серьёзе утверждали, что «нарушать его нельзя».

2) Дежурный — это был и чтец, и жнец, и на дуде игрец. Он делал всё и за себя и за того парня, который вроде есть, но «занимается сегодня другими делами».

3) Время работы дежурного за пределами с 9 до 18 не оплачивалось, отгулы не предоставлялись.

4) Дежурный не был обесчпечен тем, что ему необходимо для выполнения своих обязанностей (инструменты, доступы, инструкции). Тут есть небольшое пояснение: если инструмент есть, но он не позволяет понять, что происходит или исправить ситуацию, то я считаю, что такого инструмента нет. Например:

• свистелка показывает превышение приложением лимитов потребление памяти, график на дашборде этого не подтверждает. Что происходит — загадка для дежурного. Но делать что‑то нужно и дежурный начинает «строить самолёт из пальмовых листьев» (отсылка к карго‑культу) — пытаться с помощью логов, графиков и загадочных переключений всего и вся добиться того, чтобы свистелка перестала свистеть,

• если свистелка в одном месте, график — в другом, логи — в третьем, инструкция — в четвёртом, кнопки, которые нужно нажимать — в двадцатом, то это тоже не инструмент. Это аттракцион или цирк шапито. Знаете, такой стандартный цирковой номер, когда клоун пытается взять сразу несколько предметов, но не может, так как у него постоянно что‑то падает из рук. Вот это было очень похоже на наши «инструменты дежурного»,

• если адрес у web UI инструмента непостоянный и зависит от релиза, активного пода, фазы Луны, то это тоже не инструмент. Потом что дежурный не найдёт его, когда он будет нужен и вынужден буду проделать 100 500 шагов из инструкции, чтобы от какой‑то начальной точки прийти к действующему URL этого инструмента,

• инструкция «посмотреть список ошибок из 137 строк и на опыте на глазок прикинуть: не появились ли новые» (видимо, с последнего просмотра) — это не инструкция. Это, скорее, рецепт самоуспокоения (я сделал всё, что мог — «посмотрел на опыте»),

• доступ к хосту без доступа к приложению — это не доступ. Хотя, я даже при наличии досупа, не рискнул бы лезть на хост, на котором крутится прод, если это не я настраивал те приложения, в работу которых сейчас нужно вмешаться и не понимаю на 100%, что именно нужно сделать.

5) У дежурного были, просто, тонны ручного труда. Десятки графиков, на которые нужно смотреть и сравнивать, слушать пищалки и читать инструкции и, в зависимости от их показателей и результатов сравнения, нажимать какие‑то кнопки. Всё это можно было автоматизировать и выполнять более эффективно, чем человек, разбуженный пищалкой в 3 часа ночи.

Я не верю, что при таких условиях дежурный мог приносить ту пользу, для которой он назначался. Либо он должен быть суперменом.

Коллеги мои считали, что дежурства и должны быть такими, какими были у нас, что по‑другому нельзя. Но я думаю, что настоящая причина таких «дежурств» была в экономике компании (или отдела, в котором я трудился), часть которой составляла экономия расходов на настоящих: девопсов, техподдержку, автоматизацию процессов поддержания работоспособности приложений, дежурных.