«Чтобы DevOps-у чего-то добиться, нужна проактивная позиция, а не просто плыть по течению»

Мы продолжаем цикл публикаций про ИТ-профессии. В этот раз мы поговорили с Кириллом, руководителем группы практики DevOps в IBS. Он рассказал об особенностях профессии, образовании и том, почему «DevOps-ом невозможно прийти с улицы».

DevOps (сокращение от Development Operations) — это набор практик для повышения эффективности процессов разработки и эксплуатации ПО. Это меньше имеет отношение к ИТ-профессии, а больше про методологию или даже культуру. Во многом она определяет взаимодействие между командой разработки и командой эксплуатации.

DevOps — тайна за семью печатями. В каждой компании к этой роли относятся по-своему. Можешь рассказать, как ты ее видишь и что за ней стоит?

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

Для решения рассогласованности, повышения эффективности процессов разработки и эксплуатации был выработан набор практик DevOps. Одна из практик — IaC (Infrastructure-as-Code — инфраструктура как код).

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

Суть DevOps сводится к знанию практик и умению применять большое количество инструментов. Приходится код писать и администрировать.

Роль DevOps в компаниях молодая, ей около 10 лет. Почему она появилась именно в это время?

Потому что бизнес меняется. Раньше можно было выпускать релиз раз в квартал — писать его тихонечко, тестировать, выкатывать. Сейчас жизнь стала гораздо быстрее. Многое ушло в веб, и с развитием бизнеса появились большие потребности в быстрых решениях, фичах, MVP (minimal viable product — минимально жизнеспособный продукт). Это похоже на бесконечную акцию в магазинах: мы предоставляем клиенту маленькую ценность, он видит, что наш продукт развивается, и не уходит от нас к конкурентам.

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

То есть DevOps — это человек, который оптимизирует процесс разработки и делает его максимально простым и удобным?

Да. Программисты пишут только код, они не занимаются настройкой окружения, они продумывают архитектуру приложения на уровне кода. Часто они не задумываются о том, как мы будем доставлять и обновлять код, как будут работать хранилища данных, будем ли мы собирать метрики, логи, агрегировать все это, мониторить и т. д.

Нам приходится думать обо всем: как мы будем это доставлять, обновлять, мониторить, восстанавливать, если упало, и удобно ли это. Часто мы говорим программистам: «Нет, ребята, давайте так делать не будем, есть определенные риски с дальнейшим конфигурированием» или «Если у нас возрастет количество сервисов, то необходим единый стандарт конфигурирования, иначе возможны ошибки». Ну, и никто не отменял хардкод — это бесконечная война. DevOps — это человек-оркестр.

Можно ли стать DevOps-ом, кроме как вырасти из системного администратора или из разработчика?

Нет, абсолютно. Если человек никак не связан с разработкой, это очень сложно. Постоянно придется рассказывать, почему все так, а не иначе, потребуется много времени. А время — деньги. Чем лучше работает наш конвейер, тем дешевле и эффективнее наша разработка.

Сама работа DevOps-а тесно связана с программированием. Нужны Python, Golang, Groovy для системы сборки Jenkins. Требуются и декларативные вещи: это Ansible — описание инфраструктуры. Нужно много всего.

Хорошо, спрошу по-другому. Откуда проще приходить — из разработки или из системного администрирования?

Скорее из системного администрирования. Я и сам так пришел в профессию. Сначала работал в техподдержке, затем стал сисадмином. По сути, DevOps — это переименованный системный администратор. Просто часто они очень ленивые и ничего не хотят делать. Есть же шутливый стереотип о бородатом сисадмине, который пьет пиво и злится на всех, кто просит что-то сделать.

Но если человек заинтересован в своем росте, если изучает и пытается применять все инструменты, практики и подходы, он может вырасти до DevOps-a. Чтобы чего-то добиться, нужна проактивная позиция, а не просто плыть по течению.

Разработчики всегда говорят, что написание кода — творческий процесс. Насколько деятельность DevOps-а творческая?

