Everything as code

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

Тому пример Александр Шуляк, который нашел себя именно в Девопсе. Накануне конференции DevOps 2021 мы встретились с Сашей и поговорили о том, как и с чего начался его DevOps, а также к чему он пришел в этой карьере.

Саша, очень приятно с тобой познакомиться. На странице про твой доклад написано, что ты делал и делаешь DevOps в больших и маленьких компаниях. Расскажи, как ты начинал.

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

Правда, со временем я всё больше понимал, что ни одна из dev- и ops-областей меня полностью не устраивает. Мне хотелось совместить все эти интересные штуки из разработки и operations вместе. Но тогда я еще не знал, что это возможно в DevOps.

Как ты узнал про DevOps?

В 2016 году в Минске, где я тогда жил, DevOps только набирал обороты, и вакансий в городе было не очень много. Но когда я наткнулся на одну из них, то понял, что это то самое комбо, которое я хотел! И я начал искать именно девопс-вакансии, одновременно изучая видео на ютубе и статьи на хабре, чтобы понимать основы коммерческой разработки и узнать какие-то тонкости.

В результате мне повезло оказаться единственным DevOpsом в аутсорсе средних размеров. Меня сразу же отправили на амбразуры проектов и заказчиков. Это было безумно стрессово, но очень эффективно я учился очень быстро, буквально на ходу.

Какие твои навыки тебе тогда потребовались на практике?

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

Тогда от меня требовалось писать код, чтобы автоматизировать всё и вся. При этом нужно было ковыряться в системах, но уже абстрагируясь от железа. Использовать облачные ресурсы, чтобы быстро получать требуемые мощности.

В DevOps пригодятся любые навыки программирования, и начальный язык не так важен, потому что пересесть на профильные python/golang не будет сложным делом.

Что именно нужно уметь кодить DevOps-инженеру?

Я использую Pyhton для быстрого скриптинга, чтобы что-то автоматизировать в рутинной работе, какие-то базовые задачи автоматизации в облаках. У него много готовых библиотек, и это позволяет быстро создавать довольно сложные системы.

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

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

Shell-скрипты это ведь часть работы в терминале. Что-то еще там нужно уметь?

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

Какие инструменты нужно изучать для мониторинга и сбора логов?

Основные инструменты для сбора метрик сейчас это Prometheus и Grafana. Prometheus это метрик-коллектор (формально time-series database). Как альтернатива мне ещё очень нравится TICK стек на базе InfluxDB. Grafana, в свою очередь, используется для отрисовки красивой инфографики и отправки оповещений.

Для сбора логов в одном месте можно посмотреть Elastic Stack. Он довольно сложный, но дает отличное представление о работе с логами. У него есть бесплатная версия, и этого достаточно, чтобы поиграться с системой и понять, как она работает, из каких компонентов состоит. Альтернативы Elastic Stack Splunk, Datadog. Но это больше enterprise-инструменты, изучать их достаточно сложно.

Что насчет операционных систем? Чем тут заняться, чтобы приблизиться к девопсу?

Из моего опыта программные стеки на Linux намного популярнее, чем на Windows. Изучение можно начинать с любого семейства Linux в целом их архитектура очень схожа.

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

У Linux Professional Institute (LPI) есть статьи по работе linux и базовым манипуляциям с системой. Это открытые курсы/уроки, и они хорошо помогут разобраться с работой Linux. А у Роберта Лава (Robert Love) есть отличная, хоть и немного скучная книга Ядро Linux: описание процесса разработки. Помогает быстро уснуть :)

Ещё в изучении Linux вам может сильно помочь Youtube-канал Кирилла Семаева.

Поговорим про сетевую сторону operations. Что нужно уметь делать здесь?

Первое и самое важное знать как работает сеть. Теоретическая и практическая часть прекрасно описаны в цикле статей от linkmeup сети для самых маленьких. Статьи на примере Cisco, с прекрасными иллюстрациями и отличными объяснениями. Очень легко понять, как сеть работает на всех уровнях.

Ещё в любом случае надо знать веб-сервера, но тут достаточно изучить nginx на базовом уровне. Основные принципы не сильно отличаются от сервера к серверу, а nginx один из самых популярных из них.

Расскажи про принципы DevOps. Это что-то as Code. Как они работают?

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

Наверное, самый популярный инструмент управления инфраструктурой (Infrastructure as Code) это Terraform. Его довольно просто изучать, там великолепная документация. И буквально в этом году вышло новое издание книги Евгения Брикмана Terraform. Инфраструктура на уровне кода, которая тоже отлично объясняет, как работать с этим инструментом.

