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/ > Модуль: Observability · Уровень: Middle+/Senior ## TL;DR Три методологии «что мерить»: **RED** (Rate / Errors / Duration — для request-driven сервисов, Tom Wilkie), **USE** (Utilization / Saturation / Errors — для ресурсов: CPU, память, диск, пулы, очереди; Brendan Gregg) и **Four Golden Signals** (Latency / Traffic / Errors / Saturation — Google SRE). RED отвечает «как сервису», USE — «как ресурсу». Для латенси **нельзя использовать average**: среднее скрывает хвост, чувствительно к выбросам и не композируется. Нужны **перцентили** (p50/p99/p99.9) и понимание tail amplification (при fan-out на 100 бэкендов p99 каждого задевает почти каждый запрос). Перцентили считают через **histogram** (`histogram_quantile` по агрегированным бакетам), потому что готовые квантили **нельзя усреднять между инстансами**. И сквозная тема — **labels/cardinality**: лейблы только bounded, иначе взрыв рядов. ## Теория ### Три методологии | Метод | Для чего | Сигналы | Автор | |-------|----------|---------|-------| | **RED** | Request-driven сервисы (API, HTTP/gRPC) | **R**ate, **E**rrors, **D**uration | Tom Wilkie | | **USE** | Ресурсы (CPU, RAM, диск, сеть, пулы, очереди) | **U**tilization, **S**aturation, **E**rrors | Brendan Gregg | | **Golden Signals** | Любой пользовательский сервис | Latency, Traffic, Errors, Saturation | Google SRE | Они дополняют друг друга: RED/Golden — взгляд **снаружи** (как пользователю), USE — **изнутри** (как ресурсу). На дашборде сервиса — RED, на дашборде инстанса/ноды — USE. **RED** (на каждый endpoint/сервис): ```promql # Rate — запросов в секунду sum by (route) (rate(http_requests_total[$__rate_interval])) # Errors — доля ошибок sum by (route) (rate(http_requests_total{code=~"5.."}[5m])) / sum by (route) (rate(http_requests_total[5m])) # Duration — p99 латенси histogram_quantile(0.99, sum by (le, route) (rate(http_request_duration_seconds_bucket[5m]))) ``` **USE** (на каждый ресурс): - *Utilization* — доля времени, что ресурс занят (CPU busy %, диск busy %). - *Saturation* — насколько ресурс перегружен сверх возможностей (длина run-queue, depth очереди, swap, ожидание пула). - *Errors* — счётчик ошибок ресурса (ECC, dropped packets, failed allocs). Тонкость: высокая **utilization без saturation** — это нормально (ресурс эффективно используется). Опасна **saturation** — появилась очередь ожидания → латенси растёт нелинейно. ### Почему НЕ average для латенси Average — главный антипаттерн измерения латенси: 1. **Скрывает хвост**: 99 запросов по 10ms + 1 запрос 5s → mean ≈ 60ms, выглядит «нормально», но 1% пользователей ждут 5 секунд. 2. **Чувствителен к выбросам**: один GC/таймаут сдвигает среднее. 3. **Не композируется**: нельзя усреднить средние двух инстансов с разным трафиком и получить правду без весов. 4. **Бимодальность невидима**: cache hit (1ms) + cache miss (200ms). Average = ~100ms — значение, которого **не испытывает ни один реальный запрос**. Перцентили/heatmap покажут два пика. Вывод: латенси описывают **распределением** — перцентили + гистограмма (heatmap). ### Перцентили и tail latency | Перцентиль | Смысл | |-----------|-------| | p50 (median) | Типичный опыт | | p90/p95 | Большинство | | p99 | Хвост, который замечают | | p99.9 | Самые медленные, важны при высоком RPS и для critical paths | **Tail amplification (fan-out)** — почему p99 критичен: если запрос пользователя порождает обращения к 100 бэкендам и ждёт всех, вероятность задеть «p99 хотя бы одного» ≈ `1 - 0.99^100 ≈ 63%`. То есть **p99 отдельного бэкенда становится почти медианным опытом** агрегированного запроса. Поэтому в распределённых системах хвост (p99/p99.9) важнее среднего на порядок. ### histogram_quantile: механика и точность Histogram хранит **кумулятивные бакеты** (`le` = «≤ граница»). `histogram_quantile(φ, buckets)`: 1. Находит бакет, в который попадает φ-й перцентиль по счётчикам. 2. **Линейно интерполирует** позицию внутри бакета. Отсюда точность ограничена шириной бакета: - Если p99 попадает в бакет `[1s, +Inf]`, результат интерполируется до бесконечности — мусор. - Слишком широкие бакеты → грубая оценка; слишком узкие и много → лишние ряды. **Как выбирать границы бакетов**: вокруг ожидаемой латенси и обязательно вокруг порога SLO. Если SLO «99% < 300ms», нужен бакет ровно на `le="0.3"`, чтобы точно считать долю быстрых запросов. ```go prometheus.HistogramOpts{ Name: "http_request_duration_seconds", Buckets: []float64{0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.3, 0.5, 1, 2.5, 5}, // ↑ граница SLO } ``` ### Почему перцентили нельзя усреднять (histogram > summary) `avg(p99_inst1, p99_inst2)` математически бессмысленно: перцентиль — нелинейная функция распределения, его нельзя усреднить. Чтобы получить **общий** p99 по всем инстансам, нужны **сырые бакеты** (counters), которые складываются: ```promql histogram_quantile(0.99, sum by (le) (rate(bucket[5m]))) # ✓ верно avg(http_duration{quantile="0.99"}) # ✗ summary, неверно ``` Поэтому **histogram** (сырьё бакетов, агрегируется на сервере) предпочтительнее **summary** (готовые per-instance квантили, не агрегируются) везде, где нужна агрегация по подам/инстансам. ### Labels и cardinality Каждая уникальная комбинация лейблов = отдельный временной ряд. `series = ∏ кардинальностей лейблов`. | Хорошие лейблы (bounded) | Антипаттерны (unbounded) | |--------------------------|--------------------------| | method, status code | user_id, email | | route-шаблон `/orders/:id` | raw URL `/orders/12345` | | region, datacenter | request_id, trace_id, session_id | | error_type (enum) | произвольное сообщение об ошибке | Высококардинальные данные → в **трейсы и логи**, не в лейблы метрик. Бюджет рядов на сервис + ревью новых лейблов — обязательная senior-практика. ## Подводные камни / gotchas - **Average latency лжёт** — скрывает хвост и бимодальность; не использовать как основной показатель. - **Усреднение перцентилей** (`avg` готовых квантилей) математически неверно — нужны бакеты гистограммы. - **`histogram_quantile` врёт при плохих бакетах** — если перцентиль в последнем `[X, +Inf]` бакете, интерполяция до бесконечности; бакеты должны окружать SLO-порог и ожидаемую латенси. - **p99 из p99 нельзя** — нельзя взять p99 от per-instance p99; считай из агрегированных бакетов. - **Cardinality взрыв** от одного unbounded-лейбла кладёт TSDB. - **Error rate = errors / total**, а не отдельный «errors per second» без знаменателя — иначе рост трафика выглядит как рост ошибок. - **Missing data ≠ zero**: отсутствие точек (рестарт, нет трафика) PromQL трактует не как 0; алерт `== 0` может молчать. Учитывай `absent()`/`or vector(0)` осознанно. - **Counter, не gauge, для накопления**: счётчик событий — counter (rate() корректно учтёт reset); gauge для «текущего значения». Перепутать = неверные графики. - **Saturation важнее utilization** для предсказания деградации: 100% CPU без очереди ок, а очередь при 70% — уже проблема. ## Вопросы на собеседовании **В:** Когда RED, когда USE, когда Golden Signals? **О:** RED — для request-driven сервисов (Rate/Errors/Duration), взгляд снаружи как у пользователя. USE — для ресурсов (CPU/RAM/диск/пулы/очереди): Utilization/Saturation/Errors, взгляд изнутри. Golden Signals (Latency/Traffic/Errors/Saturation) — обобщение Google SRE для любого пользовательского сервиса. На дашборде сервиса — RED, на ноде/инстансе — USE; вместе они дают и пользовательский, и ресурсный взгляд. **В:** Почему нельзя мерить латенси средним? **О:** Среднее скрывает хвост (1% по 5s утонут в массе быстрых), чувствительно к выбросам, не композируется и невидимо для бимодальных распределений (cache hit/miss) — mean попадает в «пустоту» между пиками, где нет реальных запросов. Нужны перцентили и heatmap, описывающие распределение. **В:** Что такое tail amplification и почему p99 важнее, чем кажется? **О:** При fan-out, когда запрос ждёт N бэкендов, вероятность задеть «p99 хотя бы одного» = `1 - 0.99^N`; при N=100 это ~63%. То есть p99 отдельного сервиса становится почти медианным опытом составного запроса. В распределённых системах хвост определяет пользовательскую латенси, поэтому оптимизируют p99/p99.9, а не среднее. **В:** Почему histogram, а не summary, для распределённого сервиса? **О:** Summary считает квантили на клиенте, а их нельзя агрегировать между инстансами (усреднять p99 бессмысленно). Histogram отдаёт сырые кумулятивные бакеты (counters), которые складываются `sum by (le)`, и только потом берётся `histogram_quantile` — так получается корректный общий перцентиль по всем подам. Цена — зависимость точности от бакетов. **В:** Как выбрать границы бакетов гистограммы? **О:** Вокруг ожидаемой латенси и обязательно ровно на пороге SLO. Если SLO «99% < 300ms», нужен бакет `le=0.3`, чтобы точно считать долю быстрых запросов и p99. Иначе перцентиль попадёт в широкий бакет и `histogram_quantile` будет грубо интерполировать (особенно фатально в последнем `+Inf` бакете). **В:** Чем utilization отличается от saturation и что опаснее? **О:** Utilization — доля времени, что ресурс занят; saturation — степень перегрузки сверх возможностей (длина очереди/run-queue/ожидание пула). Опаснее saturation: высокая utilization без очереди нормальна, а появление очереди означает нелинейный рост латенси. Поэтому saturation — ранний предиктор деградации. **В:** Как правильно считать error rate? **О:** Как долю: `rate(errors_total) / rate(requests_total)`. Абсолютный счётчик ошибок без знаменателя вводит в заблуждение — при росте трафика растут и абсолютные ошибки при неизменной доле. Доля нормализует на объём и сравнима во времени и между сервисами. ## На что копают на senior+ - **Histogram vs summary** на уровне агрегируемости и почему перцентили не композируются. - **Выбор бакетов под SLO** и связь гистограммы с threshold-based SLI (доля запросов быстрее порога вместо перцентиля). - **Tail amplification** при fan-out и стратегии борьбы (hedged requests, backup requests, таймауты). - **Cardinality budgeting**: формула рядов, bounded-лейблы, вынос высококардинального в трейсы/логи, экземпляры (exemplars) для связи. - **Композируемость метрик**: что можно складывать (counters, бакеты), что нельзя (готовые квантили, средние без весов). - **Высокое vs низкое разрешение**: trade-off между гранулярностью (короткий scrape, больше бакетов) и стоимостью/кардинальностью. - **Missing data semantics** и алертинг устойчивый к отсутствию точек (staleness, `absent`).