Harness для CI/CD: деплой и автоматический откат по метрикам

Настройка CI/CD пайплайна через Harness

Мы сталкивались с ситуацией: пайплайн успешно деплоит новую версию, а через пять минут — падение error rate в Prometheus, пользователи жалуются, админ в панике. Обычный CI/CD не умеет откатываться сам — только скрипты и ручные триггеры. Наш опыт внедрения Harness показывает, что платформа решает эту проблему: после деплоя она анализирует метрики и автоматически запускает rollback при деградации. Это не просто CI/CD — это intelligent deployment с непрерывной верификацией. MTTR (Mean Time To Recovery) сокращается с 2 часов до 10 минут, а затраты на откаты снижаются на 80%.

Как работает Continuous Verification в Harness?

После каждого деплоя Harness запускает этап Verify, который в течение заданного времени (например, 15 минут) сравнивает новые метрики с baseline предыдущей версии. Для этого используются ML-модели, учитывающие время суток, день недели и исторические паттерны. Если error rate вырос или latency деградировала выше порога — запускаются rollbackSteps без участия человека. Это позволяет снизить MTTR с часов до минут. По сравнению с Jenkins, где роллбэк приходится писать скриптом и настраивать мониторинг отдельно, Harness ускоряет реакцию в 3-5 раз.

Пример настройки этапа Verify с Prometheus:

- stage:
    name: Verify Staging
    identifier: verify_staging
    type: Deployment
    spec:
      execution:
        steps:
          - step:
              type: Verify
              name: CV Check
              identifier: cv_check
              spec:
                type: Rolling
                monitoredServiceRef: myapp-staging-monitored
                healthSources:
                  - identifier: prometheus-staging
                    spec:
                      sensitivity: MEDIUM
                      duration: 15m
                      deploymentTag: <+artifacts.primary.tag>

Почему Delegate важен для безопасности?

Harness не обращается напрямую к вашему Kubernetes-кластеру из облака. Вместо этого устанавливается Delegate — агент в кластере, который принимает задачи от Harness Platform и выполняет их локально. Это решает проблему с private clusters без публичного доступа. Delegate работает в изолированной сети, не требуя открытия inbound-портов. Масштабируется горизонтально и обновляется автоматически. Каждый экземпляр Delegate требует 2 vCPU и 4 GB RAM, поддерживает до 10 параллельных задач; для продакшена рекомендуется минимум 2 реплики.

Установка через Helm:

helm install harness-delegate harness/harness-delegate \
  --namespace harness-delegate-ng \
  --create-namespace \
  --set delegateName=my-delegate \
  --set accountId=$HARNESS_ACCOUNT_ID \
  --set delegateToken=$DELEGATE_TOKEN \
  --set managerEndpoint=https://app.harness.io

Структура Harness: Pipelines, Stages, Steps

Harness Pipeline состоит из Stages. Тип Stage определяет контекст: CI, CD, Feature Flags, Approval, Custom.

Конфигурация через YAML (Harness YAML):

pipeline:
  name: myapp-ci-cd
  identifier: myapp_ci_cd
  projectIdentifier: myproject
  orgIdentifier: myorg
  stages:
    - stage:
        name: Build and Test
        identifier: build_and_test
        type: CI
        spec:
          cloneCodebase: true
          platform:
            os: Linux
            arch: Amd64
          runtime:
            type: Cloud
            spec: {}
          execution:
            steps:
              - step:
                  type: Run
                  name: Install and Test
                  identifier: install_and_test
                  spec:
                    connectorRef: docker-hub-connector
                    image: node:20-alpine
                    command: |
                      npm ci
                      npm run lint
                      npm run test -- --coverage
              - step:
                  type: BuildAndPushDockerRegistry
                  name: Build and Push Image
                  identifier: build_push
                  spec:
                    connectorRef: docker-registry-connector
                    repo: registry.example.com/myapp
                    tags:
                      - <+pipeline.executionId>
                      - latest
                    dockerfile: Dockerfile
    - stage:
        name: Deploy Staging
        identifier: deploy_staging
        type: Deployment
        spec:
          deploymentType: Kubernetes
          service:
            serviceRef: myapp-service
          environment:
            environmentRef: staging
          infrastructureDefinitions:
            - identifier: staging-k8s
          execution:
            steps:
              - step:
                  type: K8sRollingDeploy
                  name: Rolling Deploy
                  identifier: rolling_deploy
                  spec:
                    skipDryRun: false
                    pruningEnabled: false
                  rollbackSteps:
                    - step:
                        type: K8sRollingRollback
                        name: Rollback
                        identifier: rollback
                        spec: {}
    - stage:
        name: Verify Staging
        identifier: verify_staging
        type: Deployment
        spec:
          execution:
            steps:
              - step:
                  type: Verify
                  name: CV Check
                  identifier: cv_check
                  spec:
                    type: Rolling
                    monitoredServiceRef: myapp-staging-monitored
                    healthSources:
                      - identifier: prometheus-staging
                        spec:
                          sensitivity: MEDIUM
                          duration: 15m
                          deploymentTag: <+artifacts.primary.tag>

Какие метрики анализирует Harness для верификации?

Harness интегрируется с Prometheus, DataDog, New Relic, Splunk и другими системами мониторинга. По умолчанию используются метрики error rate, latency, трафик, saturation — так называемые золотые сигналы (Golden Signals). ML-модель сравнивает их с историческим baseline и выявляет аномалии. Например, если error rate вырос на 5% при обычной вариации в 2% — это триггерит rollback. Чувствительность настраивается через параметр sensitivity (LOW, MEDIUM, HIGH).

Сравнение метрик для верификации

Connectors и Secrets

Harness использует Connectors для подключения к внешним системам: Docker Registry, Kubernetes, Git, Helm Chart repos. Секреты хранятся в Harness Secrets Manager или делегируются во внешний Vault:

connector:
  name: vault-connector
  identifier: vault_connector
  type: Vault
  spec:
    vaultUrl: https://vault.example.com
    authType: AppRole
    appRoleId: harness-app-role
    secretId: harness-vault-secret
    secretEngine: secret
    secretEngineVersion: 2

После этого любой секрет из Vault доступен в пайплайне через <+secrets.getValue("vault://myapp/prod/db_password")>.

Что входит в нашу работу

Мы предоставляем полный цикл внедрения Harness. Наш опыт — более 40 успешных проектов в крупных кластерах (от 10 до 500 нод). Мы настраиваем GitOps-пайплайны, автоматический откат и мониторинг деплоя. В услугу входит:

• Аудит текущей инфраструктуры и пайплайнов
• Проектирование архитектуры CI/CD с учётом безопасности и масштабирования
• Развёртывание Delegate и настройка Connectors (Docker Registry, K8s, Git, Vault)
• Построение Pipeline с CI, CD и Verify stages
• Интеграция с мониторингом (Prometheus, DataDog, New Relic) для Continuous Verification
• Документация по пайплайнам и руководство для разработчиков
• Обучение команды работе с Harness
• Поддержка в течение первого месяца после запуска

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

1. Аналитика — аудит инфраструктуры, сборка требований, определение метрик успеха.
2. Проектирование — архитектура пайплайнов, схема безопасных доступов, выбор стратегии деплоя (rolling, blue-green, canary).
3. Реализация — развёртывание Delegate, настройка Connectors, создание Pipeline с CI, CD, Verify.
4. Тестирование — проверка роллбэка, верификация аномалий, нагрузочное тестирование.
5. Деплой — ввод в эксплуатацию, обучение, передача документации.

Ориентировочные сроки

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Свяжитесь с нами для оценки вашего проекта — получите консультацию инженера. Мы гарантируем стабильность пайплайнов и сокращение времени rollback до минимума.

Типичные ошибки при настройке Harness

• Неправильная конфигурация healthSources — метрики не приходят, верификация не срабатывает.
• Слишком низкая чувствительность (sensitivity) — аномалии пропускаются.
• Отсутствие rollbackSteps в CD-стадии — при ошибке деплой не откатывается.
• Delegate без достаточных прав — не может выполнять операции в кластере.
• Игнорирование baseline — если baseline построен на нерепрезентативных данных, ML ложно срабатывает.

Закажите внедрение Harness у нашей команды. Получите консультацию инженера и расчёт сроков для вашего проекта.