Привет! Меня зовут Эмин, я тех-лид платформенных команд в Профи. В этой статье поделюсь мнением о том, что такое хороший DevOps и какими качествами должен обладать DevOps-инженер.

База

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

• Автоматизируем всё, что можно автоматизировать в SDLC.

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

• Шарим ответственность за продукт — убираем границу между разработчиками (dev) и сис-админами (ops), больше коммуницируем, разбиваем командные «бункеры», внедряем принцип you build it — you run it.

Часто SLDC на DevOps изображают в виде знака бесконечности:

Понимаю, звучит как «за всё хорошее, против всего плохого», но дать более точное определение сложно т.к. в разных компаниях DevOps реализуется по-разному. Это как в Lego — есть много разных кубиков и механизмов, но каждый строит из них tailored-решения для своих проблем. Не смотря на это, всё же можно выделить компоненты, которые делают DevOps качественным и эффективным. 

Хороший DevOps

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

У меня получился такой минимальный набор компонентов для запуска DevOps-потока:

• Планирование.

• Автотесты.

• CI/CD.

• Выравнивание окружения.

• Непрерывный фидбек.

Планирование

Не буду подробно останавливаться на различных методах планирования и ведения задач т.к. эта тема больше относится к Agile-методологиям. Главное, чтобы инструмент работал, позволяя планировать и отрабатывать актуальные таски в соответствии с приоритетом.

Автотесты

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

Обязательно:

• smoke-тесты — дают базовую уверенность в том, что софт работает;

• api-тесты и тесты бизнес-логики — тут я бы настаивал на максимально возможном покрытии т.к. ошибки могут привести к реальным проблемам для бизнеса;

• стат-анализаторы и линтеры — гигиена, которая стоит недорого, но делает код более аккуратным, ловит базовые ошибки и опечатки;

Желательно:

• security-чеки — сканеры уязвимостей, credential-детекторы и т.п. Необходимость зависит от чувствительности продукта к проблемам безопасности и от уровня паранойи. 

• end-to-end тесты — перед автоматизацией очень аккуратно смотреть на стоимость внедрения и поддержки т.к. иногда ручное QA может быть сильно эффективней.

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

• unit-тесты — можно проверять какие-то специфические алгоритмы, могут помочь при рефакторинге, но я бы сильно не увлекался;

CI/CD

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

Обязательно:

• Система контроля версий.

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

• Автоматический запуск чеков перед и после мержа в мастер-ветку. Тут важно помнить про скорость — запуск тестов не должен надолго блокировать разработчика, особенно, если команда большая. 

• Сборка билда из мастер-ветки.

• Раскатка конкретного билда на реальных пользователей.

Желательно:

• Стенды для разработчиков.

• Continuous Deployment — автоматическая сборка и раскатка билда на реальных пользователей.

• production-like стейджинг для предрелизного тестирования. 

• Частичная раскатка билдов — канареечные релизы, фича-флаги и т.п.

Выравнивание окружения

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

• Снизить вероятность распространения багов, возникающих только в конкретном окружении — такие ошибки очень сложно ловить. Например: локально всё ок, тесты проходят, на стенде работает, а после релиза на проде взрывается;

• эффективно устанавливать зависимости во всех окружениях;

• упростить и ускорить онбординг новых разработчиков, особенно, если окружения быстро поднимаются из VM, как, например, в Codespaces или dev-containers. 

Непрерывный фидбек

CI/CD увеличивает скорость разработки, а сбор данных и мониторинг — качество. Не сам по себе, конечно, а при условии корректной интерпретации и обработки. Что должно быть на борту:

Обязательно:

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

• Мониторинг состояния критичных ресурсов — диски, память, процессоры, сеть и т.п.

• Алертинг о критичных ошибках или «пробитиях» SLO.

Желательно:

• healthcheck.

• APM-мониторинг и трейсинг — анализ того, как работают приложения и сервисы, что и сколько «жрёт», куда и как часто «ходит», как быстро обрабатываются запросы, где есть «затыки» и т.п. 

• Мониторинг работы бизнес-логики и пользовательских сценариев. 

