Олег Миколайченко, DevOps Team Lead в SQUAD в большом интервью для QAGuild рассказывает о прошлом и будущем DevOps в Украине, зарплатах, собеседованиях, росте внутри специализации, обязанностях, и чем DevOps полезен бизнесу. 

Интервью состоялось благодаря покасту Automation Remarks. С оригинальным подкастом можно ознакомиться по ссылке. 

Олег Миколайченко, DevOps Team Lead в SQUAD

Привет Олег! Расскажи о себе, ты настоящий DevOps или все-таки Infrastructure Engineer? 

Всем привет, сразу по поводу правильности термина DevOps, DevOps Engineer, Infrastructure Engineer, Site Reliability Engineer: главное, что мы друг друга понимаем, а называть можете как угодно. 

В двух словах о себе: делаю  дайджесты на DOU, пишу статьи на Habr, AIN.UA,  MC.TODAY,  Kyiv DevOps Community Co-founder и веду Telegram канал на 5k подписчиков. Работал в нескольких крутых компаниях (MacPaw, AnchorFree, Ring Ukraine), сейчас помогаю SQUAD ускорить разработку, настроить процессы и мигрировать ML-related приложения в Amazon. 

Как ты попал в IT?

С 15 лет был эникейщиком (менял картриджи в принтерах) и было непонятно, в какую сторону стоит двигаться. В какой-то момент захотелось получить сертификацию Cisco (CCNA),  и сертификацию от Microsoft - начал читать книжки, смотреть видеокурсы, набрал базовых актуальных знаний,  но деньги за попытку сдачи решил не платить - после анализа рынка это сертификаты выглядели как приятные хотелки, которые не помогут в карьере.

Где-то глубоко на админском форуме появился очень узкий луч света, который шел от DevOps специализаци. Где-то там же была заочка в НАУ на факультете Компьютерных систем. Вакансий тогда  было около 10 во всей Украине, я попробовал почитать о Jenkins + Vagrant и … понравилось!  

В каком году это было?
Около 8 лет назад. За 8 лет рынок очень сильно поменялся:
(1) Серьезное изменение вектора было, когда все начали внедрять CI/CD.  Первым об этом писал Джез Хамбл в книге “Непрерывное развертывание ПО.”

(2) Вторая сильная волна изменений принесла Configuration Management подход, когда большую часть работы можно было описать в коде (Ansible, Chef, Salt).

(3) Третья волна накатила и принесла контейнеры Docker, оркестратор Kubernetes и миллион сервисов, которые с ними связаны. 

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

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

Как найти правильного DevOps в команду, и как выглядит правильный DevOps Engineer? Какую проблему решают DevOps каждый день? 

Проблема, которую решают DevOps инженеры в компании -  это проблема разных приоритетов (Wall of Confusion - ссылка цитату с конференции). 

The Wall of Confusion - Andrew Shafer

Представим ситуацию: у нас есть отдел разработки, и отдел администрирования (упрощенно). У админов первый приоритет - стабильность системы, у разработчиков - скорость разработки.  Очевидно, что скорость разработки и стабильность системы - конфликтующие приоритеты, поэтому появляется дырка в лодке и выражение “проблема не на нашей стороне”.

DevOps методология построена на коммуникации,

и все приоритеты приводятся к одному знаменателю: сделать компанию успешной.

Представьте самое простое бизнес-критикал приложение: разворачивается на одном сервере копированием файлов по FTP. Реально? Очень даже. Но с таким решением далеко не заедешь.  DevOps инженер предложит скейлинг,  улучшение deployment процесса, возможно даже предложит сделать автоскейлинг (перед Black Friday, например). 

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

В прошлой компании мы делали VPN (HotSpot Shield) для 760 миллионов пользователей.  Если бы мы делали single cloud deployment, даже учитывая multi-region - мы все равно зависели бы от одного провайдера. Получается, это такая большая точка отказа (Single point of Failure). Поэтому, со временем получилось так, что у HotSpot Shield более 50 провайдеров.

