Описание скилл матрицы DevOps-инженера

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

Наша скилл-матрица возникла после многократных попыток придумать и расписать роадмэп роста и развития DevOps-инженера в нашей компании. Так как мы понимаем, что к нам приходят люди из разных сфер и с разным багажом знаний и компетенций. Поэтому мы решили пойти другим путем и создать перечень скиллов, необходимых для работы в нашей компании. Тем самым, сформировав трехуровневую систему, где каждый уровень состоит из опросника и критериев к кандидату. Грубо говоря, подготовили первую версию грейдинга и аттестации. Однако, такая система не помогла решить нашу задачу. Позже мы узнали о крутом инструменте для команд — self assessment skill matrix. И решили применить инструмент на практике у DevOps и трансформировали наши заготовки в скилл-матрицу. После провели сессию, где поставили себе текущие и желаемые на пол года оценки. В качестве инструмента использовали Miro, но вполне можно обойтись и Google sheets (там и компактнее, и медиану по скиллам считать проще).

Скиллы и компетенции

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

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

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

Linux

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

• процессы, девайсы, дисковые разделы, lvm, файловые системы, неймспейсы и cgroups;
• загрузчики, процесс загрузки, systemd и юниты;
• сетевая подсистема netfilter, пользовательские утилиты: iptables, shorewall, tc итд базовое знание сетевых протоколов;
• виртуализация — в первую очередь kvm, так же знать виды виртуализации и другие технологии;
• настройка и работа с базовыми сервисами: dhcpd, nfs, sshd, dns(bind), mail(postfix, sendmail), web(nginx, apache, caddy, traefik etc), database(mysql, postgres);
• базовый скриптинг на bash/python;
• базовый траблшутинг.

Docker/Containers

Не смотря на то, что Docker постепенно сдает свои позиции, но пока мы не можем его исключить из списка необходимых навыков. Как минимум еще несколько лет для локального применения представить что-то другое очень сложно. Если говорить про k8s, то официальная поддержка докера как Container Runtime полностью должна прекратиться с выпуском релиза 1.23.

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

Что необходимо знать:

• Отличие контейнеризации и виртуализации;
• Какие компоненты ОС позволяют реализовать контейнеризацию;
• Запуск докер контейнеров, используя публичные докер образы;
• Написание собственных Dockerfiles, основываясь на best practices (порядок слоев, кэши, мульти стейж сборки, etc);
• Подготовка docker-compose файлов для ускорения и упрощения локальной разработки;
• Понимание как работает сеть в докере;
• Применение security практик;
• Знать и быть готовым перейти на dockerless инструменты. Например: buildkit, buildah, kaniko, etc.

Terraform и IaC

Среди великого разнообразия инструментов (pulumi, Cloudformation, aws cdk, etc), помогающих “нести в массы“ подход IaC (Infrastructure as a Code), было решено использовать Terraform для описания инфраструктурной составляющей. Здесь очень важно понимать несколько вещей:

1. Терраформ не серебряная пуля и не может заменить абсолютно все инструменты. Так, для настройки виртуальных машин лучше использовать такие инструменты как: Packer, Ansible/Chef/Puppet/Salt, Whatever you want (bash?);
2. Это не инструмент для управления Multi-Cloud. Его можно назвать таковым с очень большой натяжкой. Управляя только AWS, нельзя поднять инфраструктуру в GCP, используя тот же самый код. Каждый провайдер имеет свой набор ресурсов и эти ресурсы называются по-разному. Но несмотря на это, использование Терраформа позволяет нам не учить новый синтаксис различных инструментов и новые подходы организации кода для работы с разными облаками/провайдерами. Что в разы ускоряет процесс написания и поддержки, и передачи кода между инженерами.

Из всего этого сложились некоторые требования к знаниям:

