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

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

Обеспечение безопасности ваших веб-приложений с помощью PHP OOP и PDO

Лучшие практики обеспечения безопасности PHP и PDO в современной веб-разработке Оглавление ...

2024-11-26

Перенос сайта на WordPress с одного домена на другой

Данная инструкция поможет вам, если вам нужно перенести сайт: с одного домена на другой; с поддомена на основной домен (наприме�...

2024-11-15

OSPanel 6: быстрый старт

Коротко объясняю как быстро начать работу с Open Server Panel v.6 Содержание: Вступление Концепция новой версии Первая уст...

2024-11-08

Как установить PhpMyAdmin в Open Server Panel

Как установить PhpMyAdmin в Open Server Panel В данной статье мы рассмотрим процесс установки и настройки PhpMyAdmin (PMA) на платформе Open Server...

2024-11-08

Как быстро запустить Laravel на Windows

Все привет, меня зовут Павел Жуковский и сегодня я расскажу о том как быстро развернуть Laravel на Windows. Как развернуть чере...

2024-09-30

Next.js

На мой взгляд, Next.js - это лучший на сегодняшний день инструмент для разработки веб-приложений. Обратите внимание: руководство актуально �...

2024-09-25

OpenAI рассказал, как запретить ChatGPT использовать содержимое сайта для обучения

OpenAI рассказал, как запретить ChatGPT использовать содержимое сайта для обучения Либо ограничить доступ. OpenAI рассказа...

2024-09-05

WebSocket

Протокол WebSocket («веб-сокет»), описанный в спецификации RFC 6455, обеспечивает возможность обмена данными между браузером и сервером че...

2024-08-01

Ошибка 404: что это такое и как ее использовать для бизнеса

Для SEO 404 Error — возможность сохранить клиента и позиции в выдаче. Как это сделать, в статье. Окно «404 Not Found» вид...

2024-07-17

PostgreSQL 16. Изоляция транзакций. Часть 2

Введение Данная статья является продолжением первой части: "PostgreSQL 16. Организация данных. Часть 1". Как и первая часть, эта является объед�...

2024-05-27

Комментирование кода и генерация документации в PHP

Зачем нужны комментарии к программному коду? В каком виде их писать? Где они нужны, а где нет? Как правильно комментировать код? Как прид�...

2024-04-22

Что такое CSS-модули и зачем они нам?

В последнее время меня интригуют CSS-модули. Если вы о них не слышали — эта статья для вас. Мы рассмотрим, что это за проект, какие задачи о�...

2024-04-22

23 сервиса для эффективного экспресс-аудита любого сайта

Аудит сайта – комплексный процесс, который позволяет оценить эффективность сайта и понять, на каком этапе теряются продажи, почему люди...

2024-04-17

Яндекс переходит на новую версию Wordstat

Часть старой функциональности уже недоступна. Обновленный Яндекс Вордстат полностью перейдет на основной домен wordstat.ru 20 марта. С...

2024-04-08

Яндекс интегрировал в свой облачный сервис эмпатичную нейросеть

Она умеет распознавать эмоции человека по голосу. Алгоритм-эмпат определяет характер речи пользователя: говорит он с явным негатив...

2024-04-08