Category: DevOps

16
Июл
2021

JetBrains опубликовала ежегодный отчёт о мире разработки The State of Developer Ecosystem 2021. Основные тезисы

JetBrains опросила разработчиков из 183 стран, чтобы составить ежегодный отчёт об экосистеме разработки в 2021 году. Вот основные тезисы исследования.
— Читать дальше «JetBrains опубликовала ежегодный отчёт о мире разработки The State of Developer Ecos…

10
Июл
2021

∞ Легко ли перейти из сисадминов/разработчиков в DevOps?

Развитие сферы IT делает некоторые профессии неактуальными, и пальма первенства переходит к более востребованным на рынке. Направление DevOps – одно из таких. Мы расспросили разработчицу и сисадмина о том, почему и как они перешли в DevOps.

Инженер DevOps и разработчик/сисадмин: в чем разница?

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

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

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

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

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

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

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

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

  • настройка облачных виртуальных машин и сервисов;
  • навыки программирования и написания сценариев;
  • понимание непрерывной интеграции (CI);
  • понимание безопасных и эффективных стратегий развертывания ПО;
  • навыки управления конфигурациями;
  • знание методов контейнеризации приложений;
  • практический опыт работы с платформами IaaS, вроде AWS и Microsoft Azure;
  • навыки коммуникации и другие soft skills.
Рассматривая разницу между DevOps-инженером и разработчиком, важно отметить, что последний сосредоточен на соответствии программного продукта потребностям клиента. Спектр обязанностей DevOps-инженера гораздо шире и включает разработку и развертывание программного обеспечения, а также обеспечение оперативной поддержки заказчиков.

В обязанности разработчика входит:

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

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

Опыт специалистов

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

Глафира Иванова, DevOps Engineer компании MedIndex

О начале карьеры
В сфере IT я работаю больше пяти лет. По образованию социолог (закончила факультет социологии СПбГУ). К концу обучения я поняла, что к социологии у меня душа не лежит, а выпускники, которые не идут в науку, обычно работают в кадрах или в рекламе. Я попробовала работать в обоих направлениях, но быстро поняла, что это совсем не мое. В то время бросать все и входить в IT еще не было такой популярной идеей, но онлайн-курсы по обучению чему угодно были уже весьма популярны. Я вспомнила, что уже проходила простенькие курсы по верстке (просто из любопытства) и мне понравилось. В связи с этим нашла первый попавшийся курс по программированию посерьезнее и села учиться.

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

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

В какой-то момент все мои коллеги-бэкендеры уволились и я стремительно выгорела, поэтому решила поискать другую работу. Учитывая, что опыт в программировании у меня был к тому моменту не слишком положительный, я подумывала о том, чтобы слегка сменить сферу деятельности (что довольно нетрудно в IT, особенно вначале).

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

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

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

Это включает множество различных задач:

  • настройку CI/CD;
  • сопровождение продуктов;
  • поддержку инфраструктуры;
  • мониторинг;
  • траблшутинг (устранение неполадок);
  • усилия по автоматизации и улучшению процессов.

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

О навыках

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

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

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

О необходимом для специалиста стеке технологий


Советую изучать:

  • ОС Linux;
  • какой-нибудь из скриптовых языков (Python, например, но наверняка придется писать и на Bash);
  • Docker;
  • Kubernetes;
  • Ansible;
  • Prometheus;
  • ELK-стек;
  • инструменты для CI/CD (Jenkins/GitLab CI);
  • полезно попробовать работать с публичными облаками (например, с AWS).

О проблемах, которые могут возникнуть в начале карьеры

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

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

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

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

Дмитрий Евстюхин, Senior Cloud Solutions Architect компании Provectus

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

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

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

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

Роль DevOps-инженера очень разнится от компании к компании. Есть определенные схожие функции, например, настройка и поддержка CI/CD пайплайнов. Часто к этой роли относят и инфраструктурные вопросы, особенно в облаках. Мне также приходилось проектировать и настраивать инфраструктуру со всеми нужными сервисами: мониторингом, логированием и так далее. Помогал командам разработки настроить их процесс, щедро сдобрив его автоматизацией и петлями обратной связи. Иногда нужно было помочь разработчикам лучше использовать возможности среды, объяснить, как правильно жить в облаке или Kubernetes.

Считаю, что DevOps – это мастер на все руки, поэтому хотя бы раз я делал в команде все сразу.

О навыках

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

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

Из hard skills я бы выделил скрипты и арсенал поверхностного понимания технологий. К примеру сертификация уровня Associate любого облака дает такой арсенал. Чем шире арсенал, тем лучше, но это не имеет большого смысла, если нет фундамента. В роли фундамента для хорошего специалиста DevOps обычно выступает глубокая экспертиза в администрировании Unix-like систем и сетевое администрирование.

О необходимом для специалиста стеке технологий

В первую очередь новичку в DevOps нужно закладывать фундамент, то есть осваивать операционные системы и сетевые технологии. Если есть достаточное понимание вышеперечисленного, стоит изучить скрипты на Bash/Python. Потом перейти к Ansible, Terraform, Jenkins, Kubernetes.

О проблемах, которые могут возникнуть в начале карьеры

Мне вспоминается ощущение ошеломления, когда я впервые увидел список технологий, которые мне нужно было изучить на своей первой работе DevOps-инженером. Из всего списка я слышал только об одной или двух, остальные были загадкой. Сначала этот океан технологий выглядит просто непокоримым, но со временем начинаешь понимать – везде примерно одно и то же, только с разными «бантиками». Жизнь становится проще, но это не умаляет объем технологий, которые надо изучить на начальном этапе.

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

Как влиться в новую команду?
Команда команде рознь. Самый главный метод адаптации – найти ментора, который поможет, покажет и научит. Хотя обычная ситуация, когда DevOps команды «в огне»: людей не хватает, задач много, все горит и никто ничего не успевает… в этом случае нет времени на новичка, и ему требуются недюжинные навыки самоорганизации, настойчивость, чтобы получить всю нужную информацию и стать полезным.

Выводы

В итоге именно вы решаете в каком направлении двигаться – стать системным администратором, разработчиком или перейти в DevOps. Как и во многих смежных направлениях, эти роли частично пересекаются. Системные администраторы уже имеют опыт написания сценариев и могут быть знакомы с технологиями автоматизации развертывания приложений, управления конфигурациями и так далее. Многие разработчики имеют представление о системном администрировании, так что изучать неофиту придется не половину (Dev или Ops), а немного меньше.

***

Если вы только собираетесь освоить популярную профессию, стоит обратить внимание на курс «Старт в DevOps: системное администрирование для начинающих» образовательной онлайн-платформы Skillbox. Там вы сможете получить навыки администрирования Linux, научитесь настраивать веб-серверы и поддерживать работу сайтов, а также усвоите базовые знания для развития в DevOps-инженерии.

За год занятий с экспертами-практиками вы соберете портфолио и сможете начать карьеру системного администратора в IT-компании. Если ваша цель – стать инженером DevOps, вы сможете попрактиковаться на реальных проектах и получите базовые навыки для развития. Продолжить обучение можно на продвинутых курсах: «Профессия DevOps-инженер», «Профессия DevOps-инженер PRO» и «Инфраструктурная платформа на основе Kubernetes». Все интересующие вопросы вы сможете задать куратору в чате Telegram, а ваши домашние задания лично прокомментирует преподаватель и даст полезные советы.

