о дежурствах

инженеры делятся на два типа: те, кто еще дежурит и те, кто уже не дежурит

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

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

когда команда кроссфункциональна (есть фронты, бэки, базисты, инженеры) — всё просто, мы сервис подняли, мы его и починим. да и вообще сделаем так, чтобы сервис не падал, либо поднимался быстро и незаметно (за 5 секунд, как бутерброд с пола)

а если у нас не stream-aligned team, а complicated subsystem team? тогда начинается жара: мы пишем сервис, им пользуются (почти) все, SLA в кучи девяток, а баланс жизнь-работа — разрушен. сидишь такой в панике, даже если всё хорошо обычно у сервиса, что он стрельнет в самый неподоходящий момент. плюс, центры экспертиз и факторы автобусов, ох, как несладко!

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

дааа, задача нелёгкая. давайте сгрузим такие задачи на кого-то?
ага, но только не на ситуационный центр. у ситуационного центра задача только разбираться с алертами и эскалациями — их нужно правильно пройти по ранбуку, вызвать нужных ответственных и создать инцидент-ВКС (если таковой возник).

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

а как бы вы организовали дежурство? или как оно у вас организовано?