DevOps-инженер – кто это такой, чем занимается и сколько зарабатывает

DevOps-инженер – кто это такой, чем занимается и сколько зарабатывает Должностные инструкции
Содержание
  1. Что такое devops
  2. Devops vs sre
  3. В какие языки надо погружаться
  4. В чём ещё участвует devops-инженер
  5. Вопросы запуска нашего решения в on-premise-окружении
  6. Журналирование и мониторинг
  7. Задачи, связанные со средой непрерывной интеграции (ci-средой)
  8. Знания, умения и личные качества
  9. Изучайте программирование
  10. Изучите git, научитесь документировать, узнайте о gitops
  11. Как devops решает проблемы разработки и операций
  12. Как стать devops‑инженером
  13. Как стать и куда двигаться дальше
  14. Как стать инженером devops
  15. Контейнеры, распределенные системы и service mesh
  16. Кто такой devops-инженер: зарплата, навыки, где научиться
  17. Мониторинг и проверка качества работы
  18. Непрерывное тестирование
  19. Непрерывные выпуск и развертывание
  20. Непрерывный мониторинг
  21. Обязанности специалиста
  22. Поймите культуру devops
  23. Понимание лучших практик в сфере кибербезопасности (devsecops)
  24. Постоянная обратная связь и оптимизация
  25. Преимущества и недостатки
  26. Противостояние devops, agile и традиционного it
  27. Развертывание с воспроизводимыми, надежными процессами
  28. Разрабатывайте и тестируйте в среде, похожей на производственную
  29. С чего начать составлять индивидуальный график
  30. Совместное развитие
  31. Типичный рабочий день devops-инженера
  32. Увалень, интроверт, агрессор: опыт классификации девопсов
  33. Усовершенствование циклов обратной связи

Что такое devops

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

Слово «DevOps» является объединением слов «разработка» (development) и «операции» (operations). DevOps помогает увеличить скорость доставки приложений и услуг. Это позволяет организациям эффективно обслуживать своих клиентов и становиться более конкурентоспособными на рынке.

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

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

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

Devops vs sre

SRE — еще одна развивающаяся тема в сообществе DevOps. Это набор практик и философий, разработанных Google. Вот что компания говорит о DevOps и SRE:

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

Я рекомендую изучить официальные документы от Google:

  1. What is SRE?

  2. SRE vs. DevOps: competing standards or close friends?

В какие языки надо погружаться

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

Поэтому следует самому покрывать код тестами и проверками и стремиться внедрять в pipeline автоматизированные тесты проверки исходного кода приложения. А ещё лучше иметь и то, и другое, и QG на них, чтобы, если код не соответствует правилам, его нельзя было влить в релизную ветку. Чем при этом пользоваться?

Python — модно, молодёжно, используется в машинном обучении и нейросетях, а также всевозможной автоматизации. Работать с подходами MLOps, DataOps крайне интересно, но для них нужен большой багаж знаний.

Java, Kotlin, Spring boot — мир корпоративного ПО, где много интересных технологий, микросервисов и взаимодействия со всеми участниками процесса. Лучше всего подходит для начинающих, чтобы быстро втянуться в основные технологии CICD и того, что есть у многих крупных компаний.

Go — ещё более модно и молодёжно, но порой сыровато, и надо скушать много известной субстанции, чтобы приготовить некоторое ПО, написанное на нём, а также выстроить цикл разработки.

C# — чистые шарпы — это тоже модно и корпоративно, но дважды подумайте, прежде чем захотите связываться с windows-стеком разработки всего, что с ним связано. Часто на нём идёт какое-либо легаси или монолит.

C# net core — несколько лучше, чем чистый C#, больше новых технологий, используется далеко не во всех компаниях, кроссплатформенный, но не забывайте, что это windows, который приготовить на linux порой бывает крайне беспощадно. Часто используется либо в смешанных системах из монолита и микросервисов, либо в микросервисах. Если у вас крепкие нервы, то вам сюда.

Ну и замкнём круги ада некоторым легаси: C, C , plsql, Delphi. В проекты, которые используют что-то из них, вы идёте исключительно на свой страх и риск. Вы окунётесь в тонну легаси, вендерлока и страданий. Только матёрые инженеры идут в этот путь, либо любители free bsd.

В чём ещё участвует devops-инженер

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

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

Между грумингом и демо идёт работа над задачами. У нас принят подход Infrastructure as Code. Это означает, что все изменения в нашей инфраструктуре мы описываем декларативным способом. Конфигурацию инфраструктуры мы держим в Git-репозитории, а все правки проходят через обязательный code review.

***

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

Вопросы запуска нашего решения в on-premise-окружении

В последнее время мы фокусировались на облаке, но уже есть задача подготовить продукт к on-premise, а с этим всё сложнее. Задачи могут быть как исследовательские (выбрать подход к тому, как мы будем разворачиваться, например), так и непосредственно связанные с имплементацией.

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

Журналирование и мониторинг

Журналирование и мониторинг — очень важные аспекты инфраструктуры.

Большинство приложений, развернутых в инфраструктуре, будут создавать журналы. Основываясь на дизайне архитектуры, журналы будут передаваться и храниться в отдельном слое инфраструктуры.

Каждая компания будет иметь отдельный уровень инфраструктуры под журналирование. Обычно используются такие стеки, как Splunk, ELK и Graylog. Кроме того, существует несколько SaaS-компаний, таких как Loggly, которые предоставляют инфраструктуру для централизованного хранилища журналов.

Разработчики, системные администраторы и команда безопасности используют системные журналы для мониторинга, диагностики неполадок, аудита приложений и инфраструктуры.

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

Также на основании правил, настроенных в системах мониторинга, будут срабатывать оповещения. Например, оповещение может быть в виде уведомления в Slack или Telegram, задачи в Jira, простого email, SMS-сообщения или даже звонка на телефон. Все схемы оповещения могут разниться от компании к компании.

Как инженер DevOps, вы должны иметь доступ к журналам и уметь устранять неполадки во всех средах (Dev, QA, Stage, Prod). Понимание регулярных выражений очень важно для построения запросов в любом инструменте централизованного хранилища журналов.

Задачи, связанные со средой непрерывной интеграции (ci-средой)

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

Знания, умения и личные качества

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

Специалист обязательно должен знать несколько языков программирования. В первую очередь это необходимо для автоматизации. Пригодятся языки Python, Bash, Ruby, Go, PowerShell. Достаточно знать основы синтаксиса, скрипты для автоматизации, понимать объектно-ориентированное программирование.

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

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

И вот еще тот минимум, что надо знать:

  • системы оркестрации, такие как Docker и Kubernetes;
  • системы конфигураций Chef, Ansible, Puppet;
  • системы сборки GitLab, Jenkins;
  • языки разметки JSON и YAML;
  • базы данных;
  • сервисы мониторинга и оповещений;
  • сервисы логирования;
  • настройки кибербезопасности;
  • процессы CI/CD;
  • английский язык;
  • периодическая таблица DevOps.

Список того, что нужно знать и уметь DevOps-специалисту можно продолжать долго. Но только практикуясь станет понятно, что именно изучать и как.

Для DevOps-инженера важны и личные качества:

  • системное мышление;
  • внимательность;
  • хорошая память;
  • коммуникабельность;
  • ответственность;
  • работоспособность;
  • исполнительность;
  • быстрая обучаемость.

Это только основные требования. Конкретные условия зависят от работодателей.

Изучайте программирование

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

Другие инструкции:  Скачать бесплатно должностную инструкцию механика 2020 | Форма, бланк

Например, для написания конвейера Jenkins в декларативном виде (как код) требуется знания Groovy; кастомный модуль Ansible требует знания Python; для написания оператора Kubernetes требуется опыт работы с Go.

Обратите внимание на следующие языки программирования, которые часто используются для написания скриптов или небольших программ:

Go действительно становится популярным в сфере DevOps. Его используют многие инструменты. Например, Kubernetes и Terraform написаны на Go. JFrog исследовал внедрение Go во время GopherCon, и 18 % респондентов заявили, что используют этот язык для работы, связанной с DevOps.

