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

Казалось бы, 2025 год, а CI/CD до сих пор есть не везде, где релизы — регулярная рутина. А там, где есть, оно порой работает так, что лучше бы не работало.

🤔 Для начала разберёмся с терминами

Есть путаница. CD — это не просто “нажал кнопку — код задеплоился”. Это подход к разработке, в котором каждое изменение потенциально готово к релизу (см. Фаулера — он пишет сложно, но полезно).
Но когда говорят “CI/CD”, чаще всего имеют в виду: “я запушил код, и он магически оказался на серверах”. Ну, магия магией, но работать это должно стабильно.

🤔 Как это устроено

Есть две модели доставки кода:

- Push — код выталкивается в среду (Jenkins, GitLab CI).
- Pull — среда сама забирает нужное из репозитория (ArgoCD, Flux).

Если триггернуться на слово "ArgoCD" — можно развести холивар про gitops-подходы, в этой заметке хотелось бы этого избежать. Поэтому сосредоточимся на GitLab CI — удобной системе, где CI/CD строится на простых скриптах.

Pipeline в GitLab CI — это просто последовательность команд. Например:

stages:
  - update_code
  - restart_service

update_code:
  stage: update_code
  script:
    - git pull origin main

restart_service:
  stage: restart_service
  script:
    - systemctl restart myservice

Этот pipeline обновляет код и перезапускает сервис. Всё просто? Нет.

🤔 Проблема с git pull

Наивная схема с git pull кажется рабочей, но тут две проблемы:

1. Изменения не атомарные!
Когда идёт git pull — файлы подменяются прямо на работающем сервисе. Если код обновился не весь (например, разорвался посреди обновления), приложение скорее всего разнесёт на куски.

2. Неуправляемое состояние.
Файлы на сервере могли быть случайно (или не случайно) изменёны вручную. Где гарантия, что git pull не выдаст конфликт? А если обновление потребует миграции БД?

Не получится сделать просто git pull && restart. Должен быть механизм откатов, контроль за зависимостями, тестирование перед выкладкой.

Ой, что-то сложно, давайте не делать? Можно сделать сначала "наивный" вариант, а по мере того, как будет отстреливать и придётся решать конфликты руками — обкладываться костылями вокруг. Эволюционный подход.
Ну или – сделать доставку атомарной сразу. Например, с помощью Docker?

🤔 Почему Docker не спасает

Окей, допустим, вместо git pull мы собираем и выкатываем контейнеры:

script:
  - docker build -t my-app .
  - docker run -d my-app

Но тут свои нюансы, которые иногда могут отстрелить нам ноги:

- Сборка образа не случится мгновенно. Если тянуть зависимости, сборка может идти долго.
- Чистка старых образов. Хранилище контейнеров растёт в размере, и если не следить, место на диске тупо кончится.
- Проблема зависимостей. Если код требует новую версию PostgreSQL, просто пересборка образа не поможет.

То есть Docker решает часть проблем, но не все (и создаёт новые 😳)

🤔 Почему у вас до сих пор нет CI/CD

1. Возможно вы не знаете bash? Не беда, у вас есть ChatGPT. Например, спросите его, как написать скрипт, который проверяет, запущен ли сервис, и если нет — перезапускает.

2. Возможно у вас нет времени? CI/CD как раз освобождает время. Задумайтесь, сколько часов в неделю уходит на ручные сборки, регрессы, конфликты при мерже. Выявите это и автоматизируйте.

3. Вас кидает с проекта на проект? Если нет времени на наведение порядка, может, пора сменить работу?

🤔 С чего начать

Начните с простого — автоматизируйте любую рутинную задачу. Например, вместо ручного git pull && restart сделайте скрипт:

#!/bin/bash
git pull origin main && systemctl restart myservice

И хотя бы проверьте, что он сработает, а не развалит всё к чертям.

CI/CD — это не про сложные пайплайны, а про здравый смысл. Чем раньше начнёте, тем меньше будете тратить время на рутину.

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

А какие критерии удовлетворенности работы Кафкой вы бы взяли? Уже вторую итерацию сомневаюсь, что хорошие выбрал.

Хороший вопрос. Но давайте сразу разберёмся — а мы про что именно?

Есть два совершенно разных уровня:

👉 1. Технические SLA 👈

Это твоя зона ответственности. Здесь всё предельно скучно и конкретно:

- гарантия сохранности и доставки сообщений (с кучей сносок и оговорок)
- работоспособность коннекторов и интеграций (Debezium и прочие)
- живые алерты и мониторинг (если упало — узнали)
- что интерфейсы мониторинга реально что-то показывают
- что есть возможность внести изменения в конфиги без плясок с бубном

Тут надо оговориться, что сохранность сообщений это сложная тема. Ты не можешь отвечать за приёмку чужих данных полностью — максимум за то, что, получив, запишешь их надёжно и сколько-то подержишь. Почему-то не очевидно, что “пуля вылетела со стороны моего приложения” — ещё не значит, что она долетела до хранилища. И обязательно надо формализовть: срок хранения, объём, всяческие оговорки вроде что происходит если клиент нарушает соглашение.

👉 2. "Удовлетворённость клиентов" / “Что всё хорошо работает” 👈

Это вообще другой пласт. И тут люди хотят магии:

- ничего не падает
- данные всегда тянутся
- любую свою поделку можно интегрировать за вечер
- саппорт отвечает быстро и по делу

Но это не про технику. Это про сервис.

Если хочешь метрику уровня "довольны — не довольны", проведи регулярный опрос вида «Кафка — заебись?». Никаких цифр в прометее не будет, но будет политический актив: аргумент на встречи с руководством и способ строить отношения с командами.

А если хочешь, чтобы эта метрика улетела в небеса — начни раздавать всем денег, вот радости-то будет!

А теперь о том, что реально можно померить.

Если хочешь именно технические метрики:

- latency контрольного приложения, которое пишет и читает тестовое сообщение — покажет по сути погоду на марсе, но прикольную
- доступность маршрута от контрольного клиента до брокеров — зависит от кучи других людей типа сетевиков, но тоже ничего так погода на марсе
- процент зелёных health-check’ов — не говорит ни о чём само по себе, но пускай будет
- размеры очередей — важно, но на практике всё сильно зависит от клиента
- падения коннекторов — 99% не зависящих от тебя, но пускай будет

Зачем? Чтобы показать “как хорошо мы работаем”? Нет, ни в коем случае!

Эти метрики могут дать ВНУТРЕННЮЮ пищу для размышлений: чтобы понять, где пора разгребать SRE-долг, как повлияли принятые решения, где искать рут коз стрельнувшей проблемы.

У продуктовых команд своя сказка, с этими метриками ВООБЩЕ не связанная. Они могут страдать даже при зелёной панели в графане.

⚠️ Важная мысль ⚠️
"Чтобы все были довольны" — это не инженерная задача. Это политическая. Игра про ожидания и договорённости.

Если хочешь работать над "удовлетворённостью" всерьёз — начинай с вопросов:

- Что именно пользователь ждал?
- Чем ты реально можешь управлять?
- Где заканчивается твоя ответственность?
- Кто будет эти ожидания формулировать и транслировать?

Это уже не про Kafka, а про продуктовое управление и лидерство.

Потому что да, если Кафка падает и теряет данные — пользователи точно будут недовольны. Но если она не падает и не теряет — довольными их это не сделает автоматически. 😳

Всё остальное — коммуникация. И договорённости.

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