Руководство: аварии, выкатка, расследование медленных запросов
Runbook аварий
Цель
Снизить MTTR (mean time to recovery), стандартизировать действия дежурных, избежать хаотичных шагов.
Шаги диагностики
-
Фиксация события
- Канал оповещения: Alertmanager → Slack/Telegram/Teams.
- Логируем факт в систему тикетов (Jira/ServiceNow).
- Классификация
- S1: полный простой сервиса BI/DWH.
- S2: деградация (рост латентности, ошибки части запросов).
- S3: локальный баг (отчёт или один коннектор).
- Проверить состояние кластера (kubectl get pods -A, kubectl describe node).
- Метрики: CPU/Mem/IOPS, p95 latency, queue depth.
- Логи: последние 10–15 минут.
- Pod CrashLoopBackOff → проверить секреты/конфиги, пробу liveness.
- OutOfMemory → посмотреть kubectl describe pod, поднять limits или оптимизировать запрос.
- Проблема Ingress/TLS → проверить cert-manager, срок действия сертификата.
- DB connection storm → включить пул соединений, ввести лимиты.
- Если изменения в чартах → helm rollback.
- Если данные повреждены → восстановление из бэкапа.
- Если сеть заблокирована → временно открыть egress с жёстким аудитом.
- Сбор информации
- Типовые сценарии и решения
- Обратимость
Риски
- Паника → хаотичные действия.
- «Тихие» ошибки (часть пользователей жалуется, а мониторинг «зелёный»).
- Неочевидные зависимости (например, BI сломался из-за TLS цепочки).
Playbook выката
Цель
Снизить риск сбоев при релизах, обеспечить трассируемость изменений.
Подготовка
- Все изменения идут через GitOps (ArgoCD/Flux).
- У каждого релиза есть ADR (architecture decision record) и changelog.
- В чарте настроены: ресурсы, пробы, конфиги.
Стратегии выката
- Blue-Green: два окружения, переключение Ingress.
- Canary: часть трафика → новая версия (Ingress/Service Mesh).
- RollingUpdate: постепенное обновление подов.
Шаги
- Создать MR в Git → CI запускает тесты (lint, security scan, smoke-tests).
- ArgoCD синхронизирует состояние в Stage.
- Smoke-test Stage → BI-дэшборды, SQL-запросы.
- Плановый выкат в Prod в окно (обычно утром или вечером в «холодные часы»).
- Наблюдение 30–60 минут: алерты, метрики latency, ошибки BI.
Rollback
- helm rollback или git revert + argo sync.
- При canary — мгновенный «откат трафика».
Риски
- Несогласованность чартов (Dev vs Prod).
- Неполное покрытие тестами → ошибка всплывает в проде.
- Человеческий фактор: выкаты без тикета/ADR.
Гайд по расследованию медленных запросов
Цель
Понять, «узкое место» в кластере: сеть, хранилище, база, планировщик BI.
Шаги
-
Фиксация кейса
- Откуда жалоба: BI-дашборд? SQL в DWH? Экспорт?
- Есть ли SLA по latency (p95)?
- Диагностика
- Метрики CPU/IO на узлах и БД.
- Query log в BI/DWH.
- План выполнения (EXPLAIN / Trino query plan / ClickHouse system.query_log).
- Посмотреть contention (lock, queue depth, merges).
- BI шлёт «SELECT *» без лимитов.
- Нет индекса/партиционирования в ClickHouse/Postgres.
- Слабая пуллинг-конфигурация (каждый запрос открывает новый коннект).
- Сеть/Ingress режет соединения (таймауты).
- Параллельные ETL перегрузили диски.
- Ввести лимиты на BI (timeout, max rows).
- Настроить материализованные витрины.
- Разнести workloads (ETL → отдельный node pool).
- Поднять ресурсы кластера / оптимизировать запрос.
- Типовые причины
- Решения
Риски
- «Затык» на одном сегменте приводит к лавинообразным таймаутам.
- Разработчики BI могут обойти лимиты (прямые коннекты).
- Локализация проблемы растягивается → пользователи недовольны.
Вопрос-ответ
В: А если во время аварии непонятно, кто должен действовать?
О: Уточните RACI: DevOps/SRE → кластер, DBA → база, BI-разработчик → отчёты. В runbook это должно быть явным.
В: Как понять, что делать rollback, а не «дочинить на лету»?
О: Если критический сервис недоступен >10 минут и нет понятного фикс’а за 5 минут — делайте rollback.
В: Как быстро отделить «медленный запрос из-за БД» от «проблем BI»?
О: Запустите тот же SQL напрямую в DWH (psql/clickhouse-client). Если время то же — проблема БД. Если быстрее — проблема в BI (драйвер, визуализация, кэш).
В: Нужно ли каждому сотруднику знать kubectl?
О: Нет. BI-разработчикам достаточно дашборда мониторинга. kubectl — только для платформенной команды и дежурных.
В: Что делать, если после выката пользователи жалуются, но метрики зелёные?
О: Проверить «скрытые» узкие места: пулы соединений, кэш BI, latency на уровне API. Иногда новые версии ломают только часть функционала.