Есть ещё принцип Configuration as Code, который описывает состояние операционной системы. Тут я советую для изучения Ansible. Можно Chef, но выбрать можно любой, так как поняв основной принцип работы одного, переходить на другие инструменты будет несложно.

А Pipeline as Code вообще очень интересная вещь. Так как синтаксис и предоставляемые возможности инструментов очень схожи, то можно спокойно выучить один и пользоваться всеми. С другой стороны, практически всегда построение пайплайнов приводит к shell-скриптам, потому что основного инструмента без его кастомизации в любом случае будет недостаточно.

Оркестрация это тоже необходимый навык?

Да, примерно по тем же причинам, почему мы используем всё as Code. Когда у вас контейнеров больше одного, ими сложно управлять. Для этого и существуют оркестраторы вроде Mesos, Nomad, Openshift, Kubernetes и так далее. Самый популярный, конечно, Kubernetes. Он достаточно сложный для изучения с точки зрения архитектуры и управления, но базовые понятия выучить не проблема. На первых порах этого должно быть достаточно, а остальное придёт с опытом и интересом.

Какие есть особенности у специализации DevOps-инженеров?

Для девопс-инженера очень важны софт-скилы, умение общаться и находить компромиссы. Часто мне нужно общаться как с разработчиками, так и с stakeholderами из продуктового мира, чтобы лучше понимать требования и задачи.

На практике список обязанностей сильно зависит от размера компании. Где-то могут быть большие команды и несколько DevOps-инженеров, которые отвечают за build продукта, релиз, платформу или безопасность и governance облака.

После интенсива в минском аутсорсе я пришел работать в Accenture в Латвии. Это было что-то абсолютно противоположное огромная корпорация, четко поставленные процессы, большие команды, много командировок и общения с заказчиками. Для меня это был очень полезный и новый опыт. Но Рига город небольшой и во многом похож на Минск. IT-рынок также не широк, а мне уже хотелось эмигрировать дальше и не просто так, а ради чего-то нового.

Так я оказался в Лондоне. Сейчас, после полутора лет в Gearset, я Senior SRE в финтех-стартапе Divido. И мой опыт показывает, что в Англии больше верят в узкую специализацию, чем у нас. То есть вам надо знать некоторые предметные области в вашем техническом стеке намного лучше, чем другие. Допустим, если вы Cloud Ops инженер, то у вас будет сильный упор на бизнес-инструменты именно в облаках.

У нас же чаще подразумевается, что человек умеет делать всё.

Твой доклад как раз по этой теме?

Нет, на этот раз я хочу поговорить о тестировании. Многие сомневаются, а нужно ли вообще тестировать. И если надо, то когда начинать, если, например, и так много задач. Особенно если у вас не хватает времени, есть какое-то легаси, да еще и технический долг, который нужно разгребать. Или внезапно продукт вашей компании должен отвечать каким-то требованиям стандартизации и сертификации. Собственно моя история будет схожей с обходными путями тестирования инфраструктуры, когда в лоб не очень получается. Я уверен, что многие сталкивались с похожими проблемами, поэтому мне очень хочется поделиться своим опытом. Тебе нравится выступать?

У меня есть некоторый опыт выступлений на DevOps-конференциях, но мне все равно было немного страшно подаваться у меня было не очень много выходов на публику. Но когда доклад приняли, я понял, что пути назад нет и это даже интереснее. Так что если у вас есть интересная тема подавайтесь даже без опыта выступлений! Вместе с куратором всё получится.

Что ты предпочитаешь, офлайн или онлайн?

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

Какие темы из программы для тебя наиболее актуальны и какие доклады хочешь послушать сам?

Разумеется доклад Дмитрия Столярова, я его большой фанат! :) У него всегда можно узнать что-то новое про кубер, с которым я последние два года очень плотно работаю. А также о теоретической части SRE/DevOps, поскольку мне очень интересно, как выстроены процессы в разных компаниях и как они скрещивают методологии с реальной жизнью.

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

Ну и конечно, нас ждет извечно актуальная и холиварная для меня тема про SRE человек-оркестр, потому что никто не знает как обозвать человека со специфичным набором навыков и вообще надо ли :)

Саша, спасибо тебе огромное за подробный разговор. Желаем тебе найти билеты в Россию, чтобы встретиться на конференции!

Спасибо и до встречи!

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

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