Полный каталог DevOps: CI/CD, Kubernetes, автоматизация — TRUETECH

DevOps-услуги: CI/CD, Kubernetes, IaC, мониторинг и GitOps

Типичная картина на входящем аудите: монолит деплоится вручную через rsync и SSH-ключ разработчика, Terraform-стейт лежит локально в папке с проектом, а алерты в Grafana настроены два года назад и с тех пор только мешают — дежурный давно их заглушил. Не потому что команда плохая. Просто инфраструктура росла быстрее, чем успевали строить процессы.

Мы занимаемся devops-услугами больше 10 лет. Ниже — честное описание того, что и как делаем, с какими проблемами сталкиваемся и почему одно и то же решение в двух проектах выглядит по-разному.

Что входит в каталог devops-услуг

Весь каталог услуг делится на несколько направлений. Каждое можно взять отдельно — но чаще они пересекаются, потому что внедрить GitOps без нормально работающего CI/CD не получится, а Kubernetes без мониторинга — это просто дорогой способ ронять сервисы молча.

CI/CD пайплайны — GitHub Actions, GitLab CI, Jenkins. Сборка, тестирование, деплой. Кэширование слоёв, матричные джобы, секреты через Vault или встроенные механизмы.

• Контейнеризация — Docker, multi-stage builds, оптимизация образов, сканирование уязвимостей через Trivy, приватные реестры.
• Kubernetes — настройка кластеров, Helm-чарты, Ingress, network policies, RBAC, HPA/VPA, Karpenter.
• Infrastructure as Code — Terraform, Ansible. State в S3 с DynamoDB-локом, разбивка на модули, drift detection.
• GitOps — ArgoCD, Flux. External Secrets Operator.
• Мониторинг и наблюдаемость — Prometheus, Grafana, Loki, Tempo, OpenTelemetry.
• Безопасность — Vault, Falco, OPA/Gatekeeper, сканирование в пайплайне.
• Стратегии деплоя — Blue-Green, Canary, Rolling Update, Argo Rollouts.
• DevOps-консалтинг — аудит, DORA-метрики, матрица зрелости, дорожная карта.

Почему Terraform State — самая частая точка отказа

Начнём с IaC, потому что здесь грабли наступаются чаще всего и тихо.

Команда начинает с локального стейта — это нормально для пет-проекта. Потом проект растёт, в инфраструктуру начинают вносить изменения два-три человека. В какой-то момент два инженера запускают terraform apply параллельно. Первый применяет изменения. Второй применяет поверх — и частично откатывает то, что сделал первый, потому что его локальный .tfstate не знал о свежих изменениях. Хорошо если это просто security group, плохо если это subnet или IAM-политика.

Правильное решение — remote state с блокировкой. Для AWS это S3-бакет + DynamoDB-таблица с атрибутом LockID. Terraform при запуске пишет lock, при завершении — удаляет. Параллельный apply падает с ошибкой Error acquiring the state lock.

terraform {
  backend "s3" {
    bucket         = "company-tf-state"
    key            = "prod/eks/terraform.tfstate"
    region         = "eu-central-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

Следующая проблема — монолитный стейт. Один .tfstate на всю инфраструктуру означает, что любое изменение блокирует всех. Разбивка на стеки по доменам (networking, eks, apps, monitoring) с terraform_remote_state или Terragrunt — стандартная практика для среднего масштаба.

Drift detection — отдельная история. Инфраструктура расходится с кодом не только из-за ручных изменений. Иногда облачный провайдер меняет дефолтное значение атрибута. Чтобы держать стейт под контролем, ставим terraform plan в CI по расписанию раз в сутки с отправкой diff в Slack. Простой способ без внедрения тяжёлых инструментов вроде Spacelift или Atlantis.

Как ускорить CI/CD пайплайн

Медленный пайплайн — это не просто неудобство. Разработчик, который ждёт 40 минут до деплоя в staging, начинает делать большие редкие коммиты. Большие редкие коммиты — это большие сложные merge request'ы. Сложные MR — долгое ревью, больше конфликтов, выше вероятность регрессии.

Три самых частых источника медленных пайплайнов:

• Нет кэша Docker-слоёв. Каждый запуск собирает образ с нуля, переустанавливает зависимости. В GitHub Actions это лечится actions/cache с ключом от хэша package-lock.json. В GitLab CI — cache: с key: ${CI_COMMIT_REF_SLUG}. Для Docker — --cache-from с образом из реестра или BuildKit с inline-кэшем.
• Тесты не параллелизированы. Матричная стратегия в GitHub Actions или parallel: в GitLab CI разбивает тест-сьют на N частей. Для pytest — pytest-split с --splits N, для Go — -parallel.
• Нет разбивки на стейджи. Монолитный пайплайн: lint → build → test → deploy в одной джобе. Правильная структура: параллельные lint и security-scan на первом стейдже, build на втором (только если первый прошёл), deploy на третьем.

Реальный кейс: пайплайн Node.js-сервиса занимал 28 минут. После включения кэша node_modules по хэшу package-lock.json, параллельного запуска unit/integration тестов и сборки Docker-образа через BuildKit с кэшем из ECR — 7 минут. Код пайплайна не стал сложнее, изменился только порядок джоб и добавилось три строки кэш-конфига. Сокращение времени сборки — 80%. Такая экономия напрямую увеличивает deployment frequency и снижает lead time.

Как настроить мониторинг, который реально работает

Стек Prometheus + Grafana + Alertmanager встречается почти везде. Но между «поднятым Prometheus» и «работающим мониторингом» — пропасть.

Типичная проблема — алерты на симптомы, а не на следствия. Алерт на cpu_usage > 80% срабатывает ночью, будит дежурного — а это batch-джоба по расписанию. Через неделю такой алерт молча заглушен.

Правильный подход — алерты на RED-метрики (Rate, Errors, Duration) на уровне сервиса. CPU-алерт имеет смысл только если коррелирует с деградацией ответов. Нужен recording rule, который считает p99 latency по histogram_quantile.

groups:
  - name: api.rules
    rules:
      - alert: APIHighLatency
        expr: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket{job="api"}[5m])) by (le, route)
          ) > 1.0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "p99 latency {{ $value }}s on {{ $labels.route }}"

