Кто занимается обслуживанием и настройкой инструментов в DevOps-практике?

В современной DevOps-культуре ответственность за инструменты разделена. Чаще всего этим занимается команда Platform Engineering или DevOps-инженеры, которые предоставляют внутренние сервисы (Internal Developer Platform) для остальных разработчиков.

Конкретные обязанности и примеры:

1. Создание и поддержка CI/CD-платформы:

   • Мы настраивали и поддерживали самообслуживаемые шаблоны пайплайнов в GitLab CI. Разработчики просто подключались к ним, указывая образ для сборки.

     # .gitlab-ci.yml (шаблон от Platform-команды)
     .base-docker-build:
     image: docker:latest
     services:
     - docker:dind
     script:
     - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
     - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

2. Управление инфраструктурой как код (IaC):

   • Наша команда поддерживала модули Terraform для развертывания стандартных сервисов в AWS (например, модуль для EKS-кластера с предустановленным мониторингом). Команды разработки использовали эти модули, не вникая в детали настройки CloudWatch или IAM.

3. Мониторинг и логирование:

   • Мы разворачивали и настраивали стэк Prometheus/Grafana/Loki, а также писали стандартные дашборды и алерты для распространенных сервисов (базы данных, очереди сообщений). Разработчики добавляли свои кастомные метрики через готовые библиотеки.

Важный нюанс: В идеале разработчики самостоятельно настраивают конфигурацию внутри предоставленных инструментов (например, описывают свои шаги в пайплайне или пишут манифесты для своего сервиса в Kubernetes), в то время как Platform-команда обеспечивает стабильность, безопасность и масштабируемость самой платформы.