Изучите git, научитесь документировать, узнайте о gitops

Очень важно применять систему контроля версий ко всему, что вы делаете (кроме паролей и секретов). Git — лучший инструмент для этого. Для него доступно множество руководств, и изучение важных операций с Git не займет много времени.

Вы можете начать с Github или Bitbucket в качестве удаленного репозитория кода.

А как только вы поймете Git, изучите GitOps. Что этот такое?

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

Ещё очень важно документировать всё, что вы делаете. Каждый репозиторий должен иметь файл README, лучше объясняющий ваш код. Хорошая документация поможет не только вам, но и тем, кто попытается использовать вашу кодовую базу.

Как devops решает проблемы разработки и операций

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

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

Как стать devops‑инженером

Если совсем нет никаких знаний в IT-области, легко и быстро начать работать не получится. Необходимо иметь предварительную подготовку.

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

В чем обязательно надо разобраться перед началом работы:

  • освоить работу с локальными и глобальными сетями: уметь устанавливать, настраивать и управлять ими;
  • как писать скрипты на каком-либо языке программирования;
  • изучить объектно-ориентированное программирование;
  • в чем состоит жизненный цикл разработки продукта.

Не помешает и английский язык для чтения документации и интерфейса.

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

Как стать и куда двигаться дальше

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

«В голове нужно иметь библиотеку по всем доступным технологиям, начиная от методов кодирования сигналов до последнего модного продукта Open Stack».

Необходимые качества:— Аналитический склад ума;— Стрессоустойчивость;— Умение не сдаваться даже в безвыходных ситуациях.

«Важно понимать, что не разработчики плохие и делают такой продукт, а просто поставить себя на их место и помочь».

Возможные карьерные пути DevOps инженера:— Расти как DevOps специалист, углубляться в специализацию и осваивать смежные технологии;— Переквалифицироваться в разработчики, если начинали как системный администратор;— Переквалифицироваться в сисадмины, если начинали как разработчик (если интересно больше работать с инфраструктурой, чем с разработкой);

«На самом деле, лучше просто быть хорошим специалистом в _ЛЮБОЙ_ своей области, которая тебе нравится, и жить полной жизнью. И неважно, кто это — DevOp или химик нефти».

P.S. Спасибо за помощь в написании статьи Алексею Асютину и еще 5 украинским DevOps инженерам, которые поделились с DOU таинствами своей профессии. Приведенные в статье цитаты взяты из их рассказов.

Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно.І підписуйтеся на Telegram-канал редакції DOU

Как стать инженером devops

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

В этой статье объясняется, как вам следует подготовиться к использованию инструментов и технологий для адаптации и работы в культуре DevOps.

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

Контейнеры, распределенные системы и service mesh

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

Как только вы изучите Docker, можете попробовать его инструменты кластеризации и оркестрации, такие как Kubernetes, Docker Swarm и т.д. Эти платформы лучше всего подходят для архитектуры на основе микросервисов.

Вот интересная тенденция использования Kubernetes по данным Datadog:

А вот пятилетняя тенденция роста поисковых запросов по Kubernetes:

Кроме того, многие инженеры проявляют интерес к изучению Kubernetes, и в 2021 году немало людей получат сертификаты по этой технологии (CA, CKAD и CKD).

Service mesh — это выделенный слой инфраструктуры с низкой задержкой для обеспечения взаимодействия между сервисами. Он даёт массу возможностей для межсервисного взаимодействия: балансировки нагрузки, шифрования трафика, авторизации, трассировки, обнаружения сервисов (service discovery) и использования паттерна автоматического выключения (circuit breaker), с которым можно ознакомиться тут.

Кто такой devops-инженер: зарплата, навыки, где научиться

DevOps-инженер — связующее звено между всеми этапами создания продукта: от написания кода до релиза. Спрос на его труд растет из года в год, и даже младший специалист может рассчитывать на зарплату от 100 тыс. рублей. Мы попросили DevOps-инженера из Ростелекома, а также автора одноименного курса в SkillFactory Вячеслава Светлова разложить для нас его профессию по полочкам.

