devops engineer кто это такой
Кто такие DevOps?
На данный момент это чуть ли не самая дорогая позиция на рынке. Суета вокруг «DevOps» инженеров превосходит все мыслимые пределы, а тем хуже с Senior DevOps инженерами.
Я работаю руководителем отдела интеграции и автоматизации, угадайте английскую расшифровку — DevOps Manager. Отражает ли именно английская расшифровка нашу повседневную деятельность — вряд ли, а вот русский вариант в данном случае более точен. По роду моей деятельности, естественно, что мне, необходимо собеседовать будущих членов моей команды и, за прошедший год, через меня прошло человек 50, а еще столько же срезалось на прескрине с моими сотрудниками.
Мы все еще находимся в поиске коллег, потому как за лейблом DevOps прячется очень большая прослойка разного рода инженеров.
Все написанное ниже является моим личным мнением, вы не обязаны соглашаться с ним, однако допускаю, что внесет оттенок в ваше отношение к теме. Несмотря на риск попасть в немилость, я публикую свое мнение, поскольку считаю что ему есть место быть.
Компании по-разному понимают кто такие DevOps инженеры и ради быстрого найма ресурса вешают этот лейбл всем. Ситуация достаточно странная, поскольку компании готовы платить нереальные вознаграждения этим людям, получая за них, в большинстве случаев, админа-тулзиста.
Так кто же такие DevOps инженеры?
Давайте начнем с истории появления — Development Operations появился как еще один шаг к оптимизации взаимодействия в малых командах для повышения скорости производства продукта, как ожидаемое следствие. Идея заключалась в том, чтобы усилить команду разработки знаниями о процедурах и подходах в управлении продуктовой средой. Иными словами, разработчик должен понимать и знать как его продукт работает в тех или иных условиях, должен понимать как деплоить его продукт, какие характеристики среды подкрутить, чтобы повысить производительность. Так, в течение некоторого времени, появились разработчики с DevOps подходом. DevOps разработчики писали скрипты сборки и упаковки для упрощения своей деятельности и работоспособности продуктивной среды. Однако, сложность архитектуры решений и взаимное влияние компонентов инфраструктуры с течением времени начало ухудшать рабочие показатели сред, с каждой итерацией требовались все более глубокие понимания тех или иных компонентов, снижая продуктивность самого разработчика из-за дополнительных затрат на понимание компонентов и тюнинга систем под конкретную задачу. Собственная стоимость разработчика росла, стоимость продукта вместе с ним, резко подскочили требования к новым разработчикам в команде, ведь им необходимо было также покрывать обязанности «звезды» разработки и, естественно, «звезды» становились все менее доступны. Также стоит отметить, что, по моему опыту, мало кому из разработчиков интересна специфика обработки пакетов ядром операционной системы, правила маршрутизации пакетов, аспекты безопасности хоста. Логичным шагом было привлечь администратора, который именно с этим знаком и возложить подобного формата обязанности именно на него, что, благодаря его опыту, позволило достичь тех же показателей меньшей стоимостью в сравнении со стоимостью «звезды» разработки. Таких администраторов помещали в команду и основной его задачей было управление тестовыми и продуктивными средами, на правилах конкретно взятой команды, с ресурсами выделенными именно этой команде. Так, собственно, и появились DevOps в представлении большинства.
Частично или полностью, со временем, данные системные администраторы начали понимать потребности именно этой конкретной команды в области разработки, как упростить жизнь разработчикам и тестировщикам, как выкатить обновление и не остаться ночевать в пятницу в офисе, исправляя ошибки деплоя. Время шло, теперь «звездами» становились системные администраторы, понимающие чего хотят разработчики. С целью минимизации импакта начали подтягиваться утилиты управления, все вспомнили старые и надежные методы изоляции уровня ОС, которые позволяли минимизировать требования по безопасности, управлению сетевой части, да и конфигурации хоста в целом и, как следствие снизить требования к новым «звездам».
Появилась «замечательная» вещь — docker. Почему замечательная? Да только лишь потому, что создание изоляции в chroot или jail, равно как OpenVZ, требовало нетривиальных знаний ОС, в контру утилите позволяющей элементарно создать изолированную среду приложения на неком хосте со всем необходимым внутри и передать бразды правления разработке вновь, а системному администратору управлять только лишь одним хостом, обеспечивая его безопасность и высокую доступность — логичное упрощение. Но прогресс не стоит на месте и системы вновь становятся все сложнее и сложнее, компонентов все больше и больше, один хост уже не удовлетворяет потребностям системы и необходимо строить кластеры, мы вновь возвращаемся к системным администраторам, которые способны построить данные системы.
Цикл за циклом, появляются различные системы упрощающие разработку и/или администрирование, появляются системы оркестрации, которые, ровно до тех пор, пока не требуется отойти от стандартного процесса, просты в использовании. Микросервисная архитектура также появилась с целью упрощения всего описанного выше — меньше взаимосвязей, проще в управлении. В своем опыте я не застал полностью микросервисную архитектуру, я бы сказал 50 на 50 — 50 процентов микросервисов, черные коробки, пришло на вход, вышло обработанное, другие 50 — разодранный монолит, сервисы неспособные работать отдельно от других компонентов. Все это вновь наложило ограничения на уровень знаний как разработчиков, так администраторов.
Подобные «качели» уровня экспертных знаний того или иного ресурса продолжаются и по сей день. Но мы немного отвлеклись, есть немало моментов которые стоит осветить.
Build Engineer/Release Engineer
Весьма узкоспециализированные инженеры, появившиеся как средство стандартизации процессов сборки ПО и его релизов. В процессе введения повального Agile казалось бы они перестали быть востребованы, однако это далеко не так. Эта специализация появилась как средство стандартизации именно сборки и поставки ПО в промышленных масштабах, т.е. используя стандартные техники для всех продуктов компании. С появлением DevOps разработчиков частично утратили функции, поскольку именно разработчики стали подготавливать продукт к поставке, а учитывая изменяющуюся инфраструктуру и подход в максимально быстрой поставке без оглядки на качество со временем превратились именно в стопор изменений, поскольку следование стандартам качества неизбежно замедляет поставки. Так, постепенно, часть функционала Build/Release инженеров перекочевала на плечи системных администраторов.
Ops’ы такие разные
DevOps — (в теории) персона, не понаслышке понимающая все процессы цикла разработки — разработку, тестирование, понимающая архитектуру продукта, способная оценить риски безопасности, знакомая с подходами и средствами автоматизации, хотя бы на высоком уровне, помимо этого понимающая также пред и пост-релизную поддержку продукта. Персона способная выступать адвокатом как Operations, так Development, что позволяет выстроить благоприятное сотрудничество между этими двумя столпами. Понимающая процессы планирования работ командами и управления ожиданиями заказчика.
Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.
Так ли это в вашей компании? — Сомневаюсь. В большинстве случаев это или IT, или R&D.
Недостаток средств и возможности влияния хотя бы на одно из этих трех направлений деятельности произведет смещение веса проблем в сторону где эти изменения проще применить, как например применение технических ограничений на релизы в связи с «грязным» кодом по данным систем статического анализатора. То есть когда PMO устанавливает жесткий срок на выпуск функционала, R&D не может выдать качественный результат в эти сроки и выдает его как может, оставив рефакторинг на потом, DevOps относящийся к IT, техническими средствами блокирует релиз. Недостаток полномочий на изменение ситуации, в случае с ответственными сотрудниками ведет к проявлению гиперответственности за то, на что они не могут повлиять, тем паче если эти сотрудники понимают и видят ошибки, и как их исправить — «Счастье в неведении», и как следствие к выгоранию и потери этих сотрудников.
Рынок DevOps ресурсов
Давайте рассмотрим несколько вакансий на позицию DevOps от разных компаний.
Резюмируя по данной вакансии можно сказать, что ребятам достаточно Middle/Senior System Administrator.
Кстати, не стоит сильно разделять админов на Linux/Windows. Я конечно понимаю, что сервисы и системы этих двух миров различаются, но основа у всех одна и любой уважающий себя админ знаком как с одним, так и с другим, и даже если не знаком, то для грамотного админа не составит труда ознакомится с этим.
Рассмотрим иную вакансию:
Резюмируя — Middle/Senior System Administrator
Хотелось бы также оставить ремарку относительно 3 пункта, дабы укрепить понимание, почему этот пункт покрывается сисадмином. Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все. Для примера возьмем ‘build framework’ Make, коего фреймворком я, к слову, не считаю. Да, я знаю про моду пихать Make куда угодно, где нужно и не нужно — обернуть Maven в Make например, серьезно?
По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s.
Однажды, я собеседовал парня, который использовал k8s в своей работе поверх OpenStack, и он рассказывал как развертывал сервисы на нем, однако, когда я спросил именно про OpenStack, оказалось, что он администрируется, равно как и подымается системными администраторами. Вы правда думаете, что человек поднявший OpenStack вне зависимости от того какую платформу он использует позади него не способен использовать k8s?=)
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.
Резюмируем в очередной раз — Middle/Senior System Administrator им будет достаточно.
Сколько вешать в граммах
Разброс предлагаемых зарплат для указанных вакансий — 90к-200к
Теперь хотелось бы провести параллель между денежными вознаграждениями Системных Администраторов и DevOps Engineers.
В принципе, для упрощения можно грейды по опыту работы раскидать, хоть это и не будет точным, для целей статьи хватит.
Сайт поиска сотрудников предлагает:
System Adminsitrators:
По стажу «DevOps»’ов использовался стаж, хоть как то затрагивающий SDLC.
Из вышеозначенного следует, что на самом деле компаниям не нужны DevOps’ы, а также что они могли сэкономить не менее 50 процентов от изначально запланированных затрат, наняв именно Администратора, более того, они могли бы четче определить обязанности искомого человека и быстрее закрыть потребность. Не стоит также забывать, что четкое разделение ответственности позволяет снизить требования к персоналу, а также создать более благоприятную атмосферу в коллективе, ввиду отсутствия пересечений. В подавляющем большинстве вакансии пестрят утилитами и DevOps лейблами, однако не имеющие в основе действительно требования к DevOps Engineer, лишь запросы на тулзового администратора.
Процесс обучения DevOps инженеров также ограничен лишь набором специфичных работ, утилит, не дает общего понимания процессов и их зависимостей. Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.
Спрос, однако, порождает предложение, и мы видим крайне перегретый рынок позиции DevOps, где требования не соответствуют реальной роли, а лишь позволяют системным администраторам зарабатывать больше.
Так кто же они? DevOps’ы или жадные системные администраторы? =)
Как дальше жить?
Работодателям — точнее формулировать требования и искать именно тех кто нужен, а не разбрасываться лейблами. Вы не знаете чем занимаются DevOps — они вам не нужны в таком случае.
Работникам — Учиться. Постоянно совершенствовать свои знания, смотреть на общую картину процессов и отслеживать путь к поставленной цели. Можно стать кем захочешь, надо лишь постараться.
Кто такой DevOps-инженер?
Эксперт в DevOps и Linux.
DevOps-инженер — связующее звено между всеми этапами создания продукта: от написания кода до релиза. Спрос на его труд растет из года в год, и даже младший специалист может рассчитывать на зарплату от 100 тыс. рублей. Мы попросили DevOps-инженера из Ростелекома, а также автора одноименного курса в SkillFactory Вячеслава Светлова разложить для нас его профессию по полочкам.
Что такое DevOps?
DevOps — это набор практик на стыке системного администрирования (Ops — Operations) и разработки (Dev — Development).
До внедрения DevOps при создании приложения целью группы разработки было написание кода, а группы инфраструктуры — поддержка всех серверов в работоспособном состоянии.
Если возникала проблема, инженер инфраструктуры мог сказать: «С сервером все в порядке, проблема с кодом, дальше разбираться я не буду, проблема не моя», — а разработчик говорил: «На моем компьютере этот код работает, проблема с сервером, дальше разбираться я не буду, это не моя зона ответственности».
С приходом DevOps-инженера вся команда фокусируется на единой цели — создании качественного продукта.
Без DevOps-культуры в компании может практиковаться ручное тестирование, ручное управление инфраструктурой, могут возникать конфликты в частях кода, написанных разными разработчиками. В итоге бизнес получит низкое качество продукта, низкую скорость вывода продукта на рынок, демотивированных сотрудников, вынужденных большую часть времени тратить на рутинные задачи и сложности при масштабировании.
Что делает DevOps-инженер?
DevOps-инженер синхронизирует все этапы создания программного продукта: от написания кода до тестирования и релиза.
Это профессионал, имеющий широкие знания в IT и понимающий, как прийти к конечному продукту. Он хорошо разбирается в инфраструктуре, понимает принципы разработки приложений и построения их архитектуры. Еще он — менеджер-практик, знающий жизненный цикл приложения и современные методологии разработки.
А можно на простом примере?
Есть два друга, которые хотят пожарить мясо на природе. Итоговый продукт их деятельности — шашлык. Друзья распределяют между собой задачи: один нанизывает мясо на шампур (сравним его с разработчиком), другой собирает мангал и разводит огонь (сравним его с инженером инфраструктуры).
Угли готовы, мясо на шампурах, положили шампуры на мангал — ждут. Но пошел дождь, надо перенести мангал под тент, чтобы угли не потухли. Одному это сделать трудно, дождь усиливается.
Без DevOps-культуры разработчик (отвечающий за нанизывание мяса на шампуры) может сказать: «Мясо на шампурах — моя работа сделана. Дальше разбираться я не буду», — и в итоге шашлыка никто не поест.
DevOps-инженер — это третий друг, который заранее посмотрел прогноз погоды, понял, что будет дождь, взял с собой тент, развернул его и, когда погода испортилась, помог перенести мангал с мясом под тент. В итоге все насладились вкусным мясом (выпустили качественный продукт).
Где нужен DevOps?
DevOps-инженеры нужны в компаниях, которые разрабатывают ПО для себя или на заказ. При этом сферы могут быть самые разные: медицина, транспорт, спорт, автомобили и пр.
Что ему нужно знать?
DevOps-инженер — многопрофильный специалист, и для успешной работы ему необходимо разбираться в нескольких IT-направлениях. Требования к нему в разных компаниях отличаются, но база для всех примерно такая:
Какие нужны софт-скилы?
Помимо хорошего технического кругозора и навыков автоматизации DevOps-инженеру крайне необходимо развивать софт-скилы, которые помогут синхронизировать работу всех участников и подразделений.
Особенно требуется умение работать в команде, поскольку DevOps-культура в целом подразумевает довольно плотное общение между командой разработки и командой инфраструктуры. Часто для получения конечного результата надо уметь находить компромиссы.
Насколько это востребовано и сколько получает DevOps-инженер?
IDC прогнозирует, что количество специалистов DevOps с 2019 по 2024 год возрастет в два раза. Ожидается, что к 2024 году минимум 30% компаний внедрят полноценный цикл DevOps.
По данным Research and Markets сфера DevOps переходит из нишевого инструмента в глобальный рынок, который имеет просто колоссальный потенциал для роста. За период карантина в 2020 году рынок вырос на 29,3%.
В марте 2021 года на сайте hh.ru было более 4,3 тыс. вакансий DevOps-инженера.
Можно заметить рост популярности запроса «devops» и других запросов по теме на графиках от сервиса Google Trends.
Зарплата зависит от компании и навыков. Младший специалист DevOps в Москве получает от 70 до 150 тыс. рублей в месяц, а зарплата ведущего составляет примерно 250 тыс. рублей. По данным Хабр Карьеры, во втором полугодии 2020 года средняя медианная зарплата специалиста DevOps составила 155 тыс. рублей.
На сайте hh.ru можно найти вакансии с зарплатой более 400 тыс. руб. в месяц. Больше всего вакансий предполагают доход от 105 тыс. до 265 тыс. рублей.
Плюсы и минусы профессии
Освойте перспективную IT-профессию на стыке разработки, системного администрирования и бизнеса. Дополнительная скидка 5% по промокоду BLOG.
Чем DevOps отличается от Agile?
Agile — обобщающий термин для целого набора принципов, подходов и практик, основанных на ценностях гибкой разработки. Такую методологию применяют для организации труда небольших групп. Она нацелена на минимизацию рисков при работе с помощью разделения разработки на короткие циклы, каждый из которых выглядит как отдельный конечный проект. Каждый из этапов обычно включает в себя спектр задач: планирование, анализ требований, проектирование, программирование, тестирование и документирование.
В отличие от Agile, DevOps предполагает разработку методологии, позволяющей оптимизировать выполнение повторяющихся задач. Этот подход лучше применять для разработок, в которых необходимо найти способ быстро и с высокой повторяемостью переносить программное обеспечение в производственную среду.
DevOps-инженерами становятся:
Я пришел в специальность из системного администрирования около трех лет назад. До этого работал в центре обработки данных (ЦОД), занимался системами мониторинга — приходилось заниматься как администрированием, так и немного разработкой. После решил попробовать себя в DevOps, там и остался.
Как начать?
DevOps вряд ли будет вашей стартовой профессией в IT, нужно уже иметь опыт в сфере и общее понимание разработки. Для DevOps-инженера также важно знать фундаментальные основы системного администрирования и сетей.
Узнать больше о сетях можно в книгах «Компьютерные сети» Виктора и Натальи Олифер и «Руководство по подготовке к экзамену CCNA» Уэнделла Одома. А ознакомиться с Linux и операционными системами в целом помогут «Настольная книга Unix & Linux системного администратора» Эви Немет и «Современные операционные системы» Эндрю Таненбаума.
Присоединяйтесь к профсообществам на форумах и в соцсетях, чтобы лучше понимать тенденции рынка и обращаться за советами:
Теоретические знания можно отрабатывать на онлайн-курсах (на Udacity есть бесплатный курс), с их помощью удобно систематизировать знания.
На курсе «DevOps-инженер» от Skillfactory вы за 6 месяцев освоите ключевые инструменты и востребованные рынком технологии. Под управлением экспертов вы создадите портфолио архитектурных решений и подходов, научитесь уверенно рассказывать о них на собеседовании и осознанно внедрять в своих проектах.
После этого вы присоединитесь к сообществу специалистов-практиков, получите рекомендации экспертов по внедрению изменений, решению реальных проблем и удержанию фокуса на постоянных улучшениях.
Освойте перспективную IT-профессию на стыке разработки, системного администрирования и бизнеса. Дополнительная скидка 5% по промокоду BLOG.
Кто такой DevOps и когда он не нужен
Тема DevOps за последние несколько лет стала очень популярной. Многие мечтают в нее влиться, но, как показывает практика, часто только из-за уровня зарплат.
Некоторые указывают в своем резюме DevOps, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «девопсом». Это, конечно, не так.
Несколько последних лет я занимаюсь в основном внедрением DevOps в различных компаниях. До этого более 20 лет работал на позициях от системного администратора до IT-директора. Сейчас — DevOps Lead Engineer в Playgendary.
Кто такой DevOps
Идея написать статью возникла после очередного вопроса: «кто такой DevOps?». До сих пор нет устоявшегося термина, что или кто это. Часть ответов уже есть в этом видео. Сначала выделю главные тезисы из него, а затем поделюсь своими наблюдениями и мыслями.
DevOps — не специалист, которого можно нанять, не набор утилит, и не отдел разработчиков с инженерами.
DevOps — это философия и методология.
Другими словами, это набор практик, который помогает активно взаимодействовать разработчикам с системными администраторами. То есть связывать и интегрировать рабочие процессы друг в друга.
С появлением DevOps структура и роли специалистов остались такими же (есть девелоперы, есть инженеры), но изменились правила взаимодействия. Размылись границы между отделами.
Цели DevOps можно описать тремя пунктами:
И это только часть инструментов DevOps
Уже больше 2-х лет собеседую людей на позицию DevOps-инженера и ко мне пришло осознание, насколько важно четко понимать суть термина. Накопился специфический опыт, наблюдения и мысли, которыми хочу поделиться.
Из опыта собеседований я вижу такую картину: у специалистов, которые считают DevOps должностью, обычно есть недопонимания с коллегами.
Был яркий пример. На собеседование пришел молодой человек с кучей умных слов в резюме. На последних трех местах работы у него был стаж 5-6 месяцев. Из двух стартапов ушел, потому что «не взлетели». А вот насчет третьей компании сказал, что там его никто не понимает: разработчики пишут код по Windows, а директор заставляет этот код «заворачивать» в обычный Docker и встраивать в CI/CD-пайплайн. Парень много чего негативного рассказал по поводу его текущего места работы и его коллегах — так и хотелось ответить: «Так ты слона не продашь».
Потом я задал ему вопрос, который в моем списке один из первых для каждого кандидата.
— Что лично для тебя означает DevOps?
— Вообще или как я это воспринимаю?
Меня интересовало его личное мнение. Он знал теорию и происхождение термина, но был категорически с ними не согласен. Он считал, что DevOps — должность. Здесь и кроется корень его проблем. Как и других специалистов с таким же мнением.
Работодатели, наслушавшись о «магии DevOps», хотят найти человека, который придёт и эту «магию» создаст. А соискатели из разряда «DevOps — это должность» не понимают, что при таком подходе они не смогут оправдать ожидания. И, вообще, написали в своём резюме DevOps, потому что это тренд и за это много платят.
Методология и философия DevOps
Методология бывает теоретической и практической. В нашем случае — второе. Как я упоминал выше, DevOps — это набор практик и стратегий, применяемых для достижения заявленных целей. И в каждом случае, в зависимости от бизнес-процессов компании, он может существенно отличаться. Что не делает его лучше или хуже.
Методология DevOps — лишь средство достижения поставленных целей.
Теперь о том, что такое философия DevOps. И это, наверное, самый трудный вопрос.
Сформулировать краткий и емкий ответ достаточно сложно, потому что он еще не формализован. И так как адепты философии DevOps больше занимаются практикой — на философствования просто нет времени. Тем не менее, это очень важный процесс. Причём напрямую относящийся к инженерной деятельности. Есть даже специализированная область познания — философия техники.
В моём ВУЗе такого предмета не было, пришлось изучать все самостоятельно по тем материалам, которые смог найти в 90-е. Тема необязательная для инженерного образования, отсюда и отсутствие формализации ответа. Но те люди, которые серьёзно погрузились в DevOps, начинают ощущать некий «дух» или «неосознанную всеобъемлющность» всех процессов компании.
Я на своем опыте постарался формализовать некоторые «постулаты» этой философии. Получилось следующее:
Что делает DevOps
Ключевое слово здесь — коммуникации. Очень много коммуникаций, инициатором которых должен быть как раз тот самый DevOps-инженер. Почему так? Потому что это философия и методология, а уже потом инженерные знания.
Про западный рынок труда говорить со 100% уверенностью не могу. Но вот о рынке DevOps в России знаю довольно много. Кроме сотен собеседований, за последние полтора года я участвовал в сотне технических пресейлов по услуге «Внедрение DevOps» для крупных российский компаний и банков.
В России DevOps ещё очень молодая, но уже трендовая тема. Насколько я знаю, только по Москве дефицит таких специалистов за 2019 год составил более 1000 человек. А слово Kubernetes для работодателей почти как красная тряпка для быка. Адепты этого инструмента готовы использовать его даже там, где это не нужно и экономически не выгодно. Работодатель не всегда понимает в каких случаях, что уместнее использовать, а при должном развертывании содержание кластера Kubernetes стоит в 2-3 раза дороже, чем развертывание приложения по обычной кластерной схеме. Используйте его там, где он действительно нужен.
Внедрение DevOps с точки зрения денег — дорого. И оправдано только там, где приносит экономическую выгоду в других областях, а не само по себе.
DevOps-инженеры, фактически, первопроходцы — именно они первыми должны внедрять в компании эту методологию и выстраивать процессы. Чтобы это было успешно, специалист должен постоянно взаимодействовать с сотрудниками и коллегами на всех уровнях. Как я обычно говорю, в процесс внедрения DevOps должны быть вовлечены все сотрудники компании: от уборщицы до CEO. И это обязательное условие. Если самый младший член команды не будет знать и понимать, что такое DevOps и зачем выполняются те или иные организационные действия, то успешного внедрения не получится.
Также DevOps-инженеру нужно время от времени использовать административный ресурс. Например, для преодоления «сопротивления среды» — когда команда не готова принять инструменты и методологию DevOps.
Разработчик должен писать только код и тесты. Для этого ему не нужен супермощный ноутбук, на котором он будет разворачивать и поддерживать локально всю инфраструктуру проекта. Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.
Но есть команды, которые, наоборот, рады внедрению новых инструментов и методов, и живо участвуют в этом процессе. Хотя даже в таком случае коммуникации между DevOps-инженером и командой никто не отменял.
Когда DevOps не нужен
Бывают ситуации, когда DevOps не нужен. Это факт — его нужно понять и принять.
В первую очередь, это касается любых компаний (особенно малого бизнеса), когда их прибыль не зависит напрямую от наличия или отсутствия IT-продуктов, предоставляющих информационные сервисы клиентам. И здесь речь не о сайте компании, будь он статической «визиткой» или с динамическими новостными блоками и т.п.
DevOps требуется, когда от наличия этих информационных сервисов по взаимодействию с клиентом, их качества и таргетированности зависит удовлетворенность вашего клиента и его желание вновь возвращаться именно к вам.
Ярким примером является один известный банк. У компании нет привычных клиентских офисов, документооборот осуществляется через почту или курьеров, а множество сотрудников работает из дома. Компания перестала быть просто банком и, на мой взгляд, превратилась в IT-компанию с развитыми DevOps-технологиями.
Много других примеров и лекций можно найти в записях тематических митапов и конференций. Часть из них я посетил лично — это очень полезный опыт для тех, кто хочет развиваться в этом направлении. Вот ссылки на YouTube-каналы с хорошими лекциями и материалами по DevOps:
Если ваша компания торгует рыбой в небольшом магазинчике и единственным IT-продуктом являются две конфигурации 1С: Предприятие (Бухгалтерия и УНФ), то вряд ли есть смысл говорить о DevOps.
Если же вы работаете на крупном торговом и производственном предприятии (например, производите охотничьи ружья), то стоит задуматься. Вы можете проявить инициативу и донести своему руководству перспективы внедрения DevOps. Ну, и заодно, возглавить этот процесс. Проактивная позиция — один из важных постулатов философии DevOps.
Размер и объем годового финансового оборота не является основным критерием для определения, нужен ли вашей компании DevOps.
Представим себе крупное промышленное предприятие, которое не взаимодействует напрямую с клиентами. Например, некоторые автоконцерны и автомобилестроительные компании. Сейчас не уверен, но, из моего прошлого опыта, много лет всё взаимодействие с клиентами осуществлялось по электронной почте и телефону.
Их клиенты — это ограниченный список автомобильных дилеров. И к каждому прикреплен специалист от производителя. Весь внутренний документооборот происходит через ERP SAP. Внутренние сотрудники, по сути, являются клиентами информационной системы. Но управление этой ИС осуществляется классическими средствами управления кластерными системами. Что исключает возможность использования практик DevOps.
Отсюда вывод: для подобных предприятий внедрение DevOps не является чем-то критически важным, если вспомнить цели методологии из начала статьи. Но не исключаю, что какие-то инструменты DevOps используются ими сегодня.
С другой стороны, есть много небольших компаний, которые разрабатывают программное обеспечение с использованием методологии, философии, практик и инструментов DevOps. И считают, что затраты на внедрение DevOps являются расходами, позволяющими им эффективно конкурировать на рынке ПО. Примеры таких компаний можно увидеть здесь.
Основной критерий для понимания нужен ли DevOps: какое значение ваши IT-продукты имеют для компании и клиентов.
Если основной продукт компании, приносящий прибыль, это ПО — вам нужен DevOps. И не так важно, если зарабатываете реальные деньги вы с помощью других товаров. Сюда также можно отнести интернет-магазины или мобильные приложения с играми.
Любые игры существуют благодаря финансированию: прямому или косвенному со стороны игроков. В Playgendary мы разрабатываем бесплатные мобильные игры, в непосредственном создании которых участвуют более 200 человек. Как мы используем DevOps?
Да точно также, как описано выше. Я постоянно общаюсь с разработчиками и тестировщиками, провожу внутреннее обучение сотрудников методологии и инструментам DevOps.
Сейчас у нас активно используется Jenkins как инструмент CI/CD pipelines для выполнения всех сборочных конвейеров с Unity и последующего деплоя в App Store и Play Market. Еще из классического набора инструментов:
Вместо заключения
Хочу закончить следующей мыслью: чтобы стать DevOps-инженером высокой квалификации, жизненно необходимо научиться живому общению с людьми.
DevOps-инженер — командный игрок. И никак иначе. Инициатива в общении с коллегами должна исходить от него самого, а не под воздействием каких-то обстоятельств. DevOps-специалист должен увидеть и предложить наилучшее решение для команды.
И да, внедрение любого решения потребует множества обсуждений, а к концу может вообще измениться. Самостоятельно развиваясь, предлагая и осуществляя свои задумки — такой человек представляет все большую ценность как для команды, так и для работодателя. Что, в конечном счёте, отражается и на размере его ежемесячного вознаграждения или в виде дополнительных премий.