08
Июл
2021

🐧 Проектирование контейнеров (часть 2): в чем важность пространства пользователя?

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

23
Июн
2021

🔄 Сетевой инженер или DevOps: в каком направлении развиваться сисадмину?

Развитие сферы ИТ приводит к тому, что некоторые специальности постепенно теряют актуальность. Есть мнение, что системный администратор – одна из умирающих профессий. Разбираемся правда ли это и в каком направлении стоит развиваться сисадмину.

Системный администратор – это специалист, который занимается настройкой, совершенствованием и поддержкой ИТ-инфраструктуры компании, включая оборудование, периферию, программное обеспечение и сетевые подключения.

Основные обязанности системного администратора:

  • Установка и настройка компьютеров и оргтехники;
  • Обслуживание локальной сети и АТС;
  • Обеспечение бесперебойной работы серверов;
  • Создание учетных записей пользователей;
  • Определение уровней доступа сотрудников;
  • Установка и обновление ПО;
  • Контроль безопасности данных и их резервное копирование;
  • Инвентаризация и закупка оборудования.
Получается, сисадмин – специалист широкого профиля, без которого трудно себе представить работу даже небольшого офиса. На портале hh.ru по запросу «Системный администратор» можно найти более пяти тысяч вакансий с зарплатной вилкой от 30 000 рублей для начинающего специалиста, до 100 000 рублей для опытного профессионала. Непохоже на вымирающую должность, но некоторые проблемы в этой сфере все-таки есть.

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

Бизнесмены, запомните: хорошему сисадмину платят за то, что он не работает!

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

Выход здесь один: относиться к работе как к источнику опыта и менять ее при первой возможности.

Будущее системного администратора

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

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

Сетевой инженер


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

Главное отличие от сисадмина в том, что сисадмины чаще обслуживают готовую инфраструктуру (если не считать небольших организаций, где айтишники «от скуки на все руки»), а сетевой инженер должен уметь построить и задокументировать корпоративную сеть с нуля. Также его работа предполагает взаимодействие с активным сетевым оборудованием таких вендоров, как Cisco, Mikrotik, Juniper и т.д.

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

Чтобы стать сетевым инженером вы должны знать:

  • Компьютерные сети на уровне не ниже CCNA/CCNP;
  • Основы безопасности сетей;
  • Основы дизайна сетей;
  • Активное сетевое оборудование (маршрутизаторы, коммутаторы, межсетевые экраны);
  • Технологии виртуализации;
  • ОС Linux и Windows Server;
  • Скриптовые языки программирования (bash, python).
Темпы карьерного роста зависят в основном от усердия и желания учиться. Если регулярно тратить на саморазвитие час-полтора в день, можно менее чем за два года вырасти с джуна до синьора. Ключевое различие между ними в том, что джуны обычно выполняют простые рутинные задачи, а синьоры занимаются более комплексными и сложными проектами, а также архитектурой сети и глобальными преобразованиями в ней. Чтобы расти, стоит начать собирать схемы в виртуальной лаборатории и изучить работу протоколов.

Инженер DevOps


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

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

Инженер DevOps – специалист, который внедряет эти методики в рабочий процесс.

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

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

Также в задачи специалиста входит написание большого количества кода на скриптовых языках: Python, GoLang или Bash.

Чтобы стать инженером DevOps вы должны знать:

  • Основы компьютерных сетей;
  • Администрирование Linux;
  • Скриптовые языки программирования;
  • Технологии виртуализации;
  • Облачные сервисы;
  • Инструменты DevOps:
  • Системы мониторинга и тестирования.

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

Другой материал по теме: как освоить профессию инженера DevOps.

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

***

Если вы не стоите на месте и хотите развиваться, обратите внимание на факультет «Сетевой инженер» образовательной онлайн-платформы GeekBrains. За одиннадцать месяцев вы изучите основы сетевых технологий, коммутацию и маршрутизацию, безопасность, масштабирование сетей и автоматизацию сетевой инфраструктуры, сделаете 2 проекта для портфолио, а также получите диплом о переподготовке и помощь в трудоустройстве.

21
Июн
2021

Конференция ZeroNights 2021

Эксперты по информационной безопасности, 4 тематических секции, воркшопы, встречи и конкурсы в городском пространстве Санкт-Петербурга.
— Читать дальше «Конференция ZeroNights 2021»

17
Июн
2021

Project Hiring Week

EPAM набирает команду разработчиков, инженеров, тестировщиков и аналитиков для работы в проектах Выделенного Центра Разработки. Оффер через 48 часов и welcome-бонус в размере одного оклада.
— Читать дальше «Project Hiring Week»

16
Июн
2021

∞ Путь в профессию: интервью с инженером DevOps

Библиотека программиста продолжает серию интервью с представителями IT-индустрии. Наш корреспондент побеседовала с Алексеем Шараповым, Head of DevOps компании «ЦРПТ». Он рассказал о своем пути в отрасли, какие требования к кандидатам предъявляют работодатели и стоит ли считать DevOps профессией или только ролью.

Библиотека программиста: Добрый день, Алексей! Расскажите, пожалуйста, для начала о своем бэкграунде. Где учились, работали, прежде чем стать инженером DevOps?

Алексей Шарапов: Учился в Ярославском Государственном Техническом Университете по специальности «Органическая химия», но вскоре понял, что больше люблю разработку и все, что с ней связано.

Еще в университете я, читая разные статьи, наткнулся на самые первые упоминания DevOps. Это был примерно 2013 год, статья Барух Садогурского, которая меня невероятно впечатлила. Тогда было абсолютно непонятно что такое DevOps, кроме того, что этим занимаются парни, которые погружены в администрирование и разработку с одинаковой интенсивностью. Мне понравилось, загорелся идеей и решил для себя, что буду заниматься именно DevOps.

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

Б.П.: С чего начался ваш путь в профессию, почему решили уйти именно в DevOps?

А.Ш.: Мой путь в профессии начался с двух направлений параллельно. На основной работе я занимался администрированием парка серверов и в это же время разрабатывал сайты на фрилансе. После этого более глубоко погрузился в администрирование, Linux сервера. При этом разработку не бросал никогда, делал простые задачи, изучал Java и даже брался за задачи по разработке наравне с коллегами. Также проходил курсы по разработке на Java для более глубокого погружения, курсы по PHP и JavaScript, так как хотелось больше узнать о программировании изнутри.

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

Б.П.: Дайте свое определение DevOps.

А.Ш.: DevOps – это практики, направленные на взаимодействие между отделом разработки и отделом Ops, которые помогают быстрее поставлять продукт с меньшим количеством ошибок и проблем.

Б.П.: По вашему мнению, DevOps – это профессия или часть обязанностей?

А.Ш.: На мой взгляд DevOps – это часть обязанностей, процесс, но никак не профессия. Мне очень нравится, когда разработчики или администраторы глубоко погружаются в эти вопросы и сами могут решить большую часть проблем.

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

А.Ш.: Требования к специалистам с одной стороны растут, даже к джуниорам. С другой стороны – нехватка хороших инженеров DevOps позволяет на некоторые вещи закрыть глаза.