DevOps — это набор практик на стыке системного администрирования (Ops — Operations) и разработки (Dev — Development).

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

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

С приходом DevOps-инженера вся команда фокусируется на единой цели — создании качественного продукта.

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

DevOps-инженер синхронизирует все этапы создания программного продукта: от написания кода до тестирования и релиза.

Это профессионал, имеющий широкие знания в IT и понимающий, как прийти к конечному продукту. Он хорошо разбирается в инфраструктуре, понимает принципы разработки приложений и построения их архитектуры. Еще он — менеджер-практик, знающий жизненный цикл приложения и современные методологии разработки.

DevOps-инженер участвует во всем цикле создания ПО. Источник

DevOps-инженер:

Есть два друга, которые хотят пожарить мясо на природе. Итоговый продукт их деятельности — шашлык. Друзья распределяют между собой задачи: один нанизывает мясо на шампур (сравним его с разработчиком), другой собирает мангал и разводит огонь (сравним его с инженером инфраструктуры).

Угли готовы, мясо на шампурах, положили шампуры на мангал — ждут. Но пошел дождь, надо перенести мангал под тент, чтобы угли не потухли. Одному это сделать трудно, дождь усиливается.

Без DevOps-культуры разработчик (отвечающий за нанизывание мяса на шампуры) может сказать: «Мясо на шампурах — моя работа сделана. Дальше разбираться я не буду», — и в итоге шашлыка никто не поест.

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

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

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

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

Вячеслав Светлов:

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

IDC прогнозирует, что количество специалистов DevOps с 2021 по 2024 год возрастет в два раза. Ожидается, что к 2024 году минимум 30% компаний внедрят полноценный цикл DevOps.

По данным Research and Markets сфера DevOps переходит из нишевого инструмента в глобальный рынок, который имеет просто колоссальный потенциал для роста. За период карантина в 2020 году рынок вырос на 29,3%.

Другие инструкции:  Должностная инструкция повара | Должностные обязанности повара, образец должностной инструкции повара

В марте 2021 года на сайте hh.ru было более 4,3 тыс. вакансий DevOps-инженера.

Можно заметить рост популярности запроса «devops» и других запросов по теме на графиках от сервиса Google Trends.

Зарплата зависит от компании и навыков. Младший специалист DevOps в Москве получает от 70 до 150 тыс. рублей в месяц, а зарплата ведущего составляет примерно 250 тыс. рублей. По данным Хабр Карьеры, во втором полугодии 2020 года средняя медианная зарплата специалиста DevOps составила 155 тыс. рублей.

На сайте hh.ru можно найти вакансии с зарплатой более 400 тыс. руб. в месяц. Больше всего вакансий предполагают доход от 105 тыс. до 265 тыс. рублей.

Плюсы профессии:

Минусы профессии:

Курс

Devops-инженер

Освойте перспективную IT-профессию на стыке разработки, системного администрирования и бизнеса. Дополнительная скидка 5% по промокоду BLOG.

Узнать больше

Agile — обобщающий термин для целого набора принципов, подходов и практик, основанных на ценностях гибкой разработки. Такую методологию применяют для организации труда небольших групп. Она нацелена на минимизацию рисков при работе с помощью разделения разработки на короткие циклы, каждый из которых выглядит как отдельный конечный проект. Каждый из этапов обычно включает в себя спектр задач: планирование, анализ требований, проектирование, программирование, тестирование и документирование.

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

Читайте: полный разбор на Хабре.

Вячеслав Светлов:

Я пришел в специальность из системного администрирования около трех лет назад. До этого работал в центре обработки данных (ЦОД), занимался системами мониторинга приходилось заниматься как администрированием, так и немного разработкой. После решил попробовать себя в DevOps, там и остался.

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

Узнать больше о сетях можно в книгах «Компьютерные сети» Виктора и Натальи Олифер и «Руководство по подготовке к экзамену CCNA» Уэнделла Одома. А ознакомиться с Linux и операционными системами в целом помогут «Настольная книга Unix & Linux системного администратора» Эви Немет и «Современные операционные системы» Эндрю Таненбаума.

Присоединяйтесь к профсообществам на форумах и в соцсетях, чтобы лучше понимать тенденции рынка и обращаться за советами:

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

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

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

Курс

DevOps-инженер

Освойте перспективную IT-профессию на стыке разработки, системного администрирования и бизнеса. Дополнительная скидка 5% по промокоду BLOG.

Смотреть программу

Мониторинг и проверка качества работы

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

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

Непрерывное тестирование

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

Непрерывные выпуск и развертывание

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

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

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

Непрерывный мониторинг

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

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

Обязанности специалиста

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

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

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

После релиза DevOps-специалист налаживает обратную связь от пользователей, внедряет улучшения и обновляет продукт.

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

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

Поймите культуру devops

Прежде всего, необходимо понять культуру DevOps. Всё дело в объединении людей для эффективной работы над общей целью.

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

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

Как только вы начнете практиковать культуру DevOps, вы перестанете говорить, что «это синоним CI/CD и автоматизации».

Понимание лучших практик в сфере кибербезопасности (devsecops)

DevSecOps — ещё одна область, связанная с интеграцией практик безопасности на каждом этапе DevOps. Википедия говорит:

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

Обзор инфобезопасности в 2020 показывает распределение разных кибератак по регионам:

В облачных средах криптомайнинг является распространенной атакой. В основном это происходит, когда секреты облачного доступа хранятся плохо, так что хакеры получают к ним доступ.

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

А вот основные стандартные практики DevSecOps, опубликованные Redhat:

Hashicorp Vault — отличный инструмент для управления секретами. Существует множество рабочих процессов для управления секретами среды.

Постоянная обратная связь и оптимизация

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

Преимущества и недостатки

Главное достоинство профессии DevOps engineer — рост интереса компаний к концепции DevOps. По данным EMA, около 30% компаний уже реализовали или планируют реализовать DevOps в ближайшее время. То есть спрос есть — без работы хороший специалист не останется.

Самих DevOps специалистов привлекает то, что в работе они имеют 100% загрузку, в отличие от профессии системного администратора.

«Нравится фактор неожиданности — это делает работу довольно интересной и не превращает в рутину».

Другой плюс — широкая специализация:

«На мой взгляд, девелопмент проигрывает оперейшеналу по простым причинам. Девелопер имеет в руках инструмент, которым он делает свою работу — синтаксис языка и какие-то там языковые примочки и особенности. Оперейшенал инженер знает кучу всего, на чем строится современные информационные системы, как они работают, и изучение какого-то Ruby мало чем будет отличаться от изучения системы мониторинга Ganglia».

Некоторых привлекает то, что результат работы можно «потрогать руками»:

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

Другие инструкции:  Должностная инструкция уборщика служебных помещений » Каменно-Бродская Средняя Общеобразовательная Школа Официальный сайт

Недостатки профессии, похоже, не отличаются от таковых у системных администраторов:

«Ночные неожиданности».

Противостояние devops, agile и традиционного it

DevOps часто обсуждается в связи с другими ИТ-практиками, в частности, гибкой и водопадной ИТ-инфраструктурой.

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

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

Сравнение традиционной водопадной модели с DevOps – хороший способом понять преимущества, которые дает DevOps. В следующем примере предполагается, что приложение будет запущено через четыре недели, разработка завершена на 85%, приложение будет запущено, и процесс закупки серверов для отправки кода только что был начат.

Развертывание с воспроизводимыми, надежными процессами

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

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

Разрабатывайте и тестируйте в среде, похожей на производственную

Суть заключается в том, чтобы позволить командам разработчиков и специалистов по контролю качества (QA) разрабатывать и тестировать системы, которые ведут себя как производственные системы, чтобы они могли видеть, как приложение ведет себя и работает задолго до того, как оно будет готово к развертыванию.

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

