Senior Go Interview Prep - Core Go: https://go.vbloher.org/docs/01-core-go/ - Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/ - Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/ - Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/ - Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/ - Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/ - Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/ - panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/ - Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/ - Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/ - Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/ - Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/ - Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/ - Concurrency: https://go.vbloher.org/docs/02-concurrency/ - sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/ - Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/ - Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/ - Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/ - Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/ - sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/ - context: https://go.vbloher.org/docs/02-concurrency/context/ - Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/ - sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/ - sync.Once: https://go.vbloher.org/docs/02-concurrency/once/ - Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/ - Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/ - Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/ - select: https://go.vbloher.org/docs/02-concurrency/select/ - sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/ - Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/ - Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/ - Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/ - Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/ - Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/ - GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/ - Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/ - Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/ - Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/ - pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/ - Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/ - Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/ - Тестирование: https://go.vbloher.org/docs/04-testing/ - testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/ - Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/ - Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/ - Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/ - Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/ - Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/ - Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/ - Backend: https://go.vbloher.org/docs/05-backend/ - Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/ - Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/ - gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/ - JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/ - Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/ - net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/ - OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/ - OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/ - Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/ - REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/ - Сети и протоколы: https://go.vbloher.org/docs/06-networking/ - Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/ - DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/ - Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/ - TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/ - TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/ - UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/ - WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/ - Базы данных: https://go.vbloher.org/docs/07-databases/ - Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/ - Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/ - Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/ - Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/ - MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/ - Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/ - Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/ - Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/ - Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/ - Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/ - Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/ - Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/ - Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/ - CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/ - Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/ - Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/ - Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/ - Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/ - Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/ - Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/ - Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/ - Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/ - RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/ - Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/ - Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/ - Observability: https://go.vbloher.org/docs/09-observability/ - Grafana: https://go.vbloher.org/docs/09-observability/grafana/ - Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/ - OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/ - Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/ - SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/ - Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/ - Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/ - System Design: https://go.vbloher.org/docs/10-system-design/ - Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/ - Chat System: https://go.vbloher.org/docs/10-system-design/chat/ - Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/ - Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/ - Order Service: https://go.vbloher.org/docs/10-system-design/order-service/ - Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/ - Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/ - URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/ - DevOps: https://go.vbloher.org/docs/11-devops/ - CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/ - Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/ - Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/ - GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/ - Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/ - Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/ - Алгоритмы: https://go.vbloher.org/docs/12-algorithms/ - Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/ - Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/ - Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/ - Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/ - Behavioral: https://go.vbloher.org/docs/13-behavioral/ - Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/ - Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/ - Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/ - Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/ > Модуль: DevOps · Уровень: Middle+/Senior ## TL;DR - **CI (Continuous Integration)** — на каждый push/PR автоматически прогоняются lint, тесты, сборка. Цель: ловить интеграционные проблемы рано, держать `main` всегда зелёным. - **CD** — двусмысленно: *Continuous Delivery* (автоматически готовим релиз, кнопка деплоя ручная) vs *Continuous Deployment* (каждый зелёный коммит в `main` автоматически едет в prod). На senior-собеседовании важно разделять эти два понятия. - Типичные стадии Go-пайплайна: `lint` → `test` (unit + race + coverage) → `build` (бинарь/Docker-образ) → `scan` (уязвимости) → `publish` (push в registry) → `deploy`. - **Артефакт** — иммутабельный результат сборки (Docker-образ по digest, бинарь, helm chart). Билдим один раз, продвигаем по окружениям (build once, deploy many). Не пересобираем для каждого env. - **Версионирование**: SemVer для библиотек/API, git SHA или `git describe` для сервисов. Образы тегируем и неизменяемым (`sha-abc123`), и плавающим (`latest`, `v1.2`) тегом. - **Стратегии деплоя**: rolling (по умолчанию в k8s), blue-green (мгновенное переключение + быстрый откат), canary (постепенный rollout на % трафика с метриками). ## Теория ### Pipeline as Code Пайплайн описывается в репозитории (`.github/workflows/*.yml`, `.gitlab-ci.yml`, `Jenkinsfile`). Преимущества: версионируется вместе с кодом, review через PR, воспроизводимость. Конфиг в UI — антипаттерн (нет истории, нет review). ### Стадии классического пайплайна | Стадия | Что делает | Инструменты (Go) | |--------|-----------|------------------| | lint / static | формат, vet, статанализ | `gofmt`, `go vet`, `golangci-lint` | | test | unit, race detector, coverage | `go test -race -cover` | | build | компиляция, Docker-образ | `go build`, `docker build`, ko, buildx | | security scan | SAST, зависимости, образ | `govulncheck`, `gosec`, `trivy`, `grype` | | publish | push артефакта | registry (ECR/GCR/GHCR) | | deploy | выкатка в окружение | kubectl/helm/argocd/terraform | ```bash # минимальный CI-набор для Go gofmt -l . # список неотформатированных файлов (должен быть пуст) go vet ./... golangci-lint run ./... go test -race -coverprofile=cover.out ./... go build -trimpath -ldflags "-s -w -X main.version=$(git describe --tags --always)" ./cmd/app govulncheck ./... # CVE в зависимостях и стандартной библиотеке ``` ### Артефакты и принцип "build once" Главное правило надёжного CD: **собранный артефакт неизменен и продвигается по окружениям**. Один и тот же Docker-образ (адресуемый по digest `image@sha256:...`) деплоится сначала в staging, потом ровно он же в prod. Пересборка под каждое окружение убивает воспроизводимость: «в staging работало, в prod нет» — потому что это два разных бинаря. Конфигурация окружений выносится наружу (env vars, ConfigMap, Secrets), а не вшивается в образ. Это 12-factor: один артефакт, разная конфигурация. ```bash # тег по неизменяемому digest, а не по плавающему latest docker build -t ghcr.io/org/app:sha-$(git rev-parse --short HEAD) . docker push ghcr.io/org/app:sha-$(git rev-parse --short HEAD) # в deploy ссылаемся на digest, который вернул push: # ghcr.io/org/app@sha256:9f2c... ``` ### Версионирование - **SemVer** (`MAJOR.MINOR.PATCH`) — для публичных API и Go-модулей. MAJOR — несовместимые изменения, MINOR — обратносовместимые фичи, PATCH — фиксы. В Go модули с `v2+` требуют суффикс в module path (`module github.com/org/lib/v2`). - **Сервисы** обычно версионируют git-тегами + `git describe` (`v1.4.2-3-gabc123` = 3 коммита после тега v1.4.2). Версия вшивается в бинарь через `-ldflags -X`. - **Образы**: каждый build получает неизменяемый тег (git SHA) + опционально плавающие (`latest`, мажорный/минорный). Никогда не деплойте `latest` в prod — невозможно понять, что именно крутится, и нет детерминированного отката. ```bash go build -ldflags "-X main.version=$(git describe --tags --always --dirty)" ./... ``` ### Стратегии деплоя **Rolling update** (дефолт в Kubernetes). Поды заменяются пачками: новый поднимается, проходит readiness, старый гасится. Параметры `maxSurge` / `maxUnavailable`. - Плюсы: без даунтайма, не нужны двойные ресурсы. - Минусы: во время выката одновременно живут обе версии (требует обратной совместимости API и схемы БД), откат не мгновенный. ```yaml spec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% # сколько лишних подов сверх replicas maxUnavailable: 0 # 0 => без просадки ёмкости ``` **Blue-Green**. Две идентичные среды: blue (текущая) и green (новая версия). После прогрева и проверки green трафик переключается целиком (через изменение Service/LB/DNS). - Плюсы: мгновенный откат (вернуть указатель на blue), нет смешанных версий в момент переключения. - Минусы: 2x ресурсов, переключение БД/состояния — сложная часть (миграции должны быть совместимы с обеими версиями). **Canary**. Новая версия получает малую долю трафика (1% → 5% → 25% → 100%), на каждом шаге смотрят метрики (error rate, latency p99, бизнес-метрики). При деградации — автоматический откат. Реализуется через mesh (Istio/Linkerd), ingress weights, или Argo Rollouts / Flagger. - Плюсы: минимальный blast radius, раннее обнаружение проблем на реальном трафике. - Минусы: сложность (нужны хорошие метрики и автоматизация анализа), дольше по времени. ```yaml # Argo Rollouts: canary со ступенями и автоанализом apiVersion: argoproj.io/v1alpha1 kind: Rollout spec: strategy: canary: steps: - setWeight: 5 - pause: { duration: 5m } - analysis: templates: [{ templateName: success-rate }] - setWeight: 25 - pause: { duration: 10m } - setWeight: 100 ``` | Стратегия | Откат | Ресурсы | Смешанные версии | Когда | |-----------|-------|---------|------------------|-------| | Rolling | медленный | 1x | да | дефолт, стабильные релизы | | Blue-Green | мгновенный | 2x | нет (момент switch) | критичные, нужен быстрый rollback | | Canary | авто/быстрый | ~1.1x | да | высокий трафик, нужна проверка на реальных юзерах | ### Связь с миграциями БД Любая стратегия без даунтайма требует, чтобы старая и новая версии кода работали с одной схемой БД одновременно. Отсюда паттерн **expand/contract** (parallel change): сначала добавляем новое (nullable-колонку), деплоим код, читающий и старое и новое, бэкфиллим данные, переключаем запись, и только потом отдельным релизом удаляем старое. Никогда не совмещайте несовместимую миграцию схемы с деплоем кода в одном шаге. ### GitOps Декларативный CD: желаемое состояние кластера описано в git, контроллер (ArgoCD/Flux) непрерывно синхронизирует кластер с репозиторием. Деплой = merge в git. Плюсы: git как source of truth, аудит, лёгкий откат через revert, автокоррекция дрейфа. ## Подводные камни / gotchas - **`latest` в prod** — нет детерминированного состояния и отката. Всегда иммутабельный тег/digest. - **Пересборка артефакта на каждый env** — теряете «build once», получаете расхождение staging/prod. - **Флаки-тесты в CI** — убивают доверие к пайплайну, люди начинают перезапускать «на всякий случай» или мерджить красное. Изолировать/чинить, а не ретраить вслепую. - **Несовместимая миграция БД при rolling/canary** — старые поды ломаются на новой схеме. Нужен expand/contract. - **Секреты в логах CI** — `echo $TOKEN`, или утечка через `set -x`. Маскируйте, используйте secret-стораджи. - **Долгий пайплайн** убивает скорость команды. Кэширование, параллелизм, разделение fast (lint+unit на PR) и slow (e2e, нагрузка на nightly). - **Canary без хороших метрик** бессмысленен: если нечем измерить деградацию, это просто медленный rolling. - **Отсутствие защиты ветки** — прямой push в `main` мимо CI. Required status checks + review обязательны. - **Деплой = только обновление образа**, но забыли про конфиг/секреты/feature flags — частичный rollout, который ведёт себя непредсказуемо. ## Вопросы на собеседовании **В:** В чём разница между Continuous Delivery и Continuous Deployment? **О:** Delivery — пайплайн автоматически готовит релиз, пригодный к деплою, но выкатка в prod — ручное решение (кнопка/approval). Deployment — каждый коммит, прошедший проверки, автоматически едет в prod без участия человека. Deployment требует очень зрелого тестирования, мониторинга и фич-флагов. **В:** Почему важно «build once, deploy many»? **О:** Чтобы в prod уезжал ровно тот артефакт, что проверен в staging. Пересборка под env вносит риск расхождения (разные версии зависимостей, флаги компиляции, время сборки). Конфигурацию выносим наружу, а образ остаётся неизменным и адресуется по digest. **В:** Сравните blue-green и canary. Когда что выбрать? **О:** Blue-green — мгновенное переключение всего трафика и мгновенный откат, но 2x ресурсов и нет постепенной проверки. Canary — постепенный rollout на % трафика с анализом метрик, минимальный blast radius, но сложнее (нужны метрики и автоматизация). Blue-green для критичных релизов, где нужен быстрый rollback; canary для высоконагруженных сервисов, где важно проверить на реальном трафике. **В:** Как делать деплой без даунтайма при изменении схемы БД? **О:** Expand/contract (parallel change): миграции обратносовместимы, схема меняется в несколько шагов так, чтобы старая и новая версии кода работали одновременно. Сначала добавить новое (nullable), задеплоить код, бэкфилл, переключить запись, и отдельным релизом удалить старое. Несовместимую миграцию нельзя совмещать с деплоем кода. **В:** Как версионировать Docker-образы для сервиса? **О:** Неизменяемый тег по git SHA (`sha-abc123`) или `git describe` плюс ссылка по digest в деплое. Опционально плавающие теги (`latest`, минорный) для удобства, но в prod деплоим только иммутабельный. Версия дополнительно вшивается в бинарь через `-ldflags -X main.version`. **В:** Что такое GitOps и чем он лучше push-деплоя? **О:** Желаемое состояние кластера хранится в git, контроллер (ArgoCD/Flux) непрерывно подтягивает и синхронизирует кластер. Деплой = merge. Плюсы: git как единый source of truth, полный аудит изменений, откат через revert, автокоррекция дрейфа, не нужен доступ CI к кластеру (pull-модель безопаснее). **В:** Как ускорить медленный CI-пайплайн? **О:** Кэш зависимостей (`go mod`, build cache), параллелизация независимых job, разделение быстрых проверок (lint+unit на каждый PR) и медленных (e2e/нагрузка на merge или nightly), сборка Docker с layer-кэшем и buildx, запуск тестов только для изменённых пакетов где возможно, отказ от лишних шагов на PR. **В:** Что такое flaky-тесты и почему они опасны в CI? **О:** Тесты, которые проходят/падают недетерминированно (гонки, таймауты, зависимость от порядка/времени/сети). Опасны тем, что разрушают доверие: команда привыкает перезапускать красное и в итоге мерджит реально сломанное. Лечение — изоляция, детерминизм (фиксированные часы, моки), `-race`, карантин с обязательным тикетом, а не слепой retry. ## На что копают на senior+ - Проектирование пайплайна для монорепо/множества сервисов: что собирать инкрементально, как определять затронутые сервисы (path filters, affected graph). - Безопасность supply chain: подпись образов (cosign/sigstore), SBOM, провенанс (SLSA), сканирование зависимостей, защита от typosquatting в `go.mod`. - Стратегия откатов: автоматический rollback по метрикам, совместимость миграций, feature flags для decouple деплоя от релиза (деплой кода ≠ включение фичи). - Промоушн между окружениями и approval-гейты, environments с защитой, OIDC-федерация вместо долгоживущих ключей. - Метрики DORA (deployment frequency, lead time, MTTR, change failure rate) и как пайплайн на них влияет. - Эфемерные/preview-окружения на PR и их стоимость.