• Умение читать чужой терраформ код. Из этого следует чтение и понимание кода используемых публичных модулей (входные/выходные параметры, логика, используемые ресурсы);
• Использование публичных модулей;
• Умение описать в виде читаемого, поддерживаемого и переиспользуемого кода инфраструктуру проекта;
• Написание собственных модулей и понимание как их использовать;
• Понимание как лучше организовать структуру проекта;
• Умение работать со стейт файлом вручную (импорт существующих ресурсов в код, удаление объектов, движение объектов между ресурсами (как пример — из ресурса в модуль));
• У MadDevs есть OpenSource проект GitHub — maddevsio/aws-eks-base: This boilerplate contains terraform configurations for the rapid deployment of a Kubernetes cluster, supporting services, and the underlying infrastructure in AWS. Предполагается, что человек, владеющий на достаточном уровне Терраформом, активно принимает участие в обсуждении улучшений, а также периодически контрибьютит изменения.

CI/CD

Без процессов CI/CD (Continuous Integration / Continuous Delivery / Continuous Deployment ) сейчас невозможно представить ни один проект, который хочет уменьшить такой показатель как Time-To-Market без потери качества. Поэтому очень важно как понимать концепции, так и уметь их правильно применять. Чаще всего наша задача здесь состоит в написании пайплайна, который ложится на flow разработки. Закрепим важную мысль, что мы не натягиваем flow на пайплайн, а подстраиваем пайплайн под flow. Сейчас уже практически не важно, какая CI/CD система будет использована, т.к. все они обладают в большей степени схожим функционалом. НО важно помнить, что EDGE кейсы существуют, и знание сильных/слабых сторон той или иной системы позволят сделать правильный выбор в нужный момент.

Необходимые знания в этой сфере:

• Понимание концепций CI, CD, CD. Что это такое и чем отличаются.
• Написание простых читаемых пайплайнов;
• Умение перенести flow разработки на CI/CD пайплайн, который может включать в себя сложную логику: откаты, ручные шаги, триггерить другие джобы, системы, отправка уведомлений;
• Оптимизация пайплайнов. Умение найти bottlenecks, ускорить, оптимизировать с точки зрения стоимости;
• Знание различных стратегий выкатки нового релиза и умение их реализовывать: RollingUpdate, Blue/Green; Canary.;
• GitOps — что это такое, когда лучше применить и какие инструменты лучше использовать;
• Знание туллинга и уметь встроить в шаги пайплайнов анализ инфраструктурного и аппликейшн кода, анализ образов и систем на уязвимости, секьюрити чек публичных эндпоинтов.

AWS/Azure/GCP (+ секция Clouds)

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

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

Что следует знать:

• Как настроить сеть: сюда могут входить такие сервисы как VPC, security groups, subnets, peerings, VPN, Firewall;
• Виртуальные машины;
• IAM;
• Стораджи: диски, объектные хранилища;
• Сервисы для деплоя контейнеров: ECS, AppRunner, Beanstalk, AppEngine, Web Apps, etc;
• Сервисы для работы с базами данных (как реляционных, так и нет);
• Как управлять кластером кубернетис;
• Load Balancers, CDN.

При построении облачной инфраструктуры также полезно:

• Понимать что это и знать различные PaaS, IaaS, SaaS. Подобные знания очень сильно могут ускорить старт проекта без лишнего рукоделия;
• Уметь мигрировать в облака с on-premise и между облаками. Т.е. необходимо правильно рассчитать капасити, стоимость, подобрать нужные сервисы и т.д.;
• Постоянно держать в голове парадигму Cost optimization и применять практики сокращения костов (споты, резервы, preemptible ноды, etc);
• Понимать Well-architected framework и уметь строить инфраструктуру по нему;
• Знать построение инфраструктуры, соответствующей тем или иным compliances (iso 27001, pci, gdpr, hipaa) и готовой для прохождения аудитов;
• Уметь эффективно управлять достаточно большой инфраструктурой (ежемесячный чек более 10к и выше).

Kubernetes

