DevOps с нуля: практики, инструменты и культура

Что такое DevOps: цели, роли, культура и ценности

DevOps — это подход к созданию и эксплуатации цифровых продуктов, который объединяет разработку (Dev) и эксплуатацию (Ops) вокруг общей цели: быстро и безопасно доставлять ценность пользователю.

Важно: DevOps — это не одна «волшебная» должность и не набор инструментов. Это способ организации работы, в котором люди, процессы и технологии выстроены так, чтобы изменения в продукте попадали к пользователю чаще, с меньшими рисками и с предсказуемым качеством.

Полезные определения от крупных практиков индустрии:

DevOps (Wikipedia)

What is DevOps? (Atlassian)

What is DevOps? (AWS)

What is DevOps? (Microsoft)

Почему появился DevOps

Исторически разработка и эксплуатация часто жили в разных «мирах»:

Разработка оптимизировала скорость изменений и выпуск новых функций.

Эксплуатация оптимизировала стабильность и минимизацию изменений.

Это создавало конфликт целей:

Разработчики хотят выкатывать чаще.

Эксплуатация хочет выкатывать реже, потому что каждый релиз несёт риск.

DevOps появился как ответ на эту проблему: вместо конфликта — общая ответственность за результат, где и скорость, и стабильность достигаются системно.

!Иллюстрация, почему DevOps объединяет цели разработки и эксплуатации

Главная цель DevOps

Главная цель DevOps — сократить время и риски доставки изменений от идеи до пользователя.

Это выражается в практических результатах:

Быстрее выпускать новые функции и исправления.

Делать релизы более предсказуемыми.

Быстрее обнаруживать проблемы.

Быстрее восстанавливаться после сбоев.

Повышать качество и безопасность поставки.

DevOps как система: люди, процессы, технологии

DevOps работает только тогда, когда одновременно меняются три слоя:

Люди и взаимодействие

- совместная ответственность за продукт и его работу в продакшене - регулярная коммуникация между разработкой, тестированием, безопасностью, эксплуатацией

Процессы

- стандарты релизов - управление изменениями - реагирование на инциденты и обучение на ошибках

Технологии

- автоматизация сборки, тестирования и доставки - наблюдаемость и мониторинг - инфраструктура как код

Если внедрить только инструменты (например, CI/CD), но оставить старые организационные барьеры, DevOps обычно не «взлетает».

Культура DevOps: ключевые принципы

DevOps чаще всего описывают через культуру и принципы.

Совместная ответственность

Команды несут ответственность не только за написание кода, но и за то, как сервис работает у пользователей:

доступность

производительность

безопасность

стоимость эксплуатации

На практике это означает, что разработка и эксплуатация не передают работу «через забор», а совместно участвуют в релизах, разборе инцидентов и улучшениях.

Автоматизация по умолчанию

Повторяемые действия должны быть автоматизированы:

сборка и тесты

выпуск релиза

развёртывание инфраструктуры

проверка конфигураций

Цель автоматизации — не «заменить людей», а снизить вероятность ошибок и ускорить доставку.

Непрерывное улучшение

DevOps-команды постоянно улучшают систему поставки:

ищут узкие места

сокращают ручные шаги

улучшают обратную связь от мониторинга и пользователей

Обучение на ошибках без поиска виноватых

Одно из важных культурных оснований — разбор инцидентов без обвинений.

Смысл в том, что большинство серьёзных сбоев — результат не «плохого человека», а:

недостатков процесса

отсутствия автоматизированных проверок

неявных зависимостей

недостаточной наблюдаемости

Фокус смещается с вопроса «кто виноват?» на «что в системе позволило этому случиться и как исправить?».

Ценности DevOps: модель CALMS

Один из популярных способов запомнить, из чего состоит DevOps, — модель CALMS:

Culture — культура сотрудничества и общей ответственности

Automation — автоматизация поставки и эксплуатации

Lean — бережливое мышление: уменьшать потери времени и лишние шаги

Measurement — измеримость: решения на основе метрик и наблюдаемости

Sharing — обмен знаниями: документация, внутренние практики, общие стандарты

Эта модель полезна как чек-лист: если «проседает» хотя бы один компонент (например, нет измерений или обмена знаниями), DevOps становится неполным.

Роли в DevOps: кто что делает

DevOps — это подход, поэтому роли могут называться по-разному в разных компаниях. Ниже — типовая картина и зоны ответственности.

Разработчик

пишет функциональность

участвует в код-ревью

помогает обеспечивать наблюдаемость (логи, метрики, трассировка)

участвует в дежурствах или в разборе инцидентов (в зависимости от модели компании)

Инженер по эксплуатации / платформенный инженер

отвечает за надёжность среды выполнения

создаёт стандартизированную платформу для команд (шаблоны сервисов, окружения, доступы)

автоматизирует развёртывание и обслуживание инфраструктуры

DevOps-инженер

Название часто используется по-разному. В здоровой модели DevOps-инженер не является «человеком, который делает всё за всех», а помогает строить платформу и практики:

CI/CD пайплайны

инфраструктура как код

стандарты мониторинга и логирования

улучшение процесса релизов и управления изменениями

SRE (Site Reliability Engineer)

SRE — близкая по духу практика, сфокусированная на инженерном подходе к надёжности. Упрощённо:

DevOps — про культуру и поток поставки

SRE — про инженерные методы обеспечения надёжности

Если хотите почитать первоисточник от Google:

Site Reliability Engineering (книга от Google)

QA / тест-инженер

В DevOps тестирование стремятся сделать частью конвейера поставки:

автоматизированные тесты (юнит, интеграционные, e2e)

проверки качества до релиза

участие в анализе дефектов и улучшении качества процесса

Security (DevSecOps)

Безопасность становится частью поставки, а не «контролёром в конце»:

сканирование зависимостей

проверки контейнеров и образов

управление секретами

политики доступа и аудит

DevSecOps — это не отдельный мир, а идея: security включается в DevOps-процесс максимально рано и максимально автоматизированно.

DevOps-практики, которые вы будете встречать постоянно

Ниже — базовые практики, которые мы будем разворачивать в следующих материалах курса.

CI (Continuous Integration)

Непрерывная интеграция — это регулярное слияние изменений в общий репозиторий с автоматическими проверками.

Обычно CI включает:

сборку

запуск тестов

статический анализ кода (при необходимости)

Цель: как можно раньше находить ошибки и несовместимости.

CD (Continuous Delivery / Continuous Deployment)

Термины похожи, но смысл различается:

Continuous Delivery — код всегда готов к выпуску, но кнопка релиза может быть ручной.

Continuous Deployment — изменения автоматически попадают в продакшен при прохождении проверок.

IaC (Infrastructure as Code)

Инфраструктура как код — это управление инфраструктурой через файлы конфигурации и версии в репозитории.

Преимущества:

повторяемость окружений

прозрачность изменений

возможность ревью инфраструктурных изменений так же, как и кода

Как в DevOps измеряют успех

Чтобы улучшать систему, её нужно измерять. Часто используют метрики потока поставки и надёжности.

Например, популярный подход — измерять:

скорость поставки изменений

стабильность релизов

скорость восстановления

В индустрии известна практика измерения через метрики DORA и похожие подходы. В качестве вводного материала можно посмотреть:

Using the Four Keys to measure your DevOps performance (Google Cloud Blog)

Важный акцент: метрики не должны превращаться в «палку». Они нужны, чтобы видеть узкие места и улучшать систему, а не чтобы наказывать людей.

Распространённые заблуждения о DevOps

«DevOps — это человек»

- На практике DevOps — это модель взаимодействия и набор практик. Роли могут помогать, но один человек не способен заменить культуру.

«DevOps = CI/CD»

- CI/CD — важная часть, но DevOps шире: включает ответственность, процессы, измеримость, обмен знаниями.

«DevOps нужен только большим компаниям»

- Чем меньше команда, тем важнее быстро и безопасно доставлять изменения. Просто масштаб практик будет проще.

«DevOps убивает стабильность ради скорости»

- Цель DevOps — достигать и скорости, и стабильности через автоматизацию, стандартизацию и наблюдаемость.

Что дальше по курсу

Эта статья задаёт основу: DevOps как культура и система. Далее логично переходить к практическим «кирпичикам»:

как выглядит путь изменения от коммита до продакшена

основы CI/CD и качество пайплайнов

инфраструктура как код и управление окружениями

контейнеризация и оркестрация

мониторинг, логирование и работа с инцидентами

!Классический цикл DevOps и непрерывная обратная связь

Linux и сети для DevOps: базовые команды и протоколы

DevOps-практики из прошлой темы (культура, автоматизация, измерения, совместная ответственность) почти всегда реализуются на базе Linux и сетей. CI/CD-агенты, контейнеры, Kubernetes-ноды, прокси, базы данных, мониторинг и логирование обычно работают на Linux-серверах и общаются по сети.

Эта статья даёт фундамент: базовые команды Linux и сетевые протоколы, которые нужны, чтобы уверенно:

диагностировать проблемы в продакшене

понимать, что именно происходит между сервисами

автоматизировать операции в скриптах и пайплайнах

читать логи, управлять процессами и сетевыми соединениями

Минимальная модель: как запрос проходит через систему

Когда «что-то не работает», обычно проблема либо:

в приложении (код, конфигурация)

в окружении (процессы, права, диски, лимиты)

в сети (DNS, маршрутизация, порты, firewall)

!Общая карта движения запроса и типовые точки отказа

Linux для DevOps: базовая навигация и работа с файлами

Где вы находитесь и что вокруг

Чаще всего вы будете работать по SSH на сервере. Базовые команды:

pwd показывает текущую директорию

ls выводит содержимое директории

cd меняет директорию

cat печатает файл

less удобный просмотр больших файлов

head и tail начало и конец файла

Пример:

Поиск по файлам и содержимому

Для диагностики полезно быстро находить конфиги и ошибки:

find ищет файлы по имени и условиям

grep ищет строки по шаблону

rg (ripgrep) часто удобнее, но может быть не установлен

Пример:

Перенаправления и конвейеры

Это основа для скриптов и автоматизации:

> перезаписывает файл выводом команды

>> дописывает в файл

| передаёт вывод одной команды на вход другой

2> перенаправляет ошибки

Пример:

Права доступа и запуск от нужного пользователя

В Linux почти любая проблема «вдруг не работает» может упираться в права.

Модель прав: владелец, группа, остальные

Команда ls -l показывает права в виде строк вроде -rw-r--r--:

первые 3 символа rw- относятся к владельцу

следующие 3 r-- к группе

последние 3 r-- к остальным

Ключевые команды:

chmod меняет права

chown меняет владельца

id показывает, кто вы и в каких группах

Пример:

Практический смысл: сервис может падать, если не может прочитать конфиг, открыть порт, создать файл, записать лог.

Процессы и сервисы: что реально работает на сервере

Процессы

Команды для понимания, что запущено и сколько потребляет:

ps aux список процессов

top или htop интерактивный мониторинг

free -h память

df -h место на диске

Пример:

systemd и управление сервисами

На большинстве современных дистрибутивов сервисами управляет systemd.

База:

systemctl status <service> статус

systemctl start|stop|restart <service> управление

systemctl enable <service> автозапуск

Пример:

Логи через journald

Если сервис под systemd, логи удобно смотреть через journalctl:

journalctl -u <service> логи конкретного сервиса

journalctl -u <service> -f «follow», поток логов

Пример:

Официальная справка по journalctl:

journalctl (man7.org)

Сеть для DevOps: основные понятия простыми словами

IP-адрес, маска и маршрут

IP-адрес идентифицирует узел в сети

маршрут определяет, куда отправлять пакеты для других сетей

шлюз по умолчанию маршрут «в остальной мир», когда нет более специфичного

Базовые команды:

ip addr адреса интерфейсов

ip route таблица маршрутизации

Документация по ip:

ip (man7.org)

Порт и сокет

порт это «номер входа» на машине для сетевого сервиса

сокет это сочетание IP, порта и протокола (TCP или UDP), через которое идёт общение

Типовые порты:

22 SSH

53 DNS

80 HTTP

443 HTTPS

DNS: как имя превращается в IP

DNS отвечает на вопрос: «какой IP у имени api.example.com?».

Частые симптомы DNS-проблем:

имя не резолвится

резолвится в неправильный IP

резолвится долго (таймауты)

Инструменты:

dig подробная диагностика DNS

getent hosts <name> проверка резолвинга так, как это делает система

Справка по dig:

dig (BIND 9 Administrator Reference Manual)

Пример:

TCP и UDP: чем отличаются

TCP надёжная доставка: порядок, повторная отправка потерянных данных, контроль соединения

UDP доставка без установления соединения: быстрее и проще, но без гарантий доставки

На практике:

HTTP/HTTPS почти всегда поверх TCP

DNS часто использует UDP (и TCP в некоторых случаях)

!Наглядное сравнение TCP и UDP

Базовые сетевые команды: что проверять в первую очередь

Ниже набор инструментов, который покрывает большую часть первичной диагностики.

Проверка связности: ping и traceroute

ping проверяет, есть ли ответ от узла (ICMP)

traceroute показывает путь по маршрутизаторам до цели

Пример:

Важно: ping может быть запрещён на маршруте или на хосте, поэтому «не пингуется» не всегда означает «не работает».

Справка:

ping (man7.org)

Смотреть, какие порты слушаются: ss

Команда ss заменила netstat во многих системах.

Частые режимы:

ss -lnt слушающие TCP-порты

ss -lnu слушающие UDP-порты

ss -lntp слушающие TCP-порты и процессы

Пример:

Справка:

ss (man7.org)

Понять, какой процесс занял порт: lsof

Если сервис не стартует из-за «port already in use», ищем владельца порта:

Справка:

lsof (man7.org)

Проверка HTTP и API: curl

curl нужен в каждом пайплайне и на каждом сервере.

Типовые проверки:

Справка:

curl documentation

«Прозвонить» TCP-порт: nc

nc (netcat) позволяет быстро понять, доступен ли порт:

Это полезно, когда DNS работает, но приложение не может подключиться к базе или внешнему API.

Справка:

nc (man7.org)

Сниффинг трафика: tcpdump

tcpdump помогает увидеть, что реально происходит на сетевом уровне: идут ли пакеты, есть ли ответы, какие порты.

Примеры:

Справка:

tcpdump (man7.org)

Осторожно: tcpdump может содержать чувствительные данные. Используйте минимально нужные фильтры и соблюдайте политики безопасности.

Практический алгоритм диагностики «сервис недоступен»

Ниже последовательность, которая хорошо работает в DevOps-практике.

Уточните, что именно не работает: DNS, TCP-соединение, HTTP-ответ, конкретный endpoint.

Проверьте DNS: getent hosts name, dig name.

Проверьте доступность порта: nc -vz host port.

Проверьте HTTP: curl -I или curl -v.

На сервере проверьте, слушает ли сервис порт: ss -lntp.

Проверьте логи сервиса: journalctl -u service --since "10 min ago".

Если непонятно, где «обрывается», примените tcpdump с фильтром по порту.

Этот подход хорошо согласуется с DevOps-ценностями из модели CALMS: вы действуете измеримо, воспроизводимо и можете автоматизировать проверки в health-check и пайплайнах.

Мини-справочник: команды и когда они нужны

| Задача | Команда | Пример | |---|---|---| | Узнать IP и интерфейсы | ip addr | ip addr show | | Узнать маршруты | ip route | ip route | | Проверить DNS | dig, getent | dig example.com | | Проверить, кто слушает порт | ss | sudo ss -lntp | | Найти процесс по порту | lsof | sudo lsof -i :8080 | | Проверить HTTP | curl | curl -I https://... | | Проверить TCP-порт | nc | nc -vz host 5432 | | Посмотреть логи сервиса | journalctl | sudo journalctl -u nginx -f |

Как это связывается с DevOps-практиками

CI/CD: curl и nc часто используются в smoke-тестах после деплоя.

Наблюдаемость: умение читать логи (journalctl) и понимать сетевые симптомы ускоряет поиск причины инцидента.

Infrastructure as Code: корректные порты, DNS-имена, маршруты и политики доступа должны быть воспроизводимы и проверяемы.

Культура общей ответственности: разработчик, понимающий базу Linux и сетей, быстрее устраняет проблемы вместе с эксплуатацией, а не «перекидывает через забор».

Дополнительные источники

The Linux man-pages project (man7.org)

iproute2 documentation (ip command, man7.org)

curl documentation

tcpdump (man7.org)

Git и управление кодом: ветвление, PR и стратегии релизов

Git — фундаментальный инструмент DevOps-практик, потому что он делает изменения управляемыми: кто, что и почему поменял; как это обсудили; как откатили; как выпустили.

В прошлых темах мы разобрали:

DevOps как культуру общей ответственности, автоматизации и измерений

Linux и сети как базу для диагностики и эксплуатации

Теперь добавляем третий «кирпичик» — управление изменениями в коде. Без него CI/CD, инфраструктура как код и стабильные релизы превращаются в хаос.

Что такое Git и чем он полезен в DevOps

Git — распределённая система контроля версий. Практически это значит:

вся история изменений хранится в репозитории

изменения можно делать параллельно (ветки)

изменения можно обсуждать и проверять до попадания в основную ветку (PR)

В DevOps Git используется не только для приложений:

конфигурации окружений

Dockerfile и манифесты деплоя

IaC (Terraform, Ansible)

документация и runbook’и

Рекомендованный базовый источник по Git:

Pro Git (книга)

Минимальная модель Git: репозиторий, коммит, ветка

Репозиторий

Репозиторий — папка проекта вместе с историей изменений.

локальный репозиторий находится у вас

удалённый репозиторий обычно живёт в GitHub/GitLab/Bitbucket

Коммит

Коммит — зафиксированный снимок изменений с сообщением.

Хороший коммит:

маленький и логичный

компилируется и проходит базовые проверки (если возможно)

имеет понятное сообщение

Команды:

Ветка

Ветка — указатель на цепочку коммитов. Обычно есть основная ветка, например main, и дополнительные ветки для задач.

Команды:

Ветвление: зачем нужно и какие есть подходы

Ветвление решает две задачи:

параллельная работа нескольких людей без конфликтов

управление риском: не смешивать незавершённые изменения с релизными

Именование веток

Единый стиль имён снижает путаницу в команде. Частые варианты:

feature/<коротко-что-делаем>

bugfix/<коротко-что-фиксируем>

hotfix/<срочный-фикс>

release/<версия-или-дата>

Важно не имя само по себе, а предсказуемость.

Как возникают конфликты и как их снижать

Конфликт — ситуация, когда Git не может автоматически объединить изменения.

Чтобы конфликтов было меньше:

делайте маленькие PR

чаще синхронизируйтесь с основной веткой

избегайте «долгоживущих» веток без необходимости

Синхронизация с main обычно делается через merge или rebase.

Merge и Rebase: в чём разница

Merge

merge объединяет две ветки и создаёт merge-коммит (если не fast-forward).

Плюсы:

сохраняется естественная история ветвления

проще для новичков

Минусы:

история может стать шумной

Пример:

Rebase

rebase «переписывает» ветку так, будто вы начали её от актуального состояния main.

Плюсы:

линейная история

проще читать git log

Минусы:

можно ошибиться, если делать rebase над уже опубликованной историей

Практическое правило:

rebase безопаснее использовать для локальных веток, пока вы один работаете над ними

для общих веток команды осторожнее: договоритесь о правилах

Пример:

Официальная справка:

git-merge (документация)

git-rebase (документация)

Pull Request: что это и зачем он нужен

Pull Request (PR) — запрос на вливание изменений из ветки в основную ветку с обсуждением и проверками.

В GitLab аналог обычно называется Merge Request.

PR нужен не для бюрократии, а для управляемости:

код-ревью и обмен знаниями

автоматические проверки (CI)

контроль качества и безопасности

журналирование изменений: контекст и обсуждения сохраняются

Документация:

About pull requests (GitHub Docs)

!Жизненный цикл PR от ветки до релиза

Хороший PR

Хороший PR обычно:

небольшой по размеру

имеет понятное описание что и зачем

содержит инструкции по проверке

включает изменения документации, если поведение поменялось

Пример структуры описания PR:

Что изменилось

Почему это нужно

Как проверить

Риски и откат

Code review: что проверять

Ревью — не поиск ошибок автора, а улучшение системы поставки.

Список типовых проверок:

корректность логики и краевых случаев

читаемость и поддерживаемость

покрытие тестами или хотя бы понятный план проверки

безопасность (секреты, доступы, инъекции)

наблюдаемость (логи, метрики, понятные ошибки)

обратная совместимость (сломаются ли клиенты)

Защита основной ветки

Чтобы случайно не сломать main, часто настраивают правила:

запрет прямых push в main

обязательный PR

обязательные статусы CI

минимум 1–2 одобрения

Это один из практических способов реализовать DevOps-ценности качества и предсказуемости.

Стратегии слияния PR

На платформах обычно есть несколько стратегий.

Merge commit

Сохраняет отдельный merge-коммит.

Подходит, если:

важна видимая история ветвлений

PR часто содержит несколько логических коммитов

Squash merge

Склеивает все коммиты PR в один.

Подходит, если:

вы хотите более чистую историю

коммиты в PR были «черновыми»

Риск:

теряется детализация истории внутри PR (коммиты исчезают как отдельные точки)

Rebase and merge

Переносит коммиты поверх main, создавая линейную историю.

Подходит, если:

команда дисциплинирована в коммитах

важна линейность

Выбор стратегии — это договорённость команды. В DevOps важно, чтобы процесс был понятным и повторяемым.

Стратегии релизов в Git: как организовать выпуск версий

Здесь речь не про деплой (blue/green, canary), а про то, как в Git описывать и готовить релиз.

Теги и версии

Тег — метка на конкретном коммите. Обычно релизы помечают тегами.

Пример:

Почему теги важны:

можно однозначно сказать, что именно было в релизе

легко откатиться на предыдущий тег

CI/CD может собирать артефакты именно по тегам

Семантическое версионирование

Частая договорённость по версиям — SemVer: MAJOR.MINOR.PATCH.

Идея простая:

MAJOR увеличивается при несовместимых изменениях

MINOR при добавлении функциональности без ломания совместимости

PATCH при исправлениях багов

Спецификация:

Semantic Versioning 2.0.0

Release notes и предсказуемые сообщения коммитов

Чтобы автоматизировать changelog и релиз-ноты, часто стандартизируют сообщения коммитов.

Популярный стандарт:

Conventional Commits

Пример сообщений:

feat: add /health endpoint

fix: handle timeout in payment client

chore: update dependencies

В DevOps это напрямую помогает автоматизации: инструменты могут понять, что именно изменилось, и собрать релиз-ноты.

Выбор workflow: trunk-based, GitHub Flow, GitFlow

Workflow — это «правила игры»: какие ветки есть, как долго живут, как делаем релиз.

Trunk-based development

Суть:

есть одна основная ветка (main)

изменения живут в коротких ветках и быстро попадают в main

релизы часто и маленькими порциями

Обычно сочетается с:

сильным CI

feature flags, если нужно прятать незавершённую функциональность

Подходит, если:

вы хотите частые релизы

команда готова инвестировать в автоматизацию проверок

GitHub Flow

Упрощённый поток:

main всегда в релизопригодном состоянии

любая работа делается в ветке

PR в main проходит ревью и CI

после merge можно релизить

Это один из самых понятных вариантов для небольших команд.

GitFlow

Классический подход с несколькими долгоживущими ветками (обычно develop, main, release/, hotfix/).

Плюсы:

удобно при редких релизах и сложной поддержке нескольких версий

Минусы:

выше сложность

выше стоимость слияний и конфликтов

Практическая рекомендация для старта:

начинайте с простого (GitHub Flow или trunk-based)

усложняйте только если есть реальная потребность (например, параллельная поддержка нескольких релизных линий)

Hotfix, backport и cherry-pick: когда нужно чинить срочно

В продакшене бывают ситуации: релиз уже ушёл, а баг критический.

Термины:

hotfix — срочное исправление для продакшена

backport — перенос исправления в более старую ветку релиза

cherry-pick — перенос конкретного коммита в другую ветку

Пример cherry-pick:

Официальная справка:

git-cherry-pick (документация)

Git и DevOps-практики: как это связывается с CI/CD и эксплуатацией

Git становится «источником правды», на который опираются остальные процессы:

CI запускает тесты на каждый PR и/или push

CD разворачивает изменения из main или по тегам релиза

IaC изменения проходят тот же путь: ветка → PR → проверки → merge

инциденты расследуются через историю изменений: что поменялось перед проблемой

Если в прошлой статье про Linux и сети мы учились диагностировать проблему на сервере, то Git помогает ответить на ключевой вопрос инцидента:

какое изменение привело к текущему состоянию системы

Мини-шпаргалка команд Git