Это дает такие возможности: 

1. двигаться быстрее

2. масштабироваться по регионам

3. делать более стабильные дорогие (пулы), менее стабильные и дешевые

Как результат - получается предоставлять клиенту лучшее качество за наименьшие деньги. 

Следующая сложность - SLA.  У сервиса может быть бизнес-приоритет и контакт быть доступным 99.999%. Сложность в том, что AWS S3 нам гарантирует 99,999999999% на хранение данных,  а  AWS EC2 всего 99.9%. Мы не можем архитектурно построить такую доступность, и для этого нужно пользоваться практикой multicloud - избыточно разворачивать приложение в нескольких облачных провайдерах.
Это те вещи, которыми DevOps Engineers занимаются каждый день - с ними должен уметь работать “правильный” инженер.

Я понимаю что, как только компания начинает вырастать из стартапа и приходят реальные клиенты, из реального мира -  тут же нужно задумываться о DevOps. Или DevOps нужно внедрять с самого начала, когда у вас еще нет помыслов захватить мир? 

Типичный конвеер доставки - Мартин Фаулер 

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

1. сборка приложения 

2. настройка окружений

3. деплоймент 

4. мониторинг и алертинг 

5. оптимизация стоимости 

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

Приложение без применения принципов DevOps методологии - это Proof of Concept

Если DevOps инженер будет привлечен с самого начала - он обязательно сделает запас прочности и возможности масштабирования + будет строить инфраструктуру как код  + переиспользуемые конвееры (Jenkins Pipelines). Как говорил СТО из стартап акселератора -  приложение без применения принципов DevOps методологии это Proof of Concept.  Поэтому, если где-то рядом уже видно MVP -  рекомендую смотреть в сторону DevOps практик. 

Когда появился DevOps на рынке нашей страны и сколько всего DevOps инженеров в Украине? 

Термин DevOps появился в 2009 году на конференции DevOps Days в Бельгии, его идейный вдохновитель и автор - Джез Хамбл.  Я уже говорил о нем ранее.  
Первые вакансии на рынке Украины появились в 2012-2013 году, а сколько DevOps инженеров - никто не знает. В самом большом сообществе ukrops.club - 3 тысячи участников, в Telegram канале “ДевОпс инженер”, автором которого я являюсь - 5 тысяч. 

Уже можно сформировать примерную картину.
Linkedin по запросу DevOps Engineer находит находит 8 тысяч специалистов в регионе Украина. Получается, мы получаем рамки - более 5000 и менее 8000.
Все 8 тысяч инженеров знают одно и то же - Terraform, AWS, Kubernetes? 

Инженеры совершенно разные, в зависимости от их опыта. Человек может прийти в DevOps из: 

1. администрирования

2. программирования

3. тестирования

Нужно подбирать инженера конкретно под вакансию, и универсальный совет - в вакансии указывать только нужные технологии. Нет смысла описывать в вакансии пол интернета, если у вас 80% работы - это AWS. 

Есть такое убеждение, что в молодые команды тестировщика не берут, т.к. он там особо не нужен будет. Эту ответственность можно переложить на разработчиков.  Достаточно ли в таком случае пригласить консультанта, который расскажет о Terraform, AWS, Jenkins, Docker  - или нужно нанимать даже на начальном этапе? 

Можно ли выжить без DevOps, только силами разработчиков? 

Нужно отталкиваться от результата. Если компания - стартап, мало денег и нужно запуститься любой ценой - лучше не нанимать, а консультироваться. Подобрать нужные инструменты, подходы, и запуститься. Это будет адекватное решение, которое будет работать.
Если компания - молодой и богатый стартап, тогда нужно строить прочный фундамент. Пример для микросервисной архитектуры: 

1. shared CI/CD 

2. shared Jenkins Pipelines 