Там где это возможно (а это 99.9999999% проектов), мы стараемся использовать Managed решения от облачных провайдеров, что накладывает свой отпечаток на характер работы с k8s. Большую часть времени мы выступаем в роли пользователей кластеров, а не в качестве их администраторов. Поэтому список необходимых знаний складывается из пользовательского опыта:

• Знания отличий Managed решений между вендорами: GKE, EKS, AKS. Какие есть преимущества и недостатки.
• Понимание, умение работать и дебажить основные объекты: Pod, Deployment, Replicaset,Jobs / Cron Jobs, Daemonset, Statefulset.
• Типы Service-ов. Что такое Ингресс.
• Работы с Configmap, Secrets. Sealed secrets, external-secrets.
• Понимание отличий между sidecar и init контейнерами и их применение при необходимости.
• Автоскейлинг кластера. Использование разных типов нод для cost-optimization.
• Применение продвинутых техник шедулинга подов: nodeSelector, affinity, antiAffinity, topologySpread.
• Управление ресурсами пода / неймспейса.
• Понимание и умение настраивать RBAC, Network Policies.
• Понимание отличий между Admission and Mutating контроллерами. И возможность написать свое решение при необходимости.
• Применение ServiceMesh там, где это надо.
• Повсеместное применение/внедрение Security практик. Использование OPA (Open Policy Agent), если необходимо.
• Понимание архитектуры: какие есть компоненты, за что отвечают, как связаны между собой.

Helm

Так как helm представляет собой инструмент для кубера, то и требования относятся к знаниям работать с ним, например:

• “Чтение“ публичных helm чартов. Какие переменные можно использовать, куда подставляются, из каких k8s манифестов состоит чарт;
• Написание своих собственных чартов. При этом необходимо придерживаться принципа DRY. Использовать циклы, условия, функции там, где это необходимо, чтобы сократить количество кода. При этом темплейты должны быть читаемы;
• Написание так называемых Umbrella charts, если это необходимо;
• Кастомизация публичный чарт (т.е. добавление новых объектов в чарт);
• Опыт работы с такими инструментами как: helm-diff, helmfile.

Observability

Одним из самых важных компонентов современных систем является Observability или по-русски “Наблюдаемость“. Не представляется возможным эффективно поставлять изменения пользователю и эффективно управлять ресурсами, не имея хорошо настроенных инструментов observability.

Чаще всего у нас на слуху только слова “Мониторинг” и “Логирование”. Но “наблюдаемость“ куда более широкое понятие, которое включает в себя еще и трейсинг. Можно сказать, что это 3 кита хорошо выстроенного процесса observability.

Ожидаемые навыки:

• Умение работать с популярными системами мониторинга: Prometheus, VictoriaMetrics, etc и компонентами вокруг (многочисленные экспортеры, etc);
• Способность работать с популярными системами/стеками логирования: ELK, EFK, Loki, Datadog, etc;
• Опыт работы с популярными системами трейсинга: Jaeger, APM, etc;
• Errors tracking и мониторинг производительности: Sentry, NewRelic, etc;
• Знание как делать кастомные дашборды для Grafana на основе выставленных требований;
• Скилл парсить и фильтровать логи в используемых системах логирования.

Security

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

• Придерживаться принципов Least Privileges при работе с юзерами, сервис аккаунтами и предоставлением прав;
• Подходы к построению инфраструктуры очень сильно изменились в последнее время. Если раньше считалось, что внутри своей приватной сети “безопасно“, то все новые подходы гласят о “Zero Trust“ (не доверяем никому и ничему) повсеместно. Поэтому нужно стараться придерживаться данной концепции везде, где только возможно;
• Знать стандарты iso 27001, HIPAA, PCI DSS, GDPR, CIS Benchmark, OWASP.

Solution Development

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

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

DevOps/SRE

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

• Иметь хорошее представление об SDLC, в первую очередь интересует модель Agile;
• Знать что из себя представляют Delivery Pipeline и Feedback Loop, уметь выстроить/оптимизировать эти процессы вместе с командой, подобрать на каждый шаг адекватный инструмент;
• Понимать и уметь выстраивать процесс менеджмента инцидентов: логирование и категоризация; оповещение и эскалация; поиск причины и ее устранение; написание плейбуков;
• Уметь и практиковать написание постмортемов для системного улучшения стабильности и качества;
• Уметь разрабатывать и внедрять адекватный требованию бизнеса Disaster Recovery план.

