Дмитрий Олефиренко работает Techlead DevOps в компании Provectus. В этом интервью он поделился своей историей карьерного пути и очень детально рассказал о том кто такие DevOps-ы и какие навыки необходимы такому специалисту.

НЕМНОГО ИСТОРИИ

Движение DevOps зародилось в 2007-2008 годах, когда сообщества ИТ-операторов и разработчиков программного обеспечения выразили обеспокоенность фатальным, по их мнению, уровнем дисфункции в отрасли.

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

У разработчиков и ИТ-специалистов были отдельные (и часто конкурирующие) цели, отдельное руководство отделов, отдельные ключевые показатели эффективности, по которым их оценивали, и зачастую они работали на разных этажах или даже в разных зданиях.

В результате возникали изолированные команды, долгие часы работы, неудачные релизы и недовольные клиенты. Конечно, за 16 лет ситуация немного поменялась, и команда разработки ценит вклад DevOps команды.

Мне, как продуктовому менеджеру, понятна работа DevOps только в общем смысле. Поэтому мне было очень интересно поговорить на эту тему со своим бывшим коллегой, специалистом высокого уровня, Дмитрием Олефиренко.

О ПОЯВЛЕНИИ ПРОФЕССИИ DEVOPS

Дмитрий, расскажи, пожалуйста, с чего ты начал свой путь к DevOps профессии?

Сначала я начну с того откуда появилась эта профессия. Развитие профессий в IT очень сильно похоже на развитие медицины. Вот был когда-то один лекарь. Он собирал травки. Он же кровь людям пускал. Он же прически им делал. Это был такой брадобрей-цирюльник. Но потом, когда медицина стала развиваться, накапливать знания,  и стало понятно, что один человек, который умеет все, не подходит. Слишком много практического опыта необходимо иметь. 

И медицина стала разделяться уже на узкие специализации. То же самое случилось и в IT. Были эникейщики, которые одновременно могли настроить и 1С, и поставить Windows и рассказать бухгалтеру, почему у них что-то в Excel не получается.

Как же произошло разделение? За счет чего?

Профессия DevOps одна из самых молодых. В двух словах, это можно назвать взаимодействием команды разработки и operations. Например, команда разработки написала продукт, но остается 100500 открытых вопросов:

• Что с этим продуктом делать дальше?
• Как этот продукт запустить на продакшн?
• Как соблюсти все security аспекты, чтобы не было дыр, чтобы не взломали, чтобы не утекли пароли?
• Дальше огромный список вопросов, связанных с observability.

В некоторых компаниях, например, в Google это даже входит в отдельную должность, которая называется Site Reliability Engineering (SRE). Это люди, которые занимаются именно observability продукта: мониторинг, логирование, алертинг, пути движения алертов, что случилось, если у нас упадет алерт и так далее.

Написание своих тулов для мониторинга, для алертинга или исследований и внедрения уже существующих. Вот здесь я со своей стороны могу порекомендовать смотреть на продукты от Grafana.

Как же ты пришел в эту профессию? 

Пришел я в эту профессию достаточно интересно. В эту профессию, в основном, приходят из сисадминов. Предполагается, что DevOps должен иметь хорошее знание операционных систем, в частности, различных Linux’ов. Потому, что по большей части все продукты запускаются именно на этих операционных системах. Но я пришел немножко по-другому. Я сперва был PhP программистом, занимался разработкой сайтов. Потом я попал работать в около-DevOps профессию под названием Build Release Engineer. И потом плавно перекочевал в DevOps.

Что ты делал, когда был в роли Build Release Engineer?

Я занимался организацией билдов. Когда надо было выпустить новую версию продукта, я следил за тем, чтоб все шло по процессу. Отчасти я этим занимаюсь и сейчас.

Можешь подробнее рассказать что сейчас входит в твои обязанности?

В большой компании для DevOps огромное количество работы. Никуда не делось программирование. Я пишу достаточно много небольших поделок, как я их называю, которые запускаются, например, внутри Kubernetes кластера: какие-то вспомогательные тулы, репортинги и так далее.

