шапка-03.jpg

Диалоги о DevOps: компетенции, философия и принципы

15 июля 2020

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

Кто такие DevOps, чем они занимаются и какую пользу приносят, рассказывают Алексей Бурим, Анатолий Фащевский и Никита Доля.

Диалоги о DevOps инженерах в iTechArt

- Термин DevOps существует с 2009-го года, но только сравнительно недавно он стал популярным. Почему?

Никита: Думаю, термин получил широкое распространение из-за бурного развития стартапов. Этим ребятам нужно как можно быстрее воплотить идею в жизнь, запитчить инвесторам, получить раунд финансирования и пойти дальше. Для них DevOps – это возможность показать, что все работает, и прибыль гарантирована. Допустим, разработчики написали первую минимально работающую версию. Теперь нужно попробовать запустить продукт, посмотреть, как он будет выглядеть на рынке. DevOps забирает функционал у разработчика, запускает код, смотрит, насколько он отказоустойчив, какую нагрузку может выдержать.

Анатолий: Сейчас все хотят быть первыми, а DevOps Engineer знает, как выиграть время и сэкономить денег. Мы максимально автоматизируем процессы и создаем подходящую инфраструктуру для доставки и хранения кода. При этом в идеале закрываем не только development operations, а еще и вопросы безопасности и качества. Поэтому наша значимость возрастает.

Алексей: 15-20 лет назад состояние IT-индустрии было другим. Например, раньше сайты делал вебмастер и разделения на front-end и back-end не было. В большинстве случаев, вебмастер делал тесты и сам “рисовал” дизайн и верстал страницы. Такой человек-оркестр. Но все развивается, и появляются узконаправленные специалисты. Так возникла необходимость в оптимизации процессов, возникли разные методологии и подходы. Поэтому для многих динозавров индустрии DevOps – это не человек, это философия. С этим я согласен, но вот с классическим восприятием, что это только лишь development operations и testing – нет.

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

- А как же высказывание, что лучшее враг хорошего?

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

Философия Devops инженеров

- В чем философия DevOps?

Алексей: В поиске оптимально качественного решения там, где не существует правильного. Например, недавно выходил из проекта и меня попросили сделать доступ для заказчика по клиентскому сертификату в системе. Это можно было сделать как минимум тремя способами. Я выбрал самый быстрый и современный, но он не подходил, потому что работал не так, как было задокументировано, я попробовал второй – тоже получилось не совсем то, что нужно. В итоге при помощи DevOps-практик я быстро перешел к резервному способу: собрал докер-контейнер, добавил софт внутрь и решил проблему. Кстати, первая заповедь DevOps: «В любой непонятной ситуации собирай докер-контейнер». Шучу, конечно!

- А вторая заповедь?

Алексей: Пиши все кодом. Все, что сделаешь руками, сто процентов забудешь и не повторишь через 2 недели. У разработчиков есть хорошее высказывание, что на любом проекте есть минимум 2 программиста: ты сейчас и ты через 2 недели. Тоже самое и у нас.

Анатолий: Точно. Вот напишу я код сейчас, вернусь к нему через год-два и буду ругаться, кто эту дичь вообще написал?

- Какую роль DevOps выполняет на проекте, в команде?

Анатолий: Иногда роль заботливого родителя, который возьмет QA и приведет его за руку к разработчику и скажет: «Ребята, а давайте договоримся, как будем работать». То есть наша задача – объединить и наладить все процессы. Разработчик пишет код, QA – тесты, а мы прикручиваем к приложению и код, и тесты, а потом доставляем все это красиво и автоматизировано в среду разработки, потом на стейдж и затем в продакшен. Еще наша роль зависит от того, что на проекте готово в плане разработки. Если только код на коленке собирают, то мы помогаем лучше понять ситуацию, создать среду разработки, чтобы ПО работало не только на компьютере инженера. Затем мы выстраиваем автоматизированный процесс сборки кода и запускаем инфраструктуру. Если уже что-то готово, то делаем ревью и смотрим, как улучшить систему.

Никита: Мы находим болевые точки, как в проектах, так и в людях и помогаем сплотить команду. Очень часто люди не хотят участвовать в общих процессах и стараются абстрагировать свой функционал. DevOps культура объясняет, что твоя зона ответственности гораздо шире и не существует в вакууме. Нельзя говорить, что это не моя проблема и сами разбирайтесь с этим, как хотите.