Для Kubernetes kube-state-metrics и node_exporter дают метрики уровня подов и нод. Но самое ценное — custom-метрики приложения через client-библиотеки Prometheus. Go-сервис, который экспортирует jobs_processed_total, jobs_failed_total и queue_depth_gauge, говорит о своём состоянии намного больше, чем любой системный метрик.

Loki для логов работает хорошо в связке с promtail-агентом в виде DaemonSet. Важно: LogQL-запросы дорогие, если нет правильных лейблов низкой кардинальности (namespace, app, pod), а не trace_id или user_id. Иначе индекс раздувается.

Внедрение такого мониторинга снижает среднее время обнаружения инцидента с 30 минут до 5 минут, а MTTR — до 15 минут при наличии runbook. Свяжитесь с нами — мы настроим observability-стек под ваши сервисы.

Что обычно пропускают при настройке Kubernetes

Ноды подняты, поды запускаются — кажется, что готово. Но несколько вещей почти всегда отсутствуют на «только что настроенном» кластере:

1. Resource requests и limits — без них Kubernetes не может правильно размещать поды. requests — для scheduling, limits — для cgroups. Под без requests.memory может получить OOMKill. Рекомендация: выставить requests по P90 потребления из метрик, limits — на 150-200% от requests для burst.
2. PodDisruptionBudget — без PDB команда kubectl drain node убивает все реплики сразу. PDB с minAvailable: 1 гарантирует хотя бы одну реплику.
3. Network Policies — по умолчанию все поды общаются со всеми. Нарушает least privilege. Базовая политика — запретить весь трафик и разрешить нужные пути.
4. RBAC с минимальными правами — ServiceAccount с cluster-admin в CI — распространённая ошибка. Если пайплайн скомпрометирован, доступ к кластеру полный.
5. Отсутствие PodSecurityStandards — старые PodSecurityPolicies (deprecated с K8s 1.25) нужно заменить на встроенные PSA или OPA/Gatekeeper.

Закажите аудит вашего кластера — получите отчёт с критическими замечаниями и приоритетом исправлений.

Стратегии деплоя: когда что применять

Canary через Argo Rollouts позволяет автоматически откатиться, если error_rate или latency_p99 превысили порог — без ручного вмешательства. Это особенно ценно для сервисов с высокой нагрузкой, где manual rollback занимает минуты, а критичен каждый секундный сбой.

Безопасность в пайплайне: не отдельный этап, а встроенный слой

Сканирование Docker-образов через Trivy в CI — минимальный порог. Добавляется одной джобой:

trivy-scan:
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $IMAGE_NAME

--exit-code 1 фейлит джобу при находке HIGH/CRITICAL уязвимостей. На практике часто приходится использовать --ignore-unfixed — иначе пайплайн падает из-за уязвимостей в базовом образе, для которых апстрим ещё не выпустил патч.

Vault для управления секретами — отдельная тема. Паттерн: приложение получает short-lived токены через Vault Agent Injector (sidecar) или через Vault Secrets Operator. Ни статических секретов в переменных окружения, ни kubectl create secret вручную. Типичная экономия на облачных инстансах после внедрения гранулированного доступа — до $1000 в месяц за счёт отсутствия лишних ресурсов.

Процесс работы

Любой проект начинается с аудита. Смотрим текущий стек, измеряем DORA-метрики там, где это возможно: Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR. Это даёт объективную точку отсчёта — не «у вас всё плохо», а «вот конкретные числа и вот на что они влияют».

После аудита — дорожная карта с приоритизацией по соотношению effort/impact. Часто перенос стейта в remote backend занимает полдня и сразу убирает класс рисков, а красивая GitOps-архитектура на ArgoCD — три недели.

Реализация — итеративная. Каждый шаг должен быть обратимым и проверяемым.

Чтобы заказать услугу, достаточно выполнить три шага:

1. Свяжитесь с нами — напишите в Telegram или на почту, приложите краткое описание текущей инфраструктуры.
2. Аудит — мы за 3-5 дней проведём аудит и вернём отчёт с цифрами и приоритетами.
3. Коммерческое предложение — после утверждения дорожной карты мы сформируем фиксированную стоимость или почасовую ставку.

Свяжитесь, чтобы записаться на аудит — просто напишите, и мы оценим ваш проект за 1 день.

Ориентиры по срокам

Стоимость рассчитывается индивидуально после аудита инфраструктуры и понимания объёма задач. Закажите аудит — получите прозрачное коммерческое предложение.

Полезные материалы: Terraform — Wikipedia, Prometheus — Wikipedia.