DevOps-инженер RecruitTech - Middle 100 - 150 тыс.

10 июля 2025 г. · 79 мин. чтения

Сегодня мы разберем собеседование, на котором интервьюер мягко, но последовательно проверяет базовые знания кандидата в архитектуре, DevOps-практиках, CI/CD и инфраструктуре как коде. В процессе диалога видно, что кандидат знаком с ключевыми инструментами (Ansible, Docker, GitLab CI), но часто теряется в терминологии и деталях, что превращает встречу в обучающую беседу с подсказками и разъяснениями со стороны интервьюера.

Вопрос 1. Как устроена архитектура современного веб-приложения при авторизации пользователя и какой путь проходит запрос, включая основные серверы и их роли?

Таймкод: 00:01:35

Ответ собеседника: неполный. Описал базовый сетевой путь (HTTP-запрос с клиента, динамический IP, NAT, DNS, запрос на сервер), но не раскрыл архитектуру приложения и роли ключевых компонентов (балансировщик, веб-сервер, backend, БД, кеш, и т.д.).

Правильный ответ:

Современная архитектура веб-приложения с авторизацией обычно многослойная и включает несколько ключевых компонентов. Важно понимать не только сетевой путь, но и ответственность каждого уровня.

Опишем типичный сценарий: пользователь открывает страницу логина, вводит логин/пароль, нажимает “Войти”.

Клиентский уровень (Browser / Mobile / SPA)

Пользовательский интерфейс: веб-приложение (HTML/JS/CSS), SPA (React/Vue/Angular), мобильное приложение.
Авторизационные данные:
- Логин/пароль через HTTPS POST.
- Либо уже сохраненный токен (JWT, session cookie).
Основные требования:
- Всегда HTTPS.
- Никаких секретов в localStorage в открытом виде бездумно; аккуратная работа с токенами.
- HttpOnly, Secure для cookie, если используется cookie-based auth.

DNS и сеть

DNS: по доменному имени (например, app.example.com) возвращает IP балансировщика или CDN.
Возможен:
- Anycast / GeoDNS / CDN для статики (JS, CSS, изображения).
- Отдельный домен/поддомен для API (api.example.com).

Это инфраструктурный уровень, он важен, но для собеседования по backend ключевое — дальнейшая обработка.

Балансировщик нагрузки (Load Balancer / Reverse Proxy) Основные роли:

Принимает входящие HTTPS-соединения.
Завершает TLS (TLS termination) — расшифровывает трафик.
Маршрутизирует запросы на один из backend-инстансов:
- по HTTP/HTTPS,
- с учетом health-check,
- с алгоритмом балансировки (round-robin, least connections, IP-hash и т.п.).
Может:
- Терминировать WebSocket,
- Декорировать заголовки (X-Forwarded-For, X-Request-ID),
- Ограничивать rate limit.

Примеры:

Nginx, HAProxy, Envoy, AWS ALB, GCP Load Balancer.

Edge / API Gateway (опционально, но часто используется) Перед backend-сервисами может стоять gateway.

Роли:

Авторизация и аутентификация:
- Проверка JWT.
- Проверка session cookie у SSO/IdP.
Rate limiting, throttling.
Routing:
- /api/auth → auth-service
- /api/user → user-service
Observability:
- Логирование, метрики, трейсинг.
Трансформация запросов/ответов (заголовки, формат).

Веб-сервер / Backend-приложение Это основной сервис, который реализует бизнес-логику авторизации.

Роли при логине:

Получить логин/пароль (по HTTPS, через gateway/balancer).
Найти пользователя в хранилище.
Проверить пароль:
- Никогда не хранить в открытом виде.
- Использовать безопасные алгоритмы (bcrypt, scrypt, Argon2).
При успешной аутентификации:
- Сгенерировать:
  - либо session-id и сохранить в session storage (БД/Redis),
  - либо JWT (access/refresh tokens),
- Вернуть клиенту:
  - session cookie (HttpOnly, Secure, SameSite),
  - или JWT в теле/заголовке (лучше cookie/secure-место).

В случае микросервисов:

Сервис авторизации (auth-service) отдельно.
Остальные сервисы доверяют токену (JWT) или проверяют session по централизованному хранилищу.

Пример простого обработчика логина на Go (session + bcrypt):

package main

import (
    "database/sql"
    "net/http"
    "time"

    _ "github.com/lib/pq"
    "golang.org/x/crypto/bcrypt"
)

type User struct {
    ID           int64
    Email        string
    PasswordHash string
}

func loginHandler(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        if r.Method != http.MethodPost {
            http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
            return
        }

        email := r.FormValue("email")
        password := r.FormValue("password")

        var u User
        err := db.QueryRow(
            "SELECT id, email, password_hash FROM users WHERE email = $1",
            email,
        ).Scan(&u.ID, &u.Email, &u.PasswordHash)
        if err == sql.ErrNoRows {
            http.Error(w, "invalid credentials", http.StatusUnauthorized)
            return
        } else if err != nil {
            http.Error(w, "internal error", http.StatusInternalServerError)
            return
        }

        if bcrypt.CompareHashAndPassword([]byte(u.PasswordHash), []byte(password)) != nil {
            http.Error(w, "invalid credentials", http.StatusUnauthorized)
            return
        }

        sessionID := generateSecureRandomString(32)
        _, err = db.Exec(
            "INSERT INTO sessions(id, user_id, expires_at) VALUES($1, $2, $3)",
            sessionID, u.ID, time.Now().Add(24*time.Hour),
        )
        if err != nil {
            http.Error(w, "internal error", http.StatusInternalServerError)
            return
        }

        cookie := &http.Cookie{
            Name:     "session_id",
            Value:    sessionID,
            Path:     "/",
            HttpOnly: true,
            Secure:   true,
            SameSite: http.SameSiteLaxMode,
        }
        http.SetCookie(w, cookie)

        w.WriteHeader(http.StatusOK)
        w.Write([]byte("ok"))
    }
}

Хранилища данных: БД и кеш

Основные сущности:
- users (логины, хеши паролей, статусы)
- sessions (если cookie-based sessions)
- tokens/refresh_tokens (если token-based auth)
- permissions/roles (RBAC/ABAC)

Пример простой схемы (PostgreSQL):

CREATE TABLE users (
    id           BIGSERIAL PRIMARY KEY,
    email        CITEXT UNIQUE NOT NULL,
    password_hash TEXT NOT NULL,
    is_active    BOOLEAN NOT NULL DEFAULT TRUE,
    created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE sessions (
    id          TEXT PRIMARY KEY,
    user_id     BIGINT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    expires_at  TIMESTAMPTZ NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_sessions_user_id ON sessions(user_id);
CREATE INDEX idx_sessions_expires_at ON sessions(expires_at);

Кеш (Redis, Memcached):

Используется для:
- хранения сессий,
- blacklist/whitelist токенов,
- rate limiting,
- кеширования пользовательских данных.
Требования:
- TTL,
- консистентность с БД для критичных вещей.

Авторизация (после аутентификации) Дальнейшие запросы пользователя (к защищенным ресурсам):

Приходят с:
- session cookie,
- или Authorization: Bearer <JWT>.
Обрабатываются:
- Gateway или backend валидирует:
  - подпись JWT,
  - срок действия,
  - права (роль/пермишены),
  - статус пользователя (активен или нет).
- При session-id:
  - ищем запись в session storage,
  - проверяем срок жизни,
  - поднимаем контекст пользователя.

Если токен/сессия валидны — запрос идет в бизнес-логику и далее в БД/кеш.

Безопасность и ключевые акценты

Всегда HTTPS.
HttpOnly + Secure для cookies.
Не хранить пароли — только хеши с солью (bcrypt/argon2).
Разделение ответственности:
- LB/gateway — сеть, маршрутизация, первичная проверка.
- Auth-сервис — аутентификация, токены.
- Бизнес-сервисы — авторизация на основе уже проверенной идентичности.
Масштабирование:
- stateless backend (JWT),
- или централизованный session storage для нескольких инстансов.

Итого: путь запроса при авторизации в современной архитектуре выглядит так: Client → DNS/CDN → Load Balancer/Reverse Proxy → (API Gateway) → Auth/Backend Service → DB/Redis → ответ клиенту с сессией или токеном → последующие запросы проходят через те же слои с проверкой авторизации.

Вопрос 2. Куда указывает DNS-запись веб-приложения как на входную точку инфраструктуры?

Таймкод: 00:04:04

Ответ собеседника: неполный. Предположил, что DNS-запись указывает на прокси-сервер, но не раскрыл общую картину и варианты.

Правильный ответ:

DNS-запись указывает на публичную точку входа в инфраструктуру, а не напрямую на backend-приложение или базу данных. Конкретная цель зависит от архитектуры и используемого окружения, но общая идея одна: домен (например, app.example.com) разрешается в IP-адрес или имя того компонента, который первым принимает внешний трафик и дальше маршрутизирует его внутрь системы.

Основные варианты:

Указание на внешний (edge) load balancer

Наиболее распространенный вариант в продакшене.
DNS-запись типа A/AAAA или CNAME указывает:
- либо на IP-адрес внешнего балансировщика нагрузки,
- либо на его DNS-имя, выданное облаком.

Примеры:

В облаках:
- app.example.com → CNAME → my-app-alb-123.aws.amazon.com (AWS ALB/NLB)
- app.example.com → CNAME → my-gclb.domain.com (GCP Load Balancer)
On-prem:
- app.example.com → A → 203.0.113.10 (IP железного/виртуального балансировщика, за которым уже стоят Nginx/HAProxy/Envoy и backend-сервисы).

Роль балансировщика:

Первое звено, принимающее HTTPS.
Маршрутизация на:
- reverse proxy,
- API gateway,
- конкретные backend-инстансы.
Health-check, отказоустойчивость, масштабирование.

Указание на reverse proxy / edge proxy Иногда балансировщик и reverse proxy совмещены:

app.example.com → A → IP сервера с Nginx/Envoy/HAProxy, который:
- терминирует TLS,
- проксирует запросы к backend-сервисам,
- может выступать как API gateway.

В этом случае прокси и есть ваша входная точка.

Указание на CDN / WAF / специализированный edge-сервис Для продвинутой инфраструктуры:

app.example.com → CNAME → app.example.com.cdn.cloudflare.net
www.example.com → CNAME → WAF/CDN-провайдера.

Тогда:

Edge-сервис:
- принимает трафик,
- фильтрует атаки (WAF, DDoS protection),
- кеширует статику,
- затем проксирует запросы к origin:
  - которым уже может быть балансировщик или reverse proxy.

Что важно понять концептуально

DNS не знает про backend-архитектуру (микросервисы, БД, кеши).
DNS всего лишь указывает на публичную входную точку:
- CDN/WAF,
- внешний load balancer,
- edge/reverse proxy.
Все остальное (маршрутизация по сервисам, авторизация, доступ к БД) происходит уже внутри инфраструктуры, после этой точки входа.

Краткая формулировка:

DNS-запись веб-приложения должна указывать на внешний балансировщик нагрузки или edge-прокси/ CDN/WAF, который является единой публичной точкой входа и далее распределяет запросы по внутренним сервисам.

Вопрос 3. Какие виды прокси- или балансировочных серверов используются в качестве входной точки?

Таймкод: 00:04:17

Ответ собеседника: неполный. Описывает прокси как средство изоляции внутреннего контура и выборочной публикации ресурсов, но не называет конкретные типы и решения, не раскрывает их роли и особенности.

Правильный ответ:

Входная точка в инфраструктуру — это обычно сочетание балансировщика нагрузки и reverse proxy/edge-прокси. Часто к ним добавляются WAF, API Gateway и CDN. Важно различать их роли и понимать, какие решения применяются на практике.

Ключевые типы и паттерны:

Reverse proxy (обратный прокси)

Стоит на периметре.
Принимает входящие HTTP/HTTPS-запросы от клиентов.
Проксирует их к внутренним сервисам.
Может:
- терминировать TLS,
- выполнять маршрутизацию по URI/хосту,
- добавлять/менять заголовки (X-Forwarded-For, trace ID),
- выполнять gzip, кеширование статического контента,
- отдавать статику,
- ограничивать размер запросов.

Типичные решения:

Nginx
Envoy
HAProxy
Apache HTTPD (mod_proxy), но реже для современных high-load API.

Часто reverse proxy и является вашей единой входной точкой (если нет внешнего LB/CDN).

L4/L7 load balancer (балансировщик нагрузки) Балансировщик может работать на разных уровнях:

L4-балансировщик:
- Работает на уровне TCP/UDP.
- Не анализирует HTTP-протокол.
- Просто распределяет соединения по backend-инстансам.
- Хорош для простоты и высокой производительности.
- Примеры: AWS NLB, TCP-режим HAProxy, железные F5, Google TCP/UDP Load Balancing.
L7-балансировщик:
- Понимает HTTP/HTTPS/WebSocket.
- Может маршрутизировать по:
  - Host (api.example.com / admin.example.com),
  - URI (/api, /static),
  - заголовкам, cookies.
- Подходит как интеллектуальная входная точка для веб-приложений и API.
- Примеры: AWS ALB, GCP HTTP(S) Load Balancer, Nginx, Envoy, HAProxy в HTTP-режиме, Traefik.

Во многих архитектурах:

Внешний L7/L4 LB → проксирует на пул reverse proxy / gateway → backend-сервисы.

API Gateway Логическое надстройка над reverse proxy/L7-LB, часто отдельный компонент.

Основные функции:

Маршрутизация API-запросов по сервисам.
Аутентификация и авторизация:
- проверка JWT,
- интеграция с OAuth2/OpenID Connect/SSO.
Rate limiting, quota, throttling.
Canary/blue-green деплой, A/B-тестирование.
Трансформация запросов/ответов:
- добавление/удаление заголовков,
- конвертация форматов.
Централизованный логинг, трейсинг, метрики.

Примеры:

Kong
KrakenD
Tyk
APISIX
AWS API Gateway
Nginx / Envoy / Traefik, настроенные как gateway.

На практике API Gateway часто является входной точкой для мобильных клиентов и внешних интеграций.

CDN и WAF как edge-уровень Не всегда, но часто первая видимая точка — это:

CDN (Content Delivery Network):
- кеширует статику (JS, CSS, изображения),
- может терминировать TLS,
- затем проксирует на origin (LB/proxy).
WAF (Web Application Firewall):
- фильтрует вредоносные запросы (SQLi, XSS, RCE-паттерны),
- защищает от бот-трафика,
- может интегрироваться с CDN/edge.

Примеры:

Cloudflare, Akamai, Fastly
AWS CloudFront + AWS WAF
Azure Front Door
Импортный/enterprise WAF.

Типичная связка входных точек Реальный продакшен обычно использует комбинацию:

Вариант 1 (облака):
- DNS → CDN/WAF → L7 Load Balancer → Nginx/Envoy (reverse proxy / gateway) → backend-сервисы.
Вариант 2 (on-prem / проще):
- DNS → Nginx/HAProxy (L7 reverse proxy + LB) → backend-приложения.
Вариант 3 (микросервисы, Kubernetes):
- DNS → Cloud LB → Ingress Controller (Nginx/Envoy/Traefik) → сервисы в кластере.

Голый backend как входная точка — плохая практика DNS, указывающий напрямую на приложение:

Лишает гибкости маршрутизации.
Усложняет масштабирование и смену версий.
Ухудшает безопасность (нет нормального периметра).
Не дает централизованных метрик, логов, rate limiting.

Минимальный пример конфигурации Nginx как входной точки

events {}

http {
    upstream app_backend {
        server 10.0.0.10:8080;
        server 10.0.0.11:8080;
    }

    server {
        listen 80;
        listen 443 ssl;
        server_name app.example.com;

        ssl_certificate     /etc/nginx/ssl/fullchain.pem;
        ssl_certificate_key /etc/nginx/ssl/privkey.pem;

        location / {
            proxy_pass http://app_backend;
            proxy_set_header Host              $host;
            proxy_set_header X-Real-IP         $remote_addr;
            proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

Итого, ответ:

В качестве входной точки обычно используются:
- L4/L7-балансировщики (облачные или софтверные),
- reverse proxy (Nginx, Envoy, HAProxy),
- API Gateway (как специализированный reverse proxy для API),
- плюс при необходимости CDN/WAF на самом внешнем уровне.
Они изолируют внутренний контур, дают масштабирование, безопасность, гибкую маршрутизацию и единое место для политики доступа и наблюдаемости.

Вопрос 4. Какие методы балансировки трафика между несколькими backend-серверами существуют?

Таймкод: 00:05:59

Ответ собеседника: неправильный. Не перечислил основные алгоритмы, не смог описать их работу; упоминание Round Robin прозвучало со стороны интервьюера.

Правильный ответ:

Для распределения нагрузки между несколькими backend-серверами используются различные алгоритмы балансировки. Выбор алгоритма влияет на производительность, устойчивость и предсказуемость системы. Ниже — ключевые методы, их особенности и где их разумно применять.

Основные алгоритмы балансировки:

Round Robin

Суть:
- Запросы равномерно по очереди распределяются по списку серверов:
  - 1-й запрос → сервер A
  - 2-й → сервер B
  - 3-й → сервер C
  - 4-й → снова сервер A
Плюсы:
- Простота, равномерность при одинаковой производительности серверов.
Минусы:
- Не учитывает текущую загрузку, время обработки запросов.
Применение:
- Однородные инстансы, stateless-сервисы, примерно одинаковая нагрузка на запрос.

Weighted Round Robin

Суть:
- Каждому серверу задается вес; чем больше вес, тем больше запросов он получает.
- Пример: A (вес 5), B (вес 1):
  - Примерно 5/6 запросов на A, 1/6 на B.
Плюсы:
- Можно учитывать разную мощность серверов.
Минусы:
- Все еще не учитывает фактическую текущую загрузку.
Применение:
- Гетерогенные сервера (разное железо, разные лимиты контейнеров).

Least Connections (наименьшее количество активных соединений)

Суть:
- Новый запрос направляется на сервер с наименьшим числом активных соединений.
Плюсы:
- Лучше распределяет нагрузку, чем Round Robin, при длительных запросах.
Минусы:
- Не всегда отражает реальную нагрузку (одно соединение может быть тяжелее другого).
Применение:
- Когда есть долгоживущие соединения (HTTP keep-alive, WebSocket, streaming).
- Когда время обработки существенно варьируется.

Weighted Least Connections

Суть:
- Комбинация веса и числа соединений:
  - учитывается и нагрузка, и относительная “мощность” сервера.
Плюсы:
- Более адекватное распределение в реальных системах.
Применение:
- Нагрузка неравномерна, сервера различаются по ресурсам.

IP Hash (Consistent Hash / Hash-based routing)

Базовый IP Hash:
- Сервер выбирается на основе хэша IP-адреса клиента.
- Один и тот же клиент (IP) стабильно попадает на один и тот же backend.
Продвинутая версия — Consistent Hashing:
- Хэшируется не только IP, но и, например, session id, user id, токен.
- При добавлении/удалении серверов перераспределяется только часть ключей.
Плюсы:
- Сессии “прилипают” к серверу без отдельного sticky-механизма.
- Полезно для stateful-систем (кеш на локальном сервере, без shared storage).
Минусы:
- Простая реализация IP Hash страдает при изменении числа серверов (массовое перераспределение).
Применение:
- Сессионные приложения без общего session storage.
- Кеш-кластеры, где важна предсказуемость размещения ключей.

Least Response Time / Latency-based

Суть:
- Балансировщик отправляет запрос на сервер с минимальным временем отклика или лучшими health-метриками.
Плюсы:
- Учитывает реальную производительность и задержку.
Минусы:
- Требует измерений и метрик, может быть нестабилен без сглаживания.
Применение:
- Глобальные нагрузки (multi-region), чувствительные к latency системы.

Random / Weighted Random

Суть:
- Сервер выбирается случайно (или с учетом веса).
Плюсы:
- Простота, при большом трафике дает статистически равномерное распределение.
Минусы:
- Без учета нагрузки; слабее, чем least-connections для неоднородных запросов.
Применение:
- Простые high-load сценарии, когда критична минимальная логика.

Sticky Sessions (Session Affinity) Это не отдельный метод распределения, а надстройка над алгоритмами.

Суть:
- Первый запрос распределяется по базовому алгоритму (например, Round Robin),
- Далее балансировщик “прилипает” пользователя к тому же серверу:
  - по cookie,
  - по IP,
  - по токену.
Плюсы:
- Позволяет использовать локальное состояние на backend'е (кеш, in-memory session).
Минусы:
- Неравномерная нагрузка,
- сложнее масштабировать и обновлять,
- отказ сервера приводит к потере сессий.
Рекомендация:
- В современных системах вместо sticky sessions — хранить сессии в Redis/БД или использовать JWT (stateless), чтобы backend оставался максимально stateless.

Примеры конфигураций (Nginx / HAProxy):

Round Robin (по умолчанию):

upstream backend {
    server 10.0.0.10:8080;
    server 10.0.0.11:8080;
}

Weighted Round Robin:

upstream backend {
    server 10.0.0.10:8080 weight=5;
    server 10.0.0.11:8080 weight=1;
}

IP Hash:

upstream backend {
    ip_hash;
    server 10.0.0.10:8080;
    server 10.0.0.11:8080;
}

Least Connections (HAProxy пример):

backend app_backend
    balance leastconn
    server app1 10.0.0.10:8080 check
    server app2 10.0.0.11:8080 check

Краткий вывод:

Базовые: Round Robin, Weighted Round Robin.
Для учета нагрузки: Least Connections, Weighted Least Connections, latency-based.
Для привязки пользователя/ключа к серверу: IP Hash / Consistent Hash.
Sticky sessions используются осторожно; предпочтительно проектировать backend stateless и хранить состояние во внешних хранилищах, что упрощает масштабирование и балансировку.

Вопрос 5. С какими системами управления базами данных есть практический опыт работы?

Таймкод: 00:06:51

Ответ собеседника: правильный. Уточнил, что имеет практический опыт работы с PostgreSQL.

Правильный ответ:

Корректный ответ — честно назвать те СУБД, с которыми есть реальный, осознанный опыт: проектирование схем, написание запросов, оптимизация, транзакции, индексы, миграции, работа в продакшене.

Если говорить о практическом опыте в контексте современных backend-приложений, обычно ценятся (и полезно уметь работать хотя бы с одной из):

Реляционные СУБД:
- PostgreSQL — де-факто стандарт для web/back-end:
  - богатый SQL-диалект,
  - транзакции, MVCC,
  - мощная работа с индексами,
  - JSONB, полнотекстовый поиск,
  - CTE, окна, расширения (pgcrypto, PostGIS).
- MySQL / MariaDB — популярны в legacy и high-load системах.
- MS SQL Server, Oracle — чаще в энтерпрайзе.
NoSQL / специальные хранилища (при необходимости):
- Redis — in-memory key-value для кеша, сессий, rate limiting.
- MongoDB — документное хранилище.
- ClickHouse, TimescaleDB и др. — аналитика, time-series.

Если кандидат называет только PostgreSQL — это абсолютно нормальный и достаточный ответ, при условии, что он уверенно владеет:

нормализацией схемы;
индексами (B-Tree, GIN/GiST для JSONB/FTS);
транзакциями и уровнями изоляции;
EXPLAIN/ANALYZE для оптимизации.

Пример типичного взаимодействия Go + PostgreSQL (database/sql + pgx):

import (
    "context"
    "database/sql"
    _ "github.com/jackc/pgx/v5/stdlib"
)

type User struct {
    ID    int64
    Email string
}

func GetUserByEmail(ctx context.Context, db *sql.DB, email string) (*User, error) {
    const q = `SELECT id, email FROM users WHERE email = $1`
    var u User
    err := db.QueryRowContext(ctx, q, email).Scan(&u.ID, &u.Email)
    if err == sql.ErrNoRows {
        return nil, nil
    }
    if err != nil {
        return nil, err
    }
    return &u, nil
}

И пример индекса под такой запрос:

CREATE INDEX idx_users_email ON users (email);

Кратко: правильный ответ — перечислить СУБД, с которыми реально работал (в данном случае PostgreSQL), и быть готовым углубиться в детали именно по ним.

Вопрос 6. К какому типу относится PostgreSQL и какие базовые виды баз данных существуют?

Таймкод: 00:07:05

Ответ собеседника: неполный. Верно указал, что PostgreSQL — реляционная база данных, но не раскрыл общую классификацию СУБД и другие их виды.

Правильный ответ:

PostgreSQL относится к классу реляционных СУБД (RDBMS), использующих реляционную модель данных и SQL как основной язык запросов. Это полнофункциональная транзакционная СУБД с поддержкой ACID, MVCC, сложных типов данных, расширений и развитого инструментарием для сложных запросов.

Однако в современной разработке важно понимать базовые виды хранилищ и их применимость.

Основные типы баз данных:

Реляционные базы данных (RDBMS)

Примеры: PostgreSQL, MySQL/MariaDB, MS SQL Server, Oracle.
Характеристики:
- Данные в таблицах (строки/столбцы).
- Строгая схема (schema-first).
- Первичные и внешние ключи, нормализация.
- Поддержка транзакций и ACID.
- Мощный SQL: JOIN, агрегаты, оконные функции, CTE.
Когда использовать:
- Критичные к целостности данные: финансы, биллинг, заказы, аккаунты, логины.
- Сложные запросы и связи между сущностями.
PostgreSQL:
- Сильная поддержка транзакций и конкурентного доступа (MVCC).
- Расширяемость: JSONB, массивы, пользовательские типы, функции на разных языках.
- Поддержка полнотекстового поиска, GIN/GiST индексов.
- Подходит как “универсальный” выбор для большинства веб-приложений.

Пример простой схемы в PostgreSQL:

CREATE TABLE users (
    id            BIGSERIAL PRIMARY KEY,
    email         CITEXT UNIQUE NOT NULL,
    password_hash TEXT NOT NULL,
    created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_users_email ON users (email);

Key-Value хранилища

Примеры: Redis, Memcached, Etcd, Consul.
Характеристики:
- Хранение данных в формате ключ → значение.
- Очень быстрый доступ по ключу.
- Часто in-memory; иногда с возможностью persistence.
Когда использовать:
- Кеш (результаты запросов, подготовленные ответы).
- Хранение сессий и токенов.
- Rate limiting, очереди, распределенные блокировки.
Не подходят для сложных запросов и связей.

Связка Go + Redis (частый кейс для сессий):

// пример: сохранить сессию
err := rdb.Set(ctx, "session:"+sessionID, userID, 24*time.Hour).Err()

Документные базы данных (Document Store)

Примеры: MongoDB, CouchDB, Firestore.
Характеристики:
- Данные в виде документов (JSON/BSON).
- Гибкая схема (schema-less / schema-flexible).
- Удобно для вложенных структур.
Когда использовать:
- Данные со “схемой, которая часто меняется”.
- Контентные системы, event-потоки, профили, где ограничений и связей меньше.
Минусы:
- Сложнее обеспечить строгую целостность,
- JOIN-ы ограничены или отсутствуют.

Column-oriented (колоночные) базы

Примеры: ClickHouse, Apache Cassandra (гибридно), Amazon Redshift, Vertica.
Характеристики:
- Хранение данных по колонкам.
- Эффективны для аналитики, агрегаций по большим объемам.
Когда использовать:
- BI, отчеты, лог-аналитика, метрики, большие выборки и агрегации.
Не оптимальны как primary storage для OLTP (обычной онлайн-транзакционной нагрузки).

Time-series (временные ряды)

Примеры: InfluxDB, TimescaleDB (над PostgreSQL), Prometheus (pull-модель).
Характеристики:
- Оптимизация под метрики, события во времени.
- Специальные индексы, компрессия, downsampling.
Когда использовать:
- Метрики сервисов, логирование, сенсоры, трекинг событий.

Графовые базы данных

Примеры: Neo4j, JanusGraph, Amazon Neptune.
Характеристики:
- Данные как узлы и ребра.
- Оптимизированы под графовые запросы (отношения, пути).
Когда использовать:
- Социальные графы, рекомендации, маршрутизация, сложные связи.

Поисковые движки (как отдельный класс, но часто используют как БД для поиска)

Примеры: Elasticsearch, OpenSearch, Solr.
Характеристики:
- Полнотекстовый поиск, скоринг, сложные фильтры.
Когда использовать:
- Поиск по тексту, логам, сложный фильтр + сортировка.

Ключевые акценты для собеседования:

PostgreSQL — реляционная ACID-СУБД общего назначения, часто основной выбор для backend-систем.
Важно уметь:
- выбирать тип хранилища под задачу,
- понимать trade-off’ы между RDBMS и NoSQL,
- не пытаться “запихнуть всё в Redis/Mongo”, когда нужны транзакции и строгая модель.
Типичная продакшн-архитектура:
- PostgreSQL как primary storage,
- Redis как кеш / сессии / rate limiting,
- специализированные хранилища (ClickHouse/Elasticsearch) для аналитики и поиска при необходимости.

Вопрос 7. Какие особенности PostgreSQL или реляционных баз данных можешь описать (области применения, кластеризация и прочее)?

Таймкод: 00:07:42

Ответ собеседника: неполный. Упомянул, что PostgreSQL поддерживает кластеризацию, и попытался говорить про синхронные/асинхронные запросы, но неточно и без объяснения механизмов, признал, что не готов раскрыть тему подробно.

Правильный ответ:

PostgreSQL — мощная реляционная СУБД общего назначения, подходящая как основной фундамент для большинства веб-, финансовых и корпоративных систем. Важно понимать не только “это реляционная база”, но и ключевые свойства: модель данных, транзакционность, механизмы конкурентного доступа, репликацию, масштабирование и области применения.

Разберем основные аспекты.

Основы реляционной модели и области применения

Реляционная модель:
- Данные представлены в виде таблиц (отношений) со строгой схемой.
- Используются первичные ключи, внешние ключи, ограничения (UNIQUE, CHECK, NOT NULL).
- Поддерживаются JOIN, сложные запросы, агрегации, оконные функции, CTE.
Типичные сценарии:
- Финансовые операции (биллинг, платежи).
- CRM/ERP, учетные системы, логины/права доступа, заказы, инвентарь.
- Любые системы, где критичны:
  - целостность данных,
  - строгие инварианты,
  - транзакции,
  - аудит.

Транзакции, ACID и уровни изоляции

PostgreSQL — транзакционная СУБД с полным ACID:

Atomicity: либо вся транзакция, либо ничего.
Consistency: данные удовлетворяют ограничениям до и после транзакции.
Isolation: параллельные транзакции логически изолированы.
Durability: после COMMIT данные сохраняются надежно.

Уровни изоляции PostgreSQL:

Read Committed (по умолчанию) — каждое чтение видит только зафиксированные изменения на момент оператора.
Repeatable Read — внутри транзакции вы видите “снимок” данных; защита от non-repeatable read, но возможны некоторые аномалии только при сложных сценариях.
Serializable — обеспечивает поведение, эквивалентное последовательному выполнению транзакций (через Serializable Snapshot Isolation).

Важно:

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

Пример транзакции в Go с PostgreSQL:

func Transfer(ctx context.Context, db *sql.DB, fromID, toID int64, amount int64) error {
    tx, err := db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelSerializable})
    if err != nil {
        return err
    }
    defer tx.Rollback()

    var fromBalance int64
    if err := tx.QueryRowContext(ctx,
        `SELECT balance FROM accounts WHERE id = $1 FOR UPDATE`, fromID,
    ).Scan(&fromBalance); err != nil {
        return err
    }

    if fromBalance < amount {
        return fmt.Errorf("insufficient funds")
    }

    if _, err := tx.ExecContext(ctx,
        `UPDATE accounts SET balance = balance - $1 WHERE id = $2`,
        amount, fromID,
    ); err != nil {
        return err
    }

    if _, err := tx.ExecContext(ctx,
        `UPDATE accounts SET balance = balance + $1 WHERE id = $2`,
        amount, toID,
    ); err != nil {
        return err
    }

    return tx.Commit()
}

Ключевые фичи PostgreSQL

MVCC (Multi-Version Concurrency Control):
- Обеспечивает конкурентный доступ без глобальных read-lock.
- Читающие запросы не блокируют пишущие и наоборот (в типичных сценариях).
- Для DBA и разработчика важно:
  - следить за autovacuum,
  - проектировать запросы и индексы так, чтобы избегать долгих блокировок.
Богатый набор типов:
- JSONB, массивы, hstore, геоданные (через PostGIS), ENUM, композитные типы.
- Позволяет гибко моделировать данные, сочетая “строгую” модель с гибкостью.
Расширяемость:
- Пользовательские функции (SQL, PL/pgSQL, Python, другие языки).
- Индексы разных типов: B-Tree, GIN, GiST, BRIN, Hash.
- Расширения (extensions): PostGIS, pgcrypto, uuid-ossp, TimescaleDB и т.д.

Индексы и производительность (то, что ожидают понимать уверенно)

Индексы:
- Ускоряют выборки по WHERE, JOIN, ORDER BY.
- Замедляют вставки/обновления → балансируем.
Типичные индексы:
- B-Tree (по умолчанию) — равенство и диапазоны.
- GIN — JSONB, полнотекстовый поиск.
- GiST — геоданные, сложные структуры.
Простой пример:

CREATE INDEX idx_orders_user_created_at
    ON orders (user_id, created_at DESC);

Анализ производительности:
- EXPLAIN (ANALYZE, BUFFERS) для поиска медленных мест.
- Избегать N+1 запросов на уровне приложения; использовать JOIN, IN, CTE.

Репликация, кластеризация и масштабирование

Важно разделить понятия:

Репликация (master/primary → replica/standby)

Логическая/физическая репликация.
Основной сценарий:
- Primary принимает запись (INSERT/UPDATE/DELETE, DDL).
- Standby получает WAL (журнал транзакций) и применяет изменения.
Режимы:
- Асинхронная репликация:
  - Primary не ждет подтверждения от реплик.
  - Быстрее, но при сбое части данных может не оказаться на реплике.
- Синхронная репликация:
  - COMMIT считается успешным только после подтверждения от одной или нескольких реплик.
  - Гарантирует отсутствие потерь (в рамках настройки), но увеличивает задержку.
Зачем:
- Масштабирование чтения (read-replicas).
- Повышение отказоустойчивости (failover).

Пример типичного паттерна:

Primary для записи.
Несколько read-replica для:
- аналитики,
- тяжелых SELECT,
- бэкендов, которым не критичны миллисекунды задержки.

Кластеризация и распределенные решения

Сам PostgreSQL — не “шардинг из коробки”.
Для горизонтального масштабирования по шардам:
- Citus (горизонтальный шардинг поверх PostgreSQL),
- Patroni/PGPool-II/Barman/etc. для управления кластерами и failover.
Подход:
- масштабироваться вертикально до разумного предела,
- использовать реплики для чтения,
- выносить тяжелую аналитику в отдельные системы (ClickHouse, аналитический кластер),
- при экстремальных требованиях — шардинг (Citus или кастомное решение).

High Availability (HA)

Типичные компоненты:
- репликация + автоматический failover,
- виртуальный IP / консенсус (Etcd/Consul) / orchestrator.
Цель:
- минимизировать downtime при падении primary.

Типичное взаимодействие backend-сервиса:

Приложение знает:
- DSN primary (для записи) и DSN replica (для чтения),
- или использует proxy (PgBouncer, HAProxy), который маршрутизирует.
В Go:
- Можно использовать пул подключений,
- Разделять read/write запросы на разные пулы.

Trade-off’ы и практические замечания

PostgreSQL отлично подходит как:
- основное хранилище для критичных данных,
- источник правды (source of truth).
Масштабирование:
- сначала: индексы, запросы, нормализация, кеширование (Redis),
- затем: read-replicas,
- потом: шардинг/специализированные хранилища.
Нельзя “лечить все NoSQL’ом”: если нужны транзакции и строгая модель — PostgreSQL (или другая RDBMS) предпочтительнее.
Важно как разработчику:
- понимать, как ваша модель данных и запросы влияют на блокировки, планы выполнения, нагрузку на диск/память,
- уметь читать EXPLAIN и использовать индексы осознанно.

Краткая емкая формулировка для интервью:

PostgreSQL — транзакционная реляционная СУБД с ACID и MVCC, мощным SQL, расширяемостью и развитой поддержкой репликации. Активно используется как основное хранилище для бизнес-критичных данных, поддерживает master-standby репликацию (синхронную/асинхронную), масштабирование чтения через read-replicas, интеграцию с внешними инструментами для HA и шардинга, и обладает богатым набором типов и индексов для сложных сценариев.

Вопрос 8. Насколько корректно использовать базу данных в виде Docker-контейнера в продуктивной среде?

Таймкод: 00:08:56

Ответ собеседника: частично правильный. Правильно указал на риск потери данных при использовании контейнера без volume и отметил уместность контейнеров для тестовой среды. Однако сделал чрезмерно категоричный вывод, что запуск БД в контейнере в продакшене — «плохая практика» вообще, не учитывая грамотные варианты использования.

Правильный ответ:

Ключевая мысль: использование PostgreSQL (и других СУБД) в Docker в продакшене само по себе не является ни “плохой”, ни “хорошей” практикой. Всё зависит от того, как именно это сделано. Некорректно — поднимать “голый” контейнер без персистентного хранилища и мониторинга. Корректно — использовать контейнеры как часть продуманной инфраструктуры: с volume, orchestration, observability, резервным копированием и т.д.

Разберем по уровням.

Когда использование Docker для БД — плохая практика

Плохо и опасно, если:

Данные хранятся внутри контейнера (в слое файловой системы образа):
- при пересоздании контейнера данные теряются;
- нет четко выстроенной стратегии бэкапов и восстановления.
Нет выделенного персистентного volume:
- не используется host volume, LVM/ZFS, сетевое хранилище или managed storage.
Отсутствует:
- мониторинг (CPU/IO/locks/replication lag),
- логирование,
- лимиты ресурсов и контроль overcommit.
Контейнеры перезапускаются хаотично “как есть”, без учета роли БД как stateful-сервиса.
Используется “для удобства” вместо нормальной настройки продакшн-контура.

Такой паттерн уместен только для:

локальной разработки;
unit/integration тестов;
временных окружений (ephemeral env).

Когда запуск БД в контейнере — нормальная и зрелая практика

Современные продакшн-инфраструктуры активно используют контейнеризацию для stateful-сервисов, включая PostgreSQL, при соблюдении ряда принципов:

Персистентное хранилище

Все данные БД вынесены на:
- Docker volume, привязанный к директории данных (/var/lib/postgresql/data),
- или на отдельный диск/RAID/LVM/ZFS,
- или на сетевое/облачное хранилище (EBS, PersistentVolume в Kubernetes).
Перезапуск контейнера не влияет на целостность данных.

Пример (упрощенно):

docker run -d \
  --name pg \
  -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:16

Ключевое: именно volume отвечает за сохранность данных, а контейнер становится “процессом” БД.

Управление и оркестрация

Корректные варианты:

Kubernetes StatefulSet + PersistentVolume:
- стабильные имена pod-ов,
- persistent volumes,
- контролируемые обновления.
Docker Swarm / Nomad при наличии продуманного stateful-паттерна.
Использование специализированных операторов:
- Patroni, Zalando Postgres Operator, CrunchyData, Bitnami Charts:
  - автоматический failover,
  - репликация,
  - бэкапы, конфигурация.
Proxy-слой и service discovery:
- HAProxy/Envoy/PgBouncer для подключения приложений к актуальному primary/replica.

Репликация, отказоустойчивость, бэкапы

Обязательные элементы для продакшена:

Репликация:
- primary + standbys (контейнеры с собственными volume).
Бэкапы:
- logical dumps (pg_dump),
- physical backups (pg_basebackup, WAL archiving, pgBackRest, Barman).
Стратегия восстановления:
- point-in-time recovery (PITR).
Health-check и автоматический failover.

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

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

выделять CPU/memory (requests/limits в Kubernetes),
понимать влияние cgroup-лимитов на планировщик PostgreSQL,
следить за дисковой подсистемой:
- IOPS, latency,
- журналы WAL,
- fsync, write barriers.
Использовать hostPath / direct volume / локальные SSD для критичных данных, а не медленное сетевое хранилище “по умолчанию”, если оно не подходит по latency.

Аргумент “DB не место в Docker” устарел

Современный подход:

“DB не в контейнере” → часто означает ту же самую виртуализацию (VM), просто без Docker.
При корректной конфигурации:
- контейнеризация дает:
  - воспроизводимость,
  - декларативную конфигурацию,
  - более простой CI/CD,
  - унифицированный operational-подход.
Однако:
- к БД предъявляются особые требования: storage, SLA, HA.
- Поэтому либо:
  - используют managed решения (RDS, Cloud SQL, Aurora, AlloyDB) — это “чужой” оркестратор поверх тех же идей,
  - либо свой кластер PostgreSQL в Kubernetes/VM с оператором и продуманной архитектурой.

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

Для собеседования разумная позиция звучит так:
- Использовать PostgreSQL в Docker в продакшене можно и это нормально, если:
  - данные вынесены на надежное persistent storage,
  - есть репликация, бэкапы, мониторинг,
  - запуск контролируется оркестратором (Kubernetes, Docker Swarm, Nomad) или грамотным скриптингом.
- Нельзя полагаться на ephemeral-контейнер “из коробки” без volume и без обеспечения надежности.
- Во многих случаях проще и надежнее использовать managed PostgreSQL (RDS/Cloud SQL), а контейнеры оставить для приложения.

Краткая формулировка:

Плохо: “поднять postgres в docker run без volume и считать это продакшеном”.
Нормально/правильно: использовать PostgreSQL в контейнерах как часть продуманной stateful-инфраструктуры с persistent volume, репликацией, бэкапами и мониторингом, либо использовать managed-сервисы облака.

Вопрос 9. Что знаешь про индексы в базах данных и их влияние на работу запросов?

Таймкод: 00:09:35

Ответ собеседника: неполный. Верно отметил, что индексы упрощают поиск и хранятся как отдельная структура, но некорректно описал минусы и не назвал реальные причины замедления (стоимость поддержки индексов при записи, избыток индексов, влияние на планировщик). Не упомянул разные типы индексов и связанные механизмы (в т.ч. материализованные представления).

Правильный ответ:

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

Однако индексы — это не “бесплатное ускорение всего”: они занимают место и замедляют операции записи (INSERT/UPDATE/DELETE). Зрелый подход — осознанно проектировать индексы под реальные запросы.

Базовые принципы

Без индекса:
- СУБД вынуждена делать последовательное сканирование таблицы (Seq Scan).
- Это приемлемо для маленьких таблиц, но не для миллионов строк.
С индексом:
- Для подходящих запросов используется Index Scan/Index Only Scan.
- Время поиска переходит от O(N) к O(log N) (для B-деревьев) или около того.
- Особенно эффективно для фильтров, JOIN-ов и сортировок по индексированным столбцам.

Структура индексов (на примере PostgreSQL)

Чаще всего используются:

B-Tree индекс (по умолчанию)

Оптимален для:
- условий равенства (=),
- диапазонов (<, <=, >, >=, BETWEEN),
- сортировки (ORDER BY).
Пример:

CREATE INDEX idx_users_email ON users(email);

Этот индекс:

ускорит запросы:
- SELECT ... FROM users WHERE email = $1
- SELECT ... WHERE email > 'a@x.com'
может использоваться для ORDER BY email.

GIN и GiST индексы

Используются для сложных типов:
- JSONB, массивы, полнотекстовый поиск, геоданные.
Примеры:
- Полнотекстовый поиск:

CREATE INDEX idx_docs_fts
    ON documents
USING GIN (to_tsvector('simple', content));

JSONB:

CREATE INDEX idx_users_data ON users USING GIN (data);

BRIN

Эффективен для очень больших таблиц, где данные “кластеризованы” по диапазонам (time-series, логи).
Очень легкий, но менее точный; СУБД всё равно дочитывает блоки.

Уникальные индексы

Гарантируют уникальность значений.
Пример:

CREATE UNIQUE INDEX idx_users_email_unique ON users(email);

Это даёт:

быстрый поиск по email,
гарантию уникальности (альтернатива UNIQUE в определении таблицы).

Как индексы ускоряют запросы

Примеры (PostgreSQL):

SELECT * FROM users WHERE email = 'test@example.com';

Без индекса:
- Seq Scan по всей таблице.
С индексом по email:
- Index Scan: быстро находим нужные строки по дереву индекса.

JOIN:

SELECT o.*
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE u.email = 'test@example.com';

Индекс по users(email) ускорит поиск пользователя.
Индекс по orders(user_id) ускорит выборку заказов по найденному пользователю.

Индексы и сортировка:

SELECT * FROM orders
WHERE user_id = 123
ORDER BY created_at DESC
LIMIT 20;

Композитный индекс:

CREATE INDEX idx_orders_user_created_at
    ON orders (user_id, created_at DESC);

Позволяет выполнить запрос через Index Scan без дополнительной сортировки.

Стоимость и минусы индексов (ключевое, что часто забывают)

Замедление операций записи Каждое изменение данных должно:

обновить не только таблицу, но и все индексы, в которые входит изменяемый столбец. Влияет на:
INSERT — вставка новых записей → обновление всех связанных индексов.
UPDATE — особенно если меняются индексируемые колонки.
DELETE — удаление записей из индексов.

Вывод:

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

Дополнительное место на диске

Индексы могут занимать сопоставимый или больший размер, чем сама таблица.
Важно:
- чистить неиспользуемые индексы,
- анализировать pg_stat_user_indexes / pg_stat_all_indexes.

Влияние на планировщик запросов

СУБД сама выбирает, использовать ли индекс:
- если условие малоселективно (например, WHERE is_active = true для 95% строк), то индекс может быть дороже, чем Seq Scan.
Неправильные индексы:
- не используются (мусор),
- или заставляют планировщик принимать неоптимальные решения, если статистика устарела.

Практика:

Регулярно обновлять статистику (ANALYZE).
Смотреть EXPLAIN/EXPLAIN ANALYZE.

Материализованные представления (связанный инструмент оптимизации)

Материализованное представление — это сохранённый результат запроса (как “закешированная таблица”), который:

может иметь индексы;
требует явного REFRESH.

Используется:

для тяжелых агрегатов/репортинга;
когда делать сложный JOIN/агрегации на лету слишком дорого.

Пример:

CREATE MATERIALIZED VIEW mv_user_stats AS
SELECT user_id,
       count(*) AS orders_count,
       max(created_at) AS last_order_at
FROM orders
GROUP BY user_id;

CREATE INDEX idx_mv_user_stats_user_id ON mv_user_stats(user_id);

Применение:

Быстрые запросы статистики по user_id без тяжелых агрегаций каждый раз.
Но нужно планировать обновление: REFRESH MATERIALIZED VIEW CONCURRENTLY mv_user_stats;.

Лучшие практики проектирования индексов

Проектировать индексы под реальные запросы:
- сначала понять частые WHERE/JOIN/ORDER BY,
- потом создавать минимальный набор индексов.
Использовать композитные индексы осознанно:
- порядок колонок важен:
  - (user_id, created_at) покрывает WHERE user_id = ? и сортировку по created_at для этого user_id,
  - но не оптимален для фильтрации только по created_at.
Не дублировать индексы:
- уникальный индекс по (email) делает отдельный неуникальный индекс по (email) бессмысленным.
Регулярно проверять:
- какие индексы реально используются (pg_stat_user_indexes),
- какие никогда не используются — кандидаты на удаление.

Краткая формулировка для интервью:

Индексы — это отдельные структуры (B-Tree/GIN/GiST/и т.д.), которые ускоряют поиск, фильтрацию, JOIN и сортировку за счет уменьшения числа просматриваемых строк.
Они не бесплатны: каждый индекс замедляет операции записи и потребляет диск.
Грамотное использование индексов требует:
- понимания паттернов запросов,
- минимального, но достаточного набора индексов,
- анализа планов запросов (EXPLAIN),
- контроля избыточных индексов.
Материализованные представления + индексы поверх них — мощный инструмент оптимизации сложных отчетов и агрегатов.

Вопрос 10. Что такое репликация базы данных и как она соотносится со схемой мастер-реплика?

Таймкод: 00:10:21

Ответ собеседника: неправильный. Фактически описал репликацию как разовый бэкап, не раскрыл идею постоянного потока изменений с ведущего сервера на реплики и не объяснил роль схемы мастер-реплика.

Правильный ответ:

Репликация базы данных — это непрерывная или почти непрерывная передача изменений с одного экземпляра базы данных (обычно называемого primary/leader/master) на один или несколько других экземпляров (standby/replica/follower). Цель — иметь актуальные копии данных для:

повышения отказоустойчивости (HA),
масштабирования чтения (read scaling),
возможности быстрого failover,
разделения продакшн-нагрузки (OLTP) и тяжёлых аналитических запросов.

Важно: репликация — это не разовый бэкап. Бэкап — статичный снимок на момент времени; реплика — живой экземпляр, который постоянно получает и применяет изменения.

Базовая схема: мастер-реплика (primary-replica)

Классический паттерн:

Primary (master):
- Единственный (или логический лидер), принимающий операции записи:
  - INSERT, UPDATE, DELETE, DDL.
- Фиксирует изменения в журнале (например, WAL в PostgreSQL).
Replica (standby):
- Получает поток изменений с primary:
  - физическая репликация (WAL-блоки),
  - или логическая (на уровне транзакций/строк).
- Применяет их, поддерживая состояние максимально близким к primary.
- Обычно:
  - разрешены только чтения (SELECT),
  - записи ограничены или запрещены (в контексте тех же данных).

Взаимосвязь с master-replica:

Модель master-replica (primary-standby) — это конкретный способ организации репликации:
- один узел — источник истины для записей,
- один или несколько узлов — его реплики.
Репликация обеспечивает:
- доставку изменений от master к replica,
- консистентность на уровне настроенной семантики (синхронная/асинхронная).

Синхронная vs асинхронная репликация

Асинхронная репликация:

Primary считает транзакцию зафиксированной, не дожидаясь подтверждения от реплик.
Плюсы:
- минимальное влияние на latency записи,
- лучше производительность.
Минус:
- при падении primary возможно небольшое окно потери данных:
  - некоторые коммиты не успели доехать до реплик.

Синхронная репликация:

Primary считает транзакцию успешно зафиксированной только после того, как хотя бы одна (или заданное число) реплик подтвердит прием изменений.
Плюсы:
- минимизация/исключение потери данных при failover на синхронную реплику.
Минусы:
- увеличение задержки записи (latency),
- зависимость от доступности реплик.

Типовые задачи, которые решает репликация

Масштабирование чтения:
- Чтения (репорты, аналитика, часть user-facing SELECT) отправляем на реплики.
- Записи продолжаем слать на primary.
- Пример:
  - API для профиля/баланса читает с primary (строгая консистентность),
  - отчетные сервисы читают с реплик (realtime не критичен, допустим небольшой lag).
Высокая доступность (High Availability):
- При падении primary:
  - одна из реплик может быть автоматически/promoted в новый primary.
- Используются:
  - оркестраторы (Patroni, repmgr, pg_auto_failover),
  - виртуальные IP или service discovery,
  - прокси-слои (PgBouncer/HAProxy/Envoy), умеющие переключаться на новый primary.
Разделение нагрузок:
- Primary — для транзакций.
- Реплики — для тяжёлых SELECT, аналитики, долгих репортов, backup-операций.

Пример на уровне концепции PostgreSQL

Primary:
- пишет изменения в WAL.
Standby:
- читает WAL (streaming replication),
- применяет изменения к своей копии данных.
В конфигурации можно задать:
- synchronous_standby_names — список реплик для синхронной репликации.
- hot_standby = on — разрешить запросы на чтение из реплики.

Важно понимать для собеседования:

Репликация — это:
- непрерывное, потоковое отражение изменений,
- механизм, обеспечивающий актуальные живые копии,
- ключевой элемент HA и масштабирования чтения.
Master/primary:
- единственная точка записи (в классической схеме).
Replica/standby:
- копия, синхронизируемая с master,
- обычно только для чтения, резерв и/или источник для failover.
Репликация не заменяет бэкапы:
- ошибка или удаление на primary реплицируется на реплики.
- Нужны отдельные бэкап-стратегии (snapshots, WAL-архивация, PITR).

Краткая формулировка:

Репликация — это механизм постоянного применения изменений с primary на replica.
Схема master-реплика — конкретный паттерн, в котором один узел принимает записи, а остальные синхронно или асинхронно повторяют его состояние и используются для чтения и отказоустойчивости.

Вопрос 11. Что известно о брокерах очередей и брокерах сообщений (например, Kafka, MQ)?

Таймкод: 00:11:07

Ответ собеседника: неправильный. Сообщает, что ничего об этом не знает.

Правильный ответ:

Брокеры сообщений и очередей — ключевой строительный блок современных распределенных систем. Они используются для асинхронного взаимодействия между сервисами, разгрузки пиков нагрузки, интеграции с внешними системами и построения event-driven архитектур.

Идея в том, что отправитель (producer/publisher) и получатель (consumer/subscriber):

не зависят напрямую друг от друга;
не обязаны быть доступны одновременно;
взаимодействуют через посредника — брокер сообщений.

Это повышает отказоустойчивость, масштабируемость и упрощает эволюцию архитектуры.

Основные концепции

Asynchronous messaging

Вместо прямого вызова HTTP-сервиса:
- сервис A отправляет сообщение в очередь/топик,
- сервис B читает и обрабатывает его, когда готов.
Преимущества:
- декуплинг (слабая связанность),
- возможность буферизовать нагрузку,
- устойчивость к временным сбоям потребителей.

Очереди (Message Queue)

Классическая модель:
- producer → очередь → consumer.
Обычно:
- сообщение читается и “забирается” (consume and remove),
- один конкретный consumer в группе обрабатывает конкретное сообщение.
Гарантии:
- at-least-once / at-most-once / exactly-once (в разных реализациях, с нюансами).
Примеры:
- RabbitMQ, ActiveMQ, IBM MQ, AWS SQS, NATS JetStream (частично).

Топики и pub/sub

Паблишер пишет в топик.
Несколько подписчиков (subscribers) могут получать копии сообщений.
Подходит для:
- событийной шины (event bus),
- широковещательной доставки: логирование, нотификации, реакция разных сервисов на одно событие.

Kafka и классические MQ: ключевые различия

Apache Kafka

Лог-ориентированная распределенная система:
- сообщения хранятся в разделах (partitions) топиков как упорядоченный лог;
- по умолчанию сообщения не удаляются сразу после чтения, а живут до retention-политики.
Масштабирование:
- партиционирование топиков,
- consumer group:
  - в группе каждое сообщение обрабатывается ровно одним consumer'ом,
  - но разные группы могут читать одно и то же независимо.
Гарантии и семантика:
- высокая пропускная способность,
- устойчивость, репликация данных между брокерами,
- управление смещениями (offsets) на стороне consumer'ов.
Типичные кейсы:
- event sourcing,
- логирование и аналитика,
- потоковая обработка (stream processing),
- интеграция микросервисов через доменные события.

RabbitMQ / классические MQ

Реализуют различные модели:
- очереди, маршрутизация через exchange,
- pub/sub, routing keys, topic exchange, fanout, direct.
Сообщения после подтверждения обработки (ACK) обычно удаляются из очереди.
Подходит для:
- task queue (фоновые задания),
- RPC over MQ,
- workflow-системы.

IBM MQ, ActiveMQ, AWS SQS и др.

Различаются по:
- протоколам (AMQP, JMS, собственные),
- гарантиям доставки,
- SLA, управляемости.
Но концептуально: все они — брокеры, обеспечивающие доставку сообщений между сервисами.

Зачем использовать брокер сообщений в архитектуре

Декуплинг сервисов:
- сервис-отправитель не знает подробностей о получателе,
- можно добавлять новых потребителей без изменения продьюсера.
Масштабирование:
- консюмеры горизонтально масштабируются, читая из одной очереди/топика.
Буферизация нагрузки:
- при пиках сообщений копятся в брокере,
- consumers обрабатывают с максимально доступной скоростью.
Надежность:
- при падении consumer'а сообщения не теряются (при корректной конфигурации).
Event-driven архитектуры:
- каждый важный бизнес-событий (user_registered, order_created) публикуется в топик,
- разные сервисы реагируют независимо (email, биллинг, аналитика и т.д.).

Пример паттерна с Kafka / MQ

Сценарий: сервис заказов создает заказ, сервис биллинга должен списать деньги, сервис нотификаций — отправить письмо.

Без брокера:
- Orders сервис синхронно дергает Billing и Notifications по HTTP:
  - сильная связанность,
  - цепочка отказов, рост latency.
С брокером:
- Orders публикует событие order_created в Kafka / MQ.
- Billing сервис подписан на order_created и обрабатывает платеж.
- Notifications сервис подписан на order_created и шлет e-mail.
- Добавить новые реакции (логирование, аналитика) можно просто подписав новые сервисы.

Пример кода на Go (упрощенный)

Отправка сообщения в Kafka (segmentio/kafka-go):

import (
    "context"
    "log"
    "github.com/segmentio/kafka-go"
)

func produceOrderCreated(brokerAddr, topic string, msg []byte) error {
    w := &kafka.Writer{
        Addr:     kafka.TCP(brokerAddr),
        Topic:    topic,
        Balancer: &kafka.LeastBytes{},
    }
    defer w.Close()

    return w.WriteMessages(context.Background(),
        kafka.Message{Value: msg},
    )
}

Чтение сообщений:

func consumeOrderCreated(brokerAddr, topic, groupID string) {
    r := kafka.NewReader(kafka.ReaderConfig{
        Brokers: []string{brokerAddr},
        Topic:   topic,
        GroupID: groupID,
    })
    defer r.Close()

    for {
        m, err := r.ReadMessage(context.Background())
        if err != nil {
            log.Printf("read error: %v", err)
            continue
        }
        log.Printf("received: %s", string(m.Value))
        // здесь бизнес-логика обработки события
    }
}

Ключевые моменты, которые стоит проговаривать на интервью:

Брокер сообщений:
- посредник между сервисами для асинхронной доставки сообщений.
Основные модели:
- очередь (point-to-point),
- pub/sub (broadcast, топики).
Kafka:
- распределенный лог, высокая пропускная способность, хранение истории.
RabbitMQ / MQ:
- гибкая маршрутизация, задачи, очереди, более традиционный message queue.
Зачем:
- размыкать прямые зависимости,
- улучшать отказоустойчивость,
- сглаживать пики,
- строить event-driven архитектуры.

Даже если нет практического опыта, важно понимать концепции и уметь объяснить, зачем это нужно и в каких сценариях применяется.

Вопрос 12. Что знаешь о подходе инфраструктура как код?

Таймкод: 00:11:24

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

Правильный ответ:

Инфраструктура как код (Infrastructure as Code, IaC) — это подход, при котором серверы, сети, балансировщики, БД, очереди, секреты, права доступа и прочие инфраструктурные ресурсы описываются и управляются декларативно или программно, как исходный код. Вместо ручного кликанья в консолях и SSH-настройки серверов мы храним конфигурацию в репозитории, под версионным контролем, с код-ревью, автоматизацией и воспроизводимостью.

Ключевая идея: инфраструктура становится детерминируемой, повторяемой и проверяемой так же, как приложение.

Основные принципы IaC

Декларативность:
- Описываем желаемое состояние (что должно быть), а не пошаговые инструкции (как это создать).
- Пример: “у меня должно быть 3 инстанса приложения за балансировщиком, RDS PostgreSQL, S3-бакет” — а не “зайди в консоль AWS и накликай”.
Идемпотентность:
- Повторный запуск одного и того же описания приводит инфраструктуру к одному и тому же состоянию, без побочных эффектов.
- Это критично для безопасных обновлений.
Версионирование:
- Конфигурация хранится в Git:
  - можно проследить изменения,
  - откатиться,
  - делать code review,
  - применять GitOps-подход.
Автоматизация:
- Развертывание, обновление, уничтожение ресурсов выполняется автоматически:
  - CI/CD pipeline,
  - GitOps (ArgoCD/Flux),
  - инфраструктурные пайплайны.
Одинаковые окружения:
- dev/stage/prod описываются одинаковыми шаблонами:
  - меньше “у меня работает, а в проде нет”.
  - различия сведены к переменным (размеры, адреса, учетные данные).

Инструменты и модели

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

Декларативные (предпочтительные в большинстве случаев):
- Terraform
- Pulumi (декларативно на обычных ЯП)
- Kubernetes-манифесты (YAML)
- Helm (шаблоны над манифестами)
- Ansible (частично декларативный)
- CloudFormation (AWS), ARM/Bicep (Azure)
Императивные:
- Скрипты на Bash/Python, которые вызывают cloud API.
- Подход рабочий, но хуже по идемпотентности и управляемости, если не наведен порядок.

Примеры IaC (на уровне, ожидаемом в реальной работе)

Terraform: создание PostgreSQL в облаке и инфраструктуры вокруг него (концептуально)

Идея:

Описываем VPC, субсети, security group, RDS, load balancer, Kubernetes-кластер — кодом.
Пример (упрощенный фрагмент):

provider "aws" {
  region = "eu-central-1"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_db_instance" "postgres" {
  engine               = "postgres"
  instance_class       = "db.t3.medium"
  allocated_storage    = 50
  name                 = "appdb"
  username             = "app"
  password             = "secret"
  skip_final_snapshot  = true
}

terraform plan показывает, что будет создано.
terraform apply приводит инфраструктуру к описанному состоянию.

Kubernetes-манифест: развёртывание Go-сервиса как кода

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
    spec:
      containers:
        - name: user-service
          image: my-registry/user-service:1.0.0
          ports:
            - containerPort: 8080

Это также IaC: состояние кластера и приложений описано декларативно.

Практические преимущества IaC (важные для собеседования)

Повторяемость:
- Новое окружение (test/stage/demo) поднимается из кода за минуты.
Прозрачность:
- Вся конфигурация системы видна в репозитории; меньше “серверов-питомцев”.
Уменьшение человеческого фактора:
- Нет “ручных настроек по инструкции из Confluence, которую никто не обновляет”.
Быстрые изменения:
- Изменения инфраструктуры проходят через pull request:
  - обсуждение,
  - review,
  - автоматическую проверку.
Аудит и безопасность:
- Можно точно увидеть, кто и когда поменял ресурсы.
- Легче применять политики (например, через OPA/Conftest/Checkov).

Типичные паттерны использования IaC в современных системах

GitOps:
- Истина — в Git.
- CD-система (ArgoCD, Flux) синхронизирует состояние кластера с репозиторием.
- Все изменения инфраструктуры — через pull request.
Разделение ответственности:
- Платформенная команда ведет репозиторий инфраструктуры:
  - сети, кластеры, observability, секреты.
- Команды приложений описывают деплой своего сервиса:
  - Helm chart, Kustomize, Terraform-модуль, values.
Комбинация:
- Terraform — для “нижнего уровня” (VPC, базы, очереди, topic-и, S3, IAM).
- Kubernetes/Helm — для приложений.
- Ansible — для конфигурации legacy/VM, если нужно.

Как это соотносится с реальной Go-разработкой

Даже будучи разработчиком прикладного сервиса, полезно:

Уметь прочитать Terraform/Helm/K8s-манифест и понять:
- где живет твой сервис,
- какие у него ресурсы/сети/переменные,
- как меняются конфиги при деплое.
Часть практики:
- описывать зависимости сервиса инфраструктурным кодом:
  - очереди (Kafka topics),
  - базы данных,
  - bucket’ы,
  - секреты.

Краткая формулировка:

Инфраструктура как код — это подход, при котором все элементы инфраструктуры описываются декларативно или программно и управляются как исходный код: через Git, code review, CI/CD. Это дает воспроизводимость, идемпотентность, прозрачность изменений, снижение ручных ошибок, быстрый подъем окружений и более надежную, управляемую инфраструктуру как часть единого инженерного процесса.

Вопрос 13. Что означает подход инфраструктура как код и какова разница в назначении Terraform и Ansible?

Таймкод: 00:11:54

Ответ собеседника: правильный. Корректно описал, что инфраструктура описывается в виде шаблонов/кода и разворачивается автоматически; Terraform используется для создания и развертывания инфраструктуры, Ansible — для конфигурации уже развернутых хостов.

Правильный ответ:

Подход “инфраструктура как код” уже был раскрыт ранее: инфраструктура (серверы, сети, балансировщики, БД, очереди, кластеры, права) описывается декларативно/программно, хранится в Git, проходит code review, воспроизводится и изменяется автоматизированно.

В контексте вопроса важно четко сформулировать различие между Terraform и Ansible, не смешивая их роли.

Кратко:

Terraform:
- Декларативный инструмент управления инфраструктурой.
- Основная задача: создание, изменение и удаление ресурсов в облаках и on-prem.
- Работает с понятием “desired state”:
  - вы описываете, что должно существовать (VPC, сети, инстансы, БД, балансировщики, очереди, S3-бакеты, Kafka topics),
  - Terraform сам вычисляет diff и применяет изменения.
- Хранит состояние (state), чтобы понимать расхождения между кодом и реальностью.
- Идемпотентен: повторный terraform apply доводит систему до описанного состояния.
- Типичные задачи:
  - развернуть инфраструктуру под приложения,
  - поднять и настроить managed PostgreSQL, Kafka, Redis, Kubernetes-кластер,
  - управлять IAM, security groups, DNS-записями.

Пример (упрощенно): создание topic в Kafka и БД в одном IaC-коде (через провайдеры):

resource "aws_db_instance" "postgres" {
  engine            = "postgres"
  instance_class    = "db.t3.medium"
  allocated_storage = 50
  name              = "appdb"
}

resource "kafka_topic" "orders" {
  name               = "orders"
  partitions         = 12
  replication_factor = 3
}

Ansible:
- Инструмент конфигурационного менеджмента.
- Основная задача: настройка уже существующих хостов и сервисов.
- Работа по SSH или через агента не требуется (agentless).
- Модель ближе к декларативной, но шаги описываются как задачи (tasks), плейбуки.
- Типичные задачи:
  - установить и настроить ПО на серверах (nginx, postgres, приложение),
  - выкатывать конфиги,
  - управлять пользовательскими аккаунтами, пакетами, сервисами.
- Можно использовать и для provisioning инфраструктуры через модули облаков, но его сильная сторона — конфигурация.

Пример (упрощенно): конфигурация Go-сервиса и systemd через Ansible:

- hosts: app_servers
  become: yes
  tasks:
    - name: Install binary
      copy:
        src: ./bin/user-service
        dest: /usr/local/bin/user-service
        mode: '0755'

    - name: Configure systemd service
      template:
        src: user-service.service.j2
        dest: /etc/systemd/system/user-service.service

    - name: Reload systemd
      systemd:
        daemon_reload: yes
        name: user-service
        state: restarted
        enabled: yes

Логика совместного использования:

Terraform:
- “Где и что развернуть?”
- Создает:
  - виртуальные машины / k8s-кластер,
  - базы данных,
  - сети, балансировщики,
  - очереди, топики, S3 и т.д.
Ansible:
- “Как это внутри настроить?”
- Конфигурирует:
  - пакеты, конфиги, сервисы,
  - деплой приложений на выделенные ВМ (если не используется Kubernetes/другой оркестратор).

Типичный современный паттерн:

Terraform — для инфраструктуры (cloud + VPC + RDS + k8s + Kafka и т.д.).
Kubernetes/Helm — для деплоя и конфигурации контейнеризированных приложений.
Ansible — для legacy/VM, init-конфигурации, bootstrap'а, специфических задач.

Краткая формулировка для интервью:

Подход “инфраструктура как код” — это описание инфраструктуры в коде с версионированием и автоматическим применением.
Terraform решает задачу декларативного управления ресурсами (provisioning и lifecycle инфраструктуры).
Ansible решает задачу конфигурации и управления ПО на уже существующих хостах; его можно рассматривать как инструмент конфигурационного менеджмента, дополняющий Terraform, а не заменяющий его.

Вопрос 14. Какие основные сущности используются в Ansible и как они связаны между собой?

Таймкод: 00:12:48

Ответ собеседника: неполный. Перечислил плейбуки, роли, переменные, группы хостов; верно отметил, что плейбук состоит из задач, использующих модули и шаблоны, но нечетко объяснил связи между ролями и плейбуками и не выделил явно inventory как ключевой элемент.

Правильный ответ:

Ansible — это инструмент конфигурационного менеджмента и автоматизации, который оперирует набором связанных сущностей. Важно понимать не только названия (playbook, role, inventory), но и их ответственность и связи.

Ключевые сущности:

Inventory (инвентарь)
Playbook (плейбук)
Play (игра внутри плейбука)
Task (задача)
Module (модуль)
Role (роль)
Variables (переменные)
Templates (шаблоны)
Handlers (обработчики)

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

Inventory

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

Формат:
- ini, yaml, динамический inventory (скрипты / плагины для AWS, GCP, k8s и т.д.).
Содержит:
- список хостов,
- группы (web, db, prod, staging),
- group_vars / host_vars (переменные на уровне групп/хостов).

Пример (YAML):

all:
  children:
    web:
      hosts:
        web-1.example.com:
        web-2.example.com:
    db:
      hosts:
        db-1.example.com:

Inventory отвечает на вопрос: “К каким машинам применять конфигурацию?”

Playbook

Playbook — это основной сценарий Ansible.

YAML-файл, состоящий из одного или нескольких plays.
Определяет:
- к каким хостам (или группам из inventory) обращаться,
- какие роли/задачи к ним применить.

Пример:

- name: Configure web servers
  hosts: web
  become: yes
  roles:
    - nginx
    - app

Playbook отвечает: “Что сделать и над какими группами хостов?”

Play

Play — один логический блок внутри playbook.

Связывает:
- группу хостов (hosts),
- набор задач или ролей (tasks/roles),
- контекст (переменные, become, environment).
В одном playbook может быть несколько plays для разных групп:

- name: Configure web
  hosts: web
  roles: [nginx, app]

- name: Configure db
  hosts: db
  roles: [postgres]

Play — “применить такие роли/задачи к таким хостам”.

Task

Task — атомарное действие.

Каждый task вызывает один module с нужными параметрами.
Tasks выполняются последовательно.
Примеры:
- установить пакет,
- создать файл,
- задеплоить конфиг,
- перезапустить сервис.

- name: Install Nginx
  apt:
    name: nginx
    state: present

Module

Module — “кирпичик логики”, встроенный или внешний.

Ansible-модуль — это кусок кода (Python/бинарь), который:
- делает конкретное действие: apt, yum, user, file, template, service, uri и т.д.
Tasks почти всегда — это “module + arguments”.
Важное свойство:
- большинство модулей идемпотентны (повторный запуск не ломает состояние).

Task использует module для работы.

Role

Role — структурированный способ группировки логики.

Назначение роли:

инкапсулировать:
- tasks,
- handlers,
- templates,
- files,
- vars,
- defaults,
- meta (зависимости от других ролей)
сделать конфигурацию:
- переиспользуемой,
- параметризуемой,
- модульной.

Стандартная структура роли (упрощённо):

roles/
  nginx/
    tasks/main.yml
    templates/nginx.conf.j2
    handlers/main.yml
    vars/main.yml
    defaults/main.yml
    files/...

Применение роли в playbook:

- hosts: web
  roles:
    - role: nginx
      vars:
        nginx_listen_port: 80

Связь:

Playbook описывает, какие роли применить.
Роль — как “библиотека/модуль конфигурации” с внутренними tasks/templates/vars.

Variables

Variables — механизм параметризации.

Могут определяться:

в inventory (group_vars, host_vars),
в playbook / play,
в роли:
- defaults (наименьший приоритет),
- vars (более высокий приоритет),
из extra-vars (через CLI),
из фактов (facts), из внешних источников (Vault, Consul и т.п.).

Пример:

- hosts: web
  vars:
    app_port: 8080

  tasks:
    - name: Template config
      template:
        src: app.conf.j2
        dest: /etc/app/app.conf

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

Templates

Templates — файлы с шаблонизацией Jinja2.

Используются для генерации конфигов, unit-файлов и т.д.
Могут ссылаться на переменные, факты, условия.

Пример nginx.conf.j2:

server {
    listen {{ nginx_listen_port }};
    server_name {{ server_name }};
}

Task:

- name: Render nginx config
  template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
  notify: Restart nginx

Handlers

Handlers — специальные tasks, которые выполняются при notify.

Используются для действий “по событию”, например:
- перезапустить сервис, если конфиг изменился.
Выполняются один раз в конце play (даже если notify было несколько).

Пример:

handlers:
  - name: Restart nginx
    service:
      name: nginx
      state: restarted

Взаимосвязь сущностей (сжато и по сути):

Inventory:
- описывает хосты и их группы.
Playbook:
- выбирает группы из inventory,
- задает, какие роли/задачи к ним применить.
Play:
- связывает “hosts → roles/tasks → vars/context”.
Role:
- организует tasks/handlers/templates/vars в переиспользуемый модуль.
Tasks:
- используют modules для конкретных действий.
Variables:
- конфигурируют поведение ролей/плейбуков под окружения.
Templates:
- генерируют конфиги на основе vars.
Handlers:
- реагируют на изменения (например, перезапускают сервисы).

Краткая формулировка для интервью:

В Ansible инвентарь описывает, “где” мы работаем (хосты и группы).
Playbook (состоящий из plays) описывает, “что” нужно сделать и над какими группами.
Внутри plays мы используем роли и задачи.
Роли — структурированный, переиспользуемый набор tasks/handlers/templates/vars.
Задачи вызывают модули, модифицируя состояние хостов.
Переменные и шаблоны позволяют одной и той же роли работать по-разному в разных окружениях.

Вопрос 15. Зачем нужна концепция инфраструктуры как код, какие у неё плюсы и минусы?

Таймкод: 00:16:34

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

Правильный ответ:

Подход инфраструктуры как код (IaC) уже был описан ранее, здесь важно акцентировать практические плюсы и реальные минусы с позиции эксплуатации сложных систем.

Плюсы инфраструктуры как код:

Воспроизводимость и детерминизм:
- Одно и то же описание создает одно и то же окружение.
- Новые стенды (dev/stage/demo/perf/prod-клон) поднимаются автоматически.
- Снижается вероятность “магических” ручных настроек, про которые знают только 1–2 человека.
Версионирование и аудит:
- Конфигурация хранится в Git:
  - понятно, кто, когда и что изменил,
  - можно посмотреть diff, историю, blame,
  - возможен rollback к рабочей версии.
- Изменения инфраструктуры проходят через pull request и code review, как код приложения.
Идемпотентность и предсказуемые изменения:
- Инструменты (Terraform, Ansible, Kubernetes-манифесты и др.) стремятся быть идемпотентными:
  - повторный запуск приводит систему к желаемому состоянию, а не “накручивает” хаос.
- Планирование изменений:
  - Terraform plan / kubectl diff / helm diff показывают, что именно изменится.
Стандартизация и масштабирование команд:
- Общие модули и роли:
  - Terraform-модули, Helm chart’ы, Ansible-ролы.
- Новые сервисы и команды используют проверенные шаблоны:
  - меньше расхождений, меньше “зоопарка”.
- Упрощается онбординг: инфраструктура описана явно, а не “в голове DevOps’а”.
Быстрое восстановление и DR (Disaster Recovery):
- При потере окружения:
  - можно быстро восстановить инфраструктуру из IaC + бэкапы данных.
- Переезд между регионами/облаками становится технически решаемым (при хорошем дизайне).
Интеграция с CI/CD и GitOps:
- Изменения инфраструктуры можно применять:
  - автоматически по merge в ветку,
  - с валидацией, тестами, policy checks.
- GitOps-подход:
  - то, что в Git — истина,
  - система сама приводит runtime к этому состоянию.

Минусы и реальные риски IaC (о которых важно честно говорить):

Требуется дисциплина и культура:
- Любые ручные изменения мимо кода ломают модель:
  - возникает drift (расхождение описанного и фактического состояния).
- Нужно:
  - запретить/минимизировать ручное “накликивание” в консолях,
  - внедрить процессы (code review, обязательный IaC для изменений).
Порог входа и стоимость экспертизы:
- Terraform, Helm, Kubernetes, Ansible, операторы БД, политики безопасности — всё это требует подготовки.
- Ошибки в IaC масштабируются:
  - одна неверная настройка может одновременно сломать все окружения,
  - пример: неправильно определенный lifecycle ресурса, который при изменении конфигурации пересоздает базу данных или очередь.
Сложность в больших системах:
- Крупный IaC-монорепозиторий без модульности превращается в “инфраструктурный монолит”:
  - долгие планы,
  - сложные зависимости,
  - страх трогать.
- Требуются:
  - модульность,
  - разделение по доменам/папкам/микросервисам,
  - понятное владение (ownership).
Управление состоянием (на примере Terraform):
- State — критичный артефакт:
  - потеря или повреждение state-файла усложняет работу,
  - нужны удаленные backends (S3/GCS + lock в DynamoDB/Consul).
- Неверная работа с state:
  - параллельные изменения без блокировок,
  - ручное редактирование state,
  - могут привести к неконсистентности и опасным операциям (удаление живых ресурсов).
Безопасность и секреты:
- Секреты в IaC:
  - нельзя хранить пароли/ключи в открытом виде в Git.
- Нужны:
  - Vault/Secrets Manager/KMS,
  - SOPS, Ansible Vault, интеграции Terraform с KMS,
  - четкие практики доступа.

Практическое резюме для собеседования:

Зачем:
- уменьшить ручные ошибки,
- стандартизовать инфраструктуру,
- ускорить подъем окружений,
- упростить масштабирование и сопровождение,
- сделать инфраструктуру прозрачной и управляемой как код.
Плюсы:
- воспроизводимость,
- версионирование и аудит,
- идемпотентность,
- стандартизация,
- автоматизация и GitOps,
- лучшее управление рисками и скоростью изменений.
Минусы/риски:
- требует квалификации и дисциплины,
- опасен drift между кодом и реальностью,
- ошибки в коде могут иметь массовый эффект,
- нужно грамотно управлять state и секретами,
- сложность в крупных ландшафтах без продуманной структуры.

Зрелый ответ подчеркивает: IaC — мощный инструмент, который дает большой выигрыш в управляемости и надежности, но только при осознанном использовании, строгих процессах и отказе от “ручной магии” поверх кода.

Вопрос 16. Как понимается концепция CI/CD и что означают её составляющие?

Таймкод: 00:18:19

Ответ собеседника: неполный. Верно упоминает, что CI — это автоматическая сборка и прогон тестов при изменениях в Git, а CD — автоматизация доставки на прод, но путается в формулировках и не различает четко continuous delivery и continuous deployment.

Правильный ответ:

CI/CD — это набор практик и процессов, обеспечивающих быструю, предсказуемую и надежную доставку изменений от разработчика до продакшена. Обычно включает три компонента:

Continuous Integration (CI)
Continuous Delivery (CD — в одном значении)
Continuous Deployment (CD — в другом, более радикальном значении)

Важно четко разделять их.

Continuous Integration (CI)

Суть:

Каждый коммит в репозиторий автоматически:
- собирается,
- прогоняет тесты,
- проходит статический анализ, линтеры, форматирование,
- при необходимости — проверки безопасности.
Цель:
- обнаруживать проблемы как можно раньше,
- не копить “интеграционный ад” в конце спринта,
- гарантировать, что ветка (обычно main/master) всегда находится в рабочем состоянии.

Типичный CI-пайплайн для Go-сервиса:

Триггеры:
- push, merge request/PR.
Шаги:
- gofmt / golangci-lint,
- go test ./...,
- сборка бинаря или контейнерного образа,
- публикация артефакта (Docker Registry, artifact storage).

Пример простого CI (концептуально, например для GitLab CI):

stages: [lint, test, build]

lint:
  stage: lint
  script:
    - golangci-lint run ./...

test:
  stage: test
  script:
    - go test ./...

build:
  stage: build
  script:
    - go build ./cmd/app
  artifacts:
    paths:
      - app

Ключевая идея: “каждое изменение проверено автоматически, master/main всегда зеленый”.

Continuous Delivery

Суть:

Система всегда находится в состоянии, готовом к деплою в продакшен одним действием:
- кнопка,
- команда,
- merge в специальную ветку.
Все шаги до продакшена:
- сборка,
- тесты,
- security checks,
- сборка и пуш docker-образов,
- миграции схемы (подготовка),
- деплой на stage,
- интеграционные/регрессионные тесты,
- могут быть полностью автоматизированы.
Но:
- финальное решение “катить в прод” может оставаться за человеком:
  - ручной approve,
  - change management.

Ключевой критерий:

Любой момент времени: “если сейчас нужно задеплоить — мы можем сделать это быстро, безопасно и предсказуемо”.

Continuous Deployment

Суть:

Максимально радикальная автоматизация:
- каждое успешно прошедшее pipeline изменение автоматически деплоится в прод без ручного подтверждения.
Требования:
- высокий уровень зрелости тестов (unit, integration, e2e),
- хорошее покрытие мониторингом, алертингом,
- безопасные механизмы отката (rollback),
- поддержка progressive delivery:
  - canary, blue-green, feature flags.

Отличие Continuous Delivery vs Continuous Deployment:

Continuous Delivery:
- pipeline готовит change до продакшена,
- деплой в прод — обычно вручную (но легко, одним действием).
Continuous Deployment:
- деплой в прод происходит автоматически после зеленого pipeline,
- человек не участвует в рутине, только реагирует на инциденты или меняет конфигурацию.

Практическая цепочка для веб/Go-сервиса

Типичный зрелый CI/CD-процесс:

Developer:

Делает изменения → создает merge request/PR.

Линтеры (gofmt, golangci-lint),
Тесты (go test),
Сборка Docker-образа,
Прогон интеграционных тестов в тестовом окружении,
Security/quality проверки.

CD (delivery):

Если pipeline зеленый:
- образ помечается как готовый к продакшену,
- автоматически выкатывается на stage,
- могут запускаться дополнительные тесты/проверки.

Continuous Delivery:

Инженер нажимает “Deploy to prod”:
- CD-система (ArgoCD, Flux, GitLab, GitHub Actions + ArgoCD, Jenkins и т.п.)
- применяет манифесты/Helm-чарты/Terraform,
- делает rolling update, blue-green, canary.

Continuous Deployment:

Тот же процесс, но шаг “Deploy to prod” триггерится автоматически после успешного pipeline, без ручного approve.

Почему CI/CD критично для современных систем

Быстрая обратная связь:
- ошибки ловятся минутами/часами, а не неделями.
Уменьшение риска релизов:
- частые маленькие релизы безопаснее, чем редкие большие.
Повышение качества:
- стандартизованные проверки, линтеры, тесты, политики.
Повышение предсказуемости:
- меньше “ночных релизов с шаманством”.
Поддержка масштабируемой архитектуры:
- десятки микросервисов без автоматики — операционный ад.

Краткая формулировка для интервью:

Continuous Integration:
- автоматическая сборка и тесты каждого изменения; цель — всегда рабочая интегрированная кодовая база.
Continuous Delivery:
- любой момент система готова к деплою в прод; деплой — быстрый и предсказуемый, но запуск может быть ручным.
Continuous Deployment:
- каждое успешно прошедшее все проверки изменение автоматически выкатывается в прод без ручного шага.

Четкое различение Delivery и Deployment — то, чего обычно ждут от сильного кандидата.

Вопрос 17. В чём разница между continuous deployment и continuous delivery на примере автоматического и ручного запуска деплоя?

Таймкод: 00:19:15

Ответ собеседника: частично правильный. По сути верно сопоставил автоматический деплой после успешного пайплайна с continuous deployment, а сценарий с ручным запуском деплоя — с отделённым шагом поставки, но ответ был неуверенным и без чёткого разграничения терминов.

Правильный ответ:

Оба подхода строятся поверх правильно организованного CI, но отличаются степенью автоматизации выхода в прод.

Кратко и чётко:

Continuous Delivery:
- Все шаги до продакшена автоматизированы:
  - сборка, тесты, проверка качества,
  - упаковка (артефакт, Docker-образ),
  - возможно деплой в stage.
- Результат: в любой момент есть “готовый к релизу” артефакт/версия.
- Деплой в прод:
  - выполняется по инициативе человека (manual approval / кнопка “Deploy”),
  - сам процесс деплоя при этом полностью автоматизирован.
- Ключевая идея: “Всегда готовы к выкладке, но человек решает, когда именно выкладывать”.
Continuous Deployment:
- Все то же, что и в Continuous Delivery, но:
  - после успешного прохождения всех автоматических проверок
  - деплой в прод запускается автоматически,
  - без ручного подтверждения.
- Любой зеленый коммит в main/master (при соблюдении правил) уезжает в прод.
- Ключевая идея: “Каждое проверенное изменение автоматически попадает в прод”.

Пример на уровне пайплайна:

Continuous Delivery:
- Pipeline:
  - build → test → security checks → build image → deploy to staging → tests on staging.
- После успеха:
  - доступен шаг “Deploy to production” (manual job / кнопка).
- Без нажатия — в прод не выкатываем.
Continuous Deployment:
- Тот же pipeline,
- но после успешных проверок:
  - автоматически идет deploy to production (auto job),
  - без ручного approve.

Вывод для интервью:

Если деплой в прод требует ручного триггера/approve — это continuous delivery.
Если деплой в прод происходит автоматически после успешного пайплайна — это continuous deployment.

Вопрос 18. Как организован процесс деплоя контейнера через GitLab и Ansible?

Таймкод: 00:20:55

Ответ собеседника: правильный. Описал типичный процесс: GitLab CI собирает контейнер, пушит его в registry, затем Ansible использует этот образ на целевых хостах и запускает контейнер.

Правильный ответ:

Это классический pipeline, объединяющий CI (GitLab) и конфигурационный менеджмент/оркестрацию (Ansible). Важно уметь описать его как последовательность четких этапов и артефактов.

Общая схема процесса:

Изменения в репозитории

Разработчик пушит изменения в Git / создаёт merge request.
Это триггерит GitLab CI pipeline.

CI: сборка и проверка Типичный pipeline в GitLab:

Шаги:
- Линтеры (gofmt, golangci-lint).
- Юнит-тесты: go test ./....
- Сборка Docker-образа приложения.
- Публикация образа в GitLab Container Registry или внешнем registry.
Пример .gitlab-ci.yml (упрощенный):

stages:
  - test
  - build
  - deploy

test:
  stage: test
  image: golang:1.22
  script:
    - go test ./...

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  only:
    - main

Ключевой артефакт этого этапа:

версионированный Docker-образ:
- $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
- часто дополнительно тегируется как :prod, :staging, :v1.2.3 и т.п.

Передача версии для деплоя

Далее нужно связать:

“какой образ задеплоить”
с Ansible-плейбуком или другим механизмом деплоя.

Подходы:

Использовать:
- переменные окружения GitLab (CI_COMMIT_SHA, IMAGE_TAG),
- файл с версией (deployment descriptor),
- инвентарь/vars в Ansible, обновляемые из CI.

Пример:

GitLab job для деплоя передает в Ansible:
- -e image_tag=$CI_COMMIT_SHA.

CD/Deploy: Ansible запускает контейнеры на целевых хостах

Ansible отвечает за:

подключение по SSH к серверам,
остановку старой версии контейнера,
запуск новой с нужным образом и параметрами,
обновление конфигов, перезапуск сервисов, health-check.

Пример плейбука (упрощенно, без registry auth):

- name: Deploy app container
  hosts: app_servers
  become: yes
  vars:
    image: registry.example.com/my-app:{{ image_tag }}
  tasks:
    - name: Pull image
      community.docker.docker_image:
        name: "{{ image }}"
        source: pull

    - name: Stop old container
      community.docker.docker_container:
        name: my-app
        state: stopped
        ignore_errors: yes

    - name: Run new container
      community.docker.docker_container:
        name: my-app
        image: "{{ image }}"
        state: started
        restart_policy: always
        ports:
          - "80:8080"
        env:
          APP_ENV: "prod"
          DB_DSN: "{{ db_dsn }}"

И GitLab job для вызова Ansible:

deploy_production:
  stage: deploy
  image: python:3.11
  script:
    - pip install ansible-core docker
    - ansible-playbook -i inventory/prod.ini deploy.yml \
        -e image_tag=$CI_COMMIT_SHA
  only:
    - main
  when: manual   # для continuous delivery (ручной триггер)

Ключевые моменты и хорошие практики:

Разделение ответственности:
- GitLab CI:
  - сборка, тесты, безопасность, упаковка образа и публикация.
- Ansible:
  - оркестрация деплоя на ВМ: запуск контейнера, конфиги, окружение.
Детерминизм:
- деплой всегда использует конкретный тег образа, а не latest.
Безопасность:
- доступ к registry и серверам через защищенные секреты GitLab (CI/CD variables).
Пошаговое выкатывание:
- можно реализовать blue-green или rolling деплой (по хостам / по группам).
Интеграция с health-check:
- после запуска контейнера можно добавить проверку доступности HTTP endpoint и в случае неуспеха откатить версию.

Краткая формулировка для интервью:

При пуше в GitLab запускается CI-пайплайн: собираем Go-сервис, упаковываем в Docker-образ, пушим в registry.
На этапе деплоя GitLab запускает Ansible, передавая тег образа; Ansible на целевых хостах подтягивает этот образ и перезапускает контейнер.
Вся цепочка описана кодом (CI-конфиг + Ansible-плейбуки), повторяема и автоматизируема, что дает контролируемый и предсказуемый деплой.

Вопрос 19. Является ли деплой контейнера через Ansible на один хост бесшовным для критичного к даунтайму приложения и почему?

Таймкод: 00:22:14

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

Правильный ответ:

Деплой контейнера на один-единственный хост через Ansible по схеме “останови старый контейнер → запусти новый” не является бесшовным для приложения, критичного к даунтайму. Между остановкой старой версии и готовностью новой неизбежно возникает окно недоступности.

Почему это не бесшовно:

Типичный плейбук:
- останавливает текущий контейнер,
- скачивает/подтягивает новый образ,
- запускает новый контейнер,
- (иногда) проверяет health-check.
В момент между stop и успешным start:
- нет живого инстанса приложения на этом хосте.
- если это единственный инстанс за балансировщиком или обращение идет напрямую к этому хосту — запросы падают (connection refused/timeout/5xx).
Даже если перезапуск занимает секунды, для:
- платежных сервисов,
- API с жесткими SLA,
- real-time систем это неприемлемо.

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

Как сделать деплой ближе к бесшовному:

Если есть только один хост:

Настоящего zero-downtime достичь сложно:
- всегда есть момент смены процесса/контейнера.
Можно минимизировать окно:
- сначала стартовать новый контейнер на другом порту,
- проверить его готовность,
- переключить трафик (например, через локальный reverse proxy / systemd socket activation / iptables),
- затем остановить старый.
Но даже тут:
- переключение трафика — критичный момент,
- нужна аккуратная реализация, чтобы не ронять активные коннекшены.

Гораздо более здоровый подход (то, что ожидают услышать):

Много инстансов за балансировщиком (минимум два):

Деплой по одному инстансу (rolling update):
- убрать инстанс из-под трафика (drain / deregister в LB),
- обновить контейнер,
- проверить health,
- вернуть в LB,
- перейти к следующему.
Для пользователя:
- трафик продолжается на здоровые инстансы,
- запросы не падают.

Blue-Green deployment:

Есть “синяя” (текущая) и “зеленая” (новая) среда.
Разворачиваем новую версию параллельно,
Переключаем трафик целиком на новую,
При проблемах быстро откатываемся обратно.

Canary deployment:

Выкатываем новую версию частично:
- на часть инстансов,
- на часть пользователей.
Если всё хорошо — расширяем.

Kubernetes / оркестраторы:

Используют rolling updates, readinessProbe, livenessProbe, maxUnavailable/maxSurge:
- автоматически поддерживают минимальное количество работающих подов,
- не шлют трафик на неподготовленные инстансы.

Итого:

Ответ на вопрос:
- Нет, деплой контейнера через Ansible на один хост в стиле “stop → start” не является бесшовным для критичных систем.
- Он приводит к даунтайму, пусть даже кратковременному.
Правильный подход:
- проектировать инфраструктуру и стратегию деплоя так, чтобы всегда был минимум один (а лучше несколько) живых инстансов под трафиком:
  - несколько хостов за LB,
  - rolling/blue-green/canary стратегии,
  - грамотные health-check и drain.
- Ansible или любой другой инструмент должен использоваться в рамках этих стратегий, а не как единственный “перезапусти контейнер на единственном сервере”.

Вопрос 20. Как можно обновлять несколько реплик приложения без даунтайма?

Таймкод: 00:23:04

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

Правильный ответ:

Идея корректная: отсутствие даунтайма достигается за счет поочередного обновления экземпляров (инстансов) приложения при наличии нескольких реплик за балансировщиком или прокси. Важно уметь описать это как четкую стратегию деплоя и показать понимание нюансов.

Основные подходы:

Rolling update (поочередное обновление реплик)

Суть:

Есть N реплик приложения за балансировщиком (L7/L4 LB, reverse proxy).
Обновляем их не одновременно, а по одной или небольшими батчами.

Типичный процесс:

Для каждой реплики:
- вывести реплику из-под трафика:
  - отключить в балансировщике (deregister),
  - пометить как drain (не принимать новые соединения, дождаться завершения активных).
- задеплоить новую версию (перезапустить контейнер / процесс).
- проверить health-check:
  - HTTP /health, /ready,
  - внутренние проверки.
- вернуть реплику в балансировщик.
Повторить для следующей.

Пока обновляется одна реплика:

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

Ключевые моменты:

Балансировщик не должен слать трафик на реплику, которая:
- в процессе обновления,
- не прошла readiness/health-check.
При высокой нагрузке:
- важно следить за тем, чтобы оставшегося числа реплик хватало:
  - регулируем batch size (одна за раз, 10%, 25% и т.д.).

Blue-Green deployment

Суть:

Есть две среды:
- Blue — текущая версия.
- Green — новая версия.
Шаги:
- развернуть новую версию (Green) параллельно, полностью задеплоенную и проверенную,
- переключить трафик с Blue на Green на уровне:
  - балансировщика,
  - DNS,
  - ingress/gateway.
- при проблемах — быстро переключиться обратно.

Плюсы:

Почти мгновенный переключатель.
Простой rollback: вернуть трафик на старую среду.

Минусы:

Требует ресурсов на две полные копии.

Canary deployment

Суть:

Выкатываем новую версию постепенно:
- 1 реплика из 10,
- 5% трафика,
- 10% трафика и т.д.
Следим за метриками:
- ошибки (5xx),
- latency,
- бизнес-метрики.
Если всё хорошо:
- увеличиваем долю новой версии,
- пока не заменим старую полностью.
Если плохо:
- откатываемся, минимизируя влияние.

Подходит для:

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

Поддержка zero-downtime за счет health-check и readiness

Независимо от стратегии, важны:

Health-check (liveness):
- показывает, что инстанс жив; при фейле — рестарт.
Readiness-check:
- показывает, что инстанс готов принимать трафик:
  - миграции выполнены,
  - подключение к БД установлено,
  - кеш прогрет.
- балансировщик шлет трафик только на готовые реплики.

Для Go-сервиса пример простого readiness endpoint:

http.HandleFunc("/ready", func(w http.ResponseWriter, r *http.Request) {
    if !isDBConnected() {
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }
    w.WriteHeader(http.StatusOK)
})

Балансировщик (Nginx / Kubernetes / AWS ALB) проверяет /ready и исключает реплики, не прошедшие проверку.

Нюансы, о которых стоит помнить на интервью

Миграции БД:
- При поочередном обновлении реплик код старой и новой версии может работать одновременно.
- Схема данных должна быть обратно совместимой:
  - сначала деплой миграций (расширяющих схему),
  - затем — приложений,
  - затем — уборка старых полей/колонок в отдельном шаге.
Sticky sessions:
- Если используются “липкие” сессии на уровне LB, нужно:
  - либо сделать backend stateless (JWT, внешние сессии),
  - либо аккуратно работать с тем, что часть трафика продолжает ходить на старые реплики.
Нагрузка:
- При обновлении части реплик увеличивается нагрузка на оставшиеся.
- Нужен запас по ресурсам.

Краткая формулировка:

Без даунтайма обновляют несколько реплик по rolling-схеме:
- выводим часть реплик из-под трафика,
- обновляем,
- убеждаемся, что они здоровы,
- возвращаем в пул,
- повторяем.
Более продвинутые варианты:
- blue-green и canary деплой.
Ключевой принцип:
- в каждый момент времени есть достаточно живых и готовых реплик под балансировщиком, чтобы обслуживать трафик, а обновление отдельных экземпляров не делает систему недоступной.

Вопрос 21. Как правильно обновлять несколько реплик приложения без даунтайма по аналогии с механизмом Rolling Update в Kubernetes?

Таймкод: 00:23:29

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

Правильный ответ:

Механизм Rolling Update в Kubernetes — формализация правильного подхода к бездаунтаймовому обновлению нескольких реплик. Та же логика применима и вне Kubernetes: мы всегда обеспечиваем достаточное количество здоровых экземпляров под трафиком, а обновление ведём поэтапно.

Ключевые принципы правильного обновления:

Не обновлять все реплики одновременно

Нельзя:
- остановить все инстансы,
- задеплоить новую версию,
- потом поднять всё разом.
Это гарантирует даунтайм.
Вместо этого:
- обновляем по одной или по батчам (1 N, 10%, 25% и т.п.),
- чтобы оставшиеся реплики продолжали обслуживать трафик.

Запуск новой реплики до остановки старой

Алгоритм, аналогичный RollingUpdate в Kubernetes:

Повысить число реплик временно:
- добавить одну новую реплику с новой версией (surge),
- не трогая старые.
Дождаться готовности новой реплики:
- readiness/health-check:
  - HTTP /ready, успешные зависимости (БД, очереди, конфиги).
Переключить часть трафика:
- балансировщик начинает слать запросы и на новую реплику.
Только после этого:
- удалить/остановить одну из старых реплик.
Повторять до тех пор, пока все старые не будут заменены.

В Kubernetes это управляется параметрами:

maxSurge — сколько новых подов можно добавить сверх желаемого количества.
maxUnavailable — сколько подов может быть одновременно недоступно. Например:
maxSurge: 1, maxUnavailable: 0:
- сначала создается новый под,
- когда он готов,
- удаляется один старый,
- в каждый момент минимум полное количество рабочих реплик.

Аналогичный подход вне Kubernetes:

При наличии балансировщика (Nginx/HAProxy/ALB):
- для конкретного инстанса:
  - убираем его из пула (drain),
  - дожидаемся завершения активных запросов,
  - обновляем контейнер/процесс,
  - проверяем health,
  - возвращаем в пул.
- Повторяем по одному инстансу.
Для более “Kubernetes-подобного” поведения:
- можно сначала поднять новый инстанс (добавить в пул),
- затем убрать старый; так достигается эффект maxSurge.

Readiness и health-check — обязательны

Чтобы rolling-обновление было корректным:

У приложения должны быть:
- liveness probe — жив ли процесс (при падении — рестарт),
- readiness probe — готов ли инстанс принимать трафик:
  - миграции выполнены,
  - коннект к БД/кешу есть,
  - локальные инициализации завершены.

Пример простого readiness handler на Go:

var ready atomic.Bool

func main() {
    // Инициализация (БД, кеш и т.п.)
    if err := initDeps(); err != nil {
        log.Fatalf("init failed: %v", err)
    }
    ready.Store(true)

    http.HandleFunc("/ready", func(w http.ResponseWriter, r *http.Request) {
        if !ready.Load() {
            w.WriteHeader(http.StatusServiceUnavailable)
            return
        }
        w.WriteHeader(http.StatusOK)
    })

    http.ListenAndServe(":8080", nil)
}

Балансировщик:

шлёт трафик только на инстансы, где /ready даёт 200.

Совместимость версий и миграции БД

Для реального zero-downtime rolling update важно учитывать, что:

Старые и новые версии приложения могут работать одновременно.
Схема БД и контракты API должны быть:
- обратно совместимыми на период релиза. Типичный безопасный паттерн миграций:
Сначала:
- добавляем новые колонки / таблицы / индексы (расширение).
Затем:
- выкатываем новую версию приложения, которая умеет работать и со старым, и с новым.
Потом:
- когда все реплики обновлены и стабильны — чистим legacy (старые поля/формат).

Резюме стратегии без даунтайма

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

Используем поочередное (rolling) обновление:
- никогда не обновляем все реплики одновременно.
Для каждой реплики:
- убираем из-под трафика (или поднимаем новую заранее),
- обновляем,
- проверяем готовность,
- возвращаем в пул.
Обязательно:
- health-check / readiness endpoints,
- совместимость версий и аккуратные миграции БД.
Аналогия с Kubernetes RollingUpdate:
- maxSurge > 0 и maxUnavailable = 0 позволяют сначала поднять новые реплики, убедиться, что они готовы, и только потом выключать старые, обеспечивая отсутствие даунтайма.

Вопрос 22. Что такое Blue-Green deployment и чем он отличается от Rolling Update?

Таймкод: 00:24:00

Ответ собеседника: неполный. Передал идею запуска новой версии без остановки старой, но перепутал детали, говорил об обновлении “по кластерам” и не выделил главное — наличие двух полноценных окружений и моментальное переключение трафика.

Правильный ответ:

Blue-Green deployment и Rolling Update — это два разных паттерна бездаунтаймового деплоя.

Они оба стремятся:

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

Но делают это по-разному.

Blue-Green deployment

Суть:

Есть два полноценных, параллельных окружения:
- Blue — текущая стабильная версия (prod сейчас здесь).
- Green — новая версия приложения с тем же набором сервисов.
В каждый момент времени трафик направлен только в одно окружение (Blue или Green).

Типичный процесс:

Blue — активное окружение, на нём крутится старая версия.
Разворачиваем новую версию в Green:
- на тех же ресурсах другого пула,
- или в отдельном кластере/namespace/VM-группе.
Прогоняем тесты и проверки в Green:
- smoke-тесты,
- интеграционные,
- нагрузочные,
- бизнес-проверки.
Когда Green признано готовым:
- переключаем весь прод трафик с Blue на Green:
  - изменяем конфиг балансировщика,
  - меняем target group,
  - обновляем route/ingress, feature flag или DNS (с аккуратным TTL).
- переключение обычно почти мгновенное.
Если всё хорошо:
- Blue можно:
  - держать как резерв для быстрого rollback,
  - позже переиспользовать как следующий “Green” для следующего релиза.
Если что-то пошло не так:
- быстро вернуть трафик на Blue.
- Откат — смена маршрутизации, без переката каждого инстанса.

Ключевые свойства Blue-Green:

Два изолированных, полноценных окружения.
Быстрый и простой rollback: переключили трафик назад.
Можно жестко валидировать новую версию до реального трафика.
Требует больше ресурсов (дублирование инфраструктуры).

Rolling Update

Суть:

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

Процесс:

Есть, например, 10 реплик приложения за одним балансировщиком.
Алгоритм:
- убираем 1–2 реплики из-под трафика,
- обновляем их до новой версии,
- проверяем readiness/health,
- возвращаем в пул,
- идем к следующим.
В каждый момент:
- часть реплик — старая версия,
- часть — новая.
Пользовательский трафик постепенно перераспределяется.

Ключевые свойства Rolling Update:

Не нужны два полных окружения — одна группа реплик, обновляемая кусками.
Минимальный даунтайм (при корректной настройке health-check и batch size).
Старые и новые версии существуют одновременно:
- важно соблюдать обратную совместимость API/БД.
Откат сложнее:
- нужно по сути сделать обратный rolling (или иметь сохранённую старую конфигурацию и снова её откатить по шагам),
- rollback не такой мгновенный, как переключение Blue ↔ Green.

Главные отличия Blue-Green vs Rolling Update

Архитектурный подход:
- Blue-Green:
  - два полных окружения (старое и новое).
  - Переключение — смена точки входа (LB/Ingress/DNS).
- Rolling Update:
  - одно окружение, часть реплик постепенно обновляется.
Одновременное сосуществование версий:
- Blue-Green:
  - с точки зрения реального трафика — в момент времени используется только одна версия (Blue или Green).
  - Вторая версия доступна для тестов, но не обслуживает прод-трафик.
- Rolling Update:
  - в процессе обновления старые и новые версии одновременно обслуживают боевой трафик.
Откат:
- Blue-Green:
  - rollback почти мгновенный: вернуть маршрутизацию на старое окружение.
- Rolling Update:
  - нужно повторно обновлять реплики назад или хранить конфигурации; откат по времени сопоставим с деплоем.
Ресурсы:
- Blue-Green:
  - требует ресурсов на полный дубль прод-окружения.
- Rolling Update:
  - ресурсы используются более экономно.

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

Blue-Green:
- “Мы держим две копии прод-окружения: Blue и Green. Новую версию разворачиваем в Green, тестируем, затем одним переключением балансировщика направляем трафик на Green. Если проблемы — так же быстро возвращаемся на Blue.”
Rolling Update:
- “Мы обновляем реплики по одной или небольшими партиями: выводим из-под трафика, обновляем, проверяем, возвращаем. В каждый момент часть трафика обслуживают старые инстансы, часть — новые.”

Такое четкое различие показывает глубокое понимание стратегий бездаунтаймового деплоя.

Вопрос 23. Знаешь ли ты, что такое DevOps (GOPS)?

Таймкод: 00:25:45

Ответ собеседника: неправильный. Сообщил, что не может ответить.

Правильный ответ:

Важно сразу отделить два момента:

DevOps — это не должность и не только “админ с Docker/Terraform”.
DevOps — это культура и набор практик, направленных на тесное взаимодействие разработки и эксплуатации, ускорение и повышение надежности поставки изменений.

Если под “GOPS” имелось в виду что-то конкретное, это, вероятно, локальный термин/оговорка; базовый и общепринятый термин — DevOps.

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

DevOps — это подход к разработке и эксплуатации программных систем, который объединяет:

разработку (Dev),
операционную деятельность и поддержку (Ops),

с целью:

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

Основные принципы и практики DevOps

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

Продуктовая команда отвечает:
- не только за написание кода,
- но и за его работу в продакшене:
  - производительность,
  - стабильность,
  - мониторинг,
  - инциденты.
Нет модели “Dev сдал — Ops страдает”.

Автоматизация

DevOps-подход предполагает активное использование:

CI/CD:
- автоматическая сборка, тестирование, деплой.
Infrastructure as Code:
- Terraform, Ansible, Kubernetes-манифесты, Helm и др.
Автоматизация повторяемых операций:
- создание окружений,
- деплой, откаты,
- управление конфигурацией.

Наблюдаемость (Observability)

Система должна быть прозрачно наблюдаема:

Метрики:
- latency, error rate, RPS, resource usage.
Логи:
- структурированные, централизованные: ELK, Loki, OpenSearch, Cloud Logging и т.д.
Трейсинг:
- распределённые трейсинги (OpenTelemetry, Jaeger, Tempo).
Алёрты:
- на основе SLO/SLA, а не “рандомные метрики”.

Это позволяет:

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

Надежность и устойчивость к изменениям

Практики:

Частые, маленькие релизы:
- легче контролировать, проще откатывать.
Стратегии безопасного деплоя:
- Blue-Green, Rolling Update, Canary,
- feature flags.
Тесты:
- unit, integration, e2e, нагрузочные.
Управление инцидентами:
- postmortem без “witch-hunt”,
- анализ причин,
- улучшения процессов и инструментов.

Культура

Очень важная часть:

Прозрачная коммуникация между Dev и Ops.
Обратная связь:
- разработчики видят реальные боли эксплуатации.
Нет “кидания ответственности”: все работают на общий результат — стабильный и развиваемый продукт.

Как это связано с современным backend/Go-разработчиком

Зрелый инженер, пишущий сервисы на Go, должен:

понимать базовые DevOps-принципы:
- как его сервис логируется, мониторится, деплоится;
- что такое health-check, readiness, алертинг;
- как читать дашборды и логи при инциденте.
уметь работать с:
- CI/CD (GitLab CI/GitHub Actions/etc.),
- контейнерами и оркестраторами (Docker, Kubernetes),
- базовыми инструментами IaC (Terraform/Helm/Ansible — хотя бы на уровне чтения и участия).
проектировать сервис так, чтобы:
- его можно было безопасно катить (идемпотентные миграции, backward compatibility),
- он был наблюдаем (метрики, логи, трейсинг),
- он хорошо вел себя в контейнерной/кластерной среде.

Краткая формулировка для интервью:

DevOps — это культурный и технический подход, который объединяет разработку и эксплуатацию, делает инфраструктуру и деплой управляемыми как код, вводит CI/CD, автоматизацию, мониторинг и практики безопасных релизов. Цель — быстрее и надежнее доставлять изменения в прод, при совместной ответственности за результат и прозрачности работы системы.

Вопрос 24. Какой у тебя опыт в настройке мониторинга и логирования и знаком ли ты с Prometheus и Grafana?

Таймкод: 00:25:54

Ответ собеседника: неполный. Упоминает запуск Zabbix-агента в тестовой среде; о Prometheus и Grafana знает теоретически, без практического опыта. Не раскрывает, как мониторинг и логирование должны быть организованы в современной системе.

Правильный ответ:

Для продвинутого backend-инженера важно не только “знать слова” Prometheus и Grafana, но и понимать, как строится наблюдаемость (observability) в целом: метрики, логи, трейсы; как они интегрируются с приложением, инфраструктурой и процессами.

Разберём ключевые элементы и свяжем с Go-сервисом.

Общая концепция observability

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

Метрики:
- численные показатели состояния системы во времени.
- Примеры: RPS, latency, error rate, CPU, RAM, GC паузы, количество goroutines, очередь запросов.
Логи:
- детальные записи событий.
- Примеры: входящие запросы, ошибки, бизнес-события.
Трейсинг:
- распределённые трассировки запросов через несколько сервисов.
- Позволяет понять, где конкретно “тормозит” или ломается запрос.

Задача инженера — проектировать приложение так, чтобы оно:

экспонировало метрики;
писало структурированные логи;
при необходимости поддерживало трассировку.

Prometheus: основные идеи

Prometheus — де-факто стандарт мониторинга для микросервисов и Kubernetes.

Ключевые особенности:

Pull-модель:
- Prometheus периодически опрашивает (scrape) /metrics endpoint у сервисов.
Модель метрик:
- time series с лейблами.
- Типы: counter, gauge, histogram, summary.
Язык запросов PromQL:
- позволяет строить сложные запросы, алерты, дашборды.
Service discovery:
- интеграция с Kubernetes, Consul, EC2 и т.п.

Интеграция с Go-приложением:

Подключаем клиентскую библиотеку:

import (
    "net/http"

    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
    httpRequests = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total number of HTTP requests",
        },
        []string{"path", "method", "status"},
    )
)

func init() {
    prometheus.MustRegister(httpRequests)
}

func main() {
    http.Handle("/metrics", promhttp.Handler())

    http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusOK)
    })

    http.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) {
        // обработка
        httpRequests.WithLabelValues("/hello", r.Method, "200").Inc()
        w.Write([]byte("hello"))
    })

    http.ListenAndServe(":8080", nil)
}

Prometheus scrape-конфиг (упрощенно):

scrape_configs:
  - job_name: 'my-app'
    static_configs:
      - targets: ['my-app:8080']

Grafana: визуализация и дашборды

Grafana — инструмент для построения дашбордов и визуализации данных из Prometheus (и не только).

Типичный use-case:

Подключаем Prometheus как data source.
Строим дашборды:
- метрики по сервисам (RPS, latency, error rate, p95/p99),
- состояние баз данных, брокеров, k8s-кластера.
Настраиваем алерты:
- через Grafana или напрямую в Prometheus Alertmanager.

Пример важных метрик для Go-сервиса:

http_requests_total / http_requests_duration_seconds (гистограммы по latency).
go_goroutines, go_memstats_alloc_bytes.
Количество ошибок (5xx), rate запросов по статусам.

Логирование: практические моменты

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

Структурированные логи (JSON), а не “просто строки”.
Обязательные поля:
- timestamp,
- level (info, warn, error),
- service, instance,
- trace_id / request_id,
- для HTTP — метод, путь, статус, время ответа.
Централизованный сбор:
- Elastic Stack (Filebeat/Fluentd/Fluent Bit + Elasticsearch/OpenSearch),
- Loki,
- облачные решения (Cloud Logging, Datadog, Splunk).

Пример логирования в Go (zerolog / zap):

logger := zerolog.New(os.Stdout).With().Timestamp().Logger()

logger.Info().
    Str("event", "user_login").
    Str("user_id", userID).
    Msg("user login successful")

logger.Error().
    Err(err).
    Str("op", "db_query").
    Msg("failed to load user")

Логи и метрики должны дополнять друг друга:

по метрикам видим: “возросли ошибки 5xx”.
в логах и трейсах находим конкретную причину.

Алертинг

Мониторинг без алертов мало полезен. Типичный набор:

Технические:
- сервис недоступен (up == 0),
- высокий процент 5xx,
- рост latency p95/p99,
- ошибки подключения к БД/кешу,
- мало свободного места на диске.
Бизнес:
- падение количества успешных заказов,
- всплеск отказов платежей.

Prometheus + Alertmanager:

пишем правила:
- “если 5xx_rate > 1% в течение 5 минут — шлём алерт в Slack/PagerDuty”.

Практическая увязка с DevOps-подходом

Зрелый ответ должен показывать понимание, что:

Наблюдаемость — не опция, а часть дизайна сервиса.
Разработчик:
- добавляет метрики, health-check, structured logs,
- участвует в настройке дашбордов и алертов,
- умеет по ним диагностировать проблемы.
Prometheus + Grafana:
- естественный выбор для контейнеризированных и Kubernetes-окружений.
Zabbix, Nagios и др.:
- могут использоваться для инфраструктурного мониторинга (железо, сети),
- но для метрик приложений Prometheus обычно удобнее.

Краткая формулировка для интервью:

Для современных сервисов важно иметь комплексную observability: метрики, логи, трейсы.
Prometheus используется для сбора и хранения метрик (pull-модель, /metrics, PromQL).
Grafana — для визуализации и алертов на основе этих метрик.
Приложение на Go должно экспонировать метрики и писать структурированные логи; мониторинг интегрируется в CI/CD и эксплуатацию, чтобы быстро выявлять и решать проблемы в продакшене.

Вопрос 25. Из каких основных элементов состоит типовой CI-пайплайн в GitLab?

Таймкод: 00:26:36

Ответ собеседника: частично правильный. Упомянул stages как блоки с задачами, переменные и rules для условий запуска, а также джобы. В целом структуру понимает, но не акцентирует типовой набор этапов (build, test, deploy) и не выстраивает четкую модель пайплайна.

Правильный ответ:

Типовой CI/CD-пайплайн в GitLab описывается в файле .gitlab-ci.yml и состоит из нескольких ключевых элементов, которые задают:

порядок выполнения задач;
условия запуска;
окружение, в котором что-то выполняется;
артефакты, передаваемые между этапами;
стратегии деплоя.

Важно понимать не только синтаксис, но и типовой жизненный цикл: от коммита до продакшена.

Основные элементы GitLab CI-пайплайна:

stages

Определяют логические этапы пайплайна и порядок их выполнения.
Пример типичной последовательности:
- lint / static-checks
- test
- build
- integration / e2e
- deploy_staging
- deploy_production
GitLab выполняет джобы в рамках одного stage параллельно (при наличии свободных раннеров) и переходит к следующему stage только после успешного завершения всех джобов текущего.

Пример:

stages:
  - lint
  - test
  - build
  - deploy

jobs (джобы)

Конкретные задачи, которые выполняются в рамках stage.
Каждый job:
- принадлежит к stage,
- запускается раннером в своем окружении (обычно контейнер),
- имеет свой script, image, зависимости, условия запуска.

Простой пример для Go-сервиса:

lint:
  stage: lint
  image: golang:1.22
  script:
    - gofmt -w ./ && git diff --exit-code
    - golangci-lint run ./...

test:
  stage: test
  image: golang:1.22
  script:
    - go test ./...

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  needs: ["test"]

Ключевые моменты по jobs:

stage — к какому этапу относится.
script — что выполняется.
image — в каком окружении.
needs — явные зависимости (для оптимизации и DAG-пайплайнов).
artifacts — файлы/билды, которые передаются следующему этапу.

image и services

image:
- Docker-образ, в котором запускается job.
- Позволяет задать окружение без ручной установки зависимостей.
services:
- дополнительные контейнеры рядом с job:
  - БД (PostgreSQL), Redis, Kafka и т.п. для интеграционных тестов.

Пример:

test:
  stage: test
  image: golang:1.22
  services:
    - name: postgres:16
      alias: db
  variables:
    DB_HOST: db
    DB_USER: test
    DB_PASSWORD: test
  script:
    - go test ./internal/...

variables

Средство передачи настроек:
- версии, пути, флаги,
- секреты (через GitLab CI/CD Variables),
- параметры окружений (dev/stage/prod).

Пример:

variables:
  GOFLAGS: "-mod=vendor"
  DOCKER_TLS_CERTDIR: "/certs"

Секреты и приватные значения:

задаются через UI GitLab (masked/protected variables),
не хардкодятся в .gitlab-ci.yml.

rules / only / except

Управляют условиями запуска jobs:
- по ветке,
- по тегам,
- по измененным файлам,
- по статусу merge request.

Современный и гибкий вариант — rules:

deploy_production:
  stage: deploy
  script: ./deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual
    - when: never

Это позволяет:

разделять поведение для MR, feature-веток, main;
реализовывать continuous delivery (ручной триггер на прод) или continuous deployment (auto).

artifacts и cache

artifacts:
- файлы, сохраненные после выполнения job и доступные в следующих job'ах или для скачивания.
- пример: бинарники, отчеты тестов, coverage.

build:
  stage: build
  script:
    - go build -o app ./cmd/app
  artifacts:
    paths:
      - app

cache:
- кеш для ускорения (модули Go, зависимости npm, Gradle, и т.п.).

environments и deploy

Позволяют описать окружения:
- review, dev, stage, prod.
Для deploy jobs:
- можно указать environment, URL, политику остановки/rollback.

Пример:

deploy_staging:
  stage: deploy
  script: ./deploy-staging.sh
  environment:
    name: staging
    url: https://staging.example.com
  when: manual

Типичный полноценный пайплайн для Go + контейнеры + деплой

Суммируя, “здоровый” пайплайн выглядит так:

stages:
- lint → test → build → scan (security) → deploy_staging → e2e → deploy_production
jobs:
- lint/test:
  - прогоняют качество и тесты для каждого коммита/PR.
- build:
  - собирает бинарь / Docker-образ,
  - пушит в registry.
- deploy_staging:
  - автоматически выкатывает на стейдж.
- e2e / smoke:
  - проверяют основную функциональность.
- deploy_production:
  - либо ручной (Continuous Delivery),
  - либо автоматический (Continuous Deployment),
  - использует ранее собранный образ и IaC/Ansible/Kubernetes для выката.

Краткая формулировка для интервью:

Типовой GitLab CI-пайплайн состоит из:

stages — определяют порядок этапов (lint/test/build/deploy и др.);
jobs — конкретные задачи внутри stages, со своим script/image/условиями;
variables — конфигурация и параметры;
rules/only/except — логика, когда и где запускать jobs;
artifacts/cache — перенос артефактов и ускорение;
environments — описание окружений для деплоя.

Ключевая идея: описать весь путь от коммита до продакшена декларативно в .gitlab-ci.yml, с четкими стадиями проверки и доставки, обеспечивая предсказуемый, воспроизводимый и автоматизированный процесс.

Вопрос 26. Что такое предопределённые переменные в GitLab CI и как они используются?

Таймкод: 00:27:21

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

Правильный ответ:

В GitLab CI есть два ключевых класса переменных:

пользовательские (определяются в проекте, группе, .gitlab-ci.yml или в UI);
предопределённые (predefined variables) — автоматически задаются GitLab для каждого job.

Предопределённые переменные — это набор стандартных переменных окружения, которые GitLab заполняет сам на основании контекста pipeline/job: репозиторий, ветка, commit SHA, tag, MR, pipeline ID, адрес registry и т.д.

Они позволяют:

строить образ с корректным тегом (по SHA/tag),
понимать, откуда пришёл pipeline (ветка, merge request),
настраивать условия запуска (rules, only/except),
прокидывать метаданные в деплой, логи, артефакты,
избегать хардкода значений (URL, имена проектов/репозиториев).

Ключевые примеры предопределённых переменных (важные на практике):

CI_PROJECT_PATH — namespace/project (например, group/app).
CI_PROJECT_NAME — имя проекта.
CI_PROJECT_DIR — путь к директории проекта в раннере.
CI_PIPELINE_ID — ID pipeline.
CI_JOB_ID — ID текущего job.
CI_COMMIT_SHA — полный SHA коммита.
CI_COMMIT_SHORT_SHA — сокращённый SHA.
CI_COMMIT_REF_NAME — имя ветки или тега.
CI_COMMIT_TAG — имя тега (если pipeline запущен по тегу).
CI_REGISTRY — URL контейнерного registry GitLab.
CI_REGISTRY_IMAGE — путь репозитория образа для текущего проекта.

Как это используется на практике:

Тегирование Docker-образов

Мы хотим, чтобы образ был однозначно связан с коммитом:

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Здесь:

CI_REGISTRY_IMAGE формируется GitLab (например, registry.gitlab.com/group/app),
CI_COMMIT_SHA — предопределённый SHA коммита.

Условия запуска (rules) по ветке/тегу

Continuous delivery / deployment:

deploy_production:
  stage: deploy
  script: ./deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual

Или деплой по релизным тегам:

deploy_release:
  stage: deploy
  script: ./deploy-release.sh
  rules:
    - if: '$CI_COMMIT_TAG =~ /^v[0-9]+\.[0-9]+\.[0-9]+$/'
      when: manual
    - when: never

Проброс версии в приложение

Можно передать версию (например, SHA или тег) в сборку Go:

build:
  stage: build
  image: golang:1.22
  script:
    - go build -ldflags "-X main.version=$CI_COMMIT_SHORT_SHA" -o app ./cmd/app
  artifacts:
    paths: [app]

В Go-коде:

package main

import "fmt"

var version = "dev"

func main() {
    fmt.Println("Version:", version)
}

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

Интеграция с деплоем

При деплое через Ansible/Kubernetes:

передаём тег образа:
- -e image_tag=$CI_COMMIT_SHA
или используем разные окружения в зависимости от ветки:

deploy_staging:
  stage: deploy
  script: ./deploy-staging.sh
  environment:
    name: staging
  rules:
    - if: '$CI_COMMIT_BRANCH == "develop"'

deploy_production:
  stage: deploy
  script: ./deploy-prod.sh
  environment:
    name: production
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual

Главное отличие от пользовательских переменных:

Предопределённые:
- автоматически выставляются GitLab,
- описывают контекст pipeline/job (коммит, ветка, проект, registry),
- нельзя “переопределить” их источник, но можно использовать в логике.
Пользовательские:
- задаются вручную (в UI, группе, проекте, .gitlab-ci.yml),
- используются для конфигурации (URL сервисов, фичи, секреты),
- могут комбинироваться с предопределёнными.

Краткая формулировка для интервью:

Предопределённые переменные GitLab CI — это автоматически доступные переменные окружения, содержащие информацию о проекте, коммите, ветке, теге, pipeline и registry. Они используются для тегирования образов, условного запуска job'ов, проброса версии в приложение и построения универсальных, не завязанных на хардкод пайплайнов.

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

Таймкод: 00:28:22

Ответ собеседника: правильный. Предложил использовать модульный пайплайн: вынести общую логику в отдельные файлы и подключать их через include/якоря, чтобы изменения в шаблоне автоматически применялись во всех проектах.

Правильный ответ:

Подход верный, но его важно оформить как системное решение. В больших организациях десятки и сотни сервисов не могут жить с копипастой .gitlab-ci.yml. Оптимальный путь — стандартизовать пайплайны и вынести общую логику в переиспользуемые шаблоны.

Основные техники оптимизации в GitLab CI:

Использование include

Вместо дублирования всей конфигурации во всех репозиториях:

создается один или несколько общих CI-шаблонов:
- в отдельном репозитории (например, company/ci-templates),
- или в .gitlab-ci.yml/.gitlab-ci-*.yml внутри монорепо/общего проекта.

В конкретном сервисе:

include:
  - project: 'company/ci-templates'
    file: '/go-service.gitlab-ci.yml'

# Локальные переопределения, если нужны
variables:
  APP_NAME: my-service

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

изменили шаблон — все проекты, его включающие, автоматически начинают использовать новую версию (с учетом политики веток/тегов);
единый стандарт для lint/test/build/release.

Многофайловая структура и локальные include

Даже в одном проекте:

можно разбить пайплайн на модули:
- .gitlab-ci.yml:
  - минимальный вход,
  - декларация include.
- ci/lint.yml, ci/test.yml, ci/build.yml, ci/deploy.yml:
  - отдельные блоки логики.

# .gitlab-ci.yml
include:
  - local: 'ci/lint.yml'
  - local: 'ci/test.yml'
  - local: 'ci/build.yml'
  - local: 'ci/deploy.yml'

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

Якоря и алиасы YAML (anchors & aliases)

Для повторяющихся кусочков внутри одного .gitlab-ci.yml:

.default-go-job: &default-go-job
  image: golang:1.22
  before_script:
    - go env
    - go version

lint:
  stage: lint
  <<: *default-go-job
  script:
    - golangci-lint run ./...

test:
  stage: test
  <<: *default-go-job
  script:
    - go test ./...

Использовать якоря удобно для:

единых настроек image, before_script, variables, cache и т.п.;
уменьшения шума и копипасты.

Централизованные шаблоны и версии

При большом количестве сервисов важно контролировать совместимость:

Вынесенный шаблон должен:
- быть версионирован:
  - использовать конкретную ветку или тег (ref: v1.2.3),
- иметь стабильный публичный контракт:
  - переменные, которые должны задать сервисы,
  - stages и jobs, которые они могут переопределять/расширять.

Пример:

include:
  - project: 'company/ci-templates'
    file: '/go-service.gitlab-ci.yml'
    ref: 'v2.0.0'

variables:
  APP_NAME: my-service
  GO_VERSION: "1.22"

Так:

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

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

Хорошая практика — иметь разные шаблоны:

go-service.gitlab-ci.yml — для Go HTTP API;
go-lib.gitlab-ci.yml — для библиотек (без деплоя, только тесты и релизы в registry);
front-end.gitlab-ci.yml — для фронтов;
helm-chart.gitlab-ci.yml — для чартов;
infra.gitlab-ci.yml — для Terraform и IaC.

Каждый сервис:

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

GitOps-совместимость и политика

Такой подход дает плюсы:

единые стандарты качества:
- все сервисы проходят общие шаги (lint, tests, security scan);
снижение операционных затрат:
- правка логики деплоя/безопасности в одном месте;
управляемые обновления:
- через теги шаблонов,
- через MR в общие CI-templates.

Краткая формулировка для интервью:

Чтобы не дублировать конфигурацию CI между десятками репозиториев, общую логику (lint/test/build/publish/deploy) выносят в один или несколько шаблонов и подключают их через include.
Внутри файлов используют anchors для сокращения повторов.
Изменения в шаблоне автоматически применяются ко всем проектам, которые его включают (или по мере обновления версии шаблона), что обеспечивает единый стандарт и значительно упрощает поддержку.

Вопрос 1. Как устроена архитектура современного веб-приложения при авторизации пользователя и какой путь проходит запрос, включая основные серверы и их роли?​

Вопрос 2. Куда указывает DNS-запись веб-приложения как на входную точку инфраструктуры?​

Вопрос 3. Какие виды прокси- или балансировочных серверов используются в качестве входной точки?​

Вопрос 4. Какие методы балансировки трафика между несколькими backend-серверами существуют?​

Вопрос 5. С какими системами управления базами данных есть практический опыт работы?​

Вопрос 6. К какому типу относится PostgreSQL и какие базовые виды баз данных существуют?​

Вопрос 7. Какие особенности PostgreSQL или реляционных баз данных можешь описать (области применения, кластеризация и прочее)?​

Вопрос 8. Насколько корректно использовать базу данных в виде Docker-контейнера в продуктивной среде?​

Вопрос 9. Что знаешь про индексы в базах данных и их влияние на работу запросов?​

Вопрос 10. Что такое репликация базы данных и как она соотносится со схемой мастер-реплика?​

Вопрос 11. Что известно о брокерах очередей и брокерах сообщений (например, Kafka, MQ)?​

Вопрос 12. Что знаешь о подходе инфраструктура как код?​

Вопрос 13. Что означает подход инфраструктура как код и какова разница в назначении Terraform и Ansible?​

Вопрос 14. Какие основные сущности используются в Ansible и как они связаны между собой?​

Вопрос 15. Зачем нужна концепция инфраструктуры как код, какие у неё плюсы и минусы?​

Вопрос 16. Как понимается концепция CI/CD и что означают её составляющие?​

Вопрос 17. В чём разница между continuous deployment и continuous delivery на примере автоматического и ручного запуска деплоя?​

Вопрос 18. Как организован процесс деплоя контейнера через GitLab и Ansible?​

Вопрос 19. Является ли деплой контейнера через Ansible на один хост бесшовным для критичного к даунтайму приложения и почему?​

Вопрос 20. Как можно обновлять несколько реплик приложения без даунтайма?​

Вопрос 21. Как правильно обновлять несколько реплик приложения без даунтайма по аналогии с механизмом Rolling Update в Kubernetes?​

Вопрос 22. Что такое Blue-Green deployment и чем он отличается от Rolling Update?​

Вопрос 23. Знаешь ли ты, что такое DevOps (GOPS)?​

Вопрос 24. Какой у тебя опыт в настройке мониторинга и логирования и знаком ли ты с Prometheus и Grafana?​

Вопрос 25. Из каких основных элементов состоит типовой CI-пайплайн в GitLab?​

Вопрос 26. Что такое предопределённые переменные в GitLab CI и как они используются?​

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

Вопрос 1. Как устроена архитектура современного веб-приложения при авторизации пользователя и какой путь проходит запрос, включая основные серверы и их роли?

Вопрос 2. Куда указывает DNS-запись веб-приложения как на входную точку инфраструктуры?

Вопрос 3. Какие виды прокси- или балансировочных серверов используются в качестве входной точки?

Вопрос 4. Какие методы балансировки трафика между несколькими backend-серверами существуют?

Вопрос 5. С какими системами управления базами данных есть практический опыт работы?

Вопрос 6. К какому типу относится PostgreSQL и какие базовые виды баз данных существуют?

Вопрос 7. Какие особенности PostgreSQL или реляционных баз данных можешь описать (области применения, кластеризация и прочее)?

Вопрос 8. Насколько корректно использовать базу данных в виде Docker-контейнера в продуктивной среде?

Вопрос 9. Что знаешь про индексы в базах данных и их влияние на работу запросов?

Вопрос 10. Что такое репликация базы данных и как она соотносится со схемой мастер-реплика?

Вопрос 11. Что известно о брокерах очередей и брокерах сообщений (например, Kafka, MQ)?

Вопрос 12. Что знаешь о подходе инфраструктура как код?

Вопрос 13. Что означает подход инфраструктура как код и какова разница в назначении Terraform и Ansible?

Вопрос 14. Какие основные сущности используются в Ansible и как они связаны между собой?

Вопрос 15. Зачем нужна концепция инфраструктуры как код, какие у неё плюсы и минусы?

Вопрос 16. Как понимается концепция CI/CD и что означают её составляющие?

Вопрос 17. В чём разница между continuous deployment и continuous delivery на примере автоматического и ручного запуска деплоя?

Вопрос 18. Как организован процесс деплоя контейнера через GitLab и Ansible?

Вопрос 19. Является ли деплой контейнера через Ansible на один хост бесшовным для критичного к даунтайму приложения и почему?

Вопрос 20. Как можно обновлять несколько реплик приложения без даунтайма?

Вопрос 21. Как правильно обновлять несколько реплик приложения без даунтайма по аналогии с механизмом Rolling Update в Kubernetes?

Вопрос 22. Что такое Blue-Green deployment и чем он отличается от Rolling Update?

Вопрос 23. Знаешь ли ты, что такое DevOps (GOPS)?

Вопрос 24. Какой у тебя опыт в настройке мониторинга и логирования и знаком ли ты с Prometheus и Grafana?

Вопрос 25. Из каких основных элементов состоит типовой CI-пайплайн в GitLab?

Вопрос 26. Что такое предопределённые переменные в GitLab CI и как они используются?

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