DevOps тебя сожрёт.
Часть 5

3. Дежурства


Этот пункт без внимания не могу оставить. Один из самых популярных минусов инфраструктурных специальностей. На самом деле, у меня есть опыт работы devops инженером без дежурств — дежурили разработчики. Но это были отдельные Data Engineering команды.

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

Например, сервис отдаёт 502 на проде, ай-яй-яй, караул. Алерт прилетел.
К тебе разработчик приходит со словами: “Плз, посмотри, что-то упало”, а НЕ “Мы проверили работу сервиса, логи, потребляемые ресурсы — на стороне сервиса не увидели проблемы.” (К слову, обычно есть настроенный мониторинг, чтобы эту инфу получить.)
Идёшь смотреть ресурсы тачки, где крутится лежачий, там всё ок: CPU, сеть, диски — всё в порядке, есть стабильные всплески, как и в любой другой день, но вот memory вызывает подозрение. Проверяешь работу сервиса в контейнере, и там, например, оказалось, что превышается лимит, контейнер падает, а случилось это через пару часов после релиза, так как косячные запросы к БД завалили сервис.

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

Также к дежурству относятся покрытие любых хотелок и вопросов со стороны остальных работников компании. День ото дня эти хотелки\запросы\вопросы очень разнообразны, контексты меняются молниеносно. Такая центрифуга высасывает из тебя все силы к концу рабочего дня. Если вы работаете вдвоём-втроём, то хотя бы раз в неделю ты будешь отправляться в центрифугу. В нормальных компаниях, где не планируется через полгода выкинуть безжизненный кусок человека на улицу, основные таски из бэклога делать не требуют. Правда, не всем так везёт, и после горячей недели тебе могут на дейлике еб**ь мозг за проё***ные сроки у особо важной задачки.

С одной стороны, дежурства — это, конечно, минус девопс-специальности.
С другой стороны, если ты понимаешь, на что идёшь, — это просто часть твоей работы, которую ты любишь. Есть также часть людей, которым прям нравятся дежурства.

Собственно, если ты к фанатам саппорта не относишься, то варианты тоже есть.
— Один из них — не идти туда, где есть дежурства.
— Второй — на собесах заранее спрашивать о количестве инцидентов, о количестве дежурных, о графике дежурств. С этим, конечно, можно жонглировать. Если вас будет два дежурных, неделя через неделю, но инцидентов один в месяц, а разработчиков 10 человек — вполне неплохой вариант. Если вас 5, инциденты каждую неделю, а разработчиков 500 человек — то это, конечно, пиз**ц. Даже если инцидентов один в полгода, то 100 разрабов на одного девопса — это пиз**ц.

При самых конченных обстоятельствах всегда есть возможность не выгореть. Самое важное — это сохранять свои ресурсы и не превращаться в инфраба.

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

— Забудь о тасках из бэклога. Дежурство — это всегда приоритет, так как запросы горящие, стоящие денег и требующие твоего оперативного внимания.

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

Есть опыт в дежурствах? Нравится саппорт? Расскажи про свой опыт.
(2 пунктика осталось)