• Сбор и агрегация данных от пользователей продукта — NPS, отзывы в сторах и т.п. 

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

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

DevOps-культура

Пару слов про культуру. Во многих статьях о DevOps пишут красивые слова «collaboration», «trust», «safety», «paradigm shift», «breaking silos» и т.п. На мой взгляд, специально заниматься внедрением DevOps-культуры не нужно т.к. уровень коммуникации, доверия и ответственности будет расти естественным образом при изменении «физической среды». Процессы и инструменты должны «вынуждать» инженеров переходить на новый культурный уровень. Например:

• наличие автотестов, алертов, мониторингов и возможности быстро откатить кривой билд, позволит разработчикам быть более автономными и чувствовать безопасность;

• наличие APM-трейсов и дашборда позволит видеть как релизы влияют на состояние инфраструктуры, что в теории должно повысить ответственность инженеров.

• «Зелёный» дашборд должен стать источником общего удовлетворения, а «красный» — общего напряжения. 

• и т.п. 

Хороший DevOps-инженер

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

• Фичи нужны «вчера» — нет времени на внедрение новомодных концепций;

• интеграция старых систем с новыми инструментами может стоить очень дорого, либо вообще невозможна;

• есть огромные легаси-монолиты, которые не получается эффективно покрыть тестами;

• «забетонированная» структура и процессы, бюрократия, привычки;

• разные люди, иногда не супер-приятные;

• и т.п. 

Какими качествами должен обладать человек, чтобы успешно внедрить хороший DevOps в реальную компанию? 

Базовые характеристики

• Отлично ориентируется в DevOps-тулинге и может самостоятельно его настроить.

• Знает основы коммерческой разработки и ops-ов — может уверенно общаться с программистами и сис-админами, умеет корректно формулировать вопросы. 

• Мыслит стратегически, умеет структурировать и презентовать информацию — может выстроить и защитить DevOps-стратегию.

• Умеет планировать ресурсы и определять приоритеты. 

• Хорошо понимает как работает компания — структуру, основные бизнес-процессы и т.п. 

Расширенные характеристики

• Middle-программист в коммерческой разработке.

• Middle по ops-хардам — базы, сервера, сети, облака и т.п.

• Понимает основы System Design — монолиты, микросервисы, EDA и т.п.

• Строит масштабируемые решения — применяет стандарты, старается избегать vendor-локов.

• Разбирается в dev-стеке на котором работает продукт: языки, фреймворки и т.п.

• Знает основы кибер-безопасности.

Имбовые характеристики

• Хорошо пишет тексты, составляет краткие и понятные инструкции. 

• Знает основы UX — «компилирует» DevOps инструменты в ясные и бесшовные пайплайны.

• Обучает и менторит коллег. 

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

Заключение

Хороший DevOps минимально состоит из планирования, автотестов, CI/CD, «ровного» окружения и постоянной обратной связи. Эти компоненты позволяют настроить более-менее непрерывный поток доставки продуктовой ценности. 

Тем временем, хороший DevOps-инженер способен внедрить DevOps в реальных, сложных условиях — умеет красиво «поженить» dev-ов и ops-ов, используя правильные процессы и уместные инструменты. А далее следит за «красотой полёта» разработки и своевременно «смазывает» места, где возникают «трения». Это и есть его основная деятельность. Таков его замысел.

Спасибо, что дочитали!
Пока ;) 

Референсы

• https://resources.github.com/devops/fundamentals/ — основы DevOps.

• https://resources.github.com/devops/fundamentals/ci-cd/ —  разбираем CI/CD.

• https://github.blog/2021-08-11-githubs-engineering-team-moved--codespaces/ — про «выравнивание» окружения в команде GitHub.

• https://habr.com/ru/companies/yandex/articles/761946/ — интересная статья про то, почему бигтехи пишут свои DevOps-решения. 

• https://www.atlassian.com/devops/what-is-devops/devops-engineer — кто такой DevOps-инженер.

• https://www.atlassian.com/devops/what-is-devops/devops-culture — про DevOps-культуру. 

• https://habr.com/ru/articles/721646/ — DevOps-бойня в комментариях к статье :) 

• Поведение Два — телеграм-канал автора