Роли инфраструктурных команд
1) Картина целиком: зачем специализация
Предсказуемость и скорость: четкие владельцы уменьшают «серые зоны».
Надежность и безопасность: распределение ответственности по доменам (K8s, сети, БД, безопасность).
Экономика: FinOps отделяет стоимость от потребления и управляет «ценой девяток».
Developer Experience: платформа как продукт — самосервис, шаблоны, каталоги.
2) Основные роли и зоны ответственности
3) Границы ответственности (границы владения)
Платформа владеет уровнями L3–L7 платформенных сервисов (K8s, сетка, observability), но не бизнес-логикой.
SRE владеет процессом надежности (SLO/инциденты/постмортемы), а не каждой конкретной метрикой команды продукта.
Release/Delivery владеет механикой выкладок, но ответственность за «что» выкладывается — у команд фич.
DBRE владеет кластерами/политиками данных, а схемой/миграциями владеет команда продукта (по стандартам DBRE).
SecOps владеет политиками и контролями, а внедрение — совместно с владельцами доменов.
4) Операционные модели
1. Централизованная платформа — быстрый старт, риск «бутылочного горлышка».
2. Платформа как продукт (PaaP) — самосервисные шаблоны, каталоги, «внутренний маркетплейс» сервисов.
3. Федерация/Гильдии — эксперты встраиваются в продуктовые домены (chapter/embedded SRE/DBRE).
4. Матрица — стратегические стандарты центра + исполнение в доменах.
Рекомендация: сочетать PaaP для базовых потребностей и embedded для критичных доменов.
5) Интерфейсы и OLAs (внутренние соглашения)
Сервис-каталог: что доступно «как услуга» (K8s namespace, БД-кластер, очередь, дашборд SLO, алерт-профиль).
OLA (Operational Level Agreement): сроки реакций, арены ответственности, точки эскалаций.
SLO-карточки платформенных сервисов: доступность, латентность API, время развертывания из шаблона.
yaml service: "Kubernetes Namespace Provisioning"
owner: "Platform"
request_channel: "Service Catalog"
targets:
response_time: "≤ 15 min"
delivery_time: "≤ 1 hour (without manual approvals)"
scope:
includes: "quota, RBAC, secrets integration"
excludes: "business configs, database migrations"
escalation: "#plat-ops-oncall"6) RACI: кто делает что
Легенда: R — выполняет, A — отвечает, C — консалтинг, I — информируется.
7) KPI и метрики эффективности по ролям
Platform: lead time на предоставление сервиса, %самосервиса, DevEx NPS.
SRE: MTTR/MTTD, выполнение SLO, покрытие плейбуками, доля авто-митигейтов.
CloudOps/NetOps: аптайм периметра, время выполнения ченджей, инциденты по конфигурации.
DBRE: RPO/RTO, успешность восстановлений, репликационный лаг p95.
Release: процент канареечных релизов, rate откатов, время окружений.
Observability: полнота сигналов, время ответа запросов/дашбордов, anti-noise ratio.
SecOps: время закрытия критических CVE, MTTD/MTTR инцидентов безопасности, охват секрет-менеджером.
FinOps: cost per service/RPS, rightsizing savings, прогноз точности.
8) Онбординг и DevEx
Start pack: шаблоны Terraform/Helm, пайплайны CI/CD, checklists «Hello, Service».
Док-портал: стандарты, примеры, «живые» дашборды, кнопки Self-Service.
Воркшопы/office hours: по ролям (SRE 101, SecOps 101, DBRE 101).
Политика эскалаций: кого звать по ночам и когда достаточно тикета.
9) Границы владения данных и доступов
IAM-страховка: владельцы ролей, срок жизни доступов, JIT (just-in-time) доступы.
Секреты: централизованный секрет-менеджер, ротация, запрет секретов в ENV/репо.
Data Ownership: продукт владеет схемой/данными домена; DBRE владеет «сосудом» (кластерами и политиками).
10) Процессы: инциденты, изменения, релизы
Инциденты: IC/war-room/постмортем (см. «Инциденты и SRE-плейбуки»).
Изменения (Change Management): risk-based, fast lane для low risk, CAB только для high risk.
Релизы: progressive delivery, freeze-правила при сгорании бюджета ошибок.
11) Чек-листы по ролям (выжимка)
Platform
- Сервис-каталог и SLA по каждому сервису платформы
- Шаблоны IaC + политики (OPA/Conftest)
SRE
- SLO-карточки топ-путей, burn-rate алерты, плейбуки
- Ежемесячный отчет по ошибочному бюджету
DBRE
- DR-дрили, тест восстановления, RPO/RTO подписаны
- Политики миграций и индексации
SecOps
- Триаж уязвимостей и патч-окна
- DLP/PII-контроли, аудит-доступы
Release
- Канареечные шаги по умолчанию, авто-rollback
- Фича-флаги и kill-switch
Observability
- Стандарты метрик/лейблов, budget-дэшборды
- Anti-noise (quorum, multi-window), SLO-виджеты
FinOps
- Chargeback/showback, rightsizing-рекомендации
- «Cost per 9», прогнозирование
12) Анти-паттерны организации
«DevOps — это человек»: перегруз «универсалов», отсутствие владельцев доменов.
«Платформа = билетная касса»: все через ручные тикеты, нет самосервиса.
«SRE = дежурные пожарные»: без SLO и полномочий.
«Security как стоп-кран»: позднее включение, вместо «guardrails by design».
«Observability = красивые графики»: без actionable-алертов и SLO.
«FinOps только про отчет»: без рекомендаций и auto-rightsizing.
13) Шаблоны артефактов
Шаблон карточки платформенной услуги
yaml service: "Managed PostgreSQL"
owner: "DBRE"
plan: "S, M, L"
slo:
availability: "99. 95 %/quarter"
rpo: "≤ 5 min"
rto: "≤ 15 min"
interfaces:
request: "Service Catalog → Postgres"
incidents: "#dbre-oncall"
changes: "Change Policy L2"
security:
secrets: "Vault"
access: "JIT/RBAC"
finops:
pricing: "по vCPU/GB/IOPS"
limits: "quota per tenant"Мини-RACI для релизов
yaml release:
strategy: canary
R: Release/Delivery
A: Product Owner
C: SRE, SecOps
I: Platform14) План внедрения (4 итерации)
1. Стандартизация (2–3 недели): карта ролей, каталога услуг, RACI, OLAs, каналы эскалаций.
2. DevEx (3–4 недели): сервис-каталог, шаблоны CI/CD, Terraform-модули, базовые SLO/дашборды.
3. Надежность и безопасность (4–6 недель): плейбуки инцидентов, DR-дрили, WAF/DLP, секрет-менеджер.
4. ФинОпс и оптимизация (непрерывно): chargeback, rightsizing, «cost per 9», авто-политики.
15) Мини-FAQ
Где держать SRE — в платформе или в продуктах?
Гибрид: стратегический SRE в платформе, embedded-SRE в критичных доменах.
Кто владеет SLO сервисов?
Продуктовые команды. SRE обеспечивает методологию, tooling и контроль процесса.
Как избежать «теневых ИТ»?
Каталог услуг, явные OLAs, быстрый самосервис и прозрачные цены (showback/chargeback).
Итог
Сильная инфраструктурная функция — это четкие роли + продуктовый подход к платформе + договоренности по интерфейсам и метрикам. Зафиксируйте RACI и OLAs, дайте самосервис и стандарты, измеряйте эффективность по KPI каждой роли и регулярно улучшайте DevEx, SLO и стоимость. Это снизит операционные риски, ускорит релизы и сделает инфраструктуру предсказуемой.