Привет, Хабр! Сегодня поговорим о 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-стратегию, которая основывалась на предыдущем опыте сотрудников и позволила не набивать «шишек». Ну а подготовленные внутри компании девопс-инженеры в процессе обучения адаптировались к условиям организации и достаточно быстро вливались в рабочие процессы. И все прошло гладко — процессы оптимизированы, «бутылочные горлышки» ликвидированы, работа отлажена.  Было бы интересно услышать ваше мнение — какие проблемы, на каком этапе и как вы решали, вводя в команду девопсов?