Что-то на айтишном: DevOps-инженер

— В DevOps я уже более семи лет, — рассказывает Александр, — До этого пять лет проработал в сфере сетевых технологий на разных позициях, но потом понял, что в сетевой части развития не особо много. С декабря 2021 работаю в компании Naviteq team lead специалистом, который занимается не только проектами, но и встречается с клиентами, продает услуги, подготавливает архитектуру и т. д.

Кроме этого, у меня есть хобби — я люблю делиться знаниями. У нас с друзьями есть подкаст DevOps Kitchen Talks, где мы общаемся на тему DevOps и пытаемся ее сделать понятной для всех — от джуниоров до технических специалистов, которые не совсем знают ту или иную доменную область.

Что такое DevOps?

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

Люди вне IT вообще не понимают, кто такие DevOps-инженеры. Я до сих пор не могу объяснить своим родственникам и некоторым друзьям, чем я занимаюсь.

Третья и особенная точка зрения — это точка зрения бизнеса. Приходят клиенты, которые не знают технических аспектов, но слышали, что DevOps могут исправить их бизнес-проблемы. У таких клиентов и заказчиков искаженный взгляд на DevOps. Они думают, что это такая «серебряная пуля»: DevOps-инженер, который все исправит. На самом деле это не так. DevOps — это не конкретная технология или инструмент. Это сотни инструментов и десятки разных подходов, и самое главное, что делает DevOps — общается. Его задача — помогать «дружить» департаментами через переговоры, через какую-то автоматизацию, которая позволяет уменьшить количество этих переговоров. В том числе это автоматизация всего того, что нужно бизнесу в конечном счете для того, чтобы упростить и ускорить работу других команд, которые вовлечены в создание продукта. Мне эта точка зрения кажется очень интересной.

Если все же говорить классическими словами, то DevOps — это комбинация подходов, паттернов, процессов, которые устанавливаются, и технологий, которые внедряются, чтобы решать конкретные технические и процессуальные проблемы и ускорять доставку конечного программного продукта клиентам. Это в общем. Если разбивать DevOps на части, Dev — это разработка, а Ops — сопровождение. Вместе DevOps — это сущность, которая находится в середине. Роман «Проект «Феникс» как раз рассказывает про проблематику DevOps: есть разработчики и есть те, кто вынужден то, что делают разработчики, где-то разворачивать, чтобы к этому получали доступ конечные клиенты. Команды, вовлеченные в разработку, постоянно перекидываются задачами, обвиняя друг друга. DevOps нужны, чтобы это общение оптимизировать путем внедрения процессов, технологий, которые позволяют это общение свести на минимум и автоматизировать его. Грубо говоря, мы внедряем правильную систему тикетов (задач) в какой-то системе типа Jira или мы внедряем какой-то оптимизированный пайплайн, который позволяет разработчикам автоматически проверять свою работу и, при необходимости, автоматически передавать ее на тестирование, а также автоматически оценивать качество по ходу и получать на выходе готовое решение, которое будет где-то развернуто.

DevOps — это своеобразный buzzword сегодня. Не все понимают, что это, но все его слышали, и некоторые представители разных отраслей могут давать абсолютно разные определения. Все будут по-своему правы. Сегодня начали появляться разные расширения в профессии: DevSecOps, MLOps, AIOps и т. д. Много разных аббревиатур, за которыми скрываются специальные направления или подходы и техники, внедряемые сегодня. Но под «капотом» это все те же люди, которые понимают в операционных системах и разбираются, как работают сети, могут написать код и знают определенные инструменты, специфичные для DevOps мира.

Перспективы профессии DevOps

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

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

Мне эта профессия очень нравится по той простой причине, что я могу постоянно изучать новое. Это и плюс, и минус одновременно. Все клиенты и все запросы одинаковые — «мы строим одинаковый замок из кубиков, но кубики разные». В конечном счете все клиенты хотят ускорить доставку своего кода, снизить количество ошибок, хотят оптимизировать затраты, хотят платить меньше за инфраструктуру, которая будет работать лучше. И путем внедрения каких-то технологий, какого-то стека и т. д. мы получаем на выходе какое-то «здание». С одной стороны, иногда надоедает обсуждать и предлагать то же самое. С другой стороны — каждый раз у тебя есть контекст конкретного проекта и стека.

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

Как понимать DevOps-инженеров лучше?

— Мы можем работать непосредственно с DevOps-инженерами, а можем не взаимодействовать с ними напрямую, но слышать на звонках какие-то аббревиатуры, слова, которые иногда могут вызывать непонимание, — объясняет Александр, — Для себя я выделил следующие термины, которые нужно знать начинающему DevOps-инженеру или тем, кто хочет попасть в эту профессию:

• CICD (continuous integration и continuous delivery или continuous deployment) — это некий непрерывный автоматизированный процесс доставки программного кода от идеи до конечного клиента. Это так называемые пайплайны, чтобы разработчики писали код, отправляли его в систему контроля версий и под «капотом» происходила магия, а именно — сборка кода, его тестирование, взаимодействие с другими департаментами. В конечном счете эта частичка кода становится доступной конечным клиентам, которые пользуется нашим продуктом. Ключевые метрики оценки качества CICD — это так называемые lead-time: время доставки от идеи до конечного клиента. Поэтому CICD наверняка есть на любом проекте, связанном с DevOps, за исключением каких-то очень узконаправленных, которые работают только с инфраструктурой, но и там скорее всего CICD замешан.
• Cloud. Все слышали про облачные вычисления и облачные технологии. Когда мы говорим облако, мы подразумеваем некий уровень абстракции. Мы не ходим к железному серверу у нас в подвале, который сильно шумит, греется и светится, как новогодняя елка. Мы платим кому-то, и этот кто-то для нас эти елки в большом количестве где-то хранит и обслуживает. Например, мы хотим из большого сервера получить какое-то количество ядер и оперативной памяти, чтобы там развернуть наш сайт. Мы платим, нам дают виртуальный кусок пирога, который мы используем. Вот этот уровень абстракции, когда мы взаимодействуем с кем-то там где-то там, и называется облака. Сегодня на международном рынке есть ключевые вендоры, такие как: Amazon Web Services, Microsoft, Google Cloud Platform, а также другие игроки чуть поменьше, но тоже набирающие обороты — Oracle, IBM и т. д. Их на самом деле много. Кроме того, некоторые заказчики строят свои приватные облака. Что это значит? У них есть парк серверов, и они таким же образом доставляют своим внутренним клиентам в компании, департаментам те же самые кусочки пирога. Только обслуживают это силами какой-то команды, которая у них есть. Условный бухгалтер не думает о том, где этот сервер находится, для него это просто точка входа в программу, где все работает.
• Configuration management — это некий класс инструментов, который позволяет описывать каким-то декларативным языком необходимое состояние системы. Например, у нас есть какой-то компьютер, и нам надо установить на него программное обеспечение: программу, браузер, что угодно. Мы это можем сделать руками, но со временем, если мы удалим эту программу, нам, чтобы ее установить снова, нужно вспомнить, как мы это делали вначале. Так вот configuration management позволяет описать необходимые шаги для установки какого-то программного обеспечения человеко читаемым языком, которые впоследствии программными средствами преобразуются в непосредственные команды на операционной системе. DevOps-инженеры занимаются этим, чтобы обеспечить быстрое восстановление в случае каких-то ручных изменений и чтобы быстро обновлять конфигурации на сотнях и тысячах серверов.
• Инфраструктура как код (infrastructure as code). То же самое, что и в предыдущем пункте: мы описываем декларативным языком сами сервера. Например, мы говорим, что хотим две виртуальные машины в облаке. Пишем в соответствии с документацией структуру текста, и благодаря разным инструментам, таким как terraform, у нас автоматически через специальные API в облаке создаются эти сущности. На выходе мы можем их также очень быстро изменять, обновлять, но не надо лишний раз кликать мышкой. DevOps-инженеры не любят кликать мышкой. Если какая-то операция делается больше одного раза, DevOps скорее всего захочет это автоматизировать, чтобы впоследствии это позволило не допускать ошибки.
• Alert — cамое нелюбимое и нежелаемое слово для DevOps-специалиста. Alert значит, что DevOps-инженеру надо идти и что-то чинить или разбираться, что не так. Поддержание качественного и постоянного работающего решения, которое строится в том числе под DevOps-подходу — это то, что обязательно включает в себя мониторинг. А мониторинг нужен не просто для того, чтобы снимать показатели системы, он должен еще отслеживать изменения в негативную сторону. Если у нас происходит что-то, чего мы не хотим, мы получаем alert. Например, кто-то нечаянно удалил нашу виртуальную машину — мы получаем alert. Кто-то нечаянно опубликовал какой-то внутренний IP-адрес в интернет, а кто-то другой начал его ломать — мы получили очень большое количество alerts.
• SRE (site reliability engineering). Это процесс, который одной из первых описала компания Google и который заключается в том, что инженеры, использующие SRE подходы, очень сильно вовлечены в работоспособность приложения. Если с приложением что-то не так, они первые, кто начинают выяснять и исправлять эту ошибку. Они следят за определенными метриками и отслеживают, чтобы этих alers было минимальное количество. Очень сложно сказать, кто есть SRE, кто DevOps. Кто-то называет себя так, кто-то так. По сути говоря, люди выполняют одну и ту же работу. Единственное отличие — считается, что SRE умеют программировать больше, чем DevOps. Если что-то случилось с системой, SRE может пойти и в коде исправить ошибку самостоятельно.
• SLA (service level agreement). SRE очень любят этот термин. Это какая-то цифра вокруг какой-то характеристики системы. Например, мы говорим, что наша система будет доступна для клиента в течение 95% всего времени в году. То есть мы утверждаем, что всего 5% времени в году наша система будет недоступна. Обе стороны подписывают это, и на этом строится договор. SRE как раз-таки составляют и следят за соблюдением таких метрик.
• Script. Это, как правило, текстовый документ, который с использованием какого-то языка программирования либо bash (скриптовый язык) позволяет выполнить набор ручных команд в автоматическом режиме. Это делается для того, чтобы автоматизировать то, что мы сделали когда-то руками и не хотим повторять это в будущем. Это что-то, как правило, легковесное, что делает очень простые вещи, но нам надо, чтобы это было автоматизировано. Например, нам надо раз в месяц пойти на какой-то сервер и удалить там мусорные файлы, чтобы у нас было чуть-чуть дискового пространства. Мы не будем это делать раз в месяц руками, мы напишем script, который будет автоматически это делать за нас на самом сервере.

Выбирай понравившуюся профессию в IT и изучай сленг:

• Что-то на айтишном: тестировщик
• Что-то на айтишном: бизнес-аналитик
• Что-то на айтишном: Data-аналитик
• Что-то на айтишном: UI/UX-дизайнер