Мифический человеко-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/
Дайджест новых статей по интернет-маркетингу на ваш email
Новые статьи и публикации
- 2024-04-22 » Комментирование кода и генерация документации в PHP
- 2024-04-22 » SEO в России и на Западе: в чем основные отличия
- 2024-04-22 » SEO для международного масштабирования
- 2024-04-22 » Как использовать XML-карты для продвижения сайта
- 2024-04-22 » Цифровой маркетинг: инструменты для продвижения и рекламы в 2024 году
- 2024-04-22 » Что такое CSS-модули и зачем они нам?
- 2024-04-17 » 23 сервиса для эффективного экспресс-аудита любого сайта
- 2024-04-08 » Яндекс переходит на новую версию Wordstat
- 2024-04-08 » Яндекс интегрировал в свой облачный сервис эмпатичную нейросеть
- 2024-04-08 » Новая версия нейросети Claude превзошла по мощности аналоги Google и OpenAI
- 2024-04-08 » Как пользоваться GPT 4 и Claude бесплатно и без VPN
- 2024-03-13 » Стратегии SEO на 2024 год
- 2024-03-13 » Как использовать анимацию с помощью JavaScript-библиотеки GSAP
- 2024-03-13 » Использование GSAP 3 для веб-анимации
- 2024-03-13 » Cогласование топографической съёмки с эксплуатирующими организациями
- 2024-02-19 » Теряются лиды? Как настроить сквозную аналитику
- 2024-02-17 » Мерч и IT: на что обратить внимание в 2024 году
- 2024-02-16 » Копируем с RSync: основные примеры синхронизации файлов
- 2024-02-15 » Лучшие noCode AI платформы для создания диалоговых ботов
- 2024-02-14 » Факторы ранжирования Google 2024 — исследование Semrush
- 2024-02-12 » Перенос сайта на другой хостинг
- 2024-02-05 » В России сформирован реестр хостинг-провайдеров
- 2024-02-04 » Использование SSH для подключения к удаленному серверу Ubuntu
- 2024-02-03 » Подключаемся к серверу за NAT при помощи туннеля SSH. Простая и понятная инструкция
- 2024-02-02 » Настройка CI/CD для Gitlab-репозитория: схемы и гайд по шагам
- 2024-02-01 » GitLab CI Pipeline. Запуск сценария через SSH на удаленном сервере
- 2024-01-29 » Introduction to GitLab’s CI/CD for Continuous Deployments
- 2024-01-26 » Настройка GitLab CI/CD
- 2024-01-25 » Установка shell gitlab runner
- 2024-01-25 » Установка и регистрация gitlab-runner в docker контейнере
"Не пытайтесь перехитрить поисковые машины - надежность и доверие ценятся в сфере поискового маркетинга куда больше." |
Мы создаем сайты, которые работают! Профессионально обслуживаем и продвигаем их , а также по всей России и ближнему зарубежью с 2006 года!
Как мы работаем
Заявка
Позвоните или оставьте заявку на сайте.
Консультация
Обсуждаем что именно Вам нужно и помогаем определить как это лучше сделать!
Договор
Заключаем договор на оказание услуг, в котором прописаны условия и обязанности обеих сторон.
Выполнение работ
Непосредственно оказание требующихся услуг и работ по вашему заданию.
Поддержка
Сдача выполненых работ, последующие корректировки и поддержка при необходимости.