Я работаю DevOps-инженером в компании Parallels. Поддерживаю развитие разных сервисов, пишу скрипты для их автоматического развертывания, общаюсь вплотную с командой разработчиков. Расскажу, как устроена работа, сколько платят и чем хорош DevOps-подход для разработки ПО.

Все началось с того, что мне стало скучно работать системным администратором, захотелось чего-то нового. Я попробовал заняться разработкой 1С, но довольно быстро понял, что это не мое. Выучил Python, улучшил свои навыки в Unix-системах и отправился на собеседование в Parallels. Тогда я почти ничего не знал про DevOps, просто пришел и сказал: хочу у вас работать. Через два месяца меня взяли.

Что такое DevOps?

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

Истина, как обычно, где-то посередине. DevOps — это все перечисленное, взятое вместе. Его главная задача — ускорить доставку продукта от бизнеса до потребителя. Сам термин был придуман независимым IT-консультантом Патриком Дебуа примерно двенадцать лет назад. Он хотел разрушить метафорическую стену между разработчиками (dev) и сисадминами (ops), объединить их в одно эффективное подразделение, которое может создавать ПО быстрее, выкатывать релизы чаще и с меньшим количеством ошибок.

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



Минутка скучной статистики. По исследованию DORA (DevOps Research and Assessment), кросс-функциональные команды, использующие DevOps-подход:

• в 208 раз чаще развертывают код;
• в 106 раз сокращают время от коммита до развертывания;
• в 2,604 раза быстрее восстанавливают системы после сбоев;
• в 7 раз снижают сам шанс сбоя в результате изменений.

Конечно, само по себе объединение dev и ops не приводит к такой эффективности. DevOps-подход включает в себя использование множества новых инструментов разработки, тестирования и развертывания для организации CI\CD (концепция непрерывной интеграции и доставки). Среди самых известных:

• Git и GitHub — системы управления исходным кодом;
• Jenkins — сервер автоматизации для создания конвейеров CI/CD;
• Docker — ПО для автоматизации деплоя и управления приложениями в средах с поддержкой контейнеризации;
• Kubernetes — открытая система оркестрации контейнеров;
• Chef, Puppet и Ansible — средства для автоматического конфигурирования и развертывания;
• Selenium — решение для автоматизации тестирования;
• Prometheus и Nagios — программы для мониторинга серверов;
• Grafana — решение для сбора и анализа метрик.

При этом универсального набора инструментов, подходящего каждому бизнесу не существует, как и нет единого пути к DevOps. Есть только то, что работает или, наоборот, не работает в вашей инфраструктуре. Я регулярно посещаю конференции и различные мероприятия, общаюсь с коллегами из других компаний и могу сказать, что 80% вещей, которые они используют, в Parallels не особо применимы.

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

Суть работы DevOps-инженера

На базовом уровне DevOps-инженер — это технический специалист, который понимает все основные этапы жизненного цикла разработки ПО, исправляет узкие места в процессах и занимается настройкой среды:

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

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

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

Конкретные обязанности, как и необходимые навыки, сильно зависят от места работы. У нас, в Parallels, много своей инфраструктуры, самые критичные части — не в публичных облаках, а на собственных физических серверах в нескольких дата-центрах. И иногда бывают крупные обновления, касающиеся железа и ПО на этих серверах, а периодически требуется миграция.

Это тоже моя работа

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

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

Это стоит сделать, даже если код приложения не особо активно меняется. Зачем, если все и так работает? Чтобы иметь возможность воспроизвести его при сбое, установить обновления безопасности, найти и исправить проблемы, о которых, возможно, даже никто и не догадывается. Недавно я как раз писал скрипты для такого сервиса с длинной историей. Потребовались изменения в его коде, работа еще не закончена, но прогресс большой. Очень интересно собирать из разрозненных кусков полную картину работы приложения, приятно смотреть потом на результат.

И, конечно, внедрение DevOps-подхода тесно связано с измерением. Насколько изменилось время отклика? Как часто возникают даже предусмотренные ошибки? Раньше системный администратор зачастую не представлял, как можно измерять эти вещи. Приложения были черными ящиками, оставались только самые базовые характеристики: загрузка процессора, потребление памяти, трафик. А при разворачивании новой версии ни сисадмин, ни программист не могли быстро определить, что все пошло не совсем так, как планировалось. Оставалось ждать гневных обращений в техподдержку.

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

Сколько зарабатывают DevOps-инженеры?

Зарплата DevOps-инженера зависит от навыков, места работы и региона проживания. Оклад специалиста, работающего в Москве, самый высокий в России, 130-350 тыс. рублей в месяц. Питерские компании предлагают на этой должности 100–300 тыс. рублей. В остальных регионах нашей страны готовы платить 70–120 тыс. рублей.

Средний годовой доход в Штатах, как говорят некоторые HR, колеблется от 100 до 125 тысяч долларов США, согласно данным, опубликованным компанией Puppet. В Австралии и Новой Зеландии — 75-100 тысяч долларов США. В Европе — 50-75 тысяч долларов США. В Азии DevOps-инженеры получают не больше 25 тысяч долларов США в год.