Олег Миколайченко, 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 провайдеров.
Это дает такие возможности:
двигаться быстрее
масштабироваться по регионам
делать более стабильные дорогие (пулы), менее стабильные и дешевые
Как результат - получается предоставлять клиенту лучшее качество за наименьшие деньги.
Следующая сложность - SLA. У сервиса может быть бизнес-приоритет и контакт быть доступным 99.999%. Сложность в том, что AWS S3 нам гарантирует 99,999999999% на хранение данных, а AWS EC2 всего 99.9%. Мы не можем архитектурно построить такую доступность, и для этого нужно пользоваться практикой multicloud - избыточно разворачивать приложение в нескольких облачных провайдерах.
Это те вещи, которыми DevOps Engineers занимаются каждый день - с ними должен уметь работать “правильный” инженер.
Я понимаю что, как только компания начинает вырастать из стартапа и приходят реальные клиенты, из реального мира - тут же нужно задумываться о DevOps. Или DevOps нужно внедрять с самого начала, когда у вас еще нет помыслов захватить мир?
Желательно - как можно раньше, меньше нужно будет переделывать. Если нет денег - лучше воспользоваться консалтингом. В таком случае, все необходимые процессы запустятся с самого начала максимально дешево:
сборка приложения
настройка окружений
деплоймент
мониторинг и алертинг
оптимизация стоимости
Обязательно должна быть заложена масштабируемость - в случае роста пользователей или взрывного роста трафика стартап должен зарабатывать деньги.
Приложение без применения принципов 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 из:
администрирования
программирования
тестирования
Нужно подбирать инженера конкретно под вакансию, и универсальный совет - в вакансии указывать только нужные технологии. Нет смысла описывать в вакансии пол интернета, если у вас 80% работы - это AWS.
Есть такое убеждение, что в молодые команды тестировщика не берут, т.к. он там особо не нужен будет. Эту ответственность можно переложить на разработчиков. Достаточно ли в таком случае пригласить консультанта, который расскажет о Terraform, AWS, Jenkins, Docker - или нужно нанимать даже на начальном этапе?
Можно ли выжить без DevOps, только силами разработчиков?
Нужно отталкиваться от результата. Если компания - стартап, мало денег и нужно запуститься любой ценой - лучше не нанимать, а консультироваться. Подобрать нужные инструменты, подходы, и запуститься. Это будет адекватное решение, которое будет работать.
Если компания - молодой и богатый стартап, тогда нужно строить прочный фундамент. Пример для микросервисной архитектуры:
shared CI/CD
shared Jenkins Pipelines
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:
- в первый день рассказывать, что все сделано неправильно
- рассказывать, как нужно делать не увидев всю картину в целом
- жевать жвачку на собеседовании, материться, приходить с бодуна и т.п.
С человеком должно быть приятно работать, он должен знать 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 инженера на систему, разделение на primary и secondary ответственного
Вторым вариантом мало кто пользуется, т.к. все хотят работать в команде, и никто не хочет быть единственным DevOps.
Как ты относишся к инженерам, которые тихо сидят в углу, которых не видно и не слышно?
Результат работы таких инженеров - это результат работы их менеджера. Менеджер получает все бенефиты, особенно, если DevOps работает методично, предсказуемо, качественно.
Очень неправильно, когда если все хорошо - Team Lead молодец, а если все плохо - это виновата команда. Так быть не должно.
Как выглядит стандартный рабочий flow? Как выглядит рабочий процесс?
В большинстве случаев команды работают по методологии Kanban, т.к. Scrum и планирование - неудобно, особенно во время пожаров. Обязательно должна быть доска, колонки должны отображать реальные этапы работы (а не To Do -> In Progress -> Done), должно быть ограничение WIP (Work In Progress).
Если появляется супер приоритетная задача, например, быстро поднять новый регион в Австралии, потому что маркетинг компанию запускают в конце недели - делают задачу с наивысшим приоритетом.
Первый свободный инженер берет с доски самую приоритетную задачу. Нужно не забывать о техническом долге, делать Feature Freeze и давать команде время подпилить напильником шероховатости.
У меня был опыт работы по Scrum - с планированием, оценкой сложности и резервом времени на тушение пожаров - это было реально сложно. Нужно успевать делать слишком много сразу:
делать новый функционал
внедрять новые походы и практики
не забывать о безопасности
чинить баги
проводить обучающие сессии и демо
тушить пожары
С тушением пожаров может помочь выделенная команда 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.
0 комментариев
Добавить комментарий