Повний каталог 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.
• Моніторинг та observability – 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 – довге рев'ю, більше конфліктів, вища ймовірність регресії. Пайплайн з кешем працює в 4 рази швидше, ніж без нього.

Три найчастіших джерела повільних пайплайнів:

• Немає кешу 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, паралельного запуску тестів та збірки через BuildKit з кешем з ECR – 7 хвилин. Код пайплайну не став складнішим, змінився тільки порядок джоб і додалося три рядки кеш-конфігу. Скорочення часу збірки – 80%. Така економія прямо збільшує deployment frequency і знижує lead time.

Як налаштувати моніторинг, який реально працює

Стек Prometheus + Grafana + Alertmanager зустрічається майже скрізь. Але між «піднятим Prometheus» і «працюючим моніторингом» – прірва.

Типова проблема – алерти на симптоми, а не на наслідки. Алерт на cpu_usage > 80% спрацьовує вночі, будить чергового – а це batch-джоба за розкладом. Через тиждень такий алерт мовчки заглушений. SLO-based alerting знижує кількість фальшивих тривог у 3 рази порівняно з threshold-based.

Правильний підхід – алерти на 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

Ноди підняті, поди запускаються – здається, що готово. Але кілька речей майже завжди відсутні на «щойно налаштованому» кластері. 90% кластерів на вході не мають Network Policies.

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 на місяць за рахунок відсутності зайвих ресурсів. А використання spot instances дозволяє знизити витрати на обчислення ще на 60%.

Процес роботи

Будь-який проєкт починається з аудиту. Дивимося поточний стек, вимірюємо DORA-метрики там, де це можливо: Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR. Це дає об'єктивну точку відліку – не «у вас все погано», а «ось конкретні числа і ось на що вони впливають».

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

Реалізація ітеративна. Кожен крок має бути оборотним і перевірюваним.

Щоб замовити послугу, достатньо виконати три кроки:

1. Зв'яжіться з нами – напишіть у Telegram або на пошту, додайте короткий опис поточної інфраструктури.
2. Аудит – ми за 3-5 днів проведемо аудит і повернемо звіт з цифрами та пріоритетами.
3. Комерційна пропозиція – після затвердження дорожньої карти сформуємо фіксовану вартість або погодинну ставку.

Замовте аудит – отримайте прозору комерційну пропозицію. Зв'яжіться, щоб оцінити ваш проєкт за 1 день.

Орієнтири за термінами

Вартість розраховується індивідуально після аудиту інфраструктури та розуміння обсягу завдань. Prometheus та Terraform – загальновизнані інструменти з відкритим кодом. Наша команда має 10+ років досвіду і 80+ впроваджених проєктів – звертайтеся за консультацією.