Какой язык ты используешь?

Несмотря на то, что сейчас модно для этого использовать GoLang, я, как большинство DevOps, отдаю предпочтение Python. Он прекрасно подходит для всяких маленьких разработок.

КАКИМ КОМПАНИЯМ НУЖЕН DEVOPS

Для каких типов продуктов нужен DevOPS? Например, я хочу сделать какой-то маленький продукт для продажи билетов. Мне нужно привлекать DevOps или нет?

Это зависит от квалификации тех, кто будет разворачивать и поддерживать этот продукт. Мы можем взять публичный cloud, если это простой продукт. Например, Amazon. Взять очень user-friendly AWS Elastic Beanstalk и опытный разработчик, знакомый с Amazon, прекрасно там его развернет. А дальше могут либо появиться вопросы, либо нет. Например, какой мы хотим RTO или RPO¹ у этого продукта? Будет ли у нас disaster recovery², за сколько часов мы готовы, сколько часов мы готовы ждать, если этот продукт ляжет? За какое время мы готовы потерять данные? И насколько просто или насколько сложно мониторится наш продукт? 

Получается, что для маленьких продуктов эту роль выполняют обычно сами разработчики?

Тут надо смотреть, что такое маленький продукт. И это зависит от самого продукта. С какими сервисами он должен взаимодействовать, какой RTO и RPO у этого продукта? Например, если у нас интернет магазин — будет ли страшно, если он, допустим, 2 часа лежал? Наверное, нет. Если люди заходили в этот интернет магазин, делали покупки, база пропала, а backup был 8 часов назад, и мы потеряли не обработанные заказы за 8 часов. Это критично для бизнеса? Для кого-то — да, для кого-то — нет. А если это, ну, скажем, система регистрации на рейсы крупной авиакомпании. Что произойдет, если эта система ляжет на 1 час? Коллапс в аэропортах всего мира, где работает эта компания.

В каком случае нужно обращаться к DevOps? Это зависит от количества сервисов, которые использует компания?

От количества сервисов, от их надежности, от опасности для бизнеса.

• Что произойдет, если эта система перестанет работать?
• Что произойдет, если в эту систему влезут злоумышленники и начнут пытаться ее ломать, начнут пытаться ее DDoS-ить³?

В некоторых случаях компании имеет смысл иметь NOC-команду⁴, которая будет круглосуточно сидеть, мониторить, смотреть борды, заводить инциденты и в случае чего кого-то будить ночью. Отсюда выходит вопрос, который я уже говорил, это observability — насколько эта система должна мониториться, логироваться и так далее. То есть какие требования предъявляет бизнес?

И, наверное, последний аспект, на какой платформе это все будет запускаться. Если это public cloud, то там есть готовые инструменты, где какой-то сервис просто запустить. А если у компании много продуктов, если это микро-сервисные продукты, то, например, на сегодняшний день стало модно это все запускать в Kubernetes-е. 

СЕРВИСЫ

Что такое Kubernetes?

Kubernetes — это такое детище компании Google, которое имеет огромнейшие возможности, но у него очень высокий порог входа.

Чем обусловлен высокий порог входа?

Google не проектировал эту систему как простую. Google проектировал эту систему, как сложную, но имеющую огромное количество возможностей.

То есть для того, чтобы начать им пользоваться, нужно уже иметь определенный  багаж знаний?

Нужно иметь багаж знаний, как работать с этим оркестратором. Но он предоставляет огромное количество возможностей по запуску сервисов, по автоматическому восстановлению сервисов, если что-то пошло не так, и очень быстрому развертыванию продуктов в Kubernetes.

Но в то же время, Kubernetes — это голая система. Когда поднимаются вопросы, как мы будем туда деплоить продукты, чем мы будем их мониторить, чем мы будем логи собирать, как мы будем хранить секреты? Выясняется, что в Kubernetes надо поставить примерно полтора десятка разных Helm chart-ов для того, чтобы этот Kubernetes кластер стал готовым к работе с production releases. Кстати, это тема моего доклада, которым я готов поделиться с желающими.

