13.05.2020 12:35
ptsecurity 2 3600 Источник


Всем привет! Меня зовут Тимур Гильмуллин, я заместитель руководителя отдела технологий и процессов разработки в компании Positive Technologies, занимаюсь автоматизацией и внедряю идеи DevOps. Сегодня расскажу, как я попал в профессию, как в нашем отделе мы видим карьеру DevOps-инженера, что такое карта компетенций, и как она помогает обеспечивать рост сотрудников.

Дисклеймер


Данная статья — не попытка описать идеальную траекторию карьеры DevOps-инженера. Наша цель — поделиться опытом и рассказать, как это устроено у нас. Есть специализированные компании (express 42, flant) и сообщества (devops deflope), которые вносят значительный вклад в развитие идей DevOps в России, а мы подобрали стек подходящих именно нам технологий и методик.

О том, как мы развивали идеи DevOps в нашем отделе и в компании, можно почитать на Хабре:


А теперь, поехали!

Зачем нам нужен DevOps


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

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

Как все устроено


Функциональные обязанности отделов автоматизации также сильно зависят от специфики работы конкретной компании. Наша компания является разработчиком и вендором решений для ИБ, и на отдел автоматизации возлагается ответственность за производственный конвейер — от сборки отдельных компонент продуктов до отправки их на тестирование и доставки обновлений на инфраструктуру заказчика. Мы помогаем автоматизировать основные разработческие процессы в командах и обеспечиваем работоспособность наших систем (continuous integration и continuous delivery (CI/CD)).

Наша работа разделена на несколько функциональных направлений. Направление continuous integration поддерживает сборочные и тестовые конвейеры для разработчиков и тестировщиков. Направление инфраструктуры занимается эксплуатацией и оптимизацией использования всех «железных» ресурсов отдела, а также автоматизацией развертывания виртуальных машин и окружения на них (infrastructure as code). Направление мониторинга обеспечивает контроль ежедневной работоспособности сервисов. Также мы предоставляем мониторинг как сервис для разработчиков (monitoring as a service).

Направление workflow предоставляет командам инструменты для управления процессами разработки и тестирования, анализа состояния кода и получения аналитики по проектам. И, наконец, направление webdev обеспечивает публикацию релизов на корпоративных серверах обновлений (GUS и FLUS), а также лицензирование продуктов при помощи сервиса License Lab.

Для поддержки производственного конвейера мы настраиваем и сопровождаем множество различных вспомогательных сервисов для разработчиков. Рассказы про некоторые из них можно послушать на наших старых митапах: Op!DevOps! 2016 и Op!DevOps! 2017. Также мы разрабатываем инструменты внутренней автоматизации, в том числе DevOpsHQ.



Опыт наших инженеров


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

В нашем отделе сейчас нет ни одного инженера, который бы смог в одиночку решить все задачи по всем направлениям. Но вместе мы как административная единица являемся тем самым SRE (только не site, a services reliability engineers, так как мы поддерживаем сервисы для разработчиков), которых безуспешно ищут HR-специалисты в лице одного инженера. Мы считаем, что большое разнообразие продуктовых задач компании возможно решать только в составе команды разносторонне образованных инженеров.

Технических кейсов внедрения автоматизации у нас великое множество. Но главное, это объяснить людям, зачем им нужна эта автоматизация. Проще всего, когда техническая задача идет от бизнеса, то есть когда у людей, приносящих компании деньги, есть четкое понимание: что, как и когда нужно сделать или оптимизировать. Предлагаю посмотреть наши кейсы автоматизации: "Личный опыт: как выглядит наша система Continuous Integration".

Про карьеру в нашем DevOps-отделе


Хотелось бы сказать, что у нас заранее все было готово и запланировано, но это не так. Сначала у нас не было ничего в планах роста и развития. В 2014 году, когда я перешел в отдел технологий и процессов разработки, продуктовая разработка жила духом стартапа: все нужно сделать здесь и сейчас, долгосрочные планы не принимались, было много «легаси». Нас тогда было четыре инженера, и перед нами стояло множество технических задач: нужно срочно делать CI, масштабировать сборочный конвейер, перед этим, конечно же, создать этот конвейер, а также выстраивать взаимодействие с нашими внутренними заказчиками — программистами из отделов разработки.

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

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



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

Но так как мы, кроме инжиниринга, еще и любим программировать, а читать скучные документы никто из нас не любит, то и здесь мы немного упростили себе жизнь. Каждую инструкцию мы написали не в ворде, а в виде простого текста, отформатированного специальным языком разметки Markdown. При этом не теряется его читаемость человеком в любом редакторе. После этого мы сохранили эти тексты в нашем хранилище GitLab. Сам GitLab умеет очень красиво отображать различные форматы документов, в том числе Markdown отрисовывает так, что не отличить от Word. А стандартный Git-клиент обладает множеством дополнительных возможностей, например может показать diff (разницу) между двумя документами.

Это очень упрощает жизнь инженеру, который хочет узнать, какие формальные требования ему нужно соблюсти, чтобы перейти на следующую ступеньку (категорию) персонального роста в нашем отделе. Чтобы узнать разницу между формальными требованиями двух должностных инструкций, нужно выполнить несколько простых действий: скачать репозиторий с должностными инструкциями из нашего GitLab, найти документы, выполнить в консоли команду Git для вывода сравнения двух файлов. Например, посмотреть разницу между старшим инженером 2-й и 1-й категорий можно так:

git --no-pager diff --no-index 
level_08__DevOps_Senior_Software_Engineer_2nd_category.md
level_09__DevOps_Senior_Software_Engineer_1st_category.md

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

Да, мы немного маньяки-технари, но тогда это нам показалось отличным решением:



Карта компетенций DevOps-инженеров


По мере развития нашего отдела и увеличения количества продуктовых конвейеров, находящихся на нашей поддержке, мы поняли, что по каждому из направлений работ, которыми мы занимаемся, не получится описать однозначную роль и найти подходящего инженера на рынке. У нас своя специфика работы и нам, например, не нужен мегаквалифицированный программист разработчик ПО для решения CI-задач, но тем не менее CI-инженер должен уметь программировать небольшие модули и скрипты на Python на приемлемом уровне. Точно также нам не нужен мегаквалифицированный Linux-администратор, но нам нужен человек с достаточными знаниями ОС Debian или Ubuntu, чтобы он сумел установить сборочные агенты GitLab CI, а еще лучше — автоматизировал эти работы через SaltStack, Ansible или другие инструменты.

Так что же должен уметь делать DevOps-инженер, работающий в нашем отделе? Для этого сначала нужно определиться с тем, что такое знания, умения и навыки (сокращенно ЗУН) в общем понимании.

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

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

Таким образом мы пришли к необходимости описать и классифицировать все наши требования к инженеру в табличном виде и у нас появилась «Карта компетенций DevOps-инженеров 1.0». Выглядит она так:



Таблица разбита на четыре крупные секции:

  1. Описание общих компетенций сотрудников нашего DevOps-отдела, необходимых для успешного решения повседневных задач.
  2. Знания — специфические, ориентированные на продукт знания инженеров DevOps.
  3. Умения — способности применить знания на практике для решения наших продуктовых задач; умение работать с используемыми у нас инструментами и технологиями.
  4. Навыки — профессиональное владение используемыми у нас инструментами и технологиями; изученные и доведенные до автоматизма действия при решении типовых задач, не требующие особых усилий для их выполнения.

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

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



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

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

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

Автор: Тимур Гильмуллин — зам. руководителя отдела технологий и процессов разработки (DevOps) компании Positive Technologies.