Представьте себе команду, которая пишет F2P-игру для мобильников. Даже если это инди-проект из трёх человек, в этой команде всё равно будут разработчики, тестировщики и хоть кто-то ответственный за инфобезопасность. И, допустим, в команде хаос.
Разрабы долго ждут обратную связь от QA, половина документации нечитабельна, в Git пропала версия кода, до которой очень нужно откатиться прямо сейчас, потому что в новой всё поломалось в проде и надо вернуть как было… Ещё и вся команда в ссоре и ни один дейли не проходит без скандала. Как вы думаете, быстро ли эта игра дойдёт до рынка?
Это, конечно, драматическое преувеличение, но для решения таких проблем и нужны DevOps-практики.
DevOps-инженер — это не дорогой сисадмин
DevOps — это не отдельная должность, а скорее культура разработки. Эта культура предполагает, что процесс создания софта — это не «лестница» с изолированными друг от друга этапами, а непрерывный цикл, где этапы перетекают друг в друга, а у всех членов команды общая ответственность. Думаем, с этой восьмёркой вы знакомы:
Культура DevOps предполагает, что инженер не только следит за тем, чтобы ничего не падало, но и прививает команде ценности по фреймворку CALMS:
Culture — научить команду тому, что ответственность за результат лежит на всех её участниках.
Automation — автоматизировать всё, что можно. Например, сделать так, чтобы автотесты запускались сами, а разработчики не ждали, когда тестировщик вернётся с перекура и нажмёт кнопку.
Lean — доставлять быстрее и не тратить ресурсы на то, что не приносит прибыль и ценность.
Measurement — постоянно мониторить всё, собирать данные и на их основе улучшать процессы.
Sharing — учить команду работать в команде и разговаривать друг с другом.
А как понять, что команда работает по девопсу?
Это как горизонт: ты бесконечно к нему стремишься, но никогда его не достигаешь. Но если вам нужны цифры, есть три способа измерить соответствие DevOps-ценностям:
Time-to-market и доступность системы. Это верхнеуровневый критерий, но когда админы эксплуатации думают о time-to-market, а разработчики думают о доступности, можно сказать, что команда работает в DevOps-подходе.
Смотреть на метрики разработки. Берём метрики эффективности разработки и смотрим на тренды — или сравниваем «до» и «после» внедрения DevOps-практик в команду. Если есть хорошие тенденции или хотя бы нет плохих, значит, нормальный у вас девопс.
DevOps-метрики для продвинутых. Здесь тоже есть разные фреймворки, остановимся чуть подробнее на самом популярном — DORA. Это 4 метрики, придуманные группой DevOps Research and Assessment из Google: частота деплоя, время внесения изменений, коэффициент ошибок и время восстановления после разных outages.
Смотря какой fabric.
Значит, отдельная постоянная роль не нужна?
Не всегда — зачастую команда и сама может прийти к DevOps-методологии без специалиста со стороны. Есть и другой подход, а именно, энейблинг. Это внедрение практик и ценностей с помощью нового члена команды, который и берёт на себя роль DevOps-инженера. В итоге команда перенимает этот опыт, использует и распространяет его дальше. И для дальнейшего поддержания нового формата работы не всегда нужен отдельный человек.
Но есть нюанс. Большинство российских компаний не понимают, что DevOps — это принципиально другая культура разработки, а не только должность в команде. Поэтому и добавляют в вакансии сисадминов модное слово. Или ищут девопса в надежде, что он наведёт порядок, хотя команда не готова к новому подходу. А если команда не готова, то нанятый DevOps-инженер упрётся в потолок, будет заниматься чисто сисадминской работой и ничего не поменяется. То есть сначала организация понимает, что она готова работать иначе, а потом уже приходит время решать, кто будет перестраивать процессы.
Хочу в девопсы, кому продать душу?
Без бэкграунда в IT стать девопсом сложнее, чем, например, разработчиком. Полезным может стать опыт в разработке, написании автотестов, или системном администрировании. А ещё на девопсов учат в университетах.
Диплом ИТМО, впрочем, необязателен. Тут как и в любой профессии: качаешь хард скиллы, качаешь софт скиллы, получаешь опыт работы в команде и изучаешь практики — всё, ты теперь энейблер с душой.
А что девопс должен уметь?
Дорожных карт для хард скиллов девопса полно — нам, например, нравится вот эта периодическая таблица от Xebialabs.
Конечно, не все инструменты из таблицы понадобятся вам в работе — нужный вам стэк зависит от задач и конкретной компании. Например, кто-то использует Jira для таск-трекинга, а кто-то Trello. С более сложными инструментами то же самое: кто-то для мониторинга использует Prometheus, а кто-то Zabbix. Поэтому лучший способ освоить хард скиллы и вообще начать карьеру в этой сфере — попасть в маленькую команду и подстроиться под её стэк. Но если вам нужен ответ покороче и без нюансов, то вот что неплохо было бы знать и уметь, если вы метите в девопсы:
Linux-администрирование
Облачные и сетевые технологии
Непрерывная разработка и интеграция
Контейнеризация, или тот самый Kubernetes
Настройка мониторинга, чтобы вовремя ловить ошибки в системе
Инфраструктура как код
Но вряд ли получится стать девопсом без эмпатии и чёткого понимания, кем ты на самом деле хочешь быть. Эмпатия нужна, чтобы осознать и прочувствовать боли, с которыми сталкиваются команды без девопса — в идеале, конечно, на личном опыте. А чёткое понимание нужно, чтобы не сойти с ума от размытого понимания роли DevOps на рынке, особенно в российских компаниях. Даже если вы хотите быть дорогим сисадмином, в этом нет ничего плохого. Другое дело, что дорогой сисадмин и человек, который хочет менять культуру в организации, будут искать вакансии по-разному.
Я всё осознал и выучил, что делать дальше?
Для начала — не бойтесь устраиваться на работу даже если у вас мало опыта, а в вакансии написано, что нужно от 5 лет и ещё 13 лет линукса и борода. У DevOps высокий порог вхождения, поэтому конкуренция за каждую вакансию меньше. Если даже после этих слов вам ещё страшно нажимать кнопку «Откликнуться на вакансию», держите советы от нашего эйчара:
Не врите в резюме. Рекрутёры в основном не понимают, что такое эти ваши девопсы, они просто смотрят на ключевые слова. Поэтому да, если вы скопипастили модный стэк, вы можете пройти. Но дальше технического собеседования вы не пройдёте, ещё и испортите репутацию.
Не пишите слишком длинные сопроводительные письма. Когда-то мы провели опрос и узнали, что 30% рекрутёров не читают сопроводительные письма. Так что если вы накатали лонгрид 10 параграфов, шанса быть услышанным у вас нет.
Но и не пренебрегайте ими. Классное сопроводительное письмо, в котором видно, как сильно вы хотите именно в это место, может выручить при недостатке опыта. Чтобы вам дали шанс, коротко опишите, почему вы хотите именно в эту компанию, что вы делали до этого и какие у вас пруфы.
А ещё у нас как раз открыта вакансия DevOps! Поэтому, если что, – написать можно и нам :)