Хорошо, а какие еще сервисы ты используешь в своей работе? 

По большей части Kubernetes и все сервисы, которые в него ставятся для мониторинга, логирования, для observability, для правильной работы с секретами. Также, много других продуктов, о которых хорошо наслышаны в мире, различные Jenkins, GitHub и так далее.

ПРОЦЕСС РАБОТЫ

Как выглядит твой рабочий день? 

Сейчас я работаю удаленно. У меня рабочий день ненормированный. У меня могут появиться какие-то срочные задачи, когда что-то пошло не так. Либо у кого-то есть срочный вопрос, а по большей части это архитектурные задачи, которые могут занимать две-три недели. Поэтому я могу начинать работу в разное время дня, даже в зависимости от времени года, когда надо дочку в школу отвозить. Я могу начинать работу в 09:00, заканчивать в 18:00. Когда-то позже, когда-то раньше.

Как у тебя происходит взаимодействие с продуктовой командой? Какое место ты занимаешь в процессе разработки продукта? 

Мы пытаемся давать разработчикам рекомендации, что им нужно сделать, чтобы, например, их продукт можно было правильно, безопасно и безотказно развернуть в кластере. Потому что существует ряд anti-patterns, какие продукты хорошо разворачивать в Kubernetes, а какие лучше там не запускать вообще. Если это legacy монолит, то, возможно, лучше его deploy оформить в Amazon при помощи Ansible.

А кто вам ставит задачи? Как у вас происходит взаимодействие внутри команды? 

У нас небольшая команда DevOps. Я отвечаю за вопросы именно автоматизации, за вопросы разворачивания Kubernetes платформы. Общение происходит очень часто напрямую с заказчиком, с техническими архитекторами заказчика. То есть они что-то хотят, и дальше может происходить длинный процесс переговоров как лучше это сделать. Потому что не всегда, когда заказчик что-то хочет, имеет смысл реализовывать именно так. Сперва есть смысл убедить заказчика, что нужно выбрать иной метод.

На каком языке, как правило, происходит общение с заказчиком? 

На английском. Конечно, его нужно знать на хорошем разговорном уровне. И еще желательно понимать людей из самых разных стран.

Как часто возникает необходимость вечером работать ночами?

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

КАК СТАТЬ DEVOPS

Интересно узнать как стать DevOps? Представь, что я захотела стать DevOps. Что мне для этого нужно сделать? Какой минимальный набор квалификаций я должна иметь?

Знание операционных систем Linux. Какие-то базовые знания в таких продуктах, как Ansible. Было бы хорошо начать изучать Docker, немного Kubernetes. Также, достаточным для начала будет понимание работы одного из трех самых популярных public cloud — AWS, Azure или Google Cloud.

Какие советы ты можешь дать начинающим DevOps-ам или тем, кто хочет им стать? 

Я вижу, что ближайшие несколько лет действительно в тренде будет Kubernetes платформа, ее нужно учить. Для желающих могу посоветовать пройти профильную сертификацию Certified Kubernetes Administrator, как это в свое время сделал я. Мне это очень сильно помогло. Хорошие курсы по подготовке можно найти, например, на Udemy.

Ссылка на курс: https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests

Насколько я помню, сертификацию можно пройти в Кишиневе?

Да, в Кишиневе я сдал очно сертификацию от Amazon, потому что в Кишиневе две компании являются представителями Pearson VUE, и это дает возможность очно сдать практически любой экзамен. Pearson VUE — основной посредник по сертификации, в частности, Amazon.

Какие вопросы обычно задают DevOps на собеседовании?

Обычно у большинства компаний есть заранее заготовленные вопросы, касающиеся стека, который использует компания. Лучше всего задавать ситуационные вопросы. Например: представьте, у вас есть Kubernetes кластер, и у вас перестала отвечать одна нода. Спросите у кандидата о его действиях. Я бы порекомендовал иметь хотя бы одного человека, который уже набил очень много шишек.

Бывают ли тестовые задания на собеседовании для DevOps-ов?

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

В чем оно заключается обычно?

Я, как интроверт, могу на тестовом задании элементарно потеряться, и я могу там такое рассказать. Я не люблю такие задания, когда меня просят тупо шарить экран и чего-нибудь быстренько написать. Да, я теряюсь. Поймите правильно, я не операционный хирург, мне не нужно принимать решение мгновенно. Я такие задания очень не люблю. Я очень люблю на собеседовании вопросы. Например, у нас есть это и это, а как бы вы это реализовали? А что бы вы тут предложили?

ОСОБЕННОСТИ РАБОТЫ DEVOPS-ОМ

Компании, в основном, маленькие по размеру, хотят сэкономить. Что будет, если взять джуниор специалиста?

Как я уже говорил, DevOps-у часто приходится разбираться с проблемами того, что что-то упало. Джуниор специалист вряд ли сможет разобраться в причинах проблем, и в целом настройке всего необходимого.

Есть ли смысл взять консультацию DevOps-а в таком случае?

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

Какой совет ты можешь дать работодателям?

1.Стоит обратить внимание на то, если DevOps стремится работать по overtime или стремится что-то сделать по-быстрее, возможно, это будет не самого лучшего качества.

2. Если вы попросили DevOps спроектировать какую-то архитектуру, от работоспособности которой будет зависеть живучесть продакшена, то не торопите его. И не заставляйте его одновременно заниматься проектированием чего-то в двухнедельном спринте, одновременно заниматься суппортом и отвечать пяти командам на вопросы почему у них что-то не работает? Это значит, вам не хватает DevOps-ов.

3. Вкладывайте деньги в повышение квалификации DevOps, мотивируйте их проходить сертификации, оплачивайте им курсы на Udemy. Например, та компания, в которой я работаю, мотивирует проходить сертификации в Amazon, оплачивает сертификацию и потом выплачивает небольшой бонус.

Как понять, что DevOps приносит пользу компании?

Вспомните очень древнюю пословицу: “Если ваш сисадмин ничего не делает, это хороший сисадмин”. То же самое касается и DevOps-а. А также, про историю о Генри Форде и его способ оплаты работы слесарей. Когда сборочный конвейер Генри Форда работал в комнате у слесарей, крутился счетчик с их зарплатой. Когда конвейер останавливался — останавливался счетчик. Зарплата слесарей зависела от того, работает конвейер или нет. Возможно, это была байка, но у DevOps-а похожая история. Хорошо организованные CI/CD процессы, хорошо построенная система бекапов, хорошо построенная система мониторинга, алертинга — в перспективе экономит время и деньги компании. 

СЧАСТЬЕ DEVOPS СПЕЦИАЛИСТА

Что тебе нравится в твоей профессии? Почему ты этим занимаешься?

Нравится заниматься разработкой архитектуры, проектированием чего-то нового. Больше всего нравится получать от этого всего позитивные результаты, что то, что я спроектировал, работает и не падает.

То есть, счастье DevOps в том, что…

Счастье DevOps в том, что он может хорошо спать по ночам. Потому что проблема DevOps, если что-то случается на продакшне — в первую очередь вспоминают о нем, тк с него все начинается.

---

Сноски:

1. RTO (Recovery Time Objective) или RPO (Recovery Point Objective) являются ключевыми факторами при определении сценариев резервного копирования и аварийного восстановления баз данных. ↩︎
2. Disaster recovery (DR) — это способность организации восстановить доступ и работоспособность ИТ-инфраструктуры после аварийного события, как природного, так и вызванного действиями (ошибками) человека. ↩︎
3. DDoS-атака – это способ заблокировать работу сайта путем подачи большого количества запросов, превышающих пропускную способность сети ↩︎
4. NOC-команда (Network Operating Center) — это команда, которая имеет возможность устанавливать оповещения и отслеживать состояние инфраструктуры 24/7. ↩︎