На данный момент я определяю требования к специалистам разных уровней следующим образом:

  1. Junior – это базовые знания Linux-администрирования, базовые знания одного-двух языков программирования, для старта этого бывает достаточно;
  2. Middle – к требованиями выше добавляются знания базовых инструментов контейнеризации, оркестрации, систем сборок, понимания принципов построения CI/CD процессов;
  3. Senior – ко всему прочему добавляется широкий бэкграунд в разных технологиях, а также умение правильно построить процесс и дать грамотную оценку задачи. Немаловажным является умение наладить контакт с коллегами. У специалиста, который будет в роли прокси-сервера между отделами, так называемые софт скиллз должны быть на высоте.

Б.П.: Опишите ваш типичный рабочий день.

А.Ш.: Типичный день обозначить очень сложно, так как каждый приносит что-то новое и интересное.

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

Б.П.: Какой стек технологий вы используете в работе?


А.Ш.: Стек технологий, который я использую в работе, достаточно широк. Это и K8S для запуска сервисов, GitLab CI для процессов CI (непрерывной интеграции), Ansible в связке с Python – для автоматизации всего.

Вокруг этих инструментов сосредоточен еще очень большой набор технологий. Например, Helmfile для накаток на разные среды, Argo CD в других проектах, иногда приходится писать на Go (например для экспортеров), где-то копаться в Java.

Б.П.: Какие технологии сейчас становятся более популярными, что учить, чтобы быть на шаг впереди остальных?

А.Ш.: Я бы выделил K8S, сейчас без него никуда. А также весь около K8S стек технологий. Это и Helm и GitOps-инструменты. Ну и облачные платформы – AWS и GCD идут впереди планеты всей и позволяют делать невероятные вещи.

Б.П.: К каким трудностям в профессии специалист DevOps должен быть готовым?

А.Ш.: Первое, что я выделил бы – понимание того, что коммуникации будут составлять достаточно большую часть вашей работы. Второе – вы должны всегда успевать за стеком разработчиков, за их изменениями и нововведениями. Ну и третье – отслеживать, что нового в индустрии, а новостей всегда много: K8S без Docker, Ansible без модулей и все в этом духе. Высокий темп в этой области превосходит многие другие.

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

Б.П.: Сколько лет вам понадобилось, чтоб вырасти до уровня senior? Что больше всего повлияло на ваш рост, как специалиста?

А.Ш.: До senior я морально вырос спустя семь лет с начала работы. Сейчас я лид направления DevOps в компании, руковожу лидами DevOps в группах разработки, но не бросаю и работу руками. Работаю с командами разработки, эксплуатации. Стараюсь уделять внимание и той и другой стороне.

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

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

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

Самая моя любимая книга для новичков – «Unix и Linux: руководство системного администратора», Немет Эви, Снайдер Гарт.


Полезно смотреть видеозаписи крупных российских и зарубежных конференций, таких как DevOpsConf, KubeCon, DockerCon.

Из ресурсов я читаю в основном блоги на официальных сайтах Docker, K8S, Red Hat, ну и Хабр, он до сих пор несет много полезной информации.

Выводы

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


***

Если вы находитесь только в начале пути, стоит обратить внимание на курс Факультета DevOps образовательной онлайн-платформы GeekBrains. Эксперты-практики из ведущих российских технологических компаний научат вас использовать методологии Agile и Scrum, оптимизировать CI/CD и работать с облачными технологиями. Курс подойдет как новичкам в IT, так и опытным специалистам, которые хотят сменить направление.

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

Успешно окончившим курс студентам HR-специалисты GeekBrains помогут создать резюме и предложат вакансии. Гарантия трудоустройства закреплена в договоре.

09
Июн
2021

Хакатон INNOHACK 2.0

Команды из разработчиков, аналитиков, тестировщиков, DevOps-инженеров и UI/UX-дизайнеров должны решить одну из 5 бизнес-задач. Призовой фонд — 1,2 млн рублей. Заявки принимаются до 15 июня.
— Читать дальше «Хакатон INNOHACK 2.0»

01
Июн
2021

Курс «Fullstack-разработчик на Python»

За 15 месяцев можно стать Fullstack-разработчиком с портфолио и получить работу при поддержке карьерного центра SkillFactory.
— Читать дальше «Курс «Fullstack-разработчик на Python»»

21
Май
2021

☸️ Первое знакомство с Kubernetes: установка кластера k8s вручную

В небольшом цикле статей мы поближе познакомим читателей с оркестратором Kubernetes. Для начала настроим кластер k8s c нуля на VPS-хостинге с помощью Kubespray.

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

Быстрый deploy приложений;

Удобное масштабирование
развернутых приложений;

Внутренние self-health;

Нулевой простой при
обновлениях приложений.

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

Варианты установки

k8s можно развернуть несколькими способами в зависимости от ваших целей и времени, которое вы намерены потратить. Есть быстрые варианты, вроде GKE (Google) или EKS (Amazon). Они позволяют быстро поднять кластер, не задумываясь о его внутреннем устройстве: вы получите результат менее чем за 5 минут.

Если вам интересно
погрузиться в тему поглубже и буквально собрать k8s в ручном режиме, эта
статья поможет. Поехали 🙂


Подготовка

В дальнейшем мы будем
использовать созданный кластер для публикации различных сервисов и поэтому установку будет производить на VPS. Для кластера потребуется несколько виртуальных машин:

Master node (CentOS 7, 1vCPU, RAM 2 ГБ, HDD 10 ГБ);

Worker node (CentOS 7, 1vCPU, RAM 2 ГБ, HDD 10 ГБ);

Worker node (CentOS 7, 1vCPU, RAM 2 ГБ, HDD 10 ГБ);

Ingress node (CentOS 7, 2vCPU, RAM 8 ГБ, HDD 10 ГБ).

На всех узлах нашего кластера k8s установлена хост-система CentOS 7. Если вы хотите использовать другую хост-систему, ищите информацию на официальном сайте Kubernetes. Рассмотрим вариант развертывания с помощью Kubespray – набора ролей Ansible для
установки и конфигурирования k8s.

Развертывание k8s

Для начала мы отключим файл/раздел подкачки и межсетевой экран на всех узлах кластера, а также сгенерируем и скопируем ключи SSH, чтобы Ansible мог ходить по хостам и творить свою магию:

Отключаем SWAP:

        swapoff -a
    

Отключаем firewall (на учебном стенде это допустимо, но на проде не стоит так делать не стоит):

        firewall-cmd --state
systemctl stop firewalld
systemctl disable firewalld

    

Наша следующая задача – сгенерировать ключ SSH и скопировать его на все узлы будущего кластера, включая
master (где ключ был изначально сгенерирован):

        ssh-keygen
ssh-copy-id [email protected]<master host IP>

    

Теперь копируем ключ на
оставшиеся хосты (команды выполняются на мастер-хосте):

        ssh-copy-id [email protected]_host
    

Далее на master устанавливаем pip
и git
:

        curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
python get-pip.py
yum install git

    

Если у вас используется старая версия Python, pip можно поставить следующим способом:

        curl "https://bootstrap.pypa.io/pip/2.7/get-pip.py" -o "get-pip.py"
python get-pip.py

    

Подготовка платформы завершена. Мы по-прежнему находимся на мастер-хосте
и до конца развертывания кластера с него не уйдем. За нас будет ходить Ansible
🙂

Для дальнейших действий потребуется репозиторий Kubespray. Клонируем его:

        git clone https://github.com/kubernetes-sigs/kubespray.git
cd kubespray

    

Устанавливаем зависимости
для Kubespray, описанные в файле requirements.txt:

        pip install --ignore-installed requests==2.23.0
pip install -r requirements.txt

    

Подведем итог наших действий:

На ноде master установлен Ansible;

Сгенерирован и скопирован ssh ключ на все узлы кластера;

Установлены необходимые зависимости из файла requirements.txt.

Конфигурация Kubespray

Чтобы Kubespray понимал, на какие узлы нужно устанавливать k8s, придется создать директорию с описанием конфигурации будущего кластера. Тему inventory в первой статье мы подробно разбирать не будем, поскольку она слишком обширная (рабочий inventory доступен по ссылке – скопируйте его).

Потребуется изменить IP-адреса. Ниже приведет пример inventory.ini c нашими адресами (у вас они будут другими):

        master-1.root.local.io ansible_host=192.168.0.3 ip=192.168.0.3
ingress-1.root.local.io ansible_host=192.168.0.6 ip=192.168.0.6
node-1.root.local.io ansible_host=192.168.0.4 ip=192.168.0.4
node-2.root.local.io ansible_host=192.168.0.5 ip=192.168.0.5

[kube-master]
master-1.root.local.io

[etcd]
master-1.root.local.io

[kube-node]
node-1.root.local.io
node-2.root.local.io
ingress-1.root.local.io

[kube-ingress-1]
ingress-1.root.local.io

[k8s-cluster:children]
kube-node
kube-master

    

Наш кластер состоит из 4 узлов:

  • один master с компонентами Control Plane;
  • один Ingress для маршрутизации трафика;
  • два Workers, на которых будут запускаться сервисы.

Control Plane (API
server, etcd, Sheduler, Controle manager) собран на одной ноде. Это очень нехорошо: обычно в секции [kube-master] больше одного узла, а в секции [etcd] – более трех. Это связано с тем, что quorum собирается не меньше
чем на 3 узлах при нечетным общем количестве узлов в etcd. Поскольку речь идет об учебной площадке, наш вариант тоже имеет право на существование.

Отредактируем k8s-cluster/k8s-cluster.yml. Нужно поменять network plugin на
flannel и имя нашего кластера на root.local:

        kube_network_plugin: flannel
cluster_name: root.local

    

Теперь поправим
k8s-cluster/k8s-net-flannel.yml. Тут обычный regexp на сеть провайдера VPS (в нашем случае это 192.168.0.0/24, но у вас подсеть может отличаться).

Исправляем:

        flannel_interface_regexp: '192\.168\.0\.\d{1,9}'
    

Сборка кластера

Поскольку inventory у нас уже
подготовлен, остается только запустить playbook на исполнение и минут
15 – 20 подождать, пока соберется кластер. Если у вас отвалится соединение SSH, и сборка прервется, ее можно будет запустить повторно – это не вызовет ошибок:

        ansible-playbook -u root -i inventory/inventory.ini cluster.yml -b --diff
    

Кластер собран. Проверяем:

        [[email protected] kubespray] kubectl get nodes
NAME                      STATUS   ROLES    AGE    
ingress-1.root.local.io   Ready    <none>   2d1h   
master-1.root.local.io    Ready    master   2d1h   
node-1.root.local.io      Ready    <none>   2d1h   
node-2.root.local.io      Ready    <none>   2d1h

    

Последний штрих – добавляем
роль нашей ноде с ingress:

        [[email protected] kubespray] kubectl label node ingress-1.root.local.io node-role.kubernetes.io/ingress=
    

Если повторно посмотреть на ingress, роль должна появиться:

        [email protected] kubespray] kubectl get nodes
NAME                      STATUS   ROLES     AGE    
ingress-1.root.local.io   Ready    ingress   2d1h   
master-1.root.local.io    Ready    master    2d1h   
node-1.root.local.io      Ready    <none>    2d1h   
node-2.root.local.io      Ready    <none>    2d1h  

    
***

Поздравляем! Вы практически вручную развернули кластер k8s, и теперь можно запустить в нем простенькое приложение. Это только начало большого пути в современное системное администрирование (или даже в DevOps). Более сложные шаги мы сделаем с вами вместе в следующих статьях. Удачи в обучении!

18
Май
2021

∞ Как освоить профессию инженера DevOps в 2021 году?

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

DevOps (англ. development and operations) – набор практик для повышения эффективности разработки (Dev) и эксплуатации (Ops) программного обеспечения. Он позволяет наладить взаимоотношения между программистами и системными инженерами, автоматизировать рабочие процессы и быстрее выпускать готовый продукт. Основные принципы DevOps мы достаточно подробно разбирали в предыдущих статьях.

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

Можно ли освоить популярную профессию, обладая минимальными познаниями в IT?

Junior DevOps существует


Новичкам доступно несколько вариантов обучения:

  • Стажировка в компании – хороший способ получить практические знания под присмотром опытных коллег, но требуется технический бэкграунд. Работодатели тщательно выбирают интернов, шанс попасть на такую стажировку с нуля небольшой. Обратите внимание на такие компании как EPAM или DINS.
  • Обучение на платных курсах подходит для всех, независимо от опыта. Организаторы таких курсов следят за актуальностью изучаемого материала, информация структурирована и подаётся по возрастающей – от простого к сложному. Главное преимущество – проработка знаний на практических заданиях и к концу обучения у вас будет портфолио, которое можно прикрепить к резюме. Определиться с выбором курсов поможет этот ресурс.
  • Самостоятельное обучение. В сфере IT специалисты-самоучки не редкость. Этому способствует доступность информации в сети: книги, документация, сообщества, каналы в YouTube – для занятий нужен только компьютер с доступом к интернету. Выбирая этот путь, вы должны быть хорошо мотивированы и дисциплинированы. Самое главное здесь – последовательность и постоянство. Лучше уделять образованию один-два часа каждый день, чем заниматься целый день раз в неделю.

Базовые знания для карьеры в DevOps

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


Знание английского трудно переоценить в любой сфере IT и DevOps не исключение. Владение языком даже на уровне A1, A2 поможет при чтении технической документации (корректный перевод получается найти далеко не всегда). Если вы совсем не знаете язык, можно переключить все устройства на английский – это позволит выработать хотя бы начальные навыки чтения.

1. Изучите основы построения компьютерных сетей, модели osi, tcp/ip.

Рекомендуемая литература:

Эти книги помогут вам заложить прочный теоретический фундамент, а практический опыт можно получить из книг по подготовке к CCNA и программы Cisco packet tracer:

2. Изучите unix-системы, в частности GNU/Linux.

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

Книги и видеоуроки по Linux:

3. Изучите скриптовый язык программирования.

На Bash обычно пишутся сценарии конфигурации сервера – это хороший выбор для работы в современных облачных средах с контейнерным хранением и микросервисами.

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

Рабочие инструменты инженера DevOps

таблица инструментов инженера DevOps
таблица инструментов инженера DevOps

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

Выделим основные инструменты:

  • Git – система контроля версий;
  • Jenkins – обеспечение непрерывной интеграции(CI, англ. Continuous Integration);
  • Ansible система управления конфигурациями;
  • Docker – контейнеризация приложений;
  • Terraform/Kubernetes – системы оркестрации;
  • AWS/GCP – облачные сервисы IaaS.

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

Каналы по DevOps на Youtube:

  • ADV-IT – Денис Астахов, опытный инженер DevOps со множеством сертификатов. На его канале есть плейлисты по всем необходимым инструментам. В своих уроках Денис доступным языком и на практических примерах объясняет с чем придется столкнуться будущему специалисту. Единственный минус – не всегда грамотно поставленная речь, так как Денис живет и работает в Канаде.
  • Kirill Semaev – еще один канал по обучению Linux и практикам DevOps. Ко всем видеоуроками есть презентации и практические примеры. Недостаток – контент давно не обновлялся.
  • DevOps Channel – канал о конференциях по тематике DevOps. Он будет полезен не только в целях обучения, но и для расширения кругозора.

Другие статьи про DevOps в «Библиотеке программиста»:

***

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

Если вы всерьез решили освоить новую профессию, советуем обратить внимание на факультет DevOps образовательной онлайн-платформы GeekBrains. За 18 месяцев обучения вы получите 4 проекта в портфолио, диплом о профессиональной переподготовке и помощь в трудоустройстве.

06
Май
2021

Конференция Highload++ 2021

Большая конференция для разработчиков высоконагруженных систем. Доклады, митапы, нетворкинг, уникальный опыт и ноу-хау от экспертов, задающих тренды.
— Читать дальше «Конференция Highload++ 2021»

27
Апр
2021

∞ Эффективный DevOps: как прокачать команду?

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

Главные цели и задачи DevOps

DevOps (Development and Operations) – практика, направленная на объединение команд разработки и эксплуатации для быстрой и надежной сборки, тестирования и выпуска релизов программного обеспечения. Она является естественным продолжением гибких подходов (SCRUM, Kanban, FDD и других).

Основная цель DevOps – ускорить вывод продукта на рынок (за счет применения постепенных улучшений в ответ на меняющуюся среду) и создать более упорядоченный процесс разработки.

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

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

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

Что делает команду DevOps эффективной

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

  1. Предоставление обратной связи о сбоях (и их причинах) на этапе сборки для оперативного исправления проблем разработчиками. Возможность давать постоянную обратную связь сокращает время, необходимое для устранения проблем на позднем этапе. Этот процесс также известен как непрерывная интеграция (CI).
  2. Максимальная автоматизация конвейера сборки и выпуска. Таким образом, ручные усилия сводятся к минимуму, сборки/развертывания становятся организованными, что ускоряет процесс предоставления результата заказчику.
  3. Управление инфраструктурой (управление серверами на любом этапе, QA, pre-production и production) – еще один аспект, в котором инженер DevOps играет жизненно важную роль. Когда облачные сервисы, вроде AWS, используются все чаще, делать это намного проще, но управление инфраструктурой остается обязанностью инженера DevOps.
До появления DevOps эти задачи выполняли либо группы разработчиков, либо группы эксплуатации. Выполнять основную работу, параллельно занимаясь сборкой и выпуском – времязатратно. По этой причине и возник подход, повышающий эффективность команд.

Чтобы организовать команду и сделать ее эффективной необходимо следующее:

  1. Чтобы бизнес-требования организации и общее видение соответствовали целям команды DevOps. Так команда сосредоточится на конкретных бизнес-целях, а не будет просто выполнять рутинные задачи.
  2. Выбрать подходящие инструменты. Инновационный набор инструментов и своевременное внедрение стека технологий поможет команде поддерживать эффективность.
  3. Измерять эффективность команды. Например:
  • анализировать частоту развертываний: соответствует ли она целям организации?
  • проверять безопасность и качество: соответствуют ли стандарты безопасности и качества проектов стандартам организации?
  • проверять объем ошибок/багов: каков процент возникающих ошибок и сколько времени нужно командам, чтобы их решить?

Советы от ведущего DevOps-специалиста

Об эффективных способах прокачки команды DevOps нашему корреспонденту рассказал Александр Крылов, Lead DevOps ПАО СК «Росгосстрах».

О принципах

На данный момент времени я взаимодействую с командами аналитики, разработки, тестирования, инфраструктуры. В процессе разработки мы стараемся не доводить до того, чтобы, если что-то идет не так, бизнес узнал об этом. Например, идет внедрение нового продукта, появление которого требует доработок в ряде систем. Доработки продумываются, оцениваются и уходят в разработку. Параллельно командой тестирования разрабатываются тесты этого функционала, формируется методология интеграционного и регрессного тестирования по всем дорабатываемым системам.
В случае, если это бизнес-критичный функционал, для него дополнительно настраивается логирование и алертинг. Это мы проносим через культуру DevOps по всему циклу CI/CD, по необходимости, встраивая в pepeline автотесты и систему репортинга по ним, чтобы наблюдать за каждой итерацией прохождения этих тестов. Поэтому, в процессе разработки мы руководствуемся одним простым принципом – здравым смыслом.

О прокачке культуры DevOps в организации и среди команд

Для прокачки культуры DevOps в организации и среди команд существуют направления:

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

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

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

3. В компании существует матрица зрелости. О ней я упоминал в выступлении на конференции DevOps Live 2020 с темой «Построение мониторинга в дружбе с DevOps. Унификация процессов».

В концепт матрицы входит оценка системы по ряду блоков и критериев, например, тестирование или разработка. После оценки системы с лидами команд разработки и тестирования, принимается решение по тем или иным работам. Для бизнеса они обосновываются, как повышение уровня матрицы зрелости с последующим профитом, например, ускорение поставки кода в продакшн за счет внедрения CI/CD. Результатом этих работ является повышение зрелости систем и масштабирование практик DevOps в компании.

О внедрении новых стеков технологий

Регулярная активность компании – NAP, что расшифровывается, как Next Action Plan. Суть NAP – это обсуждение инициатив, например, по оптимизации процессов путем внедрения какой-либо утилитки.

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

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

Об ошибках в работе DevOps

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

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

Как развиваться в DevOps начинающему и опытному специалисту

Молодому специалисту лучше начинать освоение DevOps с базовых основ Unix и Linux. Затем стоит изучить не только самые новые и модные технологии, но и то, как эти технологии появились. Не зная основ, сразу забираться в омут с головой, ограничивая себя только хайповой вещью, которая уже завтра может умереть – неразумно. Лучше прочитать историю возникновения технологии и статьи по ее возможной эволюции.

По самому же DevOps, рекомендую прочесть:

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

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

Выводы

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

***

Если вы только начинаете путь в профессии, стоит обратить внимание на курс факультета DevOps образовательной онлайн-платформы GeekBrains. Программа рассчитана на новичков и практикующих IT-специалистов, решивших освоить востребованное направление. За 18 месяцев вы научитесь использовать гибкие подходы Agile и Scrum, оптимизировать CI/CD и работать с облачными решениями. Обучение построено на взаимодействии в команде, а занятия ведут действующие специалисты российских технологических компаний. Успешно окончившие курс студенты смогут добавить в портфолио полтора года практического опыта и четыре реализованных проекта, а также получат помощь в трудоустройстве.

