Кто такой devops-инженер, что он делает, сколько зарабатывает и как им стать

Kubectl

В Кометрике активно используется оркестрация докер контейнеров на базе Kubernetes и данная утилита не требует представления.

При работе с кластерами Kubernetes невозможно обойтись без консольной утилиты Kubectl. У нее есть отличный автокомплит, что позволяет ускорить и упростить ввод команд. Конечно, во время GUI интерфейсов возможно заменить её на какой-то продвинутый дэшборд, например на тот, который есть у Rancher, но все это требует больше времени, нежели ввод пары простых команд в консоли. А уж если требуется что-то автоматизировать или провести массовые изменения, без этой утилиты просто не обойтись.

В нашей команде, для разработчиков которые только недавно познакомились с Kubernetes, мы предоставляем веб-интерфейс на базе Rancher, но как показывает практика, это опять-таки, ненадолго. И, в конечном итоге, все приходят к работе с Kubectl.

О роли DevOps-инженера

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

Для примера, специфика работы нашей компании, вендора в области инновационных решений информационной безопасности, накладывает на наш отдел автоматизации (неформально называемый DevOps-отделом) обязанность поддерживать работу всего конвейера производства ПО и сопутствующую инфраструктуру, начиная от сборки отдельных компонентов и инсталляторов продуктов до их отправки на тестирование и доставки на серверы обновлений и затем в инфраструктуру заказчиков. Несмотря на огромный объем технических задач, с ними справляются полтора десятка человек, при этом количество разработчиков в R&D, с которыми мы работаем, — несколько сотен.

DevOps в современном IT уже давно выделился в самостоятельную инженерную дисциплину — очень динамичную и технологичную. Ключевым принципом для DevOps-инженеров является принцип DevOps as a service. Мы должны оперативно приносить новые технологии нашим разработчикам и тестировщикам и поддерживать работу старых, проверенных временем сервисов. Кроме того, мы делаем труд разработчиков более комфортным, эффективным и продуктивным. Также мы разрабатываем внутренние вспомогательные инструменты, регламентируем и автоматизируем процессы разработки, сохраняем и распространяем технологические знания внутри компании, проводим технические воркшопы, митапы и делаем еще много всего полезного.

System Administrator/DevOps

Piano, Удалённо, По итогам собеседования

tproger.ru

Вакансии на tproger.ru

В отличие от классических сисадминов мы не работаем по шаблонам и инструкциям 24×7×365, мы не техподдержка, в наши обязанности не входят поддержка «железной» части инфраструктуры и круглосуточное обеспечение работоспособности серверов. Я предлагаю считать DevOps-инженеров современными инженерами-технологами в производстве ПО. Такие специалисты квалифицированно решают не только задачи своей роли, но и видят весь производственный конвейер целиком, понимают, как результаты их работы будут использованы далее и интегрированы в общую производственную цепочку.

С чего начать, чтобы стать DevOps engineer?

Начните с полезных статей:

  • Эффективный DevOps: 6 способов прокачать команду и себя
  • Как IT-специалисту ввести культуру DevOps в своей компании
  • Кто такой DevOps и как им стать: план обучения

Посмотрите видео на канале ADV-IT, где подробно расписано, что учить и в каком порядке:

Получите более уверенные знания из нескольких книг:

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

DevOps — это не просто набор техник, это философия

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

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

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

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

Эберхард Вольф познакомит вас с популярными передовыми технологиями, облегчающими труд разработчиков: Docker, Chef, Vagrant, Jenkins, Graphite, ELK stack, JBehave и Gatling. Вы пройдёте через все этапы сборки, непрерывной интеграции, нагрузочного тестирования, развёртывания и контроля.

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

И помните, что от этого специалиста требуется тщательная проработка целого ряда вопросов.

DevOps culture

It’s generally accepted that DevOps methods can’t work without a commitment to DevOps culture, which can be summarized as a different organizational and technical approach to software development.

At the organizational level, DevOps requires continuous communication, collaboration and shared responsibility among all software delivery stakeholders — software development and IT operations teams for certain, but also security, compliance, governance, risk and line-of-business teams — to innovate quickly and continually, and to build quality into software from the start.

In most cases the best way to accomplish this is to break down these silos and reorganize them into cross-functional, autonomous DevOps teams that can work on code projects from start to finish — planning to feedback — without making handoffs to, or waiting for approvals from, other teams. When put in the context of agile development, the shared accountability and collaboration are the bedrock of having a shared product focus that has a valuable outcome.

At the technical level, DevOps requires a commitment to automation that keeps projects moving within and between workflows, and to feedback and measurement that enable teams to continually accelerate cycles and improve software quality and performance.

Как инженеру пойти навстречу бизнесу

DORA State of DevOpsисследование состояния DevOps в России

  • Частота деплоев (deployment frequency) — как часто вы деплоите код в продакшен или как часто ваши конечные пользователи получают новые релизы.
  • Время внесения изменений (lead time for changes) — от коммита кода в репозиторий до его выкладки в продакшен.
  • Время, за которое сервис восстанавливается после сбоя или аварии (time to restore).
  • Частота аварий, вызванных выкладкой изменений (change failure rate) — какой процент деплоев приводит к ухудшению качества обслуживания пользователей и требует исправлений, например, откатов.

Swarming на практике: пример структуры для DevOps

У Swarming нет единственной четко определенной структуры. Отчасти это объясняется новизной и, соответственно, малой распространенностью. Однако показанный ниже пример (основанный на swarming-методах поддержки пользователей, применяемых в BMC) является типичным. Он существенно улучшил работу службы поддержки (о чем было рассказано на UK’s Servicedesk and IT Support Show в 2015).

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

Первичная сортировка в структуре Swarm

Каждая группа (Swarm) ­— это небольшая команда, которая обрабатывает поступающие заявки в режиме, близком к реальному времени:

“Severity 1” Swarm (Группа по работе с инцидентами первой степени тяжести)

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

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

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

Dispatch Swarm (Группа диспетчеризации)

Проводит встречи каждые 60–90 минут.

Сфокусирована на регионах и продуктовых линейках.

Основное внимание: «схватить вишенку» (в первую очередь браться за то, что можно исправить очень быстро).

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

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

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

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

Использование Dispatch Swarming приводит к быстрому решению значительного числа задач (в BMC их количество составляет примерно 30%), а оставшиеся обращения попадают в очереди более привычных команд поддержки, которые занимаются отдельными линейками продуктов. Здесь многие задачи будут знакомы и понятны рядовым членам команды, поэтому их решение не должно вызывать трудностей. При этом еще одна часть обращений (возможно, около 30%) могут оказаться достойны внимания лучших специалистов службы поддержки независимо от их структурной принадлежности.

Здесь используется группа третьего типа: Backlog Swarm.

Backlog Swarm (Группа работы с накопившимися задачами)

Проводит встречи регулярно, обычно ежедневно.

Основное внимание: решение сложных задач, полученных от команд поддержки продуктовых линеек.

Вторичная задача: замена одиночных экспертов.

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

Кто стоит у истоков DevOps?

Главная книжка по DevOps — «The Phoenix Project». Это такой роман, где главный герой с помощью DevOps побеждает. Сначала у них все очень просто — плохо, затем он придумывает DevOps, и у них становится все хорошо.

На обложке книги есть главные герои. Давайте рассмотрим их внимательнее:

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

Второе доказательство: книжка «Руководство по DevOps» (DevOps Handbook). Давайте посмотрим, кто ее написал:

  • Джен Ким (Gene Kim). Он написал «The Phoenix Project», то есть с ним все понятно.
  • Патрик Дебуа (Patrick Debois). Он был Systems Architect, то есть сисадмином.
  • Джез Хамбл (Jez Humble). Работал Deputy Director of Delivery Architecture, то есть сисадмином.
  • Джон Уиллис (John Willis). Был VP of Services из компании Opscode, а Opscode — это инструмент для сисадминов.

То есть «Руководство по DevOps» придумано сисадминами.

Может, у нас более продвинутые люди? Уж они-то знают, зачем нужен DevOps и кто такие DevOps-специалисты. Открываем статью на Хабре и видим высказывание Кирилла Сергеева:

Хм, то есть Кирилл утверждает, что разработчики заинтересовались сисадминством? Интересно! Как вы думаете, кем работает этот Кирилл Сергеев? DevOps Engineer в компании EPAM! Ах вон оно что, теперь понятно, это сисадмины хотят, чтобы разработчики заинтересовались сисадминством, чтобы свалить на них часть своей работы!

Спустимся и посмотрим комментарии к этой статье:

Есть еще русскоязычный чат по DevOps в Telegram:

Вот что мы знаем: DevOps — это как сисадмины, только умеют в автоматизацию и знают английский.

Откуда же взялся этот ребрендинг? Откуда появились “DevOps-инженеры”?

Как вы и могли догадаться, это маркетинговый трюк рекрутеров. Им надо нанимать сисадминов, но сисадмины больше не хотят называться сисадминами! Поэтому рекрутеры придумали новую должность: “DevOps-инженер”.

LinkedIn выдает около 15 тыс. результатов по запросу DevOps в США. Если вы думаете, что в Питере не так, то нет — около 1300 открытых вакансий DevOps-инженеров на HeadHunter по состоянию на октябрь 2019 года.

Вот откуда ноги-то растут! Ну ладно, может быть всё не так плохо, и этим «ДевОпс-инженерам» всё-таки есть дело до задач, целей и головных болей разработчиков? Еще есть такой отчет под названием Accelerate: State of DevOps. Любой DevOps-специалист начнет вам рассказывать, как там все правильно. Пока давайте немного про версию 2018 года, а о выпуске 2019 года чуть позже.

Что измеряет State of DevOps? То, как мы деплоим код, куда код девается после того, как мы его написали, какие outages у серверов, лежат ли сервера, degraded service. То есть всё-всё-всё про DevOps. Главное измерение — это new work, то есть сколько мы тратим, создавая новые фичи. Как же он измеряется?

Никаких outages, degradation, server migrations! То есть все метрики в State of DevOps — это метрики сисадминов, и к нам, разработчикам, не имеют никакого отношения, потому что у нас есть три вида работы: фигачим новые фичи, фиксим баги или делаем рефакторинг. Ну то есть суммируя: DevOps — это в лучшем случае ребрендиг сисадминства, а, может быть, даже и попытка сисадминов переложить часть своей работы на разработчиков!

На этом, господа присяжные, я считаю доказанным, что DevOps — это заговор сисадминов против разработчиков. Но я-то разработчик, и что для меня этот new work, что для меня является сделанной работой? Где я провожу эту границу между Dev и Ops в DevOps?

Перейдем к докладу «The world needs full stack craftsmen», с которым Антон Кекс выступал на JPoint 2019. Если в двух словах, то доклад про Software Craftsmanship. Антон рассказывал о том, что значит быть full stack разработчиком, но затем он говорит что-то в духе:

Дальше он говорил про deployment, потому что иначе злой админ позвонит вам в середине ночи. Но у нас же DevOps! Разработчики же деплоят! То есть в докладе еще одно доказательство, что в теме про Software Craftsmanship никаким DevOps и не пахнет. Мы должны сделать так, чтобы системные администраторы не звонили ночью, и заботиться о том, чтобы код был в продакшене.

Далее Антон рассматривал Manifest of Software Craftsmanship:

Что-нибудь про DevOps, production, delivery? Ничего.

Что же считается хорошей разработкой по Software Craftsmanship?

DevOps-минимум

Понятно, что реализация всех описанных процессов в рамках даже небольшого проекта может быть делом весьма продолжительным и сложным. Поэтому многие команды задаются логичным вопросом: “С чего начать DevOps? Какой минимум необходим? И какие элементы нужны в первую очередь?”.

Реализовав множество проектов различной сложности по внедрению DevOps, на основе полученного опыта наша команда может ответить на этот вопрос так:

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

Что касается процессов, то тут уже не всё из обозначенного выше имеет критическое значение на начальных этапах появления DevOps. Здесь нам никак не обойтись без двух “continuous”: Integration и Deployment. В первую очередь потому, что без этого DevOps так останется просто теорией и не будет иметь никакого практического смысла.

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

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

Важно, чтобы он отвечал двум требованиям:

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

Разное

Кроме рассмотренных подробно инструментов у нас используется ряд сервисов, о которых стоит упомянуть:

  • Consul/etcd/vault — сервисы для хранения конфигураций и секретов.
  • Nexus/Artifactory — сервисы, позволяющие публиковать готовые сборки и модули для сборок.
  • SonarQube/Checkmarx/JFrog Xray — сканеры ИБ и статического анализа кода.
  • Docker registry — репозиторий хранения docker контейнеров.
  • Deploy tools — тулзы для деплоя в различные среды.
  • Kubernetes operator — операторы для Kubernetes, упрощающие запуск и обслуживание сервисов, таких как базы данных и все что только возможно.
  • Также БД (sql/nosql/in memory), системы хранения данных (minio/ceph/nfs и др), брокеры сообщений (rabbitmq/activemq и др) и многое многое другое.

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

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

Сколько зарабатывает DevOps Engineer?

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

  • Junior – до 1 года опыта;
  • Middle – от 1 до 3 лет опыта;
  • Senior – свыше 3 лет опыта.

Не менее важно и расположение компании-работодателя: традиционно больше всего зарабатывают DevOps-инженеры в Москве. Уровень средней зарплаты DevOps-инженера в Москве за 2019/начало 2020 года по данным портала по трудоустройству trud.com

Уровень средней зарплаты DevOps-инженера в Москве за 2019/начало 2020 года по данным портала по трудоустройству trud.com

Градация наблюдается и по регионам страны.

Уровень средней зарплаты DevOps-инженера в регионах России за 2019/начало 2020 года по данным портала по трудоустройству trud.com

Также размер оплаты напрямую коррелирует со спектром выполняемых задач и уровнем компании. В целом же, согласно статистике сервиса Хабр Карьера, средняя медианная зарплата DevOps находилась во втором полугодии 2020 года на уровне 155 000 рублей.

DevOps and site reliability engineering (SRE)

Site reliability engineering (SRE) uses software engineering techniques to automate IT operations tasks — e.g. production system management, change management, incident response, even emergency response — that might otherwise be performed manually by systems administrators. SRE seeks to transform the classical system administrator into an engineer.

The ultimate goal of SRE is similar to the goal of DevOps, but more specific: SRE aims to balance an organization’s desire for rapid application development with its need to meet performance and availability levels specified in service level agreements (SLAs) with customers and end-users. 

Site reliability engineers achieve this balance by determining an acceptable level of operational risk caused by applications — called an ‘error budget’ — and by automating operations to meet that level. 

On a cross-functional DevOps team, SRE can serve as a bridge between development and operations, providing the metrics and automation the team needs to push code changes and new features through the DevOps pipeline as quickly as possible, without ‘breaking’ the terms of the organizations SLAs. 

Как стать DevOps-инженером?

Вообще DevOps-инженер — это больше про опыт, нежели про знание конкретного софта. Девопс-ребята постоянно учатся, изучают и тестируют новые проекты и технологии. Они должны постоянно задавать себе вопрос: улучшит ли эта технология наш проект? Что лучше выбрать в качестве языка: Ruby, Python, Go или написать на чистых плюсах? А как мы будем доставлять изменения в продакшен, чтобы не поломать работающие системы?

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

  1. Сразу напишем небольшое приложение. Язык выбираем абсолютно любой. Приложение будет отдавать информацию о пользователях через HTTP. По сути, простенькое API.
  2. Теперь давайте добавим работу с базой: пусть наши пользователи хранятся в базе. Идеально структуру базы хранить рядом с кодом и научиться прогонять миграции при новых изменениях. Таким образом ваше приложение само синхронизирует базу до нужной структуры.
  3. Регистрируемся на GitHub/Bitbucket и закидываем весь исходный код нашего приложения туда.
  4. На своей машине поднимаем Jenkins/TeamCity и настраиваем автоматическую сборку приложения из нашего репозитория по кнопке.
  5. Усложняем задачу. Настроим webhooks на GitHub/Bitbucket, которые будут автоматически запускать сборку на Jenkins/TeamCity.
  6. Добавим тестов в Jenkins: как минимум можно прогонять линтер по нашему коду или набросать unit-тесты.
  7. Переключимся на настройку dev окружения. Берём в руки Ansible, Chef, Puppet или SaltStack и настраиваем виртуалку с нуля: создаем пользователей, устанавливаем необходимые библиотеки и зависимости.
  8. Подводим все это дело под Vagrant: виртуалка должна автоматически подниматься и настраиваться.
  9. Подключаем vagrant к Jenkins с помощью соответствующего плагина: при пуше в Git наше приложение собирается, и поднимается виртуальное окружение с помощью Vagrant + Configuration System Management.
  10. Ищем best practices по деплою приложений на языке, который вы выбрали. Можно заворачивать всё в deb-пакеты, можно деплоить Ruby с помощью Capistrano. Главное — выбрать решение.
  11. Выбор сделан, реализуем его и конфигурируем Jenkins, чтобы после пуша в репозиторий, Jenkins, помимо сборки приложения и развертывания окружения, выкладывал и запускал наш код.
  12. Добавляем смоук-тесты: после запуска Jenkins должен запросить список пользователей у нашего API и убедиться, что получает ответ.
  13. Добавляем мониторинг нашего проекта: изучаем time series базы, настраиваем prometheus, grafana, автоматически подключаем новый инстанс нашего приложения к мониторингу.
  14. Улучшаем мониторинг: интегрируемся со Slack и PagerDuty, чтобы получать нотификации.
  15. Читаем про Docker, пишем Dockerfile и оборачиваем наше приложение.
  16. Изучаем увлекательные статьи про настройку систем оркестрации Swarm, Kubernetes, Rancher Cattle. Следуем рекомендациям и поднимаем кластер.
  17. Меняем Jenkins: собираем Docker-образ, прогоняем тесты, запускаем собранный докер на кластере Kubernetes, проводим smoke-тесты, вводим наше приложение в балансировку.

Главной целью всех этих шагов является получение опыта работы с различными технологиями. Я уже говорил, что самое главное для DevOps-специалиста — это кругозор, так что берем эти же 17 пунктов и в каждом из них меняем технологию на новую. Писали приложение на Go? Теперь пишем на Ruby. Использовали Jenkins? Берём TeamCity. Поднимали Kubernetes? Настраиваем swarm. Таким нехитрым образом через несколько месяцев вы заранее сможете понять, что лучше использовать в конкретной ситуации, а это — самое главное качество грамотного и успешного DevOps.

Каким должен быть DevOps-специалист

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

По моему мнению, идеальный путь человека в DevOps — когда он сначала работает системным администратором и со временем сам понимает, какие «ручные» вещи можно автоматизировать. А после этого уже начинает пробовать и внедрять разные инструменты автоматизации в свои процессы. Так он развивает в себе эту культуру и вырастает в DevOps-инженера. Нельзя сказать, что такой путь априори правильный, но выглядит он сегодня логично, — считает Дмитрий Меремьянин.

По мнению Дмитрия Меремьянина, идеальный путь человека в DevOps начинается с работы системным администратором

Роман Гершкович, преподаватель «Нетологии», выделяет четыре качества, которые должны быть важны для руководителя при выборе специалиста:

1. Хорошая база и желание разбираться, как работают используемые компоненты.

На мой взгляд, основная сложность состоит в том, чтобы найти людей с хорошей базой. Сейчас доступно множество готовых модулей, «строительных блоков» для любого инструмента управления конфигурациями, которые позволяют быстро получить сложную по устройству систему. Многие специалисты научились пользоваться подобными высокоуровневыми инструментами, но на этом остановились, не стали углубляться в принципы и результат их работы. А ведь это нужно для многих проектов: чтобы поддерживать и эффективно эксплуатировать сложную систему, минимизировать downtime, обязательно как минимум знать базовые вещи по Linux — какими ресурсами ОС управляет, как оценить их утилизацию, потребности приложений, наличие ошибок, и как их дебажить, — объясняет Роман Гершкович.

2. Структурный подход к задачам.

Используя одни и те же инструменты, можно пойти по двум разным путям:
а) сделать удобную поддерживаемую структуру,
b) сделать бездумный copy-paste из мануала.

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

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

Основная сложность состоит в том, чтобы найти людей с хорошей базой, считает Роман Гершкович

3. Умение встроиться в действующую систему.

У каждой команды и продукта своя история, экспертиза и use-кейсы. Поэтому практически по любому компоненту современных систем невозможно дать единственно верную оценку. В каждом конкретном случае иметь вес будут разные аспекты. Человек, которого вы нанимаете, должен это понимать. Даже если он суперпрофессионал в конкретной области с собственным мнением, он должен хотеть встроиться в команду с ее текущими правилами. Желание все действующее переделать, снести и построить заново только потому, что он лучше разбирается в Х, а не Y — губительно, — уверен Роман Гершкович.

4. Желание человека постоянно развиваться

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

Настоящих специалистов, которые способны внедрять методологии DevOps в компанию, очень мало. Алексей Чувашов, CTO 65apps считает, что многие бывшие сисадмины просто учат новый и модный стек, но не пытаются понять процессы разработки и workflow задачи разработчиков. Еще меньше понимания у самих заказчиков или работодателей: зачем им нужен DevOps, какие задачи и потребности он должен закрывать.

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

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

Заключение

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

Важно отметить, что это было сделано весьма успешно:

Теперь DevOps добрался до традиционных организаций, где в процессе внедрения (зачастую очень болезненного) ему предстоит столкнуться с новыми вызовами. Но для таких компаний это уже не вопрос улучшения, а необходимый шаг в борьбе за выживание. Изменения в форме «творческого разрушения» являются постоянной и реальной угрозой существованию крупных компаний. Только 12% списка Fortune 500 от 1955 года оставались в нем и в 2014.

ИТ-компании должны стараться везде, где только возможно, использовать свежие идеи и постоянно ставить под сомнение консервативные практики.

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

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

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

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

Adblock
detector