DevOps-консалтинг и платформенная инженерия
DevOps — подход, при котором разработка, тестирование и вывод ПО в эксплуатацию строятся на автоматизации и общей ответственности. Объём работ мы определяем под ваши задачи: иногда это конвейер поставки CI/CD (непрерывная интеграция и поставка) для одного приложения, иногда Kubernetes-платформа, общая для нескольких команд, а также автоматизация инфраструктуры и мониторинг. Работаем в облаке, в вашем собственном ЦОД и в гибридных средах.
- Среды
- AWS, Azure, Google Cloud, локальные облачные провайдеры, ЦОД, гибридные среды
- Платформы
- Kubernetes (EKS, AKS, GKE), OpenShift, Rancher
- Формат работы
- Проект · постоянный консалтинг · управляемые услуги
- Первый шаг
- Бесплатная первичная консультация или бесплатная оценка
Когда нужна поддержка DevOps?
По мере роста команды разработки и числа систем процесс поставки тоже должен становиться зрелее. С чего начать, мы определяем вместе, исходя из вашей текущей ситуации.
- Релизы зависят от ручных шагов. Чтобы выпускать релизы чаще, а откат сделать предсказуемым, эти шаги нужно автоматизировать.
- Среды отличаются друг от друга. Если тестовая и продуктивная среды создаются из одних и тех же описаний, неожиданных расхождений становится меньше.
- Вы используете Kubernetes, и нагрузка на эксплуатацию растёт. Нужны регулярные обновления версий, планирование мощностей и единый порядок эксплуатации.
- Изменения инфраструктуры нужно фиксировать. Возможность отследить, кто, что и когда изменил, важна и для эксплуатации, и для аудита.
- Мониторинг и оповещения требуют пересмотра. Метрики, логи и оповещения сводятся в единую систему, чтобы проблемы были видны раньше, чем их заметят пользователи.
- Команды по отдельности решают похожие инфраструктурные задачи. Общие шаблоны и среды самообслуживания сокращают повторяющуюся работу и время ожидания.
Что меняется в результате работы?
Цель не в том, чтобы установить инструменты, а в том, чтобы улучшить повседневную работу вашей команды. В таблице собраны типичные исходные ситуации и целевое состояние.
Наши принципы работы
- Инфраструктура, конвейеры поставки (CI/CD-пайплайны) и политики описываются как код.
- Изменения проходят ревью и фиксируются.
- Сама платформа тоже тестируется и версионируется.
- Успех измеряется показателями поставки, а не числом установленных инструментов.
- Где возможно, предпочтение отдаётся переносимым и открытым инструментам.
| Исходная ситуация | Целевое состояние |
|---|---|
| Ручные шаги релиза | Повторяемый автоматический пайплайн, который запускается при каждом изменении |
| Изменения инфраструктуры через консоль | Код инфраструктуры с версиями и ревью |
| Разные пайплайны в каждой команде | Общие шаблоны и рекомендуемый путь |
| Среды, создаваемые по заявке | Среды, которые команды создают сами по заданным правилам |
| Разрозненные логи и оповещения | Мониторинг в одном месте и содержательные оповещения |
| Знания об эксплуатации у отдельных сотрудников | Регламенты эксплуатации (runbook) и описанные процедуры |
Что мы делаем в DevOps и платформенной инженерии?
Одно направление или весь цикл целиком, в зависимости от ваших задач.
Kubernetes-платформа
Установка, обновление версий, управление несколькими кластерами и планирование мощностей: EKS, AKS, GKE, OpenShift, Rancher или ваш собственный ЦОД.
CI/CD-пайплайны
Пайплайны, автоматизирующие сборку, тестирование, сканирование безопасности и деплой, на основе общих шаблонов и воспроизводимые во всех командах.
Инфраструктура как код (IaC) и GitOps
Terraform/OpenTofu для инфраструктуры, Ansible для конфигурации серверов, Argo CD или Flux для деплоя; каждое изменение фиксируется в Git.
Наблюдаемость
Дашборды с метриками, логами и трассировками в одном месте; содержательные оповещения и целевые уровни сервиса (SLO).
Внутренняя платформа для разработчиков
Среда самообслуживания, в которой команды сами создают окружения, сервисы и пайплайны в рамках заданных правил.
Контейнеризация
Перенос приложений в контейнеры и на Kubernetes, спланированный вместе с изменениями инфраструктуры и кода.
Что такое платформенная инженерия и когда она нужна?
Платформенная инженерия — это создание общей для команд внутренней платформы самообслуживания, чтобы практики DevOps оставались устойчивыми и при росте числа команд. Вместо того чтобы заново строить инфраструктуру, команды пользуются готовыми согласованными путями платформы.
Рекомендуемый путь (golden path)
Готовый согласованный путь для нового сервиса: шаблон, пайплайн, мониторинг и проверки безопасности с самого начала.
Самообслуживание
Команды сами создают среды, базы данных или пайплайны в заданных границах, без необходимости оформлять заявки.
Правила в платформе
Правила безопасности, затрат и соответствия встроены в платформу, и каждой команде не нужно применять их отдельно.
Когда она нужна?
Когда несколько команд порознь решают похожие задачи инфраструктуры, нужна платформа; одной команде часто хватает хорошего CI/CD.
Сначала пилот, затем масштабирование.
Мы вносим изменения поэтапно. Результат и критерии успеха каждого этапа определяются в начале работы, и вы отслеживаете прогресс по тем же критериям.
Что мы измеряем?
Пять метрик, которые исследовательская программа DORA использует для измерения эффективности поставки ПО. Какие из них отслеживать, мы выбираем вместе, исходя из имеющихся у вас данных:
- Частота развёртываний
- Время вывода изменения в эксплуатацию
- Доля изменений, приводящих к сбоям
- Время восстановления после неудачного развёртывания
- Доля развёртываний, требующих внеплановых исправлений
Обследование и анализ
Изучаем текущую архитектуру, процесс релизов, структуру команды и риски.
Результат: Результаты обследования и целиЦелевая архитектура и дорожная карта
Выбираем инструменты и платформы с обоснованием и расставляем приоритеты работ.
Результат: Архитектурный документ, поэтапный планПилот
Выстраиваем весь цикл для одного приложения и одной команды, измеряем и улучшаем.
Результат: Работающий пилот и первые замерыМасштабирование
Переносим проверенное в пилоте решение на другие сервисы и команды.
Результат: Пайплайны и средыПередача и эксплуатация
Обучаем вашу команду и передаём регламенты эксплуатации; при желании продолжаем эксплуатацию вместе с вами в рамках управляемых услуг.
Результат: Документация, обученная командаЧто остаётся у вас по итогам DevOps-проекта.
Состав результатов зависит от объёма работ; они документированы, пригодны для использования вашей командой и передаются в ваших собственных инструментах.
Архитектурная документация
Целевая архитектура, записи архитектурных решений и их обоснование.
Инфраструктурный код
Код Terraform и Ansible, модули и руководство по использованию.
Описания CI/CD
Конфигурации пайплайнов, их шаблоны и стратегии развёртывания.
Дашборды и оповещения
Готовые дашборды мониторинга, правила оповещений и описания SLO.
Регламенты эксплуатации
Процедуры для инцидентов, резервного копирования, отката и обновлений.
Обучение и передача знаний
Практические занятия для вашей команды и записи этих занятий.
Мы опираемся на ваши текущие инвестиции.
Сначала мы анализируем инструменты, которые у вас уже есть, и предлагаем замену, только если она даёт явный выигрыш.
Контейнеры и оркестрация
- Kubernetes
- OpenShift
- Rancher
- Amazon EKS
- Azure AKS
- Google GKE
- Docker
- Helm
CI/CD и GitOps
- GitLab CI
- GitHub Actions
- Jenkins
- Azure DevOps
- Argo CD
- Flux
Инфраструктура как код (IaC)
- Terraform
- OpenTofu
- Ansible
- Packer
Платформенная инженерия
- Backstage
- Crossplane
- HashiCorp Vault
Наблюдаемость
- Prometheus
- Grafana
- Loki
- OpenTelemetry
- Elastic / OpenSearch
Облака и виртуализация
- AWS
- Microsoft Azure
- Google Cloud
- Локальные облачные провайдеры
- VMware
- Proxmox
С чего начать с учётом размера вашей команды?
Малый и средний бизнес, небольшие команды
Обычно старт — CI/CD-пайплайн одного приложения, базовый мониторинг и резервное копирование; цель — простая и удобная в эксплуатации система.
Растущие команды разработки
По мере роста числа команд процесс релизов становится масштабируемым благодаря общим шаблонам, Kubernetes и средам самообслуживания.
Корпоративные ИТ-подразделения
Экспертная поддержка в конкретной области наряду с вашей командой; проектирование с учётом задач модернизации и регуляторных требований.
Чтобы первая встреча была продуктивной.
Ничто из этого не обязательно; всё, что у вас есть, сделает первый разговор более предметным.
Что можно подготовить, если есть
- Текущие архитектурные схемы и список сред
- Краткое описание процесса релизов и примеры недавних сбоев
- Структура команды: кто за что отвечает
- Регуляторные требования или требования заказчиков
О DevOps-консалтинге
Источники и стандарты
- Руководство по метрикам DORA (откроется в новой вкладке)Метрики эффективности поставки ПО
- Документация Kubernetes (откроется в новой вкладке)Официальная документация проекта
- Документация OpenTofu (откроется в новой вкладке)Открытый инструмент «инфраструктура как код»
- Документация Argo CD (откроется в новой вкладке)Непрерывная поставка по модели GitOps
- Google SRE: целевые уровни сервиса (откроется в новой вкладке)Понятие SLO
Давайте вместе уточним ваши задачи.
На бесплатной первичной консультации мы обсуждаем вашу текущую ситуацию и цели, а своим первым впечатлением и возможными следующими шагами делимся на той же встрече.
- Техническая беседа со специалистами по вашей теме
- Первое впечатление о вашей ситуации и возможные подходы
- Если уместно, следующий шаг: оценка, проектное предложение или консалтинг
- При необходимости — соглашение о неразглашении до встречи
- Ответ на запрос в течение 4 рабочих часов
DevOps: примеры из практики
На наглядных сценариях показываем, как шаг за шагом работают решения, которые мы часто внедряем.
CI/CD-пайплайн от кода до продакшена
Изменение проходит от запроса на слияние до продакшена автоматически и под контролем. У каждого шага есть критерий прохождения; если он не выполнен, пайплайн останавливается.
Запрос на слияние
Изменение поступает в отдельной ветке; при открытии запроса на слияние (merge request) пайплайн запускается автоматически.
- $ git push origin feature/payment-limit
- Merge request !214 opened
- Pipeline #4821 started
Сборка и тесты
Приложение собирается в образ контейнера; выполняются модульные и интеграционные тесты.
- $ docker build -t registry.example.local/payments-api:1.9.0 .
- => naming to registry.example.local/payments-api:1.9.0
- $ pytest -q
- ✓ 214 passed in 38.2s
Сканирование безопасности
Образ проверяется на известные уязвимости; при высоких или критических находках пайплайн останавливается.
- $ trivy image --severity HIGH,CRITICAL --exit-code 1 payments-api:1.9.0
- Total: 0 (HIGH: 0, CRITICAL: 0)
- ✓ quality gate passed
Развёртывание в тестовой среде
Тег новой версии записывается в репозиторий конфигурации; Argo CD синхронизирует тестовую среду с этим описанием.
- $ argocd app sync payments-api-staging
- Sync Status: Synced
- ✓ Health Status: Healthy
Поэтапный выпуск в продакшен
После одобрения новая версия сначала получает небольшую долю трафика; если метрики в пределах целевых значений, доля увеличивается.
- $ kubectl argo rollouts get rollout payments-api
- Step: 1/3 SetWeight: 10
- $ kubectl argo rollouts promote payments-api
- ✓ SetWeight: 100 Status: Healthy
Мониторинг
Доля ошибок и время отклика отслеживаются на дашбордах; при превышении порога срабатывает оповещение, и можно вернуться к предыдущей версии.
- PromQL: error rate (5 min)
- → 0.0021 (threshold 0.01)
- ✓ within service level objective
- GitLab CI
- Docker
- Trivy
- Argo CD
- Argo Rollouts
- Prometheus
Развёртывание среды с Terraform и Ansible
Новая среда описывается в коде, проходит проверку и затем создаётся. Terraform управляет ресурсами инфраструктуры, Ansible — конфигурацией внутри серверов.
Описание
Сеть, виртуальные машины и балансировщик нагрузки описываются модулями Terraform; различия между средами хранятся в файлах переменных.
- $ terraform fmt -check && terraform validate
- ✓ Success! The configuration is valid.
План
Пайплайн формирует планируемое изменение в виде плана и прикрепляет его к запросу на слияние.
- $ terraform plan -out=tfplan
- Plan: 12 to add, 0 to change, 0 to destroy.
Проверка
План проверяет и одобряет участник команды; одобрение фиксируется в истории.
- Merge request !87 · 1 approval
- ✓ review completed
Применение
Одобренный план применяется без изменений; файл состояния хранится в удалённом хранилище с блокировкой.
- $ terraform apply tfplan
- ✓ Apply complete! Resources: 12 added, 0 changed, 0 destroyed.
Настройка серверов
Параметры операционной системы, пакеты и службы с помощью Ansible настраиваются одинаково на всех серверах.
- $ ansible-playbook -i inventories/prod site.yml
- web-01 : ok=38 changed=6 unreachable=0 failed=0
- web-02 : ok=38 changed=6 unreachable=0 failed=0
Контроль дрейфа
Плановое задание регулярно сравнивает среду с кодом, чтобы выявить изменения, внесённые вручную.
- $ terraform plan -detailed-exitcode
- ✓ No changes. Your infrastructure matches the configuration.
- Terraform / OpenTofu
- Ansible
- GitLab CI
Развёртывание в Kubernetes по модели GitOps
То, как приложение работает в кластере, описано в Git; Argo CD приводит кластер в соответствие с этим описанием. Откат — это отмена изменения в Git.
Целевое состояние в Git
Версия, число реплик и параметры описаны в репозитории конфигурации.
- # values-prod.yaml
- image.tag: 1.9.0
- replicaCount: 3
Выявление расхождений
Argo CD непрерывно сравнивает состояние кластера с описанием в репозитории и показывает расхождения.
- $ argocd app get payments-api-prod
- ! Sync Status: OutOfSync from main (a41c9e2)
Синхронизация
Одобренное изменение применяется к кластеру; Kubernetes поочерёдно заменяет старые реплики новыми.
- $ argocd app sync payments-api-prod
- deployment.apps/payments-api configured
- ✓ Synced · Healthy
Откат
При проблеме изменение отменяется в Git, и предыдущее описание применяется снова. Данные это не затрагивает: для них есть отдельный план резервного копирования.
- $ git revert a41c9e2 && git push
- ✓ Synced to main (7be2d10)
Журнал изменений
Каждое изменение остаётся в истории Git с указанием, кто, когда и зачем его внёс.
- $ git log --oneline -2
- 7be2d10 Revert "payments-api 1.9.0"
- a41c9e2 payments-api 1.9.0
- Argo CD
- Helm
- Kubernetes
- Git
Мониторинг, целевые уровни сервиса и оповещения
Оповещения строятся на качестве сервиса, которое видят пользователи, а не на метриках серверов. Дежурного инженера уведомляют, только когда действительно нужно вмешательство.
Сбор данных
Метрики, логи и трассировки запросов приложения собираются в стандартном формате с помощью OpenTelemetry.
- $ kubectl get pods -n observability
- otel-collector-6d9f 1/1 Running
- prometheus-0 2/2 Running
Целевой уровень сервиса
Задаётся цель для доли успешных запросов, которую видят пользователи, например 99,9 % успешных запросов за 30 дней.
- SLO: successful requests ≥ 99.9% / 30 days
- error budget: 43 min 12 s
Оповещение
Если бюджет ошибок начинает быстро расходоваться, дежурный получает уведомление; кратковременные колебания оповещений не вызывают.
- ! ALERT ErrorBudgetBurn severity=page
- burn rate 14.4x (1 h) · 14.4x (5 min)
- → on-call engineer notified
Диагностика
Дашборды, логи и трассировки открываются за один и тот же интервал времени; выполняются шаги регламента эксплуатации (runbook).
- {app="payments-api"} |= "timeout"
- 12:04:31 upstream timeout: bank-service 3000ms
Разбор после инцидента
Первопричина и долгосрочные улучшения описываются письменно; при необходимости обновляются оповещения и дашборды.
- Incident #23 · duration 18 min
- ✓ action: timeout and retry settings updated
- OpenTelemetry
- Prometheus
- Alertmanager
- Grafana
- Loki