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 Grafana — слой визуализации и алертинга поверх множества источников данных (Prometheus, Loki, Tempo, и др.). Дашборд = набор **panels**, каждая панель выполняет запрос к data source и рендерит результат (time series, stat, gauge, table, heatmap). Сила Grafana — **корреляция трёх сигналов**: из метрики (Prometheus) по exemplar прыгнуть в трейс (Tempo), из трейса в логи (Loki) через derived fields. **Templating** (`$variable`) делает дашборды переиспользуемыми между сервисами/инстансами. Grafana **Unified Alerting** — отдельная подсистема (alert rules → notification policies → contact points), не путать с панельным «алертом». Senior-практика: **дашборды как код** (provisioning/Terraform/Grafonnet, не клики), иерархия overview → service → instance, аннотации деплоев, и осторожность с `$__rate_interval`, downsampling и вводящими в заблуждение average-панелями. ## Теория ### Источники данных и корреляция | Data source | Сигнал | Язык запросов | |-------------|--------|---------------| | Prometheus / Mimir | Метрики | PromQL | | Loki | Логи | LogQL | | Tempo | Трейсы | TraceQL | | Postgres/MySQL, CloudWatch, Elasticsearch | разное | SQL/нативный | Главная ценность — **переходы между сигналами** в одном UI: - **Exemplars** (Prometheus): точки на графике латенси несут `trace_id` → клик → трейс в Tempo. - **Trace-to-logs** (Tempo): из спана прыжок в Loki по `trace_id`. - **Derived fields** (Loki): регуляркой выдёргиваем `trace_id` из строки лога → кнопка «открыть трейс». Это и есть «observability», а не три разрозненных инструмента. ### Типы панелей | Панель | Когда | |--------|-------| | **Time series** | Основная: тренды rate/latency/errors во времени | | **Stat** | Одно число: текущий error budget, RPS, версия | | **Gauge** | Значение относительно порога (utilization, SLO остаток) | | **Table** | Топ-N (по эндпоинтам, по подам), `instant` запросы | | **Heatmap** | Визуализация **гистограммы во времени** (распределение латенси) — нужен histogram data source | | **Histogram** | Распределение значений (не во времени) | | **Logs / Traces** | Панели для Loki/Tempo | | **Bar gauge / State timeline** | Статусы, up/down | Heatmap — лучший способ увидеть бимодальность латенси, которую average и даже p99 скрывают. ### Templating / переменные ```text $job — Query variable: label_values(up, job) $instance — label_values(up{job="$job"}, instance) (зависимый) $interval — Interval variable: 1m,5m,1h ``` ```promql # Панель использует переменные sum by (le) (rate(http_request_duration_seconds_bucket{job="$job", instance=~"$instance"}[$__rate_interval])) ``` - **Query variables** — значения из лейблов (`label_values(...)`), каскадно зависимые. - **Multi-value + `=~"$instance"`** — выбор нескольких значений (регэксп-матч). - **Repeat panels/rows** — одна панель размножается по каждому значению переменной (по инстансу/поду). - **Custom/Interval/Textbox/Datasource** переменные — для гибкости и мульти-кластерных дашбордов. ### Transformations Постобработка результатов на стороне Grafana без изменения запроса: join нескольких queries, organize/rename fields, calculate (добавить вычисляемое поле), group by, filter, reduce. Полезно для table-панелей и комбинирования источников. ### Dashboards as code Кликами собранный дашборд не версионируется и не воспроизводится. Senior-подход: ```json // provisioning/dashboards/payments.json (упрощённо) { "title": "Payments / RED", "templating": { "list": [{ "name": "job", "query": "label_values(up, job)" }] }, "panels": [ { "type": "timeseries", "title": "Rate", "targets": [{ "expr": "sum(rate(http_requests_total{job=\"$job\"}[$__rate_interval]))" }] } ] } ``` ```yaml # provisioning/dashboards/provider.yaml — Grafana подхватывает из папки apiVersion: 1 providers: - name: 'gitops' folder: 'Services' type: file options: { path: /etc/grafana/dashboards } ``` Варианты: file provisioning, **Grafonnet** (Jsonnet-библиотека для генерации JSON), **Terraform provider** (`grafana_dashboard`), хранение JSON в git с code review. Это даёт воспроизводимость, ревью, откат. ### Grafana Alerting (Unified) Современный alerting — отдельная подсистема, единая для всех data sources: - **Alert rule** — запрос (PromQL/LogQL/…) + условие + `for` (как долго держится) → состояния Normal/Pending/Firing. - **Contact points** — куда слать (Slack, PagerDuty, email, webhook). - **Notification policies** — дерево маршрутизации по лейблам алерта (label matching), с **grouping** (схлопывание похожих в одно уведомление), таймингами (`group_wait`, `repeat_interval`). - **Silences** — временное глушение по матчерам (на время maintenance). - **Mute timings** — расписания без уведомлений. Отличие от **legacy alerting**: старый был привязан к панели (один алерт = одна панель, только Prometheus-подобные источники). Unified — независимые rule groups, мульти-источники, multi-dimensional (один rule → много алертов по сериям). Важно: «алерт на панели» в UI ≠ настоящий alert rule. Для прода — alert rules + notification policies, либо вообще Prometheus Alertmanager (Grafana может им рулить). ### Что показывать Иерархия дашбордов (drill-down): 1. **Overview / fleet** — health всех сервисов, золотые сигналы агрегатом, SLO/error budget. 2. **Service dashboard** — RED (Rate/Errors/Duration) для конкретного сервиса + зависимости. 3. **Instance/pod** — USE (CPU/mem/saturation), GC, goroutines, для дебага конкретного инстанса. Best practices: - На каждый сервис — стандартный RED-дашборд (генерируй из шаблона). - Латенси — **перцентили (p50/p90/p99)**, не average; heatmap для распределения. - **Аннотации деплоев** (vertical lines) — мгновенно видно «сломалось после релиза». - Consistent time ranges и единые единицы. - Не перегружать: 6–12 осмысленных панелей лучше 40 шумных. ## Подводные камни / gotchas - **Дашборды кликами не версионируются** — без provisioning/git теряются и не воспроизводятся. - **`$__interval` vs `$__rate_interval`**: `$__interval` зависит от ширины графика и может стать меньше scrape interval → `rate()` даёт дыры/нули. Для `rate()` всегда `$__rate_interval` (учитывает scrape interval). - **`max data points` и downsampling**: Grafana просит у источника ограниченное число точек; при широком окне точки агрегируются и **скрывают пики** (max-spike сглаживается). Для алерт-валидации смотри сырьё. - **Heatmap требует правильного формата**: histogram-метрика с бакетами и правильный режим панели, иначе каша. - **Алерт на панели ≠ alert rule** — панельная индикация не шлёт уведомления через notification policies. - **Misleading average panel**: `avg(latency)` или mean легко рисует «всё хорошо», пряча хвост; ревьюверы дашбордов это ловят. - **Перегруженный дашборд** + много панелей → тормоза браузера и когнитивная перегрузка дежурного. - **Перцентиль из готовых summary-квантилей** (если источник — summary) нельзя агрегировать в панели по инстансам — рисует неправду. - **Variables с `All` и regex** могут раздуть запрос и положить Prometheus тяжёлым PromQL. ## Вопросы на собеседовании **В:** В чём разница `$__interval` и `$__rate_interval` и почему это важно? **О:** `$__interval` вычисляется из ширины панели и `max data points`, может оказаться меньше scrape interval, тогда `rate()` не находит ≥2 точек в окне и рисует дыры. `$__rate_interval` гарантирует окно ≥ ~4× scrape interval, поэтому для `rate()`/`increase()` нужно использовать его. Это та же проблема «правила 4×» из Prometheus, но на стороне Grafana. **В:** Как организовать корреляцию метрик, трейсов и логов в Grafana? **О:** Exemplars в Prometheus-метриках несут trace_id → клик с графика латенси открывает трейс в Tempo; в Tempo trace-to-logs ведёт в Loki по trace_id; в Loki derived fields выдёргивают trace_id из строки лога и дают кнопку в Tempo. Так в одном UI идёшь metric → trace → log, что и есть смысл observability. **В:** Почему дашборды надо хранить как код? **О:** Кликами собранные дашборды не версионируются, не ревьюятся и не воспроизводятся при пересоздании Grafana. Provisioning из git (JSON/Grafonnet/Terraform) даёт code review, откат, единые шаблоны на все сервисы и устойчивость к потере инстанса. Это GitOps-подход к observability. **В:** Чем Unified Alerting отличается от legacy и от Prometheus Alertmanager? **О:** Legacy alerting привязан к панели (один алерт = одна панель, ограниченные источники). Unified — независимые rule groups для любых data sources, multi-dimensional (один rule → много алертов по сериям), с notification policies и contact points. Prometheus Alertmanager делает маршрутизацию/дедуп/группировку на стороне Prometheus; Grafana Unified может его дублировать или управлять им — выбор зависит от того, где живёт источник истины алертов. **В:** Почему стат-панель с average latency опасна? **О:** Среднее скрывает хвост распределения и чувствительно к выбросам; при бимодальном трафике mean может лежать в «пустой» зоне между двумя пиками и показывать «всё хорошо», когда часть пользователей страдает. Нужны перцентили (p99) и heatmap распределения. **В:** Что показывать на дашборде сервиса? **О:** RED: Rate (RPS), Errors (доля 5xx/бизнес-ошибок), Duration (p50/p90/p99 + heatmap). Плюс зависимости (latency/errors downstream), saturation ресурсов (USE), SLO/error budget, и аннотации деплоев. Иерархия overview → service → instance для drill-down. **В:** Как сделать один дашборд для всех инстансов сервиса? **О:** Query variables: `$job = label_values(up, job)`, зависимый `$instance = label_values(up{job="$job"}, instance)`, multi-value с `=~"$instance"` в запросах. Опционально `repeat` панелей по инстансу. Это шаблонизирует дашборд под любой сервис/под без копипасты. ## На что копают на senior+ - **Dashboards-as-code / GitOps**: Grafonnet/Terraform/provisioning, генерация стандартных RED-дашбордов из библиотек, версионирование и ревью. - **Механика `$__rate_interval`** и взаимодействие с scrape interval, max data points и downsampling — почему графики «врут» при больших окнах. - **Корреляция трёх сигналов** в UI (exemplars, trace-to-logs, derived fields) и как это настраивается на уровне data sources. - **Архитектура алертинга**: Grafana Unified vs Prometheus Alertmanager, где источник истины, multiwindow burn-rate алерты, дедуп при HA-паре Prometheus. - **Масштабирование и multi-tenancy**: организация дашбордов/папок, RBAC, datasource per tenant, производительность при сотнях дашбордов/панелей. - **Provisioning безопасности**: read-only provisioned дашборды, секреты data sources, service accounts вместо API keys.