Мифический человеко-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/

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

Идентификация доменов через Госуслуги с 1 сентября 2026 года: что изменилось для вашего бизнеса и как не потерять сайт

С 1 сентября 2026 года в России вступил в силу Федеральный закон № 569-ФЗ, который вводит обязательную идентификацию администраторов �...

2026-09-02

Яндекс Вебмастер ускорил обновление данных в Мониторинге запросов: что это значит для вашего бизнеса

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

2026-08-03

Overlay в РСЯ: новый формат мобильной рекламы, который не раздражает пользователей

23 июля 2026 года Рекламная сеть Яндекса представила новый формат рекламных блоков для мобильных версий сайтов — Overlay. Это событие...

2026-07-29

Нейросети в дизайне сайтов и графике: революция, эволюция или угроза?

«Мне нужен единорог в стиле пиксель-арт за пять секунд» — еще пару лет назад такое техническое задание звучало как анекдот. Сегодня...

2026-07-23

Аналитика нового поколения: как Яндекс Метрика превращает данные в управляемые конверсии

В мире веб-аналитики произошло важное обновление. Компания Яндекс анонсировала масштабное обновление своей системы веб-аналитики �...

2026-07-03

Искусство диалога с ИИ: как составить промпт, чтобы нейросеть поняла вас с полуслова

Вы когда-нибудь просили ChatGPT написать пост для соцсетей или Midjourney нарисовать картинку, а в ответ получали нечто, что «мягко говоря, не...

2026-07-01

Как оставить отзыв на Яндекс Картах, чтобы модерация его точно пропустила

Как оставить отзыв на Яндекс Картах Чтобы написать отзыв, вам понадобится учетная запись в Яндексе. Сделать это можно одним из трех �...

2026-05-28

Будущее без cookies: альтернативные решения для идентификации пользователей

С 2016 года вводятся ограничения для сторонних (third-party) cookies, и с каждым годом их становится все больше. Как меняется работа с данными и...

2026-05-07

Чем грозят дублированный контент и пустые страницы: ошибки, которые убивают ваш трафик

Дублированный контент — одна из самых распространенных проблем в вебе. Чаще всего он встречается в описаниях товаров и услуг: в высо...

2026-05-07

Формы сбора согласий на сайте

Сайты делают формы регистрации — без этого никуда. Возьмите любой ресурс: от частной фотостудии до городской стоматологии — в 90% с...

2026-04-17

Микрофронтенды — максимально простое объяснение

Что такое микрофронтенды простыми словами? Объясняем на примерах, как это работает и где применяется. Микрофронтенды — эт...

2026-04-08

Почему скорость загрузки сайта — это вопрос выживания в 2026 году

Скорость, с которой открывается ваш сайт, — это не просто техническая характеристика. Это главный фактор, который либо приводит �...

2026-03-13

12 признаков, что ваш сайт безнадежно устарел (и как это проверить)

Раньше посетитель уходил только с совсем «мертвого» сайта — если тот не грузился или выдавал ошибку. Сегодня конкуренция за вним...

2026-03-13

Главные тренды веб-дизайна 2026 года: от гиперминимализма до кибербрутализма

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

2026-03-03

No-code vs Профессиональная разработка: выстрелит ли Tilda в 2026 году?

Искусственный интеллект и платформы без кода обещают, что теперь любой желающий сможет собрать сервис уровня Netflix. Но так ли это �...

2026-02-22