Привет, Хабр! Сегодня поговорим о DevOps-ах. Эту тему здесь обсуждают довольно часто — все потому, что самой специальности всего несколько лет. Об истории этого направления на Хабре уже публиковали статьи, поэтому повторяться не буду. Сегодня хотелось бы показать, кто такой DevOps с наглядной демонстрацией кейсов в компании, где я работаю. Меня зовут Александр Крючков, я ведущий инженер DevOps в Группе «Иннотех», и о том, чем занимаются девопсы, знаю не понаслышке. Поехали!
Чем занимается DevOps?
Если коротко, то DevOps объединяет в работающую систему разработчиков, которые создают какой-то продукт, инженеров, которые занимаются поддержкой этого продукта, и, собственно, сам продукт и технологии.
Ну а если подробнее, DevOps-инженеры следят за жизненным циклом продукта с момента его появления и до завершения поддержки. Они оптимизируют разработку, поддержку, увеличивают эффективность работы системы в целом. Это комплексная, системная работа, которую кто-то обязательно должен выполнять. Просто представьте себе более-менее крупную компанию, в команде которой меняются разработчики, инженеры, менеджеры и т.п. Кто-то приходит, кто-то увольняется, а ведь непрерывность бизнес-процессов, разработки и поддержки продукта никто не отменял.
И вот для того, чтобы продукт — сервис, игра, софт и т.п. всегда работал одинаково хорошо, и нужны DevOps-инженеры.
Задач у DevOps немало, и это только критически важные, есть и масса других, которые связаны с основными. Вот эти главные задачи:
● Создание необходимых для разработки ПО, сервисов или игр (нужное подчеркнуть) технологических инструментов, а также разворачивание инфраструктуры.
● Автоматизация процессов. Это может быть автоматизация тестирования продукта. На всех этапах работы продукт необходимо тестировать. Этим, конечно же, занимаются профильные специалисты, но DevOps-инженеры помогают им автоматизировать и оптимизировать процесс.
● Работа с облачными сервисами и технологиями, которые нужны компании. Здесь важно следить как за рабочими процессами, так и за безопасностью облачной среды.
● Интеграция различных компонентов и модулей в продукт. Если компания разрабатывает большой проект или сразу несколько таких проектов, то часто возникает необходимость добавления различных модулей в продукт. А это означает тестирование, анализ работоспособности всей системы, проверку безопасности и т.п.
● Общая поддержка процессов, связанных с продуктом компании.
Но список нельзя считать некими устоявшимися стандартами. Все это более-менее общая информация. Задачи девопсов в разных компаниях могут различаться, и довольно сильно. Вот, например, еще один список, правда, уже небольшой. Это то, что делают DevOps-инженеры в «Иннотех»:
● Работают над инфраструктурой для разработки и тестирования (тесная интеграция всех инструментов разработки).
● Помогают командам разработки выстроить процессы сборки и поставки собранных артефактов, а также в написании высокодоступного, высокопроизводительного решения (Service Mesh, Ingress Controllers etc).
● Участвуют в нагрузочном тестировании новых подходов и технологий для дальнейшего использования в разработке.
Понятно, что профессионал, который способен все это выполнять, должен знать и уметь кучу вещей. Об этом и поговорим ниже.
Что должен знать специалист, чтобы справляться с задачами DevOps-инженера
Девопс-инженер, без преувеличения, должен быть продвинутым эрудитом из мира IT, который неплохо разбирается во многих системах и знает, хотя бы и поверхностно, несколько языков программирования. Кроме того, инженер должен оперативно решать задачи и проблемы, возникающие по ходу работы. Его можно назвать универсальным солдатом, способным делать все и еще немножко.
Вот то, что совершенно точно должен знать девопс-инженер:
● Различные операционные системы. С ними нужно не просто уметь работать, а разбираться в принципах организации и базовых принципах архитектуры. Это нужно для того, чтобы понимать, как будет работать продукт компании на разных платформах.
● Программирование. Без этого никуда — нужно знать несколько ЯП. Какие-то можно знать глубже, какие-то более поверхностно, но одним языком здесь не обойтись.
● Работа со скриптами. Как и в случае языков программирования, требуется понимать и уметь пользоваться скриптовым языком, а то и несколькими. Очень желательно знать несколько скриптовых языков, если продукт компании кроссплатформенный.
● Знать принципы работы и уметь обращаться с инструментами виртуализации и контейнеризации.
А вот то, что должны знать инженеры по DevOps в «Иннотех»:
● Навыки в области computer science, сетевого взаимодействия (на уровне администратора).
● Лучшие практики работы с кодом (merge requests etc)
● Умение работать с одним (желательно несколькими) целевыми инструментами для разработчика.
Всего три пункта, но насколько они обширны на самом деле, знают только сами девопсы — «стеклянного потолка» в профессиональном развитии здесь просто нет.
Ну и для того, чтобы окончательно прояснить вопрос, привожу список навыков, которые чаще всего указывают DevOps-инженеры на Хабр Карьере.
Да, еще моментик — крайне важно, чтобы девопс-инженер понимал и основы бизнеса своей компании, для того чтобы осознавать потребности компании.
Всем ли нужны девопсы? Не-а
Специалисты такого класса нужны, в основном, тем компаниям, которые разрослись настолько, что внутри начинают возникать проблемы с коммуникацией и взаимодействием различных отделов. Какие это проблемы? Давно наболевшие, в дискуссиях о которых на Хабре сломано так много копий. Например, менеджеры, отвечающие за развитие бизнеса, слабо взаимодействуют с отделом разработки. Нарушаются процессы, срываются сроки выполнения задач, частенько начинаются конфликты в команде. Вот здесь девопсы очень нужны.
А вот небольшим и средним компаниям стоит воспользоваться услугами консультантов — им далеко не всегда нужны на постоянку девопс-инженеры. Если команды небольшие и нормально взаимодействуют, то DevOps вряд ли нужен.
Еще один важный момент. Нужно иметь в виду, что просто взять и нанять девопса может быть недостаточно. Сначала требуется провести работу по модификации принятых в компании процессов. Нужно внедрять методы и подходы DevOps, без них даже очень хорошему специалисту будет очень сложно что-то сделать.
В идеальном варианте после внесения изменений внутри компании должен использоваться принцип «один за всех и все за одного». Это когда все команды и отдельные сотрудники осознают ответственность за работу над продуктом. А если что-то идет не так, не перекладывают вину друг на друга. Как бы там ни было, DevOps-инженер может решить эти проблемы и сделать работу компании более эффективной.
Зачем девопс-инженеры понадобились Группе «Иннотех»? Как раз была достигнута «точка бифуркации», когда бурно начало развиваться и расширяться все и вся. Вот парочка примеров:
● При реализации программы разработки инноваций для заказчика, в которой потребовался взрывной рост команд разработки по современным методологиям, включая практики DevOps/DevSecOps.
● Столкнулись с проблемой Configuration drift и потенциальным появлением серверов-снежинок.
Где их взять-то, DevOps-инженеров?
Есть несколько вариантов найти хорошего специалиста:
● Найти готового профессионала с полным набором софт- и хард-скилов. IT-специалисты достаточно часто меняют место работы, поскольку ищут интересные проекты и, конечно, хорошие условия. Это можно, но сложно.
● Найти IT-специалиста, который не является DevOps-инженером, но обладает почти полным набором компетенций для этой специальности. Это могут быть системные администраторы с бэкграундом программирования или программисты со знанием основ системного администрирования.
● Вырастить специалиста у себя, взяв новичка, который хотел бы стать девопс-инженером. Этот пункт почти не отличается от предыдущего, разница только в том, что человек уже внутри компании, понимает и принимает корпоративную культуру.
Мы выбрали второй путь. Пригласили полуготовых девопсов, а потом развивали их в сторону реализации выбранной стратегии, которая получена за несколько лет предыдущего опыта разработки ПО. Подготовленные специалисты находятся максимально близко к разработчикам, но не внутри команд. Обычно они работают с 2-3 командами, за некоторыми исключениями. Кроме того, допустимо предоставление DevOps-инфраструктуры как сервис для команд разработки со стороны ИТ-подразделения, но этот сервис должен отличаться высоким уровнем SLA и компетенциями сотрудников.
Нам кажется, что это хорошая стратегия (можно спорить, конечно, если у вас другое мнение — давайте обсудим в комментариях). До того, как набирать специалистов, мы подготовили DevOps-стратегию, которая основывалась на предыдущем опыте сотрудников и позволила не набивать «шишек». Ну а подготовленные внутри компании девопс-инженеры в процессе обучения адаптировались к условиям организации и достаточно быстро вливались в рабочие процессы. И все прошло гладко — процессы оптимизированы, «бутылочные горлышки» ликвидированы, работа отлажена.
Было бы интересно услышать ваше мнение — какие проблемы, на каком этапе и как вы решали, вводя в команду девопсов?