В любой инженерной работе есть определенная доля творчества, потому что «каждая метла метет по-своему». В DevOps, как и в программировании, необходимо предусмотреть множество «если», сделать это красиво и оптимально. Работа творческая, но часто приходится искать оптимальные решения и перелопачивать много информации, тратить много времени. Тут уже не до творчества.

Можешь назвать качества, которыми должен обладать хороший DevOps?

Обязательно проактивность. Если человек не заинтересован в обучении, а настроен плыть по течению, сразу нет.

Умение видеть причинно-следственные связи и выстраивать сложные логические цепочки. Программист держит в голове только свою часть системы, а DevOps — зачастую все, включая информацию о серверах.

И наконец, постоянное недоверие к разработчикам. То, что они говорят, часто надо перепроверять.

Можешь назвать преимущества своей профессии?

У меня есть возможность щупать новые технологии. Зачастую программисты используют один и тот же фреймворк и язык программирования. А у меня полный зоопарк, я могу играть с чем угодно. Взять те же хранилища данных — у меня большая свобода выбора среди того разнообразия, которое существует на данный момент.

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

Чем практика DevOps отличается в разных компаниях?

Тут, скорее, различия в заказчиках. И есть определенные сложности, связанные с выбором технологии. Где-то нельзя использовать облака, определенные инструменты, операционные системы, могут быть ограничения. Но в enterprise они есть всегда и с ними нужно жить.

С точки зрения работы: сборки и доставки кода, написание автоматизации — ничего не меняется, везде один и тот же конвейер. Могут меняться люди, технологии, но сам процесс разработки не меняется — код, его сборка, тестирование, доставка. Бесконечная петля.

Без каких знаний DevOps-у не обойтись?

Я убежден, что образование в России немного недотягивает в отношении свободы. У нас фундаментальный подход — учи что сказали. На Западе студент сам волен выбирать, какие предметы будет изучать. Естественно, есть и обязательные предметы для получения диплома, но большую часть предметов студент волен выбирать сам.

По сравнению с этой системой мы — в кандалах. Человек пришел учиться на программиста, а у него в расписании — философия и офисные технологии. Но такой студент уже знает, как работает компьютер. Его не надо учить, как работать в Word. Да, есть дисциплины, без которых не обойтись в системном программировании, но это не значит, что они нужны для веб-разработчика. Сомневаюсь, что в наших вузах можно почерпнуть что-то для хорошего старта в карьере. Самообразование, на мой взгляд, пока полезнее.

Ты упомянул самообразование. Как ты повышаешь свою квалификацию?

Моя работа — это мое хобби. В компьютерные игры я не играю, другими активностями не занимаюсь. Увлечен реализацией информационной платформы на базе Kubernetes. Она нужна для максимально быстрого старта процесса разработки. Это своего рода конструктор, который позволит приступить к процессу разработки без ожидания настройки требуемых интеграционных компонент, настройки сборки и доставки кода.

Обучаться — это пробовать что-то новое. Читать книги бесполезно, потому что пока не начнешь это щупать, толку мало. Все равно что читать про Эрмитаж. Посмотрел картинки — да, красиво. Но в нем надо побывать и самому все прочувствовать.

Ты посещаешь какие-нибудь профессиональные мероприятия, конференции, форумы?

Нет. Иногда смотрю в записи, но в них много воды про «успешный успех». Какие мы классные, как мы кнопку нажали и у нас все стало хорошо. Такого не бывает в жизни. Люди не рассказывают о своих проблемах, о том, как они превозмогали боль в достижении результата. Тратить на это несколько дней я не вижу смысла, проще посмотреть в записи те моменты, что интересны, и применить на практике.

Есть ли тогда необходимость в профессиональных сертификатах?

Да. Это другое. Бизнесу нужно понимать, что перед ним человек, который обладает требуемой квалификацией. Сертификат не только показывает, кто что умеет, — он подтверждает компетенцию. Это определенная гарантия, что перед вами специалист, а не дурачок.

В резюме пишут все что угодно. В сертификации такое не прокатит. Кроме того, если человек получил сертификат, значит, у него есть знания в данной области, он потратил на это свое время, деньги.

Можешь посоветовать что-нибудь тем, кто хочет стать DevOps-ом?

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