Тема DevOps за последние несколько лет стала очень популярной. Многие мечтают в нее влиться, но, как показывает практика, часто только из-за уровня зарплат.
Некоторые указывают в своем резюме DevOps, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «девопсом». Это, конечно, не так.
Несколько последних лет я занимаюсь в основном внедрением DevOps в различных компаниях. До этого более 20 лет работал на позициях от системного администратора до IT-директора. Сейчас — DevOps Lead Engineer в Playgendary.
Кто такой DevOps
Идея написать статью возникла после очередного вопроса: «кто такой DevOps?». До сих пор нет устоявшегося термина, что или кто это. Часть ответов уже есть в этом видео. Сначала выделю главные тезисы из него, а затем поделюсь своими наблюдениями и мыслями.
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-методологией должны руководствоваться все сотрудники компании планируя свою деятельность.
- DevOps затрагивает все процессы внутри компании.
- DevOps существует, чтобы снижать временные затраты на любые процессы внутри компании для обеспечения развития её услуг и максимального комфорта клиента.
- DevOps, современным языком, есть проактивная позиция каждого сотрудника компании, нацеленная на снижение временных издержек и улучшение качества окружающих нас IT-продуктов.
Думаю, что мои «постулаты» это отдельная тема для обсуждения. Но теперь есть от чего отталкиваться.
Что делает 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-продуктов, обеспечивающих взаимодействие с клиентом?
Если ваша компания торгует рыбой в небольшом магазинчике и единственным 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. Еще из классического набора инструментов:
- Asana — для управления проектами. Настроена интеграция с Jenkins.
- Google Meet — для проведения видеовстреч.
- Slack — для коммуникаций и различных оповещений, включая нотификации из Jenkins.
- Atlassian Confluence — для документирования и групповой работы.
В ближайших планах внедрить статический анализ кода с помощью SonarQube и провести автоматизированное UI-тестирование средствами Selenium на этапе Continuous Integration.
Вместо заключения
Хочу закончить следующей мыслью: чтобы стать DevOps-инженером высокой квалификации, жизненно необходимо научиться живому общению с людьми.
DevOps-инженер — командный игрок. И никак иначе. Инициатива в общении с коллегами должна исходить от него самого, а не под воздействием каких-то обстоятельств. DevOps-специалист должен увидеть и предложить наилучшее решение для команды.
И да, внедрение любого решения потребует множества обсуждений, а к концу может вообще измениться. Самостоятельно развиваясь, предлагая и осуществляя свои задумки — такой человек представляет все большую ценность как для команды, так и для работодателя. Что, в конечном счёте, отражается и на размере его ежемесячного вознаграждения или в виде дополнительных премий.