3. shared Terraform modules 

Конечно, можно вручную запустить EC2 инстанс, а можно сделать модуль, который будет подставлять правильный SSH ключ, конфигурировать Security Group и автоматически добавлять Elastic IP. Также можно делать copy-paste Jenkinsfile между репозиториями, а можно сделать scripted pipline и одной строкой запускать процесс для похожего приложения. 

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

Ок, выглядит так что без DevOps Engineer разобраться невозможно. Может быть есть какая-то простая инфраструктура, где все работает сразу - или это миф?  Какое твое мнение?

Да, например Heroku будет отлично работать. Будет работать, пока программисты и бизнес не столкнуться с ограничениями платформы.

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

Для MVP - отлично, для продукта с 10 пользователями - отлично, для серьезного решения - извините, нет. 

Можно ли прожить без DevOps, как без QA?

В моей практике ни один продукт не обходился без QA. Короткий ответ - можно, если кто-то возьмет на себя задачи по инфраструктуре и фасилитации + получит экспертизу, которую мы обсуждали выше. 

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

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

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

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

Типичные ошибки с неправильными soft skills:

1. в первый день рассказывать, что все сделано неправильно 
2. рассказывать, как нужно делать не увидев всю картину в целом 
3. жевать жвачку на собеседовании, материться, приходить с бодуна и т.п.

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

На собеседование пришел инженер, и предложил запрещенные вещества 

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

Ты на собеседовании не спрашиваешь, как упаковать контейнер в Docker, или как настроить Ansible, а спрашиваешь его о soft skills?

Что значит культура и что значит культурно не подходит?

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

Часто кандидаты критикуют свою прошлую компанию, менеджеров, коллег и т.д. Это также плохой знак. Указывает на проблемы с коммуникацией и неумение договариваться.
DevOps подход - это вместе найти решение проблемы. Не переводить стрелки и ответственность, а вместе делать результат.

SRE books от Google: собрано самое ценное и нужное  

Давай представим что мы уже наняли человека -  как из Junior DevOps стать гуру? Есть какие то рецепты как стать Senior DevOps? И вообще, как стать Junior? Что нужно знать начинающим? 

Первый совет - читать книжки SRE и смотреть митапы CNCF

Первый совет - читать книжки SRE и смотреть митапы CNCF. Бонусный совет - повторять уроки по Linux на DigitalOcean Tutorials. 

Идем дальше: берем Ubuntu, выбираем тулу для Configuration Management (Ansible), выбираем облачный провайдер (AWS), однозначно Docker, и оркестратор - Kubernetes. Дальше крутим и учим в разных вариациях, добавляем книжки из первого совета + читаем Джеза Хамбла и Мартина Фаулера.
Этого будет более чем достаточно, чтобы приносить результаты себе и команде. 

Не нужно думать что получится найти работу сразу, в реальной жизни это будет около 10 компаний для наработки опыта. 11-я компания уже даст оффер. Если получилось быстрее - поздравляю. Важно не складывать руки, а методично обрабатывать фидбек, анализировать и пробовать еще. 

Где потолок для Senior DevOps и куда вырастают крутые DevOps дальше?

Зеркальный потолок есть, но чтобы до него добраться - нужно очень много работать.

Я лично видел пример роста отличного инженера в DevOps Team Lead, через пару лет в Head of Engineering, и дальше в Director of Engineering. Сейчас у него в подчинении более 60 человек, и, я уверен, есть вектор развития в CTO. 

Второй пример - DevOps Team Lead, который ушел в CMO помогать развиваться мониторинг системе, т.к. очень любил мониторинг и имел сильную экспертизу. Это круто. 

Что бы ты посоветовал DevOps Team Lead? Со стороны инженера, и со стороны менеджмента.  

Не нужно воровать победы у своей команды.

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

Реально ли перейти в DevOps из QA Automation, если да, то что нужно сделать?

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