21
Апр
2021

Как работать с апи если сайт требует SSL сертификат?

У меня есть некая программа для работы с апи DevOps. Получение данных с одного DevOps и создание user story/tasks в другом. Функция получения данных будет ниже.
Но недавно нам сказали установить SSL сертификат и заходить в девопс теперь м…

04
Мар
2021

∞ Обучение на инженера DevOps: как не имея опыта найти работу?

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

Почему в DevOps не…

25
Фев
2021

Школа Linux от КРОК

Это не курс и не вебинар, а полноценная работа с параллельным обучением для будущих Linux-администраторов. Эксперты КРОК делятся своим опытом и вы тут же применяете его на практике.
— Читать дальше «Школа Linux от КРОК»

20
Фев
2021

∞ Основы методологии DevOps

Раскладываем методологию DevOps по полочкам. Анализируем преимущества и недостатки, вспоминаем основополагающие принципы, идеи, культуру и историю развития DevOps.

Что было до D…

14
Фев
2021

Как устроен боевой проект на docker?

Подскажите пожалуйста примерную структуру проекта. Как я понимаю структуру сейчас:
Сервер Ubuntu:

Docker:

Контейнер с приложением (например Django)
Контейнер с БД

Nginx

Казалось бы все просто. Но возникает вопрос https://testdriven.io…

01
Фев
2021

∞ Эксперты рассказывают о работе специалистов DevOps в крупных IT-компаниях

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

25
Дек
2020

∞ Перспективы для инженера DevOps в 2021 году

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

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

О DevOps в 2020

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

Несмотря на экономический спад во всем мире, отрасль DevOps активно развивается. По данным поставщика рыночной информации и консультационных услуг International Data Corporation (IDC), продолжается рост технологических изменений и достижений, связанных с платформами доставки и развертывания приложений.

Ожидается, что на мировом рынке выручка в DevOps вырастет на 29,4% в 2020 году, а затем продолжит расти и достигнет прогнозируемой отметки в $21,3 млрд. к 2027 году.

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

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

Отчет компании Puppet

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

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

Наибольшее количество респондентов находится в Европе (33%), США и Канаде (30%). Большинство из них (33%) представляют технологические компании, финансовые организации и промышленные предприятия.

Количество опрошенных по глобальным регионам и отраслям в процентном соотношении
Количество опрошенных по глобальным регионам и отраслям в процентном соотношении

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

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

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

Ключевые выводы из отчета Puppet:

  • организации с высокоразвитыми практиками DevOps больше полагаются на внутренние платформы, которые, тем не менее, могут быть слабым местом, поскольку для стандартизации требуется больше времени, опыта и настройки;
  • организации должны рассматривать свои цифровые инициативы как продукты, а не как проекты, что позволит масштабировать платформы и практики DevOps;
  • наиболее распространенный интерфейс самообслуживания это CI/CD в организациях на разных уровнях развития DevOps;
  • организации, внедрившие безопасность во весь жизненный цикл DevOps, могут устранить почти половину своих критических уязвимостей менее чем за 24 часа. Не столь зрелые организации могут решить только 25% проблем за тот же период.

Отчет DevOps Institute

Институт DevOps провел посвященное навыкам специалистов исследование. Более 1200 опрошенных по всему миру профессионалов определили, какие из них считаются критически важными для DevOps и цифровой трансформации.

Ключевые выводы из отчета:

  • поиск и привлечение квалифицированных специалистов по-прежнему остается проблемой в 2020 году. 58% респондентов заявили, что найти квалифицированных специалистов по DevOps очень сложно. 48% считают, что столь же непросто удержать опытных профессионалов в компании;
  • некоторые навыки будут более востребованы. В 2020 году управление версиями программного обеспечения стало более востребованным, чем навык разработки полного цикла. Также рейтинг опыта в настройке и мониторинге производительности увеличился с 32% до 39%.
  • SRE начинает cильнее конкурировать с Agile, DevOps и ITIL. Рейтинги внедрения Agile (81%), внедрения практик DevOps (74%) и ITIL (25%) выросли по сравнению с результатами аналогичного опроса 2019 года. Внедрение SRE увеличилось с 10% в 2019 году до 28% в 2020 году.
Показатели роста методологий SRE, Agile и DevOps в 2019 и 2020 годах
Показатели роста методологий SRE, Agile и DevOps в 2019 и 2020 годах

Состояние DevOps в 2020 году в России

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

В 2020 году состояние DevOps в России решили изучить компании «Экспресс 42» и «Онтико». Авторы исследования Игорь Курочкин и Виталий Хабаров.

Им удалось опросить 889 человек из России и СНГ.

Количество опрошенных по регионам в процентном соотношении
Количество опрошенных по регионам в процентном соотношении

Четыре ключевые метрики авторы соотнесли с тремя профилями эффективности: Low, Medium, High.

Соотношение ключевых метрик исследования и профилей эффективности специалиста DevOps
Соотношение ключевых метрик исследования и профилей эффективности специалиста DevOps

По результатам опроса только 16% респондентов были точно определены в один из профилей. Остальные находятся на стыке Low, Medium или High. Авторы исследования советуют использовать калькулятор DORA для точного определения своего уровня.

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

Среди облачных сервисов наиболее популярны Amazon Web Services (AWS) и Google Cloud Platform. Объемы использования российских облачных хостингов постепенно увеличиваются.

Kubernetes занимает лидирующую позицию среди программного обеспечения для автоматизации развертывания. Ansible первый среди систем управления конфигурацией, а Jenkins и GitLab – среди CI-систем.

Использование инструментов DevOps специалистами в процентном соотношении
Использование инструментов DevOps специалистами в процентном соотношении

Авторы решили также проверить, как компании чувствуют себя в условиях пандемии COVID-19. Из таблицы можно сделать вывод, что команды профиля High справляются лучше, чем остальные. Они в 1,5-2 раза активнее выпускали новые продукты и в 2 раза чаще повышали производительность и/или надежность инфраструктуры приложений.

Уровень развития команд DevOps в условиях пандемии COVID-19
Уровень развития команд DevOps в условиях пандемии COVID-19

Основные планы команд-респондентов на 2021 год:

  • DevOps-трансформация;
  • изменение организационной структуры или переформирование команд;
  • внедрение DevSecOps, интеграция практик безопасности в процессы разработки, тестирования и эксплуатации.
Список запланированного развития команд DevOps на 2021 год
Список запланированного развития команд DevOps на 2021 год

Прогнозы на 2021 год

Проанализировав ряд свежих отчетов о состоянии DevOps, мы можем сделать вывод о тенденциях наступающего года:

  • большинство российских и иностранных компаний в 2021 году будут внедрять ориентированную на облако инфраструктуру для поддержки облачных рабочих процессов и приложений. Из-за связанных с пандемией изменений эти шаги уже начали предприниматься. В отчете “IDC FutureScape: Прогноз всемирно известных разработчиков и DevOps на 2021” утверждается, что 80% предприятий разработают механизм, позволяющий удвоить скорость этого внедрения уже к концу 2021 года. 29% опрошенных российских команд DevOps планируют миграцию инфраструктуры или приложений в облака в следующем году;
  • безопасность приложений и внедрение DevSecOps станет ключевым аспектом развития DevOps в 2021 году. Все больше команд будут внедрять гибкие методологии в DevOps, следовательно, у них будет мало времени на длительный цикл тестирования безопасности. Поэтому популярность DevSecOps существенно вырастет. Безопасность облачных вычислений также будет актуальной. Компании переходят в облако для быстрого и частого предоставления новых функций, а командам безопасности необходимо использовать новые инструменты и процессы, чтобы гарантировать быстроту и безопасность развертываний. 30% респондентов отчета о состоянии DevOps в России планируют внедрение DevSecOps и интеграцию практик безопасности в 2021 году;
  • гибридные рабочие места будут популярны и в 2021 году. В 2020-м компании были не готовы к массовому переходу на удаленный формат работы. Сейчас им стоит принимать долгосрочные решения, которые касаются формата работы. Преуспевающие в этом году компании сумели быстро изменить свою модель работы и предоставили сотрудникам возможность работать где угодно и в любой среде. В своем отчете компания IDC отметила, что к 2023 году 75% компаний создадут гибридную структуру того или иного типа;
  • многие команды перейдут на использование внутренних платформ. В исследовании Puppet 63% респондентов отметили, что их компания использует от 2 до 4 внутренних платформ. 25% опрошенных команд из России планируют внедрение или разработку внутренней платформы в следующем году. Хотя такие платформы достаточно громоздки, а также требуют большого количества времени и навыков для стандартизации, они будут активно внедряться в ближайшее время.
***

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

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

30
Ноя
2020

Конференция DevFest Siberia 2020

Пятая ежегодная конференция по Mobile, Frontend, Backend, DevOps, Security, Data Science и Hype. Более 40 спикеров со всего мира, 4 трека и воркшопы.
— Читать дальше «Конференция DevFest Siberia 2020»

30
Ноя
2020

💵 Сколько зарабатывают инженеры DevOps в разных странах

Желающим освоить профессию важно понимать состояние рынка труда. По сайтам вакансий мы изучили требования к квалификации специалистов и зарплаты инженеров DevOps в России, Европе и США.

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

Определение и обязанности DevOps

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

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

Сегодня обязанности инженера DevOps выглядят так:

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

На собеседованиях менеджеры HR ожидают увидеть специалиста, который разбирается в использовании облачных технологий и автоматизации крупной инфраструктуры. Инженер DevOps должен обеспечивать безопасность и отказоустойчивость ПО, отлично владеть базовыми инструментами: AWS, Ansible, Docker, Kubernetes, Chef, Puppet и другими, а также понимать процессы планирования работ, уметь управлять командами и ожиданиями заказчика.


Уровни специалистов DevOps

Инженеров DevOps можно условно поделить на три типа:

  • Junior – до 3-х лет опыта.

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

  • Middle – до 6-ти лет опыта.

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

  • Senior – от 6-ти лет опыта.

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

Это условная градация, которая встречается в вакансиях. На самом деле грейды от Junior к Senior больше свойственны программистам. Карьера специалистов DevOps часто начинается со среднего уровня, где требуемый опыт работы – больше трех лет. Обычно DevOps вырастают из системных администраторов, которые разобрались в инструментах программирования, или из разработчиков, изучивших тонкости операционных процессов.

Сколько зарабатывают DevOps в России, Европе и США

Судя по объявлениям на hh.ru, в Москве доступно более 3 тысяч вакансий по запросу DevOps. На них приходится более 5 тысяч резюме от 4 тысяч соискателей.

Скриншот сайта для поиска работы hh.ru
Скриншот сайта для поиска работы hh.ru

Можно сделать вывод, что количество соискателей всего за полгода (по данным из статьи на habr.com) увеличилось почти в 2.5 раза.

Скриншот из статьи на сайте habr.com
Скриншот из статьи на сайте habr.com

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

В регионах младший специалист DevOps может заработать от 25 до 80 тыс. рублей, а ведущий – от 100 тыс. рублей. Большинство работодателей ожидают увидеть от трех лет практического опыта администрирования ОС Linux и опыт работы с Docker, Kubernetes, Ansible, а также с инструментами CI/CD.

Средняя медианная зарплата специалиста DevOps по данным Хабр Карьера во втором полугодии 2020 года составила 155 тыс. рублей.

Средняя медианная зарплата специалиста DevOps в России
Средняя медианная зарплата специалиста DevOps в России

В первом полугодии 2019 года средняя медианная зарплата DevOps в России составляла 130 тыс. рублей, а в первом полугодии 2020 года – 140 тыс. рублей.

Сравнение заплат DevOps за 2019 и 2020 годы
Сравнение заплат DevOps за 2019 и 2020 годы

По запросу DevOps на одном из популярных международных сайтов для поиска работы Monster.com, можно найти более 14 тыс. вакансий в США, из них более 2 тыс. для удаленной работы.

Скриншот сайта для поиска работы Monster.com
Скриншот сайта для поиска работы Monster.com

Американские работодатели готовы платить младшим специалистам DevOps от $5-7 тыс. в месяц, а продвинутым – от $10 тыс. в месяц. Разница в зарплате для офисных и удаленных сотрудников несущественна.

Среди требований: от 3 до 5 лет опыта в разработке программного обеспечения или DevOps, владение платформами: Git, AWS, Jenkins, Kubernetes, Puppet, Chef и другими, а также понимание систем сборки для разных языков программирования: C/C ++, Go, Python, Bash.

В Германии для DevOps открыто более 900 вакансий на сайте Monster.de. Младшему специалисту там предложат от 3 тыс. в месяц, а продвинутому – от 6 тыс.

Немецким предприятиям необходимы сотрудники с высоким уровнем владения английским. Часто требуется, но не во всех компаниях обязательно – знание устного и письменного немецкого языка (не ниже B1).

Специалистов DevOps в Германии ищут в основном консалтинговые компании, банки, компании-разработчики ПО и другие организации.

На платформе для удаленной работы UpWork доступно более 200 вакансий для DevOps. Можно найти хорошие варианты для проектной работы.

Скриншот сайта для поиска удаленной работы UpWork
Скриншот сайта для поиска удаленной работы UpWork

Выводы

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

Прежде чем приступить к поиску работы, стоит сделать следующее:

  • решите, где вы хотите работать.

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

  • определите, в чем вы действительно сильны.

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

  • установите зарплатные ожидания.

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

  • ищите компанию, которая соответствует всем вашим требованиям.

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

***

Если вы только начинаете свой путь в отрасли, стоит обратить внимание на курс DevOps онлайн-университета GeekBrains. Вы освоите упомянутые в статье современные технологии: Git, Docker, Kubernetes, AWS, Azure и многие другие. Опытные преподаватели помогут студентам получить все необходимые для старта карьеры в DevOps знания, а также решить шесть проектных задач и применить полученные навыки на практике.

27
Ноя
2020

Где размещается staging, testing environment в случае микросервисов работающих в облаке?

Допустим мы решили делать проект на Java, изначально с микросервисной архитектурой, работать он будет в AWS под управлением docker containers + kubernetes. Где в таком случае поднимать окружения для того чтобы:

разработчики могли что-то п…

19
Ноя
2020

👨‍🎓️👨‍🔧️50 терминов DevOps: словарь инженера

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

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

Совместно с Факультетом DevOps онлайн-университета GeekBrains мы составили список из 50 терминов, часто употребляемых специалистами в работе.

***

Словарь DevOps

A

Agent

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

Agile

(Гибкая разработка программного обеспечения)

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

Amazon AWS

(Amazon Web Services)

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

Apache

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

API

(Программный интерфейс приложения)

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

Artifact

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

B

Bastion host

(Узел-бастион)

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

Black Box Testing

(Тестирование по стратегии «черного ящика»)

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

Branching

(Разветвление)

Существует для разделения основного кода на пути развития (ветки) в системе управления версиями (например Git). Каждая ветка может содержать собственную модификацию основного кода.

Build Agent

(Агент сборки)

Тип агента, который используется в непрерывной интеграции и отправляет/получает сообщения об обработке сборки ПО.

Build Artifact

(Артефакты сборки)

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

Build Automation

(Автоматизация сборки)

Автоматизация сборки ПО и связанных с ней процессов (компиляция исходного кода в двоичный, упаковка двоичного кода и выполнение автоматических тестов).

C

Canary Release

(«Канареечный релиз»)

Метод, который используется для постепенного ознакомления с выпуском ПО небольшой подгруппы пользователей. Главная задача – убедиться в безопасности и функциональности ПО перед развертыванием для всей пользовательской базы.

Capacity Test

(Тест емкости)

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

Commit

Операция, которая сохраняет последние изменения исходного кода в репозитории (например, Git).

Configuration Management

(Управление конфигурацией)

Дисциплина постоянного мониторинга и поддержания согласованных настроек системы с помощью инструментов для автоматизации ИТ-инфраструктуры (например, Chef, Puppet, Kubernetes, Ansible).

Container

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

Containers-as-a-Service (CaaS)

(Контейнеры как услуга)

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

Continuous Delivery (CD)

(Непрерывная доставка)

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

Continuous Integration (CI)

(Непрерывная интеграция)

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

Cluster

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

D

Deployment

(Развертывание)

Термин, который объединяет все связанные с запуском нового ПО процессы: установку, настройку, запуск и тестирование.

DevOps

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

DevSecOps

(Операции по обеспечению безопасности доставки)

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

E

Exploratory Testing

(Исследовательское тестирование)

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

F

Fail Fast

(«Быстрый провал»)

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

G

Google Cloud Platform

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

H

Hybrid Cloud

(Гибридное облако)

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

I

Integration Testing

(Интеграционное тестирование)

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

K

Kanban

Инструмент организации производства, который является частью agile-философии и позволяет реализовывать принцип «точно и в срок». Достичь необходимого результата можно с помощью визуализации (виртуальной или реальной доски, на которую прикрепляются стикеры или карточки).

L

Lead Time

(«Время производственного цикла»)

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

M

Machine Learning (ML)

(Машинное обучение)

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

Microservices Architecture

(Микросервисная архитектура)

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

Microsoft Azure

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

N

Nginx

HTTP-сервер. ПО с открытым кодом, совместимое с UNIX-системами. Области его применения – от кэширования HTTP до создания инвертированного прокси-сервера.

O

Open Source

(Открытое программное обеспечение)

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

P

Pair Programming

(Парное программирование)

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

Platform-as-a-Service (PaaS)

(Платформа как услуга)

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

Production

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

R

Rollback

(Откат)

Автоматическая или ручная операция возврата продукта или приложения к предыдущей версии.

S

Self-Service Deployment

(Самостоятельное развертывание)

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

Software-as-a-Service (SaaS)

(Программное обеспечение как услуга)

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

Staging Environment

(Промежуточная среда)

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

T

Test Automation

(Автоматизация тестирования)

Использование отдельного ПО для тестирования. Этапы: запуск, инициализация, выполнение, анализ и автоматическая выдача результата. Используется для контроля выполнения тестов и сравнения фактических результатов с прогнозируемыми.

Technical Debt

(Технический долг)

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

U

User Acceptance Testing (UAT)

(Пользовательское приемочное тестирование)

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

Unit Testing

(Модульное тестирование)

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

V

Virtual Machine (VM)

(Виртуальная машина)

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

W

Waterfall

(Модель «Водопад»)

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

White Box Testing

(Тестирование по стратегии «белого ящика»)

Метод функционального тестирования внутренней структуры, дизайна и кода ПО. Отличается от тестирования по стратегии «черного ящика» тем, что исходный код виден тестировщику.

Выводы

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

17
Ноя
2020

Конференция HighLoad++ 2020

Темы выступлений — все аспекты разработки и поддержки высоконагруженных систем. Спикеры расскажут про архитектуры и разные методологии.
— Читать дальше «Конференция HighLoad++ 2020»

03
Ноя
2020

👨‍🔧️ Зачем DevOps сисадмину и программисту?

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

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

Почему DevOps?

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

Разница все-таки есть: практики DevOps (Development Operations) сочетают разработку (Dev) и ИТ-операции (Ops) для обеспечения непрерывной поставки софта заказчикам. Навыки администрирования относятся к Ops – это лишь часть необходимого инженеру багажа, хотя и достаточная для старта в новой профессии. Не случайно многие девопсы вышли из сисадминов, а споры о различиях между профессиями не утихают годами. И те и другие делают, чтобы все работало, но в случае DevOps в квесте возникают дополнительные уровни сложности.

Иллюстрация с pixabay.com
Иллюстрация с pixabay.com

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

Освоивший практики DevOps программист перестает думать алгоритмами и кодом. Эволюция сисадмина идет другим путем, но сходным образом: где разработчики получают навыки администрирования, там администраторы нарабатывают скилы разработчиков. Это грубая и неточная формулировка, но суть дела она отражает. Когда Dev и Ops сходятся в одном человеке, наступает просветление. У программиста появляется навык работы с инфраструктурой и видение всего ландшафта, а понимание привязки приложения к местности позволяет ему писать более качественный код. Отошедший от сферы обслуживания в сторону создания платформы сисадмин учится объединять разрозненные ее части, т.е. создавать для компании новую ценность – интегрированный инфраструктурный продукт.

Как познать мудрость?

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

Иллюстрация с pixabay.com
Иллюстрация с pixabay.com

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

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

***

Чтобы сделать выбор, начать в любом случае стоит с профориентации. Компания OTUS проводит запись на бесплатный день открытых дверей к объемному онлайн-курсу по практикам и инструментам DevOps. Позже будет еще один предварительный вебинар по этой теме, но чтобы на него попасть, нужно пройти тестирование. Аналогичные мероприятие запланированы и для курса по Kubernetes. После регистрации все желающие смогут познакомиться с преподавателем и учебной программой на вебинаре, а прохождение теста позволит поучаствовать в бесплатном вводном онлайн-занятии. Успешно окончившие курс студенты смогут пройти сертификацию от CNCF: CKA и CKAD. Специально к ней не готовят, но встречающиеся на экзамене темы освещаются подробно.