Чек-лист: готовность BI/MDM/Каталога к контейнерам, сети, SSO и лицензиям
Как пользоваться
- Идите по разделам слева направо (базовая контейнеризация → сеть → SSO → лицензии → эксплуатация).
- Для каждого вопроса фиксируйте доказательства (мануал, Helm-чарт, матрица совместимости, скрины).
- В конце заполните скоринговую матрицу (шаблон ниже) — получите быстрый «да/нет/риски/доработки».
Контейнеризация и модель поставки
Образы и реестры
Спросить: Где хостятся образы? Есть ли версии для air-gapped? Подпись образов (cosign/Sigstore)? SBOM?
Хорошо: Образы в публичном/частном реестре + офлайн-bundle; подпись и SBOM; чёткий цикл релизов и CVE-SLA.
Риск: «Доставляем .tar раз в год», нет подписи, нет SBOM; нет политики по CVE.
Права контейнера
Спросить: Работаете ли без root? Нужны ли CAP_SYS_ADMIN, hostPath, privileged?
Хорошо: non-root, минимальные capabilities, без hostPath; готовые примеры PodSecurity/Kyverno.
Риск: Требуют privileged/hostNetwork «для всего».
Kubernetes-артефакты
Спросить: Есть ли Helm-чарт/Kustomize, CRD/Operator? Пробы liveness/readiness/startup? PVC?
Хорошо: Официальные чарты с values для SSO, DB, TLS, ресурсов; поддержка SSA; примеры PDB/HPA.
Риск: «Запустите docker run и будет работать», YAML «на коленке».
Хранилище и состояние
Персистентность
Спросить: Что хранится в данных? Поддержка PVC (RWO) и storageClass с WaitForFirstConsumer? Рекламации при потере диска?
Хорошо: Чёткий список томов, совместимость c CSI, ReclaimPolicy=Retain, бэкап-гайд.
Риск: Данные в emptyDir/NFS (RWX) «для БД», нет восстановления.
Бэкапы/восстановление
Спросить: Инструменты (pgBackRest/WAL-G/clickhouse-backup/собственные), расписание, тест восстановления?
Хорошо: Описанные RPO/RTO, холодное восстановление в новом namespace, sample-runbook.
Риск: «Снимайте снапшоты VM — как-нибудь».
Сеть, публикация и egress
Ingress/маршрутизация
Спросить: Поддерживаемые контроллеры (ingress-nginx/HAProxy/Traefik/Gateway API), WebSocket/HTTP2/gRPC? Sticky-сессии?
Хорошо: Таблица совместимости, аннотации/CR для таймаутов, заголовков, размер тел.
Риск: Только «встроенный nginx» и мануальный правки конфигов.
TLS
Спросить: Прозрачная работа с cert-manager, цепочки доверия, клиентские сертификаты (mTLS), ротация секретов?
Хорошо: Док по интеграции с cert-manager, поддержка mTLS, горячая ротация.
Риск: Ручная подмена tls.crt «по SSH».
NetworkPolicy/mesh
Спросить: Есть список необходимых портов/направлений? Работает ли за mTLS (Istio/Linkerd)?
Хорошо: «Белый список» egress, готовые NetworkPolicy (DNS/мониторинг/DB/кэш).
Риск: Нужен открытый интернет 0.0.0.0/0 для телеметрии/лицензии.
Прокси и офлайн-режим
Спросить: Поддержка корпоративного HTTP(S)-proxy, офлайн-активаций, каталога корневых сертификатов?
Хорошо: Настройки HTTPS_PROXY/NO_PROXY, офлайн-bundle, установка корневых CA.
Риск: Жёсткая зависимость от внешних API без прокси/кэшей.
Аутентификация, авторизация и SSO
Протоколы и провайдеры
Спросить: Поддержка OIDC, SAML 2.0, LDAP/AD, SCIM (провиженинг)?
Хорошо: Любой из OIDC/SAML + SCIM, тестовые профили Okta/Keycloak/ADFS, маппинг групп/ролей.
Риск: Только «локальные пользователи» или базовый LDAP без групп.
RBAC/ABAC
Спросить: Как права назначаются? Есть row/column-level (для BI), data-domain/role (для MDM/каталога)?
Хорошо: Гранулярные роли, наследование, импорт из SSO-групп.
Риск: «Админ или никто», права в базе без синка с IdP.
Сессии/токены
Спросить: TTL сессии, refresh, принудительный logout, аудит входов?
Хорошо: Конфигурируемые TTL, single-logout, аудит (кто/откуда/когда).
Риск: Вечные куки и нет аудита.
Наблюдаемость и эксплуатация
Метрики/логи/трейсинг
Спросить: Экспорт Prometheus (endpoint, названия метрик), health endpoints, логи в stdout (JSON), OpenTelemetry?
Хорошо: /metrics с label’ами тенанта/реплики; логи — stdout; трейсинг — OTLP/Jaeger.
Риск: Логи только в файл внутри контейнера; «свой формат» без документации.
Готовность к k8s-жизни
Спросить: Пробы (readiness/startup), graceful shutdown, idempotent старт, совместимость с HPA/VPA?
Хорошо: Док по пробам, параметры таймаутов, «холодный старт» < заданного SLO.
Риск: Нестабильные пробы → «флаппинг» подов.
Производительность и масштабирование
Масштабирование
Спросить: Stateless-шардинг/репликация? Поддержка горизонтального масштабирования компонентов (web/API/worker)?
Хорошо: Чёткая reference-архитектура: «x web + y workers + z координатор».
Риск: Один монолит — «вертикально на 64 ядра и всё».
Пулы соединений и кэш (BI/MDM-особенности)
Спросить: Pooling к БД, кэш слоёв, ограничения по concurency, очереди задач?
Хорошо: Конфигурируемые пулы/квоты, защита БД от «штормов», лимиты экспорта/отчётов.
Риск: Неограниченные коннекты → падения DWH.
Лицензирование и комплаенс
Модель лицензии
Спросить: Как считается — «per-user», «per-core», «per-container», «per-cluster»? Нужна ли отдельная лицензия на HA/DR/шардинг?
Хорошо: Прозрачная модель, dev/test лицензии, BYOL для облаков, офлайн-активация и HA лиценз-сервер.
Риск: Лицензия «per-VM» без понимания k8s; «привязка к MAC/hostname».
Аудит и правовая база
Спросить: Audit-лог действий, хранение персональных данных, матрица соответствия (GDPR/152-ФЗ и т.п.)?
Хорошо: Встроенный аудит (CRUD, входы), экспорт в SIEM, настройка ретенции.
Риск: Нет аудита/ретенции/маскировки данных.
Обновления, совместимость и поддержка
Совместимость с версиями k8s
Спросить: Поддерживаемые версии Kubernetes/CNI/Ingress/DB; график EOL; деприкации API?
Хорошо: Матрица совместимости, релиз-ноты, стратегия апгрейда (canary/blue-green).
Риск: «Работает на 1.21, остальное не знаем».
Поддержка и SLA
Спросить: Каналы поддержки, SLA на реакцию, workaround-гайды, база знаний?
Хорошо: 24×7 для критики, шаблоны RCA, библиотека «best practices».
Риск: Только e-mail «в рабочие дни».
BI-специфика (добавить к общим вопросам)
- Семантический слой/Роллевая фильтрация (RLS/CLS): как управлять через SSO, как версионировать (Git)?
- Планировщик отчетов/экспорт: SMTP/файловые экспорты в S3/NAS, лимиты на рассылку, ретраи и аудит.
- Кэширование/Query pushdown: есть ли кэш витрин, invalidate по расписанию/событию, лимиты на тяжелые запросы.
- Совместимость драйверов: Postgres/ClickHouse/Trino/ODBC/JDBC версии, пул соединений.
Красные флаги: рассылка «из контейнера» без S/MIME/DMARC; бесконечные запросы без таймаутов; кэш — только в памяти контейнера.
MDM/Каталог-специфика
- Роли стюардов/владельцев: разграничение операций (approve/merge/retire), аудит изменений.
- Интеграции: REST/GraphQL, OpenLineage/Marquez, импорт/экспорт метаданных (CSV/JSON), коннекторы к S3/БД.
- Качество данных (DQ): встроенные правила/профайлинг, отчеты, web-hooks/шины событий.
- Workflow и задачи: SLA задач, нотификации, интеграция с SSO-группами.
Красные флаги: workflow «провязан» на локальные пользователи; нет экспорта/импорта метаданных.
Эксплуатация и безопасность по умолчанию
- Секреты: поддержка External Secrets Operator/Vault/CSI, ротация ключей.
- Политики: примеры NetworkPolicy, Pod Security (baseline/restricted), образ без уязвимостей «вчерашней давности».
- Runbooks: «пропали пробы», «сломался Ingress», «закончился сертификат», «очередь отчетов переполнена».
Шаблон скоринга (сводная таблица)
|
Направление |
Вопрос/критерий |
Оценка (0–2) |
Доказательство/комментарий |
Риск/план действий |
|---|---|---|---|---|
|
Контейнеризация |
Образы подписаны, есть SBOM |
|||
|
Сеть/TLS |
Поддержка mTLS/Ingress аннотаций |
|||
|
SSO/RBAC |
OIDC/SAML + SCIM, групповой маппинг |
|||
|
Хранилище |
PVC RWO + бэкап/restore-гайд |
|||
|
Наблюдаемость |
/metrics + stdout JSON + OTEL |
|||
|
Лицензии |
Модель, офлайн, HA licensing |
|||
|
Совместимость |
Матрица версий k8s/CNI/DB |
|||
|
Эксплуатация |
Helm-чарт, пробы, PDB/HPA |
Интерпретация: 0 — нет/красный флаг; 1 — частично/есть обход; 2 — соответствует best practice.
Сумма <60% → «только пилот в песочнице», 60–80% → «стейдж + оговорки», >80% → «готово к прод при внедрении политик».
Мини-примеры (проверки без кода)
- Ingress: проверьте WebSocket/HTTP2: публикация демо-страницы, Upgrade: websocket — работает?
- Метрики: откройте /metrics в тестовом стенде — есть ли бизнес-метрики (очереди, jobs), а не только тех.
- SSO: создайте тестовую группу в IdP, назначьте роль в продукте — применяется ли автоматически?
Вопрос-ответ
В: «У нас всё работает в Docker — значит, в Kubernetes тоже». Достаточно?
О: Нет. Docker ≠ k8s. Нужны пробы, PVC, политика завершения, масштабирование, наблюдаемость, Helm/Kustomize. Просите официальный чарт/гайд и подтверждение работы под NetworkPolicy/PodSecurity.
В: Вендор требует RWX/NFS для базы — это нормально?
О: Для stateful-БД — почти всегда плохая идея: блокировки, деградации. Требуйте RWO-диски/CSi и гайд на бэкапы/restore. RWX — только для общих файлов/экспортов.
В: Продукту нужен свободный доступ в интернет. Что делать в «закрытом» контуре?
О: Спрашивайте перечень доменов/портов, офлайн-активации, зеркала/репозитории, egress-gateway/прокси. Без этого — высокий операционный риск.
В: Нет SCIM — как жить?
О: Возможно синк групп через периодический импорт или LDAP-маппинг, но это хрупко. Закладывайте трудозатраты/риски и планируйте доработку/замену.
В: Лицензия «per-VM», а у нас k8s.
О: Проясните метрику: per-node/per-core/per-pod/per-cluster. Иначе при горизонтальном масштабе счёт может «взорваться». Ищите BYOL/кластерную модель.
В: Метрик мало, только «жив/не жив».
О: Требуйте Prometheus-экспорт ключевых счётчиков: очереди задач, латентности, ошибки коннекторов, статус кэша. Иначе SLO и алерты будут «слепыми».
В: Вендор против non-root.
О: Минимум — док с обоснованием и список нужных capabilities. В идеале — non-root образ. Иначе — конфликт с PodSecurity/Gatekeeper.
В: Как быстро понять, что продукт «сядет» на наши политики?
О: Пилот в изолированном ns: включить default-deny NetworkPolicy, PodSecurity baseline/restricted, TLS через cert-manager, SSO OIDC. Если заводится без ручных хаков — плюс к скору.
Сильный вендор показывает готовые артефакты (Helm-чарт, матрица совместимости, SBOM/подпись, гайд на SSO/TLS/PVC/бэкапы) и не требует опасных привилегий/открытого интернета. Используйте чек-лист и скоринг, чтобы быстро отделить «готово к прод» от «только песочница», и заранее снизить риски стоимости, безопасности и доступности.