Могу рассказать о окружении, созданном вместе с QA Automation:
1. Задача появляется в Jira 

2. Автоматизация создает git branch  

3. В тестовом Kubernetes кластере создается namespace 

4. Каждый git push автоматически собирается, и деплоится в namespace 

5. Запускаются Selenium тесты 

Это окружение дает максимально быстрый feedback loop и максимальную уверенность в сборке. 

QA Automation будет полезен опытом в автоматизации, всегда у DevOps есть ручные действия, которые просто необходимо автоматизировать. Очень часто QA отлично знают Jenkins/TeamCity, умеют хорошо программировать и даже находить ошибки в коде.

Дальше - больше. Все знают как тестировать изменения в приложении, но никто не знает как тестировать изменения в инфраструктуре. Если в этом помогут QA Automation - будет вообще супер. 

Такой человек принесет очень много велью в DevOps, даст свежий взгляд и это 100% круто.  

Как понять “DevOps отдел”? Ведь DevOps и отделы это невозможно. 

Толсто! Я знаю 2 варианта, как работают DevOps инженеры:

1. как отдельная команда с единой точной входа задач 

2. выделенный инженер в каждой команде 

Для отдельной команды важно соблюдать правила: 

1. единая точка входа задач 

2. работа по приоритетам 

3. обязательно ротация похожих задач между инженерами 

4. вылазки в мир - демо новых подходов, обучение разработчиков, и т.д. 

5. >1 инженера на систему, разделение на primary и secondary ответственного

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

Как ты относишся к инженерам, которые тихо сидят в углу, которых не видно и не слышно? 

Результат работы таких инженеров - это результат работы их менеджера. Менеджер получает все бенефиты, особенно, если DevOps работает методично, предсказуемо, качественно. 

Очень неправильно, когда если все хорошо - Team Lead молодец, а если все плохо - это виновата команда. Так быть не должно. 

Как выглядит стандартный рабочий flow? Как выглядит рабочий процесс? 

В большинстве случаев команды работают по методологии Kanban, т.к. Scrum и планирование - неудобно, особенно во время пожаров. Обязательно должна быть доска, колонки должны отображать реальные этапы работы (а не To Do -> In Progress -> Done), должно быть ограничение WIP (Work In Progress). 

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

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

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

1. делать новый функционал 

2. внедрять новые походы и практики 

3. не забывать о безопасности 

4. чинить баги 

5. проводить обучающие сессии и демо 

6. тушить пожары 

С тушением пожаров может помочь выделенная команда Support Èngineer которые смогут чинить простые ошибки по runbook и инструкциям, но такие команды есть только у избранных. 

Сколько может заработать DevOps Engineer?

Статистика зарплаты на DOU для DevOps инженера с опытом 6+ лет

Если это первая работа, и инженер только начинает понимать что тут происходит -  около 500$ - это норма. В целом, Strong Junior DevOps Engineer, если умеет работать сам, то может зарабатывать до 1500$. 

Если больше $1500 - считается уже Middle уровень, и где-то до $3500 в месяц. 

Senior уровень это  3500+ и выше. Расти можно где-то до 6000$, дальше - нужно приносить действительно много deliveries, которые влияют на бизнес.

Градация Junior/Middle/Senior абсолютно условная, и ей пользуются для того, чтобы платить меньше

С моей точки зрения градация Junior/Middle/Senior абсолютно условная, и ей пользуются для того, чтобы платить меньше. Очень часто ищут Middle, а в требованиях - Senior. Неприятно.  

Я писал статью с  аналитикой по зарплатам для MC.TODAY по результатам опросов на  dou.ua - они есть в формате csv на GitHub.  Из 200 анкет около 30 были с зарплатами $5000+, и несколько  ребят которые зарабатывали $8000+. В целом, это price рокстаров. 

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

