вторник, 21 апреля 2020 г.

Личный опыт: карьерный рост в DevOps-отделе компании разработчика ПО

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

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


Дисклеймер

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

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

Про DevOps-направление в ИТ индустрии

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

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

 Функциональные обязанности отделов автоматизации сильно зависят от специфики работы конкретной компании. Например, в связи с тем, что наша компания является разработчиком и вендором решений в сфере ИБ, то на наш отдел автоматизации (очень неформально называемый DevOps-отделом), возлагается ответственность за производственный конвейер: от сборки отдельных компонент продуктов, до отправки их на тестирование и доставки обновлений на инфраструктуру заказчика. Мы помогаем автоматизировать основные разработческие процессы в командах и обеспечиваем работоспособность наших систем Continuous Integration и Continuous Delivery (CI/CD).

Наша работа разделена на несколько функциональных направлений. Направление Continuous Integration поддерживает сборочные и тестовые конвейеры для разработчиков и тестировщиков. Направление инфраструктуры занимается эксплуатацией и оптимизацией использования всех «железных» ресурсов отдела, а также автоматизацией развертывания виртуальных машин и окружения на них (Infrastructure as a Code). Направление мониторинга обеспечивает контроль работоспособности сервисов 24/7. Также мы предоставляем мониторинг как сервис для разработчиков (Monitoring as a Service). Направление workflow предоставляет командам инструменты для управления процессами разработки и тестирования, анализа состояния кода и получения аналитики по проектам. И наконец, направление webdev обеспечивает публикацию релизов на корпоративных серверах обновлений (GUS и FLUS), а также лицензирование продуктов при помощи сервиса LicenseLab.

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


Личный опыт развития в профессии и кейсы внедрения DevOps-культуры

Расскажу немного про развитие в профессии, но издалека, на личном примере. Как я попал в DevOps и автоматизацию? У меня был длинный путь и, поначалу, совершенно не связанный с разработкой. Более того, честно признаюсь, я никогда и не хотел быть разработчиком. Мой диплом вообще учителя математики и информатики. Тем не менее, ещё со школьных лет я так или иначе всегда был связан с программированием, математикой и ИТ.

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

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

Более глубоко интересоваться разработкой программного обеспечения я начал, когда устроился на работу тестировщиком-автоматизатором в компанию интегратор "Центр" в Казани. Там я получил первый опыт в автоматизации тестирования веб-приложений, а главное, стал лучше понимать этапы разработки ПО, даже начал вести блог по этой теме. Затем я попал в компанию Позитив Текнолоджиз в Москве. Начал карьеру также тестировщиком-автоматизатором и работал над новым перспективным продуктом компании — Black Box веб-сканером ИБ. После этого работал в разных отделах, накапливал опыт и с 2014 года перешёл в отдел технологий и процессов разработки, где мы вместе с коллегами начали развивать и внедрять идеи DevOps. Именно здесь я стал интересоваться не только разработкой ПО, но и погружаться глубже в процессы разработки и концептуально понимать продуктовый конвейер.

У остальных наших ребят совершенно различный бекграунд: есть тестировщики, программисты, инженеры и администраторы ИТ, но благодаря разнообразию общего опыта мы смогли справиться с задачами всех наших направлений работы. Фактически, в нашем отделе сейчас нет ни одного инженера, который бы смог в одиночку решить все задачи по всем направлениям. Но все вместе мы, как отдел, как административная единица, являемся тем самым SRE, только не "Site", так как мы поддерживаем сервисы для разработчиков, a "Services" Reliability Engineers, которых безуспешно ищут HR-специалисты в лице одного инженера. Мы считаем, что большое разнообразие продуктовых задач компании возможно решать только в составе команды разносторонне образованных инженеров.

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

Много лет назад в компании выбрали в качестве системы Continuous Integration для автоматизации сборки и тестирования кода инструмент TFS (Team Foundation Server). С течением времени стало очевидно, что у этой системы есть целый ряд недостатков. В частности, при её использовании было трудно поддерживать шаблоны сборочных, деплойных и тестовых конфигураций, возникали проблемы с интеграцией не C#-проектов, было невозможно оперативно расширять инфраструктуру. Чем дольше мы использовали TFS, тем острее становились потребности в типизации и шаблонизации конфигураций, ускорении создания типовых проектов и обеспечение их масштабируемости. На решение этих задач у нас ушло почти два года, но зато сейчас бизнес имеет возможность создавать с нуля сборку любых новых продуктов или их компонент очень и очень быстро, экономя и деньги и время дорогих квалифицированных разработчиков.

Вот, как сейчас выглядит инфраструктура Continuous Integration в Positive Technologies. Она состоит из связки трех базовых сервисов: GitLab CI — система организации Continuous Integration. GitLab — система хранения исходного кода. Artifactory — система хранения собранных бинарных версий компонент и продуктов. Отдельное внимание мы уделили разработке типовых проектов. Это позволило нам добиться унификации проектов, выделив так называемую релизную схему сборок с продвижениями. Помимо стандартных процессов сборки, деплоя, тестирования и продвижения, у нас добавилась система публикации протестированных релизных сборок на Global Update-сервера, откуда они распространяются дальше вплоть до инфраструктуры заказчика. Это типовая схема продуктового конвейера, по которой идёт разработка всех продуктов компании.


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

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

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

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


Разумеется, под каждую категорию мы разработали документы с должностными инструкциями, где были прописаны функции и роли сотрудников, а также указаны зоны ответственности сотрудников по сервисам и направлениям работ. Но так как мы, кроме инжиниринга, ещё и любим программировать, а читать скучные документы никто из нас не любит, то и здесь мы немного упростили себе жизнь. Каждую инструкцию мы написали не в Word-е, а в виде простого текста, отформатированного специальным языком разметки Markdown. При этом не теряется его читаемость человеком в любом редакторе. После этого мы запушили (сохранили) эти тексты в нашем хранилище GitLab (это специальный сервер, который часто используют программисты для хранения исходного кода программ, а для общения с ним устанавливают у себя локально на компьютере git-клиент). Сам 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 на приемлемом уровне. Точно также нам не нужен мега-квалифицированный линукс-администратор, но нам нужен человек с достаточными знаниями ОС Debian или Ubuntu, чтобы он сумел установить сборочные GitLab CI агенты, а ещё лучше, автоматизировал эти работы через SaltStack, Ansible или другие инструменты.

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

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

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


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

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


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

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

Автор: на
Ярлыки: , , , , , , , , ,