Алексей: Неправильно думать, что если в команде есть DevOps, то сейчас он все разрулит. Так не бывает. Вот я всегда могу сказать, это не мое дело, что они там накодили, их косяк –пусть и решают. Но я так не делаю. Это не DevOps! Я понимаю, что конечный результат зависит от слаженной работы. Мало просто взять технологии и инструменты и считать, что у нас все тип-топ. DevOps эффективен в том случае, если его делает вся команда, вся компания, а не отдельный инженер.

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

- Какую пользу приносит DevOps?

Алексей: Например, одному заказчику инфраструктура обходилась в несколько тысяч долларов, а после оптимизации подешевела в 12,5 раз. Оказалось, что большая часть ресурсов никем не использовалась и этого никто не замечал, пока не стали внедрять DevOps-подходы. Или другой забавный случай, когда я пришел на проект, где деплоймент у ребят происходил примерно полчаса. И то 50 на 50 повезет или нет. Если не повезет, то нужно делать откат к прошлой версии и снова начинать с нуля. Потому что, пока они не поймут, сделали они часть работы или нет, двигаться дальше нельзя. В итоге при помощи оптимальных подходов я сократил время деплоймента до 14-25 секунд. Видели бы вы квадратные глаза разработчиков и вопрос «А что так вообще можно было?» Для клиента это означало, что, например, корзина в их онлайн-магазине появилась через день, а не через месяц.

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

- Какие мифы существуют о DevOps?

Никита: Что мы не умеем писать код.

Анатолий: Мы даже костыли можем сделать, если понадобится. (Смеется)

Никита: На одном из проектов, где работаем вместе с Лешей, попросили сделать MVP. Изначально думали, что на минимально работающую версию уйдет дня два-три, а в итоге справились за два часа. Клиент был очень доволен и прожужжал разработчикам все уши, как здорово, что все получилось, и можно идти дальше. То есть в этой задаче я выполнял функции программиста – запускал код и смотрел, как он локально работает.

Алексей: Практически все современные системы и особенно облачные имеют API и управляются запросами с командами. При любом подходе DevOps должен описать систему кодом или очередностью вызовов к API. Это позволяет исключить ситуацию, когда что-то сделано руками и повторить это через месяц, когда выход в продакшен уже послезавтра, невозможно. Фактически мы пишем скрипты и вспомогательные программы, и у нас достаточно широкий бэкграунд. То есть мы в состоянии поговорить с разработчиками, разобраться в чем дело и доходчиво объяснить суть ограничений или проблемы.

Анатолий: Еще один миф, что DevOps – это дорогой сисадамин. Действительно, многие приходят в DevOps из системного администрирования. Например, я проработал на этой позиции более 8 лет и даже занимал руководящую должность, у меня были подчиненные. Но хотелось перемен. Мне нравилось автоматизировать процессы, и в какой-то определенный момент логическим развитием карьеры стал переход в DevOps. Но это произошло не сразу. Я еще успел поработать build инженером, и на одном из проектов мне надоело, что процессы автоматизированы только на половину. Это стало большим челленджем, так как для решения проблемы пришлось выучить еще один язык программирования. Была сложная система, которая включала в себя 10 больших Java-приложений, которые зависели от более чем 50 мелких, и эта цепочка насчитывала 5 или 7 очередей. Это сильно усложняло сборку проекта, а мне хотелось упростить, сделать так, чтобы все работало по кнопке и без моего участия. В итоге потратил полгода, но это того стоило – улучшилась не только моя эффективность, но компании в целом. Поэтому DevOps – это не переименованный сисадмин, а человек, который использует другие подходы и от него требуют гораздо больше навыков и знаний.

Никита: Но бэкграунд сисадмина становится поводом для холиваров. Некоторые код-наци возмущаются, с какой стати сисадмин будет их учить их жизни и считают, что DevOps могут делать только разработчики. Но это не совсем верно. Мой тим-лид бывший программист, и в реальности я вижу, что мы хорошо дополняем друг друга. В вопросах, которые связаны с сетями, я сильнее. Зато он лучше понимает в задачах, которые связаны с разработкой: может быстро посмотреть, внести изменения или дописать код при необходимости. Несмотря на то, что в университетах нет такой специальности, как DevOps, и мы, самоучки, временами сталкиваемся с тем, что заказчики хотят видеть в роли DevOps бывшего разработчика. Потому что считают, что он лучше может сделать Proof of Concept приложения и в то же время создать рабочую экосистему. Но, честно говоря, это все до поры до времени. Потом все равно придется звать Лешу, который скажет, что все неправильно, и все нужно менять.