Вероятно, в первую очередь из-за COVID-19 сократят тестировщиков, а DevOps сокращать  не должны. Как часто увольняют или сокращают DevOps инженеров?

DevOps инженеры в группе риска, потому что зарабатывают больше медианы рынка. Компенсация в $5000-$6000 для DevOps инженера уже считается адекватной.  Могут сокращать команды, оставляя менее квалифицированных ребят на поддержку.

С увольнениями со стороны компании я не сталкивался - люди растут быстрее компаний, и получить увольнение - нужно постараться. Совсем не работать, обманывать, сделать security bridge - так да, можно нарваться на увольнение. 

Как работает взаимозаменяемость DevOps и легко ли заменить одного инженера на другого?

Тяжело, но сильно зависит от окружения.  Если работа задокументирована, архитектура нарисована, а  инфраструктура описана в Terraform - легко. 

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

Если инженеры специально создают bus factor и делают завязку на себя во всех процессах, в таком случае ответ - практически невозможно. Но это уже проблема менеджмента. 

Понятно, а что делать, чтобы не уволили? Например, я как DevOps инженер - что могу сделать, чтобы меня не сократили и не уволили? 

Главный совет - приходить к бизнесу (С-level) и спрашивать “А что тебе сейчас важно, что тебе сейчас нужно?”.  Понять, что для компании важно сейчас, в условиях кризиса. 

“Работает - не трогай” - это для админов. 

“Работает - трогай, чтобы работало лучше” - это для нас, это DevOps

Можно самому начать процесс Cost Optimization - сократить количество серверов, оптимизировать ресурсы, отказаться от ненужных подписок и.т.п. Я уверен на 100%, что у каждого, кто это читает - можно сделать review и удалить несколько больших серверов, о которых все забыли (но за которые все равно нужно платить). 

Особенно это относится к серверам, которые передаются из поколения в поколение как артефакт, и все боятся их трогать. “Работает - не трогай” - это для админов. “Работает - трогай, чтобы работало лучше” - это для нас, это DevOps.  

Если прийти к СТО с формулировкой - мы сами решили сократить траты на инфраструктуру, оптимизировали в этих двух местах и отказались от 1, 2, 3 ненужных сервисов - вас не уволят, а дадут премию. Это очень сильная позиция. 

Всегда могут быть приоритеты, которые вы не видите - например, запустить быстро новый MVP или отказаться от дорогой интеграции. Люди - основная ценность компании. 

Возможно ли на Microsoft stack работать с DevOps, или лучше не даже не пробовать?

Я отношусь с пониманием к  реализации DevOps методологии, которую пытаются сделать на инфраструктуре Microsoft. Более того, я уверен что сейчас есть достаточное  количество инструментов (Azure, Powershell, etc) и практик которые позволяют это делать. Но я бы лично не хотел этим заниматься.

Что изменилось в DevOps за то время которое ты работаешь на рынке Украины? 

С развитием стало намного интереснее, задач больше и они сложнее, delivery также больше и масштабнее. Сейчас компании с самого начала хотят масштабируемую инфраструктуру и Kubernetes, хотят контейнеры и Infrastructure as Code. Появилось огромное количество подходов для логирования (EFK),  мониторинга (Prometheus stack + long-term storage) - это супер круто. Индустрия развивается, и DevOps вместе с ней. 

Появились классные локальные конференции - DevOps Days Kyiv, XPdays, DevOpsStage, Highload fwdays.

Подтянулись зарплаты. 

Появилось огромное количество возможностей развиваться и учиться, которого не было семь лет назад. CNCF митапы и Kubernetes & Cloud Native Group Kyiv.  

Блог “Девопс Инженер” стал лидером мнений.
DevOps дайджесты выходят постоянно, и их читают. 

Интервью состоялось благодаря покасту Automation Remarks. Если вам понравилось интервью - лучшей благодарностью будет подписка на сообщество Automation Remarks и Сергея Пирогова на Patreon.