Основы DevOps
DevOps в этой энциклопедии — про как довести проверенную сборку до продакшена без простоя и с откатом — тестовые стенды, CI/CD, инфраструктура как код, наблюдаемость. Если вы только пишете код в IDE и никогда не видели staging — начните здесь: без различия тест и прод остальные главы про Jenkins, Kubernetes и Terraform воспринимаются как чужой мир. Карта всего раздела — в оглавлении.
Куда идти дальше по разделу: CI/CD — принципы · стратегии выката · Git и GitFlow · настройка конвейеров · жизненный цикл пайплайна · Azure Repos и TFS · GitHub Actions — CI/CD рецепты. Смежно: система контроля версий (Git), контейнеризация, основы ИБ.
Тест и прод
Две среды и зачем их разделяют
Часто путают "прод", "тест" и "стенд". Смысл прост: нельзя размещать тестовые или непроверенные вариации приложения на рабочей среде, поэтому нужна "копия" рабочей среды для проверок и экспериментов. Стенд — это обычно именно такая копия — отдельный сервер или кластер, куда ставят сборку "как на проде", но без реальных пользователей и с тестовыми данными. Тестовая среда — более широкое понятие: любое окружение, где проверяют изменения до выката. Продакшен (прод) — среда, куда ходят клиенты. Поэтому разворачивается целая инфраструктура вроде такой:
Разбор:
- Диаграмма в нотации Mermaid
flowchart LR— слева направо показывает поток от разработки к пользователям. - Узел
dev[Разработчики]— источник изменений — коммиты, сборки, эксперименты. - Стрелка
dev --> test— код и артефакты сначала попадают на тестовую среду или стенд, а не сразу в прод. - Цикл
test -->|проверки, эксперименты| test— на стенде можно многократно прогонять тесты, ломать данные и откатывать без риска для клиентов. - Стрелка
test -->|утверждённый релиз| prod— в прод идёт только версия, прошедшая проверки на тесте. - Узел
prod[Продакшен]— боевая среда;users[Пользователи] --> prod— конечные клиенты работают только с продом.
Здесь мы видим следующий порядок:
- Создаётся тестовая среда, на которой развёртывается тестовая база данных и тестовая сборка приложения (часто её называют "стенд"). Сотрудникам компании, заказчиков или разработчиков предоставляется доступ к этой среде — часто даже полный — можно ломать данные, перезапускать сервисы, откатывать миграции без риска для бизнеса.
- Создаётся продакшен (промышленная) среда с реальной базой данных (готовой "к бою") и только проверенной версией приложения. У команды разработки доступ к продакшену часто ограничен или отсутствует — чтобы случайный
DROP TABLEили неверный конфиг не остановил сервис для всех пользователей.
Между ними часто добавляют staging (предпрод) — почти копию прода по конфигурации и версиям зависимостей, но с обезличенными данными. На staging прогоняют финальные проверки перед кнопкой "в прод". Подробнее про цепочку сред — в статье CI/CD. Принципы.
Смысл продакшен-среды в том, чтобы установить туда рабочую программу и "не трогать, пока работает". Доступ туда даётся лишь ограниченный, как для обычных пользователей. К примеру, открыв любой сайт, маркетплейс, или даже игру, вы как пользователь получаете доступ именно к проду, поэтому да, всё вокруг нас - продакшен. И представьте, вы подаёте заявку на кредит на сайте, и прямо в середине процесса у вас резко меняется цвет интерфейса, а введённые вами данные очистились. Неприятно? Не то слово.
Поэтому разработчики сначала разработают и протестируют все изменения на тестовой среде без вреда для юзеров, и лишь потом полноценно развернут новую систему на продакшене.
Классическое развёртывание на продакшене — остановить приложение, заменить файлы и конфигурацию, снова запустить новую версию. Но представьте, если работа онлайн-банка или маркетплейса по всему миру…остановится, для установки обновления? Это же смертельно для бизнеса!
Поэтому существует автоматический процесс поставки с теста на прод.
Разбор:
git[Git: коммит / PR]— точка входа: push или merge request запускает автоматизацию.ci[CI: сборка и тесты]— пайплайн компилирует код, гоняет линтеры и тесты; при ошибке дальше не идут.artifact[Артефакт / образ]— неизменяемый результат сборки (Docker-образ, JAR) с привязкой к коммиту.staging[Staging]— предпрод: тот же артефакт проверяют в условиях, близких к проду.staging -->|ручное или авто одобрение| prod— gate перед продом: кнопка approve или политика auto-deploy.monitor[Мониторинг и логи]— метрики и алерты после выката; обратная связьmonitor --> gitзамыкает цикл улучшений.
Здесь всё искусство администраторов и DevOps-инженеров как раз в том, чтобы аккуратно обновить продакшен без вреда бизнесу. Современные технологии и инструменты позволяют производить такую "поставку" автоматически — через пайплайн и стратегии выката (rolling, blue/green, canary). Отсюда и термин CI/CD.
dev — локально или общий стенд для ежедневной разработки.
test / QA — автотесты и ручная проверка функций.
staging — "репетиция" прода перед релизом.
prod — боевая среда для конечных пользователей.
Что такое DevOps?
DevOps и CI/CD — разные уровни одной цепочки. DevOps — культура и практики совместной работы разработки и эксплуатации; CI/CD — конкретные автоматизированные шаги (сборка, тесты, выкат). Путать их не страшно, но полезно разделять — можно "делать DevOps" без зрелого CI/CD, и наоборот — иметь зелёный пайплайн при токсичной передаче "мне без разницы, у меня локально работает".
Итак, мы спроектировали решение, определились с архитектурой и даже разработали его. Что дальше? Нужно установить и запустить на сервере. Тут вступает в силу развёртывание (деплой).
Развёртывание – процесс установки и запуска программного обеспечения на целевой среде (например, сервер). Оно бывает ручным и автоматическим. И если ручное – это классическая установка всех компонентов, зависимостей и программ, то автоматическое – более интересный и сложный процесс, который требует особой квалификации – DevOps.
DevOps (от Разработка + Operations) – культура, методология и набор практик, которые направлены на автоматизацию и ускорение процессов разработки и развертывания программного обеспечения путем улучшения взаимодействия между разработчиками (Dev) и ИТ-операциями (Ops).
Важно — это не сисадмины, не релиз-мастера, и не конкретный инструмент. Это подход, который затрагивает и меняет весь цикл разработки ПО – от написания кода до его работы в продакшене.
Цель — ускорить выпуск продукта без потери качества. Аналогия — автоматический конвейер на заводе вместо ручной сборки каждой детали: цели те же, эффект сопоставим. Важно запустить проект так, чтобы он работал, и чтобы этот запуск был быстрым, безопасным и повторяемым.
Принципы DevOps (каждый пункт — конкретная практика):
- Автоматизация — меньше ручных шагов при сборке, тестах, деплое и настройке серверов. Инфраструктура описывается кодом (Terraform, Ansible — в блоке
21xраздела), изменения проходят через Git и пайплайн. Ручной "залив по SSH" остаётся только там, где автоматизация ещё не дозрела. - Коллаборация — разработчики, сисадмины, QA и техподдержка делят ответственность за путь кода до пользователя — общие стенды, понятные runbook'и, совместные постмортемы. Задача — убрать стену "разработчик бросил jar — админ разбирайся".
- Непрерывность — частые небольшие интеграции в общую ветку, автотесты на каждый push, регулярные выкаты на staging и контролируемый выход в прод, плюс мониторинг и логи после релиза. Ошибки ловят рано, а не в пятницу на проде.
Возможно, многие сталкивались с традиционной для любой ячейки общества системы "перекладывания ответственности", появившейся из "разделения ответственности". Допустим, разработчик сделал четко, что требуется, закинул код, передал админам, а на любые замечания говорит — "Мне без разницы, вот, смотрите, у меня всё работает". Админы пытаются, настраивают всё вручную, но не получается – то ошибка в тоннах конфигураций серверов, то нет нужных зависимостей, то нагрузка намного выше, чем на тестовом стенде. Итог – бесконечное перекладывание вины, медленные релизы, падение продакшена и конечно же "выдёргивание" разработчика для решения проблемы.
На практике знаю – это колоссальный стресс, я сталкивался с этим и как пользователь, и как техподдержка, и как администратор, и как разработчик. Когда не обеспечена автоматизация или должным образом все принципы не соблюдены – цикл "релизного ада" будет постоянным.
DevOps меняет ситуацию — разработчик пишет код, достаточный для задачи, и отвечает на вопросы эксплуатации:
- Как код будет работать в продакшене (переменные окружения, секреты, лимиты памяти)?
- Как он масштабируется при росте нагрузки (горизонтально, кэш, очереди)?
- Как быстро откатить релиз, если метрики пошли в красную зону (rollback)?
Ops (операторы, администраторы, SRE) участвуют в планировании с самого начала — знают архитектуру приложения, помогают проектировать стенды и пайплайны, а не только "принимают архив по почте".
Также DevOps практикует ещё и встраивание тестировщиков в процесс с самого начала, когда тесты пишутся параллельно с кодом, что обеспечивает тестирование не в конце, а на каждом этапе, а также используется автоматическое тестирование.
Всё это, в совокупности обеспечивает то, что команда перестаёт бояться изменений, а развертывание продукта становится гибким и плавным.
Основные понятия в DevOps
| Термин | Кратко | Подробнее |
|---|---|---|
| Dev | Разработка: код, тесты, ревью в Git | Git в DevOps |
| Ops | Эксплуатация: среды, деплой, мониторинг, инциденты | Сисадмин — раздел |
| Pipeline | Автоматизированная цепочка шагов от коммита до среды | Жизненный цикл пайплайна |
| Artifact | Результат сборки (образ, JAR, пакет), один и тот же на всех стендах | Один образ с тегом sha-abc123 едет на test → staging → prod |
| Environment | Изолированная среда (dev, test, staging, prod) | Среды в CI/CD |
| Deployment | Установка артефакта в целевую среду | Стратегии |
В DevOps рядом с CI/CD идут петля обратной связи и пайплайн.
Пайплайн (pipeline) — автоматизированный конвейер: берёт код из Git, прогоняет проверки и доставляет артефакт на нужный стенд. Упрощённая схема:
Git (push/PR) → Сборка → Автотесты → Деплой на test/staging → (ручные проверки) → Деплой на prod → Мониторинг
Разбор:
Git (push/PR)— событие в репозитории (push в ветку или открытие pull request) стартует пайплайн.Сборка— из исходников получают артефакт с фиксированными зависимостями (lock-файлы, образ CI).Автотесты— unit, integration, при необходимости E2E; красный шаг блокирует продвижение дальше.Деплой на test/staging— тот же артефакт ставят на общий стенд для QA и интеграционных проверок.(ручные проверки)— опциональный человеческий gate (approve, smoke руками) перед продом.Деплой на prod— выкладка проверенной версии в боевую среду по стратегии.Мониторинг— логи, метрики, алерты; при деградации — откат или hotfix в Git.
На практике шагов больше — линтинг, скан секретов, сборка Docker-образа, публикация в registry, smoke-тесты после деплоя. Разбор по этапам — в статье про жизненный цикл; тонкая настройка gates и approvals — в особенностях эксплуатации конвейеров.
CI/CD (Continuous Integration / Continuous Delivery / Deployment) — три связанные практики:
- Непрерывная интеграция (CI) — частые коммиты и слияния в общую ветку; при каждом push запускаются сборка и автотесты, чтобы ошибки находили до релиза. "Сломали main" — видно за минуты, а не через неделю.
- Непрерывная доставка (Continuous Delivery) — артефакт после CI всегда готов к выкладке; выход в prod часто требует ручного approve (кнопка "в прод"), но без ручной "сборки на сервере по SSH".
- Непрерывное развёртывание (Continuous Deployment) — каждый прошедший проверки коммит сам попадает в prod. Подходит зрелым командам с сильными тестами и canary; для банков и медицины чаще оставляют ручной gate.
Минимальный фрагмент пайплайна (GitHub Actions), иллюстрирующий CI:
name: ci
on: [push, pull_request]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test && npm run build
Разбор:
name: ci— имя workflow в интерфейсе GitHub Actions.on: [push, pull_request]— пайплайн запускается при push в репозиторий и при событиях pull request.jobs.build-and-test— одна job с именемbuild-and-test.runs-on: ubuntu-latest— job выполняется на свежем образе Ubuntu на hosted runner.steps— упорядоченный список шагов внутри job.uses: actions/checkout@v4— action клонирует репозиторий в рабочую директорию runner (аналогgit checkout).run — npm ci && npm test && npm run build— в одной shell-команде — установка зависимостей по lock-файлу (npm ci), тесты, production-сборка; при ненулевом exit code job падает и merge можно заблокировать.
Петля обратной связи — замкнутый цикл — жалобы пользователей, логи, метрики и алерты с прода анализируются, задачи возвращаются в разработку, исправления снова проходят CI/CD. Без этого команда "летит вслепую" после релиза. Сюда входят централизованные логи, дашборды (Практикум Prometheus и Grafana, PromQL — галерея, Практикум Zabbix, логирование в DevOps), тикеты в поддержку и постмортемы без поиска виноватых.
Ниже — интерактивная схема: как коммит запускает сборку и выкат (тот же смысл, что у демо CI/CD):
Play ITЗагрузка интерактивного демо…
В подборках
Статья входит в тематические подборки и блок "С чего начать?" на главной. Соседние шаги того же маршрута:
Соло / инди-разработчик — IDE, Разработка — о разделе, Разработка игр — о разделе, HTML — о разделе, Python — о разделе, Основы работы с Git — о разделе.
DevOps и инфраструктура — Модели и сервисы облачных технологий, Терминал — о разделе, Платформы — о разделе, Системное администрирование — о разделе, Архитектура персонального компьютера, Основы информационной безопасности — о разделе.