С чего начать составлять индивидуальный график

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

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

  1. Опыт работы и понимания принципов работы Linux.

  2. Понимание работы сетей, хотя бы на уровне сетевых протоколов и уровней TCP/IP.

  3. Понимание принципов работы виртуализации и умение работать с ней.

  4. Понимание работы контейнеров, умение их готовить.

  5. Понимание разницы между монолитной и микросервисой архитектурой. Набор паттернов при построении архитектуры, анти-паттерны.

  6. Понимание культуры и принципов взаимодействия в команде на базе agile, devops. Понимание подходов к организации разработки: kanban, scrum.

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

  8. Понимание принципов работы с репозиторием, версионирования кода, подходов к разработке, например, стандартный gitflow.

  9. Понимание безопасности кода, как можно использовать подходы к нему, включить в pipeline.

  10. Подходы к тестированию кода, виды тестирования, тулзы для АТ: mock, системное, нагрузочное, регресс.

  11. Подходы к тестированию инфраструктурного кода и автоматизации этого тестирования.

  12. Базовые принципы и виды мониторинга, алёртинга, какие есть тулзы. Что такое LogTracing, подходы OpenTracing, OpenTelemetry. 

  13. Умение понимать, какие задачи стали рутинными, чтобы можно было их автоматизировать и перестать на них тратить время.

И два бонуса из не совсем технической части: 

Совместное развитие

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

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

Типичный рабочий день devops-инженера

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

После встречи DevOps-инженер работает над своими задачами с учётом возможных изменений, оговорённых во время стендапа. Чаще всего он общается с разработчиками и с IT-службой, если нужно запросить больше ресурсов on-premise или получить дополнительные доступы для команды.

Многие задачи занимают много времени. Иногда можно провести целый рабочий день оптимизируя что-либо или пробуя те или иные подходы. Как выглядит одна из типичных рабочих задач? Например, сейчас очень актуально создание CI/CD pipeline в Kubernetes для того, чтобы разработчик мог убедиться, что продукт в системе собирается, работает, интегрируется и готов к продвижению по тестовым средам.

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

Увалень, интроверт, агрессор: опыт классификации девопсов

Градация среди инженеров по уровню задач, которые они решают, безусловно, есть. Это, конечно, стандартная база: junior, middle, senior. Но мои наблюдения показывают, что даже на этих уровнях различия между специалистами очень большие.

Junior — начинающий специалист, который либо только пришёл в профессию, либо имеет минимальный набор знаний. Моя дополнительная классификация джуниоров:

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

  • Разработчик-интроверт — он может быть хорошим специалистом, иметь прекрасные hard skills, но минимальный уровень гибких навыков, а потому над ним всегда должен быть сеньор или менеджер, который будет ему помогать.

  • Любитель поговорить — обладает хорошими гибкими навыками и чуть выше уровня junior hard skills, на чём и выезжает. Активен, участвует во всех встречах, летучках, созвонах, сборах требований. Очень часто такие специалисты становятся менеджерами. 

  • Проджект — человек, обладающий неплохими гибкими навыками, неплохими hard skills, умеет делать проекты «от и до». Очень близок к сеньору. 

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

Ну и самое интересное — senior DevOps. Это люди, которые повидали такое на свете, о чём не стоит говорить в приличном обществе. Могут менторить, вести проекты от и до. Я общался с разными сеньорами:

  • Архитектор — занимается проектированием hardware и app уровнями систем, которые только начинают или планируют внедряться. За счёт опыта и сплита навыков hard и soft может один сделать проект от сотворения вселенной до продакшена.

  • Активист — этот в каждой бочке затычка. Он говорлив, активен, энергия бьёт ключом. Часто посещает конференции, слушает подкасты, читает разные порталы. Такие очень часто участвуют в пилотах новых продуктов, предлагают продукты для внедрения/пилотов. Входят в различные инициативные группы и комитеты, помогая выстроить процесс. Чаще всего являются лидами.

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

Главное, что можно сказать о переквалификации в DevOps — всё индивидуально. 

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

Тут я рекомендую не искать серебряную пулю, а составить личный график саморазвития.

Так называемый ИПР, или индивидуальный план развития. Затем разделить его на временные рамки и далее следовать ему. Постепенно, двигаясь по вашему личному ИПР, вы будете набирать экспертизу и получать левел-апы. Опять же, такой подход работает в любом обучении.

Усовершенствование циклов обратной связи

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

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

Оцените статью
Добавить комментарий