Что такое DevOps для системного администратора?

Что такое DevOps?

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

Истина где-то посередине. DevOps — это все перечисленное, взятое вместе. Его главная задача — ускорить доставку продукта от бизнеса до потребителя. Сам термин был придуман независимым IT-консультантом Патриком Дебуа примерно двенадцать лет назад. Он хотел разрушить метафорическую стену между разработчиками (dev) и сисадминами (ops), объединить их в одно эффективное подразделение, которое может создавать ПО быстрее, выкатывать релизы чаще и с меньшим количеством ошибок.

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

Минутка скучной статистики. По исследованию DORA (DevOps Research and Assessment), кросс-функциональные команды, использующие DevOps-подход:

  • в 208 раз чаще развертывают код;
  • в 106 раз сокращают время от коммита до развертывания;
  • в 2,604 раза быстрее восстанавливают системы после сбоев;
  • в 7 раз снижают сам шанс сбоя в результате изменений.

Конечно, само по себе объединение dev и ops не приводит к такой эффективности. DevOps-подход включает в себя использование множества новых инструментов разработки, тестирования и развертывания для организации CI\CD (концепция непрерывной интеграции и доставки). Среди самых известных:

  • Git и GitHub — системы управления исходным кодом;
  • Jenkins — сервер автоматизации для создания конвейеров CI/CD;
  • Docker — ПО для автоматизации деплоя и управления приложениями в средах с поддержкой контейнеризации;
  • Kubernetes — открытая система оркестрации контейнеров;
  • Chef, Puppet и Ansible — средства для автоматического конфигурирования и развертывания;
  • Selenium — решение для автоматизации тестирования;
  • Prometheus и Nagios — программы для мониторинга серверов;
  • Grafana — решение для сбора и анализа метрик.

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

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

Суть работы DevOps-инженера

На базовом уровне DevOps-инженер — это технический специалист, который понимает все основные этапы жизненного цикла разработки ПО, исправляет узкие места в процессах и занимается настройкой среды:

  • пишет код для автоматизированного развертывания приложений;
  • отвечает частично за их доступность, не самолично как сисадмин, а вместе со своей командой;
  • несет дежурство по своей инфраструктуре (разбирается с ошибками, иногда вместе с программистом).

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

В DevOps это работает немного по-другому. Приложение разворачивается при помощи скриптов. DevOps-инженер задает некую последовательность действий, которая приносит код, написанный программистом, сначала на тестовый сервер, а потом на боевой (если принято решение, что изменения можно релизить). Таким образом, у разработчика есть возможность проверять свой код хоть каждые 15 минут и делать это даже в три часа ночи простым нажатием на кнопку.

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

Это тоже моя работа

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

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

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

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

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

Сколько зарабатывают DevOps-инженеры?

Зарплата DevOps-инженера зависит от навыков, места работы и региона проживания. Средний годовой доход в Штатах, как говорят некоторые HR, колеблется от 100 до 125 тысяч долларов США, согласно данным, опубликованным компанией Puppet. В Австралии и Новой Зеландии — 75-100 тысяч долларов США. В Европе — 50-75 тысяч долларов США. В Азии DevOps-инженеры получают не больше 25 тысяч долларов США в год.

Если вам интересна тема DevOps, то обязательно переходите по ссылке и знакомьтесь с нашими курсами по DevOps-инструментам.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *