Привет! Меня зовут Мария, я DevOps-инженер в компании Wrike. В этой статье расскажу о работе DevOps-инженеров с командами разработчиков: как выглядит процесс взаимодействия, из каких этапов состоит и как построить его с нуля. Статья будет полезна, если вы часто меняете проекты и каждый раз вам приходится заново создавать документацию и внедрять базовые процессы в работу команды.
За время моей профессиональной карьеры DevOps-инженера я поучаствовала в разных проектах: от создания небольшого веб-бота до комплексного решения для колл-центра. Каждый проект был по-своему уникален, и над ним работали самые разные люди.
В идеале, DevOps-инженер присоединяется к проекту в самом начале, чтобы взять процессы под контроль и наладить их, например, помочь с CI/CD пайплайнами. Но самый ценный опыт я получила, когда работала над проектами на заключительном этапе. Было довольно сложно, потому что все разработчики к тому моменту уже покинули проект, и мне приходилось переносить приложение на новую инфраструктуру без серьезных простоев.
В такой ситуации особенно важно знать, как построить взаимодействие, составить план действий и провести аудит проекта.
Как ставить достижимые цели
В большинстве случаев DevOps-инженер закреплен за проектом или конкретной командой разработки. Обычно это значит, что какие-то проблемы в этой команде уже возникли. Это может быть что угодно: начиная от большого количества роллбеков до полного отсутствия основных процессов разработки.
Перед тем как приступить к выполнению любой задачи, стоит подготовить план с высокоуровневыми целями. Эти цели должны отражать измеримое решение проблем.
Я предлагаю использовать для этого подход SMART.
Вот некоторые примеры распространенных ошибок, с которыми можно столкнуться при постановке целей:
Цель «Провести аудит проекта» — неизмеримая, потому что невозможно понять конечный результат. Лучше переформулировать ее во что-то более конкретное, например: решить пять самых критических проблем в инфраструктуре службы X. Это описание поможет менеджерам и коллегам по команде понять планы и ожидаемый результат.
Цель «Настроить деплой в новом регионе AWS» на первый взгляд кажется неплохой. Но если DevOps-инженер, который за нее отвечает, уйдет в отпуск или будет переназначен в другой проект, такое описание будет непонятно для других ребят из команды.
Последняя цель «Настроить мониторинг для службы X» тоже на первый взгляд кажется вполне удачной. Но не совсем понятен объем работы: можно развернуть весь стек Prometheus или же настроить параметры в конфигурации приложения.
Больше информации о подходе SMART в области разработки ищите в этой статье.
Как провести аудит приложения
Проверка всего сервиса или группы микросервисов может быть сложной задачей, поэтому важно понимать цель и определить текущее состояние различных составляющих приложения. Если нужно улучшить мониторинг и логирование, лучше сосредоточиться на этих двух задачах, а не пытаться делать все сразу.
Документация. Работа с документацией — важная часть процесса аудита. Я предлагаю сосредоточиться на главной задаче — иметь достаточно документации, чтобы при необходимости эффективно поддерживать или иметь возможность без проблем передать проект.
Что проверять:
Диаграмму архитектуры с основными компонентами и их взаимодействием. Эта диаграмма поможет собрать минимум необходимой информации для начала работы.
Список компонентов и их описание.
Список внешних зависимостей: облачные сервисы, внутренние ресурсы и т.д.
Управление конфигурацией.
Инструкции по локальной разработке.
Документацию OPS: мониторинг, логирование, дебаг, деплой.
Необязательно иметь все пункты сразу, но в некоторых случаях их наличие может оказаться очень полезным.
Если чего-то из списка не хватает, то нужно попробовать заполнить пробелы. Это можно сделать следующим образом:
Попросить разработчиков написать документацию и помочь команде с этим. Да, писать документацию скучно, но задача DevOps-инженера — начать работу, руководить процессом и объяснить, почему это важно.
Пишите документацию так, чтобы она была емкой и достаточно детальной. Ведь чаще всего ей будут пользоваться новые коллеги.
Объясните разработчикам, с чего можно начать. Лучше иметь шаблон или привести наглядный пример того, как документация выглядит в соседнем или похожем проекте.
DevOps-аудит. На этом этапе главная цель — определить текущие проблемные места (bottlenecks) в текущем процессе разработки.
Что проверять:
CI/CD пайплайны.
Релизные процессы.
Порядок деплоя.
Процедуру эскалации в случае возникновения проблем. Все участники должны четко понимать, как действовать в критических ситуациях, какой путь проходит алерт/тикет от момента появления до непосредственного решения и каков ожидаемый результат (поручена ли задача команде разработчиков, отдельной команде поддержки и т.д.).
Необязательно устранять все проблемы разом. Лучше попытаться понять, что на самом деле беспокоит разработчиков: например, есть проблемы со стабильностью CI/CD пайплайнов. Если есть время, то можно сразу взять конкретную задачу в работу или же пометить ее как технический долг.
Как проверить:
Обсудить с разработчиками их процесс разработки: как они справляются с техническим долгом, проводят код ревью и т.д.
Проверить все CI/CD пайплайны на наличие важных шагов и проверок, а также анти-паттернов. Вероятно, вы сможете внедрить лучшие практики для повышения стабильности и качества кода.
Проверить конфигурации сборки и деплоя. Например, отсутствие версионирования или использование тега latest для образов Docker.
Хорошей отправной точкой для передовых практик CI/CD и примером таких практик, связанных с конкретными технологиями, являются helm-чарты.
Аудит инфраструктуры. Этот этап сложен, потому что инфраструктура — обширная тема. Подходов много, и каждый различается в зависимости от конкретного случая. Я предлагаю сосредоточиться на проверке соответствия инфраструктуры требованиям: например, надежности, времени безотказной работы, высокой доступности, масштабируемости и т.д.
Что проверять:
Технологии и инструменты, которые используются для предоставления инфраструктуры.
Тип среды: облачная, собственные дата-центры или гибридная.
Конфигурация среды.
Как проверять:
Проверить среду на соответствие известным требованиям.
Проверить файлы, связанные с Ansible-, Terraform-, X-tool на наличие плохих и хороших практик, о которых вы знаете.
Проверить процесс управления конфигурацией для этих файлов. Проблемы могут появиться, если для них не производится code review или отсутствует версионирование.
Проверить версии инструментов: нужно ли их обновить для получения новых функций или повышения безопасности использования этих инструментов.
Подробнее об аудите инфраструктуры: лучшие практики Terraform и чеклист для проверки готовности приложения к production окружению.
Security-аудит. Мы работаем с пользователями, и наши пользователи хотят безопасно хранить свою электронную почту, пароли и другие личные данные. На этом этапе главная цель — минимизировать риски безопасности как для среды, так и для ее пользователей.
Что проверять:
Dockerfiles, манифесты Kubernetes, Helm-чарты.
Конфигурацию среды. Например, есть ли в проекте приватные Kubernetes-кластеры и правила фаервола.
Права и роли пользователей.
Секреты.
Как проводить аудит безопасности:
Ручные или автоматические проверки в репозиториях кода.
Если в компании есть отдельная команда безопасности, запросите аудит у них.
Понять, как секреты передаются в приложение и есть ли какие-то риски, связанные с этим процессом.
Аудит наблюдаемости. Цель этого шага — получить необходимые источники информации для дебага любой проблемы. Если приложение небольшое, то может быть достаточно только логов. Если в приложении используется микросервисная архитектура или высоконагруженная и распределенная система, лучше также использовать метрики и алерты.
Что проверять:
Логи.
Метрики и алерты для приложения.
Метрики и алерты для инфраструктуры, CI/CD пайплайнов, проблем безопасности.
Как провести аудит наблюдаемости:
Убедиться, что логи правильно отформатированы и настроены, попробовать запустить поиск в агрегаторе логов (например, Elasticsearch, Graylog).
Проверить дэшборды Grafana и метрики приложения и убедиться, что они содержат всю важную информацию.
Убедиться, что алерты являются индикатором каких-то проблем и отражают неработоспособность какой-то части приложения.
Если в приложении много микросервисов и сложных цепочек запросов, можно предложить внедрить tracing запросов.
Узнать подробнее об этом шаге вы можете в обзоре популярных стратегий мониторинга, а также посмотрев на пример семи показателей перформанса приложения.
Набор DevOps-инструментов: первая помощь
Существует множество инструментов, которые могут помочь автоматизировать все этапы аудита. Их можно запускать локально или интегрировать в CI, чтобы разработчики видели предупреждения, если собираются внести нежелательные изменения.
Документация:
Лучше иметь решение со встроенным версионированием: например, Markdown-/Github-/Gitlab-страницы или вики-страницы Confluence.
Notion. Инструмент с удобным интерфейсом. Будет полезен, если проект не очень большой.
Backstage от Spotify. Инструмент с приятным интерфейсом, большим количеством функций и плагинов.
Деплой в Kubernetes:
Helmfile — для декларативного развертывания (особенно для приложений, связанных с инфраструктурой).
Helm-docs — автоматически генерируемый README для helm-чартов.
Helm-diff — плагин helm для отображения различий перед деплоем чарта.
Chart-testing — линтер для helm-чартов по заданным правилам.
Kubeval — проверяет манифесты на соответствие различным версиям Kubernetes.
Pluto — обнаруживает устаревший API в кластере Kubernetes.
Еще несколько интересных инструментов можно найти в списке awesome-helm.
Инфраструктура:
Molecule — фреймворк для тестирования ролей Ansible. Если инфраструктура построена с использованием Ansible, это решение идеально подходит для проверки ролей перед их применением.
Terraform pre-commit hook — поддерживает инструменты Terraform (например, tflint, tfsec), интегрируется локально или в CI. Поможет сохранить единообразие файлов Terraform в нескольких репозиториях и ускорить процесс проверки кода.
TFSwitch — удобный инструмент управления версиями Terraform.
Демо-сценарий с Molecule и Github Action.
Контейнеры:
Hadolint — тестирование Dockerfiles на соответствие лучшим практикам.
Dive — просмотр содержимого образов Docker.
Kaniko — создание образов Docker без Docker.
Безопасность:
Trivy — сканер образов Docker, репозиториев Git и файловых систем.
Polaris — анализ рабочей нагрузки с использованием best-practices в Kubernetes.
Kube-bench — инструмент CLI с теми же функциями, что и Polaris, но немного другими проверками.
Локальная разработка:
Minikube — прост в использовании, имеет кучу полезных плагинов.
Kind — Kubernetes в Docker, поддерживает работу с несколькими нодами.
Skaffold — проект, который позволяет разработчикам легко создавать и развертывать свои приложения в Kubernetes.
Telepresence — позволяет разработчикам перенаправлять трафик из кластера на локальный компьютер и многое другое.
Вместо заключения
Теперь у вас есть все необходимое, чтобы погрузиться в проект любой сложности, провести аудит и подготовить план необходимых изменений. Я постаралась привести список источников и инструментов, которые сделают этот путь немного короче и легче. Буду рада ответить на вопросы!
