Мифический человеко-DevOps

Привет! Меня зовут Эмин, я тех-лид платформенных команд в Профи. В этой статье поделюсь мнением о том, что такое хороший 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://habr.com/ru/articles/786854/

Статьи по теме

9 лучших бесплатных фотостоков

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

2025-12-02

10 причин высокого показателя отказов на сайте

Понятие «идеального» показателя отказов относительно --- то, что считается высоким в одной нише, может быть нормой в другой. Разбер...

2025-11-26

Зачем запускать MVP и как сделать это грамотно?

Создание проекта без минимально жизнеспособного продукта (MVP) аналогично строительству здания без проверки несущей способности фу...

2025-11-26

Перенос сайта с большим количеством ссылок

Сложности переноса крупных проектов Перенос корпоративных сайтов с большим количеством URL требует решения не только техниче...

2025-11-20

Онлайн-формы: универсальный инструмент для сбора обратной связи

В современном бизнесе систематическое получение обратной связи стало необходимостью для компаний любого масштаба. Особую значи�...

2025-11-14

Авторизация на сайте: как выбрать решение для удержания клиентов и сохранения продаж

Оглавление Кому нужна авторизация на сайте? Когда и как лучше вводить авторизацию? Виды авторизации: что выбрать для удерж�...

2025-11-14

Внедрение DMARC для защиты корпоративного домена от спуфинга

Привет, Хабр! В этом посте мы снова поговорим о проблеме подделки отправителя (или так называемом спуфинге)...

2025-10-28

Цифровой детокс: необходимость, тренд или искусственная потребность?

Если десять лет назад смартфоны символизировали технологический прогресс, то сегодня каждый третий пользователь (35%) открыто призн...

2025-10-24

No-code/low-code: как создавать цифровые продукты в 2025 без программистов

Представьте: у вас родилась блестящая идея. Не просто очередная догадка, а по-настоящему инновационное решение, которое может изм�...

2025-09-26

Yandex Data Lens: как визуализировать данные для маркетинга и аналитики

Yandex DataLens — это сервис от Яндекса, с помощью которого маркетологи визуализируют результаты рекламных кампаний. Он подключается к разным ...

2025-09-10

Владельцам сайтов: изменения в законе о персональных данных

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

2025-07-04

11 нейросетей для генерации изображений в 2025 году

Генерация картинок нейросетью упрощает работу маркетологам, дизайнерам, контент-мейкерам, а теперь — и владельцам бизнеса. Для всех �...

2025-06-10

Год назад то, что занимало у меня несколько дней работы, сейчас я делаю за 1-2 часа. Без преувеличений. И это только начало

За этот год я нашел 7 способов применения ИИ, с которыми моя эффективность и качество взлетели минимум в пять раз. Расскажу честно — без п...

2025-05-30

Нейросети для написания текста: 7 сервисов в помощь копирайтеру

Наверное, нет уже человека, который ничего не слышал о нейросетях и искусственном интеллекте. С одной стороны, подобные сервисы вызывают...

2025-05-25

Мы делали презентации 35 лет, а потом пришла нейросеть

*Отсчёт от создания PowerPoint в 1987 году Эту историю для блога рассказал Николай Букин, дизайнер и основатель брендингового ...

2025-05-05