Алексей: Со словами “А-а-а-а, мы через две недели уходим в продакшен. Все горит!” Рынок часто хочет DevOps инженера, чтобы за чуть большие деньги получить универсального человека, который и в коде понимает и поправить что-то может, но в тоже время и инфраструктуру может поковырять. Или наоборот, иногда заказчик хочет просто инженера, который будет чуть-чуть разбираться в инфраструктуре. А все потому, что методологически DevOps – это не человек.

Никита: Вывод один – как и отмечают в статьях, что все равно понятие девопса как специалиста расплывчато и единого подхода нет. Забавно, что сами компании по-разному понимают и трактуют понятие DevOps. Мой приятель прошел собеседование в крутой американский стартап, с хорошей прибылью и большим штатом сотрудников. Так вот, там ему сказали, что они сильно не любят называть таких специалистов DevOps, только системный инженер, только хардкор.

- Зависит ли функционал DevOps от масштабов компании?

Никита: Например, в нашей компании больше случаев, когда работаешь на стартапе и выполняешь самый разный спектр задач. Как говорил Толик – вплоть до того, что разговариваешь с тестировщиком и программистом, чтобы скомбинировать в одной сессии их подходы и получить в итоге конфетку. Энтерпрайз проекты в компании тоже есть, но их меньше. Там все совсем по-другому: тебе дают инфраструктуру и сиди ковыряйся в ней. Часто на энтерпрайз проектах объем задач большой для одного специалиста, поэтому среди DevOps можно увидеть подразделения: секьюрити, билд-инженер и так далее.

Анатолий: Но на стартапе работа более интересная. Тут даже вопроса нет. Энтерпрайз загоняет в рамки того, что уже сделано. Ты должен пользоваться теми инструментами, к которым они привыкли. Шансы предложить что-то новое, альтернативное крайне малы, потому что энтерпрайз медленный и неповоротливый в принятии решений.

Никита: С моей точки зрения, не совсем так. В энтерпрайз ты работаешь вглубь, а со стартапами вширь. Иногда хочется погрузиться в решение одной проблемы и не думать ни о чем другом. Хотя тяжело отказаться от разнообразия задач и областей, которые требуют широкого охвата знани».

Анатолий: Поэтому кто-то берет разные проекты и совмещает работу в энтерпрайз со стартапом, чтобы не тупеть и развиваться. Стартапы работают с хайповыми технологиями. Допустим, что-то новое появилось, находится на пике обсуждений, а в стартапе оно по умолчанию уже есть. Люди пытаются делать достаточно высокотехнологичный продукт, а в энтерпрайз тот же переход с PHP на Node.js будет огромной проблемой и займет кучу времени.

Алексей: Не стоит забывать, что с энтерпрайз важную роль играет то, зачем вас берут на проект. Это первое, что нужно выяснить и понять. Бывает, что и в крупную компанию нанимают с целью что-то поменять. Укоренившиеся годами практики непросто ломать, даже, если они были неправильными. Ведь по мнению заказчика они работали, хотя и приносили бизнесу головную боль. Другая ситуация, если приходишь в энтерпрайз DevOps инженером и поддерживаешь их текущие практики, не советуя ничего нового. Но, если говорить с большего, то действительно в стартапах мы можем решать проблемы напрямую, не тратить время на согласования или выдачу доступов отделом безопасности.

- В чем кайф работы DevOps?

Никита: Есть несколько способов решения одной и той же задачи, и возможность сделать лучше, внести какой-то новый функционал. Это вызывает очень большой интерес, потому что работа всегда нетривиальная. Очень редко бывают задачи, которые повторяются. И другой момент - ты действительно видишь, насколько быстро компании начинают развиваться, когда процесс DevOps налаживается внутри компании, команды, и насколько больше появляется плюшек и возможностей.

Анатолий: На предыдущих работах на подготовку информации могло уйти от недели до месяца, а сейчас на похожую задачу уходит примерно 2 часа. Чувствуешь себя суперменом.

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

1432
Стань частью нашей команды