Инфрақұрылымдық командалардың рөлдері

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 for 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 мен өкілеттіксіз.
«stop-кран ретінде security»: «guardrails by design» орнына кейінірек қосу.
«Observability = әдемі графика»: actionable-alert және 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: Platform

14) Енгізу жоспары (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 әдіснаманы, құралды және процесті бақылауды қамтамасыз етеді.

«Көлеңкелі АТ-ны» қалай болдырмау керек?
Қызметтер каталогы, айқын OLAs, жылдам өзін-өзі қызмет көрсету және ашық бағалар (showback/chargeback).

Жиынтығы

Күшті инфрақұрылымдық функция - бұл нақты рөлдер + платформаға азық-түлік тәсілі + интерфейстер мен метриктер бойынша уағдаластықтар. RACI және OLAs-ті белгілеңіз, өзіндік қызмет көрсету мен стандарттарды беріңіз, әрбір рөлдің KPI тиімділігін өлшеңіз және DevEx, SLO және құнын үнемі жақсартыңыз. Бұл операциялық тәуекелдерді төмендетеді, релиздерді жеделдетеді және инфрақұрылымды болжамды етеді.