| Задача | Команда | Пример | |---|---|---| | Проверить состояние | git status | git status | | Создать ветку | git switch -c | git switch -c feature/x | | Забрать изменения | git pull | git pull --rebase | | Посмотреть историю | git log | git log --oneline --decorate --graph | | Слить ветку | git merge | git merge main | | Перебазировать | git rebase | git rebase origin/main | | Поставить тег | git tag | git tag -a v1.0.0 -m "Release" | | Перенести коммит | git cherry-pick | git cherry-pick <sha> |

Что дальше

После Git логично переходить к темам, которые строятся на управляемых изменениях:

CI: автоматические проверки на каждый PR

CD: стратегии выката по тегам, веткам и окружениям

Infrastructure as Code: изменения инфраструктуры через PR и ревью

наблюдаемость: связывание релизов (тегов) с метриками и инцидентами

CI/CD: сборка, тестирование, деплой и пайплайны

CI/CD — это практики и инструменты, которые превращают изменения в репозитории (Git) в проверенные и повторяемо доставленные изменения в окружениях (dev, stage, prod).

В предыдущих темах курса мы собрали основу:

DevOps как культура: совместная ответственность, автоматизация, измерения (CALMS)

Linux и сети: умение диагностировать проблемы и понимать, что происходит «на сервере»

Git: управляемые изменения через ветки, PR и стратегии релизов

CI/CD логично продолжает эту цепочку: Git делает изменения управляемыми, а CI/CD делает их доставку управляемой.

!Схема типового CI/CD пайплайна от коммита до продакшена

Термины: CI, CD и что именно «непрерывно»

Continuous Integration

CI (непрерывная интеграция) — это практика, при которой изменения:

регулярно попадают в общий код (обычно через PR в main)

автоматически проверяются (сборка, тесты, статический анализ)

дают быструю обратную связь автору

Классическое описание CI:

Continuous Integration (Martin Fowler)

Continuous Delivery и Continuous Deployment

Термины CD часто путают, поэтому важно разделить:

Continuous Delivery: система устроена так, что каждое изменение может быть выпущено в продакшен в любой момент, но само решение о релизе может быть ручным (кнопка, approval)

Continuous Deployment: каждое изменение автоматически попадает в продакшен после прохождения проверок

Хорошее объяснение разницы:

Continuous Delivery (Martin Fowler)

В рамках DevOps культуры ключевое не то, «есть ли кнопка», а то, что релиз становится:

предсказуемым

воспроизводимым

измеримым

Зачем CI/CD нужен в DevOps

CI/CD решает системные проблемы, которые без автоматизации постоянно возвращаются:

Человеческий фактор: ручные шаги забываются, выполняются по-разному, плохо документируются

Поздняя обратная связь: ошибки обнаруживаются в конце (или в продакшене)

Сложность отката: непонятно, какой набор изменений был выпущен и как вернуться назад

Долгие релизы: чем больше пакет изменений, тем сложнее найти причину проблем

Если связать это с CALMS:

Automation: пайплайн заменяет ручную сборку и деплой

Measurement: пайплайн даёт метрики времени сборки, процента падений, частоты релизов

Sharing: пайплайн как код — это документация процесса доставки

Из чего состоит пайплайн

Пайплайн — это последовательность автоматизированных шагов, которые выполняются при событии в репозитории (push, PR, tag, manual).

Типовая структура пайплайна:

Триггер: когда запускать (push в ветку, PR, тег релиза, расписание)

Этапы: логические блоки (build, test, security, deploy)

Джобы: конкретные задачи внутри этапов

Артефакты: то, что производится (бинарник, Docker-образ, архив)

Гейты: условия допуска дальше (успешные тесты, approval, политика безопасности)

Runner, агент, исполнитель

Пайплайн выполняется не «в облаке вообще», а на конкретных исполнителях:

runner/agent — машина или контейнер, где запускаются джобы

окружение раннера определяет доступные инструменты (например, docker, node, python)

Практическое следствие: если пайплайн на одном раннере проходит, а на другом падает, проблема часто в:

версиях инструментов

правах доступа

сетевых правилах

отсутствии кэша или зависимостей

Это напрямую связывает CI/CD с темой Linux и сетей: диагностика падающих пайплайнов часто начинается с логов, прав и сетевых проверок.

Артефакты и принцип «собрали один раз, развернули много раз»

Один из главных принципов надёжной доставки:

один и тот же артефакт должен продвигаться по окружениям

Пример:

на CI вы собрали Docker-образ myapp:1.4.0 и запушили в registry

дальше вы разворачиваете этот же образ на dev, stage и prod

Почему это важно:

если пересобирать «на каждом окружении», то dev и prod могут получить разные артефакты

отладка становится сложнее: «на stage работало» перестаёт быть сильным аргументом

В Git это часто связывают с тегами релиза:

тег v1.4.0 указывает на конкретный коммит

пайплайн собирает артефакт, помеченный версией

Проверки в CI: что обычно автоматизируют

CI не равен «прогнать тесты». Это конвейер качества. Типовой набор проверок:

сборка

юнит-тесты

интеграционные тесты (по возможности)

линтеры и форматирование

статический анализ и поиск уязвимостей

проверка инфраструктурных конфигов (если репозиторий содержит IaC)

Пирамида тестов в контексте CI

Чтобы пайплайн был быстрым и полезным, тесты обычно распределяют по уровням:

много быстрых юнит-тестов

меньше интеграционных тестов

ещё меньше e2e, потому что они самые дорогие и нестабильные

Цель — получить ранний сигнал об ошибке.

Security в пайплайне: DevSecOps на практике

Чтобы безопасность не была «этапом в конце», её включают в CI/CD как автоматические проверки:

сканирование зависимостей (SCA)

статический анализ кода (SAST)

сканирование контейнерных образов

проверка секретов, случайно попавших в репозиторий

Хорошая отправная точка по идеям:

OWASP DevSecOps Guideline

CD: деплой как управляемый процесс

Деплой — это не только «запустить новую версию». Это управляемое изменение состояния системы.

Минимальные компоненты CD:

развернуть артефакт в окружение

применить конфигурацию

выполнить миграции (если нужно)

проверить работоспособность (smoke/health-check)

зафиксировать, что произошло (версия, время, кто инициировал)

Окружения и продвижение

Частая модель окружений:

dev: быстро, часто, допускаются эксперименты

stage: ближе к продакшену, проверка совместимости и сценариев

prod: конечные пользователи

Продвижение обычно строят так:

одно изменение проходит один и тот же путь

чем ближе к prod, тем выше строгость проверок

Гейты: где уместна ручная проверка

Ручные шаги не запрещены. Важно, чтобы они были осознанными гейтами, а не «потому что иначе страшно».

Типовые гейты:

approval на деплой в prod

ручная проверка release notes

подтверждение, что выполнен план коммуникации

Хороший признак зрелости: ручной шаг остаётся решением, но не заменяет автоматические проверки.

Пайплайн как код

Современная практика: описание пайплайна хранится в репозитории рядом с кодом.

Плюсы:

изменения пайплайна ревьюятся через PR

история изменений пайплайна прозрачна

можно вернуться к рабочей версии пайплайна

Популярные платформы и документация:

GitHub Actions Documentation

GitLab CI/CD Documentation

Jenkins User Documentation

Пример: минимальный CI пайплайн

Ниже пример на GitHub Actions: сборка и тесты для проекта на Node.js. Важно не запомнить синтаксис, а увидеть структуру: триггер, шаги, кэш.

Что здесь происходит:

Пайплайн запускается на PR и на push в main

Раннер поднимается на Ubuntu

Забирается код

Ставится нужная версия Node.js

Включается кэш зависимостей, чтобы ускорить сборку

Ставятся зависимости и запускаются тесты

Пример: минимальный CD шаг с проверкой доступности

После деплоя важно сделать хотя бы smoke-check. На практике часто используют curl из прошлой темы.

Пример команды, которая проверяет код ответа и время:

Как это читать:

-s отключает лишний вывод

-o /dev/null не сохраняет тело ответа

-w печатает выбранные метрики

%{http_code} HTTP-код

%{time_total} общее время запроса

Если health-check нестабилен, это сигнал к улучшению наблюдаемости и готовности сервиса.

Практические принципы хорошего пайплайна

Быстрая обратная связь

Пайплайн должен быстро говорить разработчику: всё хорошо или что сломалось.

Технические приёмы:

параллелизация джоб

кэширование зависимостей

разделение тестов на быстрые и медленные

Детерминизм и воспроизводимость

Один и тот же вход должен давать один и тот же результат.

Частые угрозы детерминизму:

плавающие версии зависимостей

нефиксированные версии инструментов

зависимости от внешних сервисов без стабов

Идемпотентность деплоя

Идея простая: повторный запуск деплоя не должен ломать систему.

Примеры:

если деплой прервался, повторный запуск должен корректно довести систему до нужного состояния

миграции БД должны быть спроектированы так, чтобы их повторный запуск не приводил к ошибкам

Управление секретами

Секреты нельзя хранить в репозитории. Обычно используют:

секреты платформы CI (Secrets в GitHub/GitLab)

внешние хранилища секретов

Ключевой принцип:

пайплайн получает секреты в рантайме

в логах секреты не должны появляться

Наблюдаемость пайплайна

Пайплайн — часть вашей продакшен-системы доставки, значит его тоже нужно измерять.

Полезные показатели:

среднее время выполнения

процент падений по причинам

частота релизов

доля «красных» сборок на main

Для связи DevOps-практик с результатом в индустрии часто используют метрики DORA:

DORA Metrics (Google Cloud)

Частые ошибки при внедрении CI/CD

Делать один огромный пайплайн, который трудно поддерживать

Считать, что CI/CD заканчивается на «прошли тесты» и не включать проверку деплоя

Пересобирать артефакт на каждом окружении вместо продвижения одного артефакта

Хранить секреты в репозитории или выводить их в логи

Не фиксировать версии инструментов, из-за чего пайплайн «вчера работал, сегодня нет»

Как это связывается с Git и релизами

CI/CD опирается на принципы управления изменениями из Git-темы:

PR как точка контроля качества

защищённая основная ветка

теги как привязка релиза к конкретному коммиту

Практическая схема выглядит так:

Разработчик создаёт ветку и PR

CI автоматически проверяет PR

После merge в main запускается пайплайн сборки и упаковки артефакта

CD разворачивает артефакт в dev или stage

Релиз в prod делается по тегу или через approval (в зависимости от модели)

Что дальше по курсу

После CI/CD обычно переходят к темам, которые делают доставку ещё более воспроизводимой:

контейнеризация и Docker как стандарт упаковки артефакта

Infrastructure as Code: окружения и конфигурации через Git

стратегии выката (rolling, blue/green, canary) и откаты

наблюдаемость (метрики, логи, трассировка) как основа обратной связи после релиза

Контейнеры и оркестрация: Docker и Kubernetes основы

Контейнеры и Kubernetes часто воспринимают как набор модных инструментов, но в DevOps они решают очень практичную задачу: сделать запуск приложения воспроизводимым и управляемым от ноутбука разработчика до продакшена.

Связь с предыдущими темами курса:

Из статьи про Git у нас есть управляемые изменения (ветки, PR, теги релизов).

Из статьи про CI/CD у нас есть конвейер, который проверяет и доставляет изменения.

Контейнеры добавляют недостающее звено: в чём именно мы доставляем приложение (артефакт) и как гарантировать, что оно запускается одинаково.

Kubernetes добавляет следующий уровень: как запускать и обновлять много контейнеров, обеспечивая масштабирование, отказоустойчивость и сетевую доступность.

!Диаграмма различий между виртуальными машинами и контейнерами

Контейнеры: что это такое простыми словами

Контейнер — это способ упаковать приложение вместе с его зависимостями так, чтобы оно запускалось одинаково в разных средах.

Ключевая идея:

контейнер изолирует приложение на уровне процессов, файловой системы и сети

при этом контейнеры используют ядро (kernel) хостовой ОС, поэтому обычно они легче виртуальных машин

Важно различать термины:

образ (image) — шаблон, из которого создаются контейнеры

контейнер (container) — запущенный экземпляр образа (или остановленный, но созданный)

реестр (registry) — хранилище образов (например, Docker Hub)

Полезные источники:

Docker: Get Started

Kubernetes: What is Kubernetes?

OCI: Open Container Initiative

Почему контейнеры важны для DevOps и CI/CD

Контейнеры помогают реализовать принцип из CI/CD: "собрали один раз, развернули много раз".

Практически это выглядит так:

CI собирает Docker-образ (артефакт)

образ получает версию (например, по тегу Git)

образ публикуется в registry

CD разворачивает тот же образ в dev, stage, prod

Плюсы такого подхода:

меньше сюрпризов типа "на моём ноутбуке работает"

проще откатываться (откат = вернуть предыдущий тег образа)

удобнее стандартизировать рантайм (одинаковая структура логов, health-check, переменные окружения)

Docker как стандартный инструмент контейнеризации

Docker — самая распространённая экосистема для сборки и запуска контейнеров. На практике вам нужно понимать:

как устроен образ

как писать Dockerfile

как запускать контейнер

как хранить и передавать образы

Документация:

Dockerfile reference

Docker CLI reference

Образ: слои и кэш

Docker-образ собирается из слоёв (layers). Каждый слой обычно соответствует инструкции в Dockerfile.

Зачем это знать DevOps-инженеру:

слои кэшируются, поэтому сборки ускоряются

порядок команд в Dockerfile влияет на кэш и время сборки

большие слои увеличивают размер образа, что замедляет загрузку и деплой

Dockerfile: минимальный пример

Dockerfile — это рецепт сборки образа.

Пример для простого приложения (идея важнее языка):

Что здесь происходит:

FROM выбирает базовый образ

WORKDIR задаёт рабочую директорию

COPY копирует файлы в образ

RUN выполняет команду на этапе сборки

EXPOSE документирует порт приложения

CMD задаёт команду запуска контейнера

Базовые команды Docker: собрать, запустить, посмотреть

Связь с темой Linux:

внутри контейнера вы используете те же базовые команды (ps, ls, cat, netstat часто заменён на ss)

диагностика часто начинается с логов и проверки, слушает ли процесс порт

Registry: как образы попадают в CI/CD

Типовой поток:

разработчик пушит код в Git

CI собирает образ и пушит его в registry

CD забирает образ из registry и разворачивает

Пример (общая механика):

Конфигурация приложения: переменные окружения

В контейнерном мире конфигурацию часто передают через переменные окружения:

Это удобно для CI/CD:

один образ, разные значения переменных для разных окружений

Важно: секреты (пароли, токены) нельзя печатать в логи и хранить в репозитории. В реальных системах используют секрет-хранилища или секреты платформ CI.

Данные: тома (volumes)

Контейнеры по умолчанию эфемерны: их файловая система исчезает при удалении контейнера. Для данных используют volumes.

Пример:

Сеть: порты и сети Docker

В Docker есть несколько типовых сценариев:

проброс порта наружу: -p hostPort:containerPort

общение контейнеров друг с другом через docker network

Для локальной разработки часто используют Docker Compose.

Docker Compose: несколько сервисов локально

Docker Compose — это способ описать набор контейнеров (например, приложение + база данных) в одном файле.

Документация:

Docker Compose overview

Минимальный пример:

Практики хороших контейнеров

Делайте образы меньше

Почему:

быстрее скачивание и деплой

меньше поверхность атаки

Типовые приёмы:

выбирать slim-образы

очищать кэш пакетного менеджера

использовать multi-stage build (сборка в одном образе, рантайм в другом)

Запуск не от root

Если процесс внутри контейнера работает от root, то при уязвимости риск выше. Часто добавляют пользователя:

Health-check и наблюдаемость

Контейнеры хорошо сочетаются с идеей health endpoint (/health). Это связывает тему контейнеров с темой CI/CD (smoke-check через curl) и будущими темами наблюдаемости.

Зачем нужна оркестрация и почему Kubernetes

Когда контейнеров становится много, появляются задачи, которые вручную решать нельзя или слишком дорого:

запуск на нескольких серверах

автоматический перезапуск при падении

балансировка трафика

масштабирование

обновления без простоя

управление конфигурацией и секретами

Оркестратор — система, которая управляет жизненным циклом контейнеров в кластере.

Самый распространённый оркестратор — Kubernetes.

Документация:

Kubernetes Documentation

!Обзор архитектуры Kubernetes кластера

Kubernetes: базовые понятия

Кластер, control plane и worker nodes

Кластер Kubernetes — набор машин (физических или виртуальных), где запускаются контейнеры.

Роли:

control plane управляет кластером (принимает команды, планирует размещение, хранит состояние)

worker node запускает рабочие нагрузки (контейнеры)

kubectl и декларативный подход

В Kubernetes обычно не делают "запусти контейнер" как в Docker. Вместо этого описывают желаемое состояние.

вы описываете, сколько экземпляров приложения нужно, какую версию образа использовать, какие порты и переменные

Kubernetes пытается привести реальность к этому описанию

CLI-инструмент:

kubectl — основной клиент для общения с Kubernetes API

Документация:

kubectl overview

Pod

Pod — минимальная единица запуска в Kubernetes.

Pod обычно содержит:

один контейнер приложения

иногда вспомогательные контейнеры (например, для прокси или инициализации)

Важно:

Pod не считают "вечным": он может быть пересоздан и получить новый IP

Deployment

Deployment управляет набором Pod и обновлениями.

Он отвечает за:

нужное количество реплик (например, 3 Pod)

rolling update (плавное обновление версии)

откат к предыдущей версии

Service

Service даёт стабильную точку доступа к набору Pod.

Потому что Pod могут пересоздаваться, Service берёт на себя:

постоянное имя

балансировку трафика между репликами

Labels и selectors

Kubernetes связывает объекты через метки:

label — пара ключ-значение (например, app=myapp)

selector — правило, по которому Service или Deployment выбирают Pod

Это фундаментальный механизм, без которого сложно понять, как Service "находит" нужные Pod.

Namespace

Namespace — логическое разделение ресурсов в кластере.

Типовые сценарии:

отдельные namespace для dev, stage, prod

изоляция команд (team-a, team-b)

ConfigMap и Secret

ConfigMap — хранит несекретную конфигурацию.

Secret — хранит чувствительные данные.

Важно понимать границы:

Secret в Kubernetes не равен полноценному vault, но это базовый механизм доставки секретов в Pod

секреты всё равно требуют политики доступа и аккуратного обращения

Документация:

ConfigMaps

Secrets

Минимальный пример манифестов Kubernetes

Ниже пример Deployment и Service. Это упрощённый шаблон, чтобы увидеть структуру.

Как это читать:

replicas: 2 означает, что Kubernetes будет поддерживать 2 Pod

image указывает точный артефакт (Docker-образ), собранный в CI

Service направляет трафик на Pod с меткой app: myapp

Обновления и проверки: что делает деплой безопаснее

Rolling update

Deployment обычно обновляет Pod постепенно:

часть реплик остаётся на старой версии

часть поднимается на новой

если новая версия не готова, обновление может остановиться

Probes: liveness и readiness

Чтобы Kubernetes понимал состояние приложения, используют проверки:

livenessProbe: приложение живо или его нужно перезапустить

readinessProbe: готово ли приложение принимать трафик

Зачем это важно:

без readiness приложение может получать трафик, ещё не поднявшись

без liveness приложение может "зависнуть" и не быть перезапущенным

Документация:

Probes

Requests и limits

Kubernetes планирует размещение Pod по ресурсам.

requests: сколько CPU и памяти Pod гарантированно просит для планирования

limits: верхний предел

Это влияет на стабильность кластера и предсказуемость.

Документация:

Resource Management for Pods and Containers

Как Docker и Kubernetes встраиваются в Git и CI/CD

Типовая связка выглядит так:

Git PR запускает CI: тесты, линтеры, сборка образа

CI публикует образ в registry с версией (например, v1.0.0)

CD обновляет манифест (или Helm/Kustomize) на новую версию образа

Kubernetes выполняет rolling update

post-deploy проверки (например, curl /health) подтверждают работоспособность

В зрелых командах:

Kubernetes-манифесты тоже лежат в Git и проходят PR

изменения инфраструктуры и доставки становятся такими же управляемыми, как изменения кода

Частые ошибки новичков

Путать образ и контейнер: образ строят, контейнер запускают.

Собирать образ на продакшене вместо CI.

Не версионировать образы и использовать только latest.

Хранить секреты в Dockerfile, в репозитории или печатать их в логах.

В Kubernetes деплоить без readinessProbe и удивляться нестабильности при старте.

Что дальше

После контейнеров и Kubernetes логично перейти к темам, которые делают эксплуатацию предсказуемой:

наблюдаемость (метрики, логи, трассировка)

стратегии выката (blue/green, canary) на базе Kubernetes

инфраструктура как код и GitOps-подход

Контейнеры дают упаковку и переносимость, Kubernetes даёт управление жизненным циклом, а DevOps-культура и CI/CD дают процесс, который делает всё это стабильным и повторяемым.

Инфраструктура как код: Terraform, Ansible и конфигурации

Инфраструктура как код (Infrastructure as Code, IaC) — это практика, в которой инфраструктура и конфигурации описываются в виде файлов, хранятся в Git и изменяются через тот же процесс, что и приложение: ветка → PR → ревью → автоматические проверки → применение.

Связь с предыдущими темами курса:

Из темы про Git у нас есть управляемые изменения и контроль через PR.

Из темы про CI/CD у нас есть автоматизированный конвейер проверок и доставки.

Из темы про контейнеры и Kubernetes у нас есть воспроизводимый артефакт приложения.

IaC добавляет следующий уровень: воспроизводимую и проверяемую среду, в которой это приложение работает.

!Поток изменения инфраструктуры через Git и CI/CD

Что такое IaC и почему это важно в DevOps

В традиционной модели инфраструктура часто создаётся и меняется вручную:

кто-то заходит в облако и кликает настройки

кто-то меняет конфиги на сервере по SSH

детали остаются в голове или в чатах

Проблемы такого подхода:

изменения сложно повторить (нет точного рецепта)

сложно понять, кто и зачем что-то поменял

сложно откатить

часто появляется дрейф: то, что в документации, не совпадает с тем, что реально

IaC решает это через принципы:

описание желаемого состояния в файлах

версионирование изменений в Git

автоматизированные проверки перед применением

воспроизводимость окружений (dev/stage/prod)

Полезная отправная точка:

Terraform Documentation

Ansible Documentation

Два слоя: провижининг и конфигурация

На практике IaC почти всегда состоит из двух разных задач.

Провижининг

Провижининг отвечает на вопрос: какие ресурсы должны существовать.

Примеры ресурсов:

VPC/сети, подсети, маршруты

виртуальные машины

балансировщики

базы данных как управляемый сервис

DNS-записи

Kubernetes-кластеры

Типичный инструмент: Terraform.

Конфигурация

Конфигурация отвечает на вопрос: как настроить уже созданные ресурсы и что на них запустить.

Примеры:

поставить пакеты и сервисы

разложить конфиги

создать пользователей и права

настроить systemd-юниты

выполнить шаги деплоя на VM

Типичный инструмент: Ansible.

Важно: граница условная. Но новичкам помогает простая модель:

Terraform создаёт скелет инфраструктуры

Ansible настраивает содержимое и поведение

Terraform: базовая модель и рабочий цикл

Terraform — инструмент для декларативного описания инфраструктуры.

Ключевая идея: вы описываете желаемое состояние, а Terraform вычисляет, что нужно создать, изменить или удалить.

Официальная документация:

Terraform CLI Commands

Основные понятия Terraform

provider — плагин для работы с конкретной платформой (AWS, GCP, Azure, Kubernetes и другие)

resource — описываемый объект инфраструктуры (например, сеть или виртуальная машина)

module — переиспользуемый набор ресурсов (как библиотека)

variables — входные параметры, чтобы переиспользовать конфигурацию

outputs — выходные значения (например, IP или DNS), полезные для других систем

Минимальный пример Terraform-конфигурации

Синтаксис Terraform называется HCL.

Это не создаёт ресурсы, но показывает механику:

variable задаёт параметр

output возвращает значение (например, для чтения в CI)

Plan и Apply

Типовой цикл работы:

terraform init скачивает провайдеры и подготавливает рабочую директорию

terraform fmt форматирует файлы

terraform validate проверяет синтаксис и базовую корректность

terraform plan показывает план изменений (что будет создано/изменено/удалено)

terraform apply применяет изменения

С точки зрения DevOps важно, что plan позволяет сделать изменение обсуждаемым и проверяемым до реального применения.

Terraform state и почему он критичен

Terraform хранит информацию о созданных ресурсах в файле state.

Зачем нужен state:

Terraform должен знать, какие ресурсы уже существуют и как они связаны с кодом

Terraform сравнивает желаемое состояние (код) с текущим состоянием (state + фактическая платформа)

Практические следствия:

state нельзя терять

state нельзя хранить как попало

при командной работе нужен общий доступ и блокировки

Официальная документация:

Terraform State

Remote state и блокировки

В командной среде state обычно хранят удалённо (remote backend), чтобы:

все работали с одним источником правды

избежать одновременного apply, которое может повредить систему

Документация по бэкендам:

Terraform Backends

Дрейф (drift): когда реальность расходится с кодом

Дрейф — это ситуация, когда кто-то изменил ресурсы вручную, и фактическое состояние перестало соответствовать IaC.

Почему это плохо:

следующий apply может неожиданно удалить или изменить то, что руками «подкрутили»

поддержка становится дорогой: никто не уверен, как оно устроено

Базовая защита:

запрещать ручные изменения политиками доступа

регулярно прогонять terraform plan в CI как проверку

Terraform-модули и структура репозитория

Как только инфраструктура перестаёт быть игрушечной, без модулей появляется копипаста.

Зачем нужны модули

Модули помогают:

стандартизировать подход (сети, логирование, теги, политики)

переиспользовать решения

уменьшать количество ошибок

Документация:

Terraform Modules

Типовая структура

Ниже один из рабочих вариантов структуры. Он не единственный, но хорошо читается.

Идея:

modules содержит переиспользуемые кирпичи

envs содержит разные окружения с разными параметрами

Ansible: конфигурация, идемпотентность и роли

Ansible — инструмент для управления конфигурацией и выполнения автоматизированных действий на серверах.

Документация:

Ansible User Guide

Что значит идемпотентность в Ansible

В контексте конфигурации идемпотентность означает:

если вы применили playbook повторно, система останется в правильном состоянии

повторный запуск не должен «ломать» сервер и не должен постоянно вносить изменения без необходимости

Это перекликается с принципами из CI/CD: повторяемость и предсказуемость.

Основные понятия Ansible

inventory — список хостов и групп (куда применять)

playbook — сценарий действий (что применять)

task — шаг в playbook

module — готовое действие (установка пакета, шаблон, пользователь)

role — структура для переиспользуемой конфигурации

handler — действие, которое выполняется при изменениях (например, перезапуск сервиса)

Минимальный пример playbook

Пример показывает установку nginx и запуск сервиса.

Что важно:

become: true означает выполнение с повышенными правами (аналог sudo)

модуль package не будет переустанавливать nginx каждый раз, если он уже установлен

Роли и шаблоны

Для реальных систем часто нужно раскладывать конфиги. Типовой подход:

хранить шаблон конфигурации

подставлять параметры (порты, пути, режимы)

при изменении шаблона перезапускать сервис через handler

Это помогает стандартизировать серверы и минимизировать ручные правки.

Секреты в Ansible

Секреты нельзя хранить в открытом виде в репозитории.

Один из базовых инструментов экосистемы:

Ansible Vault

Практический принцип:

секреты должны попадать в систему только на этапе выполнения и с минимально нужными правами

Управление конфигурацией: что такое конфигурация и где её хранить

Важно различать типы данных, которые вы передаёте приложению и инфраструктуре.

Конфигурация и секреты

конфигурация: не чувствительные параметры (имя окружения, URL сервиса, флаги)

секреты: пароли, токены, ключи, приватные сертификаты

Правило по умолчанию:

конфигурацию можно хранить в Git

секреты в Git хранить нельзя

Подходы к доставке конфигурации

Часто используются:

переменные окружения

конфигурационные файлы из шаблонов (например, через Ansible)

ConfigMap и Secret в Kubernetes

секреты и параметры из внешних хранилищ (зависит от платформы)

В рамках курса важно усвоить принцип: один и тот же артефакт приложения должен запускаться с разной конфигурацией в dev/stage/prod, а не пересобираться под каждое окружение.

IaC + Git + CI/CD: практический процесс изменений

Ниже типовой процесс, который связывает темы Git и CI/CD с IaC.

Изменение инфраструктуры делается в отдельной ветке.

Открывается PR.

CI запускает проверки:

- terraform fmt -check - terraform validate - terraform plan и публикация плана как артефакта - для Ansible: линтеры и проверка синтаксиса (в зависимости от стека)

Ревью смотрит не только код, но и план: что реально изменится.

После merge применение делается контролируемо:

- вручную с подтверждением - или автоматически, но с гейтами и политиками

!Как Terraform, Ansible и CI/CD дополняют друг друга

Частые ошибки новичков и как их избежать

Ручные изменения в облаке поверх Terraform

Хранение секретов в репозитории

Один общий state на всё без изоляции окружений

Отсутствие ревью и plan в PR

Использование непредсказуемых версий

Практики, которые помогают:

фиксировать версии Terraform и провайдеров

настраивать remote state и блокировки

разделять окружения и параметры

делать изменения маленькими и частыми

Как это связывается с контейнерами и Kubernetes

В современной инфраструктуре часто получается связка:

Terraform создаёт кластер Kubernetes, сети и доступы

CI собирает Docker-образы и публикует их в registry

CD обновляет манифесты или чарты и выкатывает в кластер

Даже если вы пока не используете Kubernetes, логика та же:

Terraform создаёт VM и сеть

Ansible настраивает VM

пайплайн выкатывает приложение и проверяет доступность (curl, health-check)

Что дальше

После IaC логично развивать эксплуатационную часть DevOps:

наблюдаемость (метрики, логи, трассировка) как обратная связь после изменений

управление инцидентами и постмортемы

практики безопасных релизов и откатов на уровне инфраструктуры и приложений

Наблюдаемость и надежность: мониторинг, логи, алерты и SRE

Наблюдаемость (observability) и надежность (reliability) — это практики, которые позволяют понимать, что происходит в системе прямо сейчас, почему это происходит и как быстро вернуть сервис в норму.

Связь с предыдущими темами курса:

После Git и CI/CD мы научились управлять изменениями и доставлять их предсказуемо.

После Docker/Kubernetes мы получили стандартизированный рантайм и механизм выката.

После IaC (Terraform/Ansible) мы научились воспроизводимо создавать и настраивать окружения.

Теперь добавляем обязательный слой для продакшена: как измерять качество работы, как замечать деградации, как реагировать на инциденты и как улучшать систему на основе данных.

!Как телеметрия связывает путь запроса с мониторингом и реакцией

Что такое наблюдаемость

Наблюдаемость — это способность по внешним сигналам понять внутреннее состояние системы.

Практически это означает:

вы можете ответить, что сломалось (симптомы)

вы можете ответить, почему сломалось (причины)

вы можете сделать это быстро и воспроизводимо (процессы и инструменты)

Часто наблюдаемость описывают через три основных типа телеметрии:

Метрики: числовые ряды во времени (например, RPS, ошибки, задержки).

Логи: события (например, ошибка подключения к БД с контекстом).

Трассировка: путь конкретного запроса через компоненты системы.

Терминология и современные стандарты часто обсуждаются в экосистеме OpenTelemetry:

OpenTelemetry

Мониторинг и наблюдаемость: в чем разница

Мониторинг обычно отвечает на вопрос: система работает в пределах нормы или нет?

Наблюдаемость отвечает на вопрос: почему она вышла из нормы, и где искать причину?

На практике это выглядит так:

мониторинг дает графики и алерты по заранее известным проблемам

наблюдаемость помогает разбирать новые и сложные ситуации, когда заранее не было готового алерта

Важно: мониторинг почти всегда строится на метриках, а наблюдаемость почти всегда требует связки метрик, логов и трассировки.

Что такое надежность и как ее измеряют

Надежность — это способность сервиса стабильно выполнять обещанную функцию: быть доступным, отвечать достаточно быстро, не ошибаться выше допустимого уровня.

В инженерных командах надежность часто формализуют через SLI, SLO и SLA.

SLI (Service Level Indicator): измеряемый показатель качества (например, доля успешных запросов).

SLO (Service Level Objective): цель по SLI (например, 99.9% успешных запросов за 30 дней).

SLA (Service Level Agreement): внешнее обязательство перед клиентом (часто с компенсациями).

Классический источник по подходу SRE:

Site Reliability Engineering (книга Google)

Error budget: почему он нужен

Если у вас есть SLO, то появляется бюджет ошибок (error budget): сколько деградаций качества вы можете позволить в выбранный период.

Частая простая модель для доступности:

Разбор обозначений:

— целевой уровень, например 0.999 (это 99.9%).

— окно измерения, например 30 дней.

— сколько времени в этом периоде сервис может быть недоступен и все еще укладываться в SLO.

Зачем это в DevOps:

если бюджет ошибок почти исчерпан, команда временно снижает темп рискованных изменений и инвестирует в надежность

если бюджет ошибок расходуется мало, можно смелее выпускать изменения

Это связывает надежность с CI/CD: релизы перестают быть спором мнений и становятся управлением риском на основе измерений.

Метрики: что измерять и как не сломать мониторинг

Типы метрик, которые чаще всего встречаются

Counter: только растет (например, число запросов, число ошибок).

Gauge: может расти и падать (например, использование памяти).

Histogram/Summary: распределение значений (например, задержки по квантилям и бакетам).

Эти типы особенно важны, если вы работаете с Prometheus-экосистемой:

Prometheus

Золотые сигналы и быстрые модели для сервисов

Чтобы не тонуть в сотнях графиков, используют компактные наборы сигналов.

Four Golden Signals (часто применяются для HTTP/API сервисов):

Latency: задержка ответа.

Traffic: нагрузка (например, запросы в секунду).

Errors: ошибки (например, 5xx).

Saturation: насыщение ресурсов (CPU, память, пул соединений).

Также распространены практические схемы:

RED для сервисов: Rate, Errors, Duration.

USE для ресурсов: Utilization, Saturation, Errors.

Лейблы и кардинальность: типичная ловушка

Метрики часто имеют лейблы (например, method=GET, status=200).

Ошибка новичков: добавлять лейблы с большим числом уникальных значений (например, user_id, request_id). Это называется высокой кардинальностью и может:

резко увеличить объем хранения

замедлить запросы к метрикам

сделать мониторинг дорогим и нестабильным

Правило по умолчанию:

в метриках оставляйте лейблы с ограниченным набором значений

детализацию до конкретных запросов выносите в логи и трассировку

Дашборды: зачем они нужны, но почему они не спасают

Дашборды полезны, когда:

у команды есть единый способ быстро понять состояние сервиса

есть несколько стандартных панелей для инцидентов и релизов

Но дашборд не заменяет:

корректные SLI/SLO

качественные алерты

runbook с действиями

Популярный инструмент для визуализации:

Grafana

Логи: как сделать их полезными в продакшене

Логи — это события с контекстом. Главная ценность логов в том, что они помогают объяснить, почему произошла ошибка и в каких условиях.

Структурированные логи

Практически полезный стандарт: писать логи в структурированном виде (часто JSON), чтобы потом фильтровать по полям.

Что обычно кладут в поля логов:

уровень (info, warn, error)

имя сервиса и окружение (service, env)

сообщение

контекст запроса (например, trace_id)

код ошибки и тип исключения

Уровни логов и шум

Типовые уровни:

debug: только для диагностики, часто выключают в prod

info: важные события потока

warn: подозрительные ситуации, но сервис продолжает работать

error: ошибка выполнения запроса или операции

Частая проблема: слишком много info и warn, из-за чего реальные ошибки теряются.

Централизация логов

Если логи лежат на отдельных VM или нодах Kubernetes, искать инцидент сложно. Поэтому логи обычно собирают в централизованную систему.

Распространенные варианты:

стек Elastic (Elasticsearch и Kibana): Elastic Stack

Grafana Loki: Grafana Loki

Трассировка: как найти узкое место в распределенной системе

Распределенная трассировка показывает путь запроса через несколько сервисов.

Базовые термины:

Trace: цепочка обработки одного запроса.

Span: один шаг в trace (например, запрос к БД или внешний HTTP вызов).

Context propagation: передача идентификаторов между сервисами, чтобы связать trace.

Зачем это нужно:

понять, где именно теряется время (API, БД, очередь, внешний сервис)

увидеть, какие зависимости реально участвуют

связать конкретный медленный запрос с логами и ошибками

Стандарт де-факто для инструментирования:

OpenTelemetry

Корреляция: как связать метрики, логи и трассировку

Когда начинается инцидент, полезный рабочий путь выглядит так:

Алерт или жалобы пользователя показывают симптом, часто через метрики (рост 5xx, рост задержки).

Дашборд подтверждает масштаб и время начала.

Логи дают сообщения об ошибках и контекст.

Трассировка показывает конкретное место деградации.

Чтобы это работало, нужен общий ключ корреляции, чаще всего:

trace_id в логах

trace_id в заголовках запросов между сервисами

Алертинг: как сделать так, чтобы алерты помогали

Алерт должен требовать действия

Хороший алерт:

означает проблему, важную для пользователя или бизнеса

имеет понятную срочность

подразумевает конкретные действия

Плохой алерт:

часто срабатывает ложноположительно

не объясняет, что делать

срабатывает на причину без понимания влияния (например, краткий всплеск CPU без влияния на задержку)

Это приводит к alert fatigue: команда начинает игнорировать сигналы.

Symptom-based alerting

Сильная практика: алертить на симптомы, а не на каждую возможную причину.

Примеры алертов по симптомам:

доля 5xx выше порога

задержка на 95 перцентиле выше порога

доля успешных запросов (SLI) падает ниже SLO-траектории

Алерты по причинам полезны как дополнительные сигналы, но обычно не как единственная линия защиты.

Paging и ticket: разные уровни реакции

Чтобы не будить людей без необходимости, разделяют:

paging: срочно, требует реакции сейчас (обычно on-call)

ticket: несрочно, задача в бэклог (например, рост логов или постепенная деградация)

Runbook: что должно быть у каждого алерта

Runbook — короткая инструкция, что делать при срабатывании алерта.

Минимально полезный runbook содержит:

что означает алерт

где посмотреть метрики и логи

быстрые проверки (команды, ссылки на дашборды)

варианты mitigation (например, откат релиза, выключение фичи)

критерий завершения инцидента

Runbook связывается с темами Linux и сети: часто первые действия включают curl, ss, проверку логов и DNS.

SRE как инженерный подход к надежности

SRE (Site Reliability Engineering) — это практика, которая применяет инженерные методы к надежности.

Ключевые идеи SRE, которые полезны в DevOps с самого начала:

надежность измеряется через SLI/SLO, а не через субъективное чувство

error budget помогает балансировать скорость изменений и стабильность

автоматизация важнее ручных героических действий

постмортемы делаются без поиска виноватых, чтобы улучшать систему

Официальный материал:

Site Reliability Engineering (книга Google)

Toil: что автоматизировать в первую очередь

В SRE важен термин toil: повторяющаяся, ручная, не приносящая долгосрочной ценности операционная работа.

Примеры toil:

ручные рестарты сервисов

ручная чистка дисков

однотипная диагностика без автоматизированных проверок

Связь с DevOps культурой:

автоматизация снижает человеческий фактор

улучшения делаются системно, а не только во время пожара

Инциденты: базовый жизненный цикл

Инцидент — это нарушение SLO или реальное ухудшение пользовательского опыта.

Практический жизненный цикл:

Детекция: алерт, мониторинг, обращение пользователя.

Триаж: быстро понять масштаб, затронутые компоненты, приоритет.

Митигирование: остановить ухудшение (откат, отключение фичи, масштабирование).

Восстановление: вернуть сервис к нормальным SLI.

Постмортем: разобрать причины и добавить улучшения (тесты, алерты, лимиты, guardrails в CI/CD).

Постмортем в DevOps делается в логике обучения на ошибках без поиска виноватых.

Как встроить наблюдаемость в ваш DevOps-процесс

Практический минимум, который стоит внедрять рано:

в каждый сервис добавить health endpoint (например, /health) и базовые метрики

в CI/CD после деплоя запускать smoke-check через curl

в Kubernetes настроить readiness и liveness probes

стандартизировать формат логов и добавить trace_id

описывать алерты и дашборды как код, хранить в Git и ревьюить через PR

Так наблюдаемость становится частью системы поставки, а не ручной активностью после проблем.

Мини-чеклист: что должно быть у продакшен-сервиса

| Область | Минимум | Почему важно | |---|---|---| | Метрики | трафик, ошибки, задержки, насыщение | быстро понять состояние и масштаб | | Логи | структурированные, уровни, контекст | быстро найти причину | | Трассировка | trace/span, распространение контекста | находить узкие места и зависимости | | Алерты | симптомные, с runbook | реакция без хаоса | | SLO | измеримые цели | управлять надежностью и риском | | Постмортемы | действия по улучшению | уменьшать повторение инцидентов |

!Три опоры наблюдаемости и как они используются при инциденте

Что дальше по курсу

После наблюдаемости логично углубляться в практики, которые делают систему еще более управляемой:

безопасные стратегии релизов и откатов (blue/green, canary)

управление зависимостями и таймаутами, лимитами, ретраями

GitOps для инфраструктуры и Kubernetes

безопасность в эксплуатации (аудит, управление секретами, политики доступа)

Наблюдаемость дает данные, SRE дает рамку надежности, а DevOps-практики доставки превращают улучшения в регулярный процесс.