Карьерный план: что это и как его составить

Soft Skills

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

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

Что особенно выделяется среди скилов:

• Самообучение. В наше время, когда технологии меняются каждый день — невозможно опираться на знания, полученные 10 лет назад (если это базовые вещи, такие как TPC/IP). Необходимо все время совершенствоваться и изучать что-то новое. Без самообучения невозможно хорошо и быстро прокачать hard скилльную составляющую.
• Коммуникативные навыки. Рабочий процесс DevOps-инженера чаще всего строится на командной работе, коммуникациях, эскалации проблем и т.д.Также в рамках таких коммуникаций реально проверить и прокачать свои хард скиллы. Не забывайте как вы формулируете свои мысли при постановке задач. Ваша команда должна получать четкие и понятные пояснения к задачам.
• Самоорганизация. Умение работать независимо без постоянного менторства. Это не касается, конечно же, момента, когда вы только что приступили к своим обязанностям и не знаете даже направления, в котором необходимо работать. Но чем быстрее вы сможете начать работать без постоянного наставника, тем быстрее пойдет процесс прокачки.
• Менторство. Для того чтобы обучать кого-то не обязательно быть Senior Engineer. Умение обучать других — хороший способ закрепить и систематизировать знания, которые были получены. Также это помогает прокачивать коммуникативные навыки.
• Целеустремленность. Нужно уметь достигать поставленных целей как в одиночку, так и работая в команде. Не всегда получается залететь в проект командой DevOps инженеров, поэтому необходимо уметь выставлять и достигать поставленных целей.
• Знание английского языка. Подробнее зачем и для чего DevOps-инженеру нужен английский мы поговорим ниже.

Специально для оценки Soft skills в нашей компании есть отдельная матрица, где очень подробно подсвечены все необходимые навыки.

English

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

Большинство проектов приходят в MD из англоязычного сегмента. И как бы вы не подходили по компетенциям и скиллам, вы просто не сможете попасть в такой проект без знания английского. Есть исключения, когда можно “спрятаться за команду или ПМа”. Но и это работает до поры до времени, т.к. наступит момент, когда придется отстоять свое решение/мнение/точку зрения перед англоязычным заказчиком, продактом или тиммейтом, и верно донести или воспринять информацию. Также стоит обратить внимание на тот факт, что зачастую зарубежные проекты более технологичные и передовые, что влияет на рост инженера.

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

Ответ очевиден — чем выше, тем лучше! Из опыта можем указать, что уровень нужен не ниже B1.

• B1 — уже хорошо
• B2 — отлично
• C1 — супер.

Подробнее об уровнях знания английского языка:

• B1 (Intermediate) — рунглиш и уже развивающийся правильный разговорный. Можешь выйти за рамки базового английского, но не всегда готов на нем общаться на рабочие темы. На таком уровне знаний ты можешь излагать мысли так, что твои собеседники тебя понимают; средне понимаешь речь на слух; читаешь и пишешь, регулярно используя переводчик или словарь; базовая грамматика присутствует.
• B2 (Upper-Intermediate) — уверенная и разнообразная разговорная речь (с акцентом, но правильным произношением). Можешь спокойно общаться и работать в англоязычной среде; уверенное письмо и хорошая грамматика — минимум ошибок, правильное применение времен, герундий, модальных глаголов, нет проблем с артиклями (вроде простая вещь, но она и выдает уровень).
• C1 (Advanced) — Уровень, к которому нужно стремиться. С данным уровнем можно спокойно жить и общаться в стране, где родным языком жителей является английский. Ты можешь говорить на уровне с носителями или даже лучше.

Заключение

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

Постройте свою карьеру вместе с Mad Devs