Infrastructure Team Roles

1) The whole picture: why specialize

Predictability and speed: clear owners reduce "gray areas."

Reliability and security: distribution of responsibility by domains (K8s, networks, DB, security).

Economics: FinOps separates value from consumption and manages the "price of nines."

Developer Experience: platform as a product - self-service, templates, catalogs.

2) Key roles and responsibilities

3) Boundaries of responsibility (boundaries of ownership)

The platform owns the levels of L3-L7 platform services (K8s, grid, observability), but not business logic.
SRE owns the reliability process (SLO/incidents/post-mortems) rather than each specific product team metric.
Release/Delivery owns the mechanics of the calculations, but the responsibility for "what" is laid out is with the feature commands.
DBRE owns the clusters/data policies, and the schema/migrations are owned by the product team (according to DBRE standards).
SecOps owns policies and controls, and implementation is shared with domain owners.

4) Operational models

1. Centralized platform - fast start, bottleneck risk.
2. Platform as a product (PaaP) - self-service templates, catalogs, "internal marketplace" of services.
3. Federation/Guilds - experts are embedded in product domains (chapter/embedded SRE/DBRE).
4. Matrix - strategic standards of the center + execution in domains.

Recommendation: combine PaaP for basic needs and embedded for critical domains.

5) Interfaces and OLAs (internal agreements)

Service directory: what is available "as a service" (K8s namespace, database cluster, queue, SLO dashboard, alert profile).
OLA (Operational Level Agreement): reaction dates, responsibility arenas, escalation points.
SLO cards of platform services: availability, API latency, deployment time from the template.

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: who does what

Legend: R - performs, A - responds, C - consulting, I - informed.

7) KPIs and performance metrics by role

Platform: lead time for service provision,% self-service, DevEx NPS.
SRE: MTTR/MTTD, SLO execution, playbook coverage, auto-mitigate share.
CloudOps/NetOps: perimeter uptime, changey runtime, configuration incidents.
DBRE: RPO/RTO, recovery success, replication lag p95.
Release: percentage of canary releases, rate of rollbacks, time of environments.
Observation: completeness of signals, response time of requests/dashboards, anti-noise ratio.
SecOps: closing time for critical CVEs, MTTD/MTTR security incidents, secret manager coverage.
FinOps: cost per service/RPS, rightsizing savings, accuracy prediction.

8) Onboarding and DevEx

Start pack: Terraform/Helm templates, CI/CD pipelines, "Hello, Service" checklists.
Docking portal: standards, examples, "live" dashboards, Self-Service buttons.
Workshops/office hours: by role (SRE 101, SecOps 101, DBRE 101).
Escalation policy: who to call at night and when a ticket is enough.

9) Boundaries of data ownership and access

IAM insurance: role owners, access life, JIT (just-in-time) access.
Secrets: centralized secret manager, rotation, prohibition of secrets in ENV/repo.
Data Ownership: the product owns the schema/data of the domain; DBRE owns the "vessel" (clusters and policies).

10) Processes: incidents, changes, releases

Incidents: IC/war-room/postmortem (see Incidents and SRE playbooks).
Change Management: risk-based, fast lane for low risk, CAB for high risk only.
Releases: progressive delivery, freeze rules when burning budget errors.

11) Checklists by role (squeeze)

Platform

• Service directory and SLA for each platform service
• IaC + Policy Templates (OPA/Conftest)

SRE

• SLO-cards of top paths, burn-rate alerts, playbooks
• Monthly erroneous budget report

DBRE

• DR drills, recovery test, RPO/RTO signed
• Migration and Indexing Policies

SecOps

• Triage of vulnerabilities and patch windows
• DLP/PII controls, audit accesses

Release

• Default Canary Steps, auto-rollback
• Feature flags and kill-switch

Observability

• Metrics/Label Standards, Budget Dashboards
• Anti-noise (quorum, multi-window), SLO widgets

FinOps

• Chargeback/showback, rightsizing recommendations
• "Cost per 9," forecasting

12) Anti-organization patterns

"DevOps is a man": overload of "generalists," lack of domain owners.
"Platform = ticket office": all through manual tickets, no self-service.
"SRE = firefighters on duty": without SLO and authority.

"Security as stopcock": later inclusion, instead of "guardrails by design."

"Observability = beautiful graphs": without actionable-alerts and SLOs.
"FinOps only about the report": without recommendations and auto-rightsizing.

13) Artifact patterns

Platform Service Card Template

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"

Mini RACI for releases

yaml release:
strategy: canary
R: Release/Delivery
A: Product Owner
C: SRE, SecOps
I: Platform

14) Implementation plan (4 iterations)

1. Standardization (2-3 weeks): role map, service catalog, RACI, OLAs, escalation channels.
2. DevEx (3-4 weeks): service catalog, CI/CD templates, Terraform modules, basic SLO/dashboards.
3. Reliability and security (4-6 weeks): incident playbooks, DR drills, WAF/DLP, secret manager.
4. FinOps and optimization (continuous): chargeback, rightsizing, "cost per 9," auto-policies.

15) Mini-FAQ

Where to keep SRE - in the platform or in products?
Hybrid: strategic SRE in the platform, embedded-SRE in critical domains.

Who owns SLO services?
Product teams. SRE provides methodology, tooling, and process control.

How to avoid "shadow IT"?
Service catalog, explicit OLAs, fast self-service and transparent pricing (showback/chargeback).

Total

A strong infrastructure function is clear roles + a product approach to the platform + agreements on interfaces and metrics. Capture RACIs and OLAs, give self-service and standards, measure performance against KPIs of each role, and regularly improve DevEx, SLO, and cost. This will reduce operational risks, speed up releases and make infrastructure predictable.