ინფრასტრუქტურული გუნდების როლები

1) სურათი მთლიანად: რატომ სპეციალიზაცია

პროგნოზირება და სიჩქარე: მკაფიო მფლობელები ამცირებენ „ნაცრისფერ ზონებს“.
საიმედოობა და უსაფრთხოება: პასუხისმგებლობის განაწილება დომენებზე (K8s, ქსელები, მონაცემთა ბაზა, უსაფრთხოება).
ეკონომიკა: FinOps გამოყოფს მოხმარების ღირებულებას და მართავს „ცხრა ფასს“.
Developer Experience: პლატფორმა, როგორც პროდუქტი - თვითდახმარება, შაბლონები, კატალოგები.

2) ძირითადი როლები და პასუხისმგებლობის სფეროები

3) პასუხისმგებლობის საზღვრები (საკუთრების საზღვრები)

პლატფორმა ფლობს პლატფორმის სერვისების L3-L7 დონეს (K8s, ქსელი, observability), მაგრამ არა ბიზნეს ლოგიკა.
SRE ფლობს საიმედოობის პროცესს (SLO/ინციდენტები/პოსტმორტემები), და არა პროდუქტის ბრძანების ყველა კონკრეტული მეტრი.
Release/Delivery ფლობს გამოთვლების მექანიკას, მაგრამ პასუხისმგებლობა „რაც“ არის ასახული - გუნდებს აქვთ fich.
DBRE ფლობს მტევანს/მონაცემთა პოლიტიკოსებს, ხოლო პროდუქტის გუნდი ფლობს სქემას/მიგრაციას (DBRE სტანდარტების შესაბამისად).
SecOps ფლობს პოლიტიკოსებსა და მაკონტროლებლებს, ხოლო განხორციელება - დომენის მფლობელებთან ერთად.

4) ოპერაციული მოდელები

1. ცენტრალიზებული პლატფორმა სწრაფი დასაწყისია, „ბოთლის ყელის“ რისკი.
2. პლატფორმა, როგორც პროდუქტი (PaaP), არის თვითნაკეთი შაბლონები, კატალოგები, სერვისების „შიდა ბაზარი“.
3. ფედერაცია/გილდიები - ექსპერტები შედიან სასურსათო დომენებში (chapter/embedded SRE/DBRE).
4. მატრიცა არის ცენტრის + სტრატეგიული სტანდარტები დომენებში.

რეკომენდაცია: PaaP- ს გაერთიანება ძირითადი საჭიროებებისთვის და კრიტიკული დომენებისთვის.

5) ინტერფეისები და OLAs (შიდა ხელშეკრულებები)

სერვისული კატალოგი: რა არის ხელმისაწვდომი „როგორც მომსახურება“ (K8s namespace, BD მტევანი, რიგი, SLO dashbord, ალერტული პროფილი).
OLA (ოპერატიული ხაზის მოქმედება): რეაქციის დრო, პასუხისმგებლობის ასპარეზები, ესკალაციის წერტილები.
პლატფორმის სერვისების 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: მომსახურების მიწოდების დრო, მომსახურების%, DevEx NPS.
SRE: MTTR/MTTD, SLO შესრულება, პლეიბუკების დაფარვა, მანქანების მიტიგიტების წილი.
CloudOps/NetOps: პერიმეტრის აფთიაქი, ჩენჯის დრო, კონფიგურაციის ინციდენტები.
DBRE: RPO/RTO, აღდგენის წარმატება, რეპლიკაციური lag p95.
Release: კანარის გამოშვებების პროცენტი, გამოტოვება, გარემოცვის დრო.
Observability: სიგნალის სისრულე, მოთხოვნის/დაშბორდის პასუხის დრო, anti-noise ratio.
SecOps: კრიტიკული CVE, MTTD/MTTR უსაფრთხოების ინციდენტების დახურვის დრო, საიდუმლო მენეჯერის გაშუქება.
FinOps: cost სერვისის/RPS, rightsizing savings, სიზუსტის პროგნოზი.

8) ონბორდინგი და DevEx

Start pack: Terraform/Helm შაბლონები, paplines CI/CD, checklists „Hello, Service“.
დოქის პორტალი: სტანდარტები, მაგალითები, „ცოცხალი“ დაშბორდები, Self-Service ღილაკები.
Workshops/office hours: როლები (SRE 101, SecOps 101, DBRE 101).
ესკალაციის პოლიტიკა: ვის უნდა დაურეკოს ღამით და როდის არის საკმარისი თიკეტი.

9) მონაცემთა საკუთრებისა და წვდომის საზღვრები

IAM დაზღვევა: როლების მფლობელები, წვდომის სიცოცხლის ხანგრძლივობა, JIT (just-in-time) ხელმისაწვდომია.
საიდუმლოებები: ცენტრალიზებული საიდუმლო მენეჯერი, როტაცია, საიდუმლოებების აკრძალვა ENV/რეპოში.
Data Ownership: პროდუქტი ფლობს სქემას/დომენის მონაცემებს; DBRE ფლობს „გემს“ (მტევანი და პოლიტიკოსები).

10) პროცესები: ინციდენტები, ცვლილებები, გამოშვებები

ინციდენტები: IC/ომის ოთახი/postmortem (იხ. „ინციდენტები და SRE ფლეიბუკები“).
ცვლილებები (Change Management): risk-based, fast lane დაბალი risk, CAB მხოლოდ მაღალი რანგისთვის.
გამოშვებები: Progressive delivery, freeze წესები შეცდომების ბიუჯეტის დაწვის დროს.

11) ჩეკის ფურცლები როლებით (დაჭერით)

Platform

• სერვისის კატალოგი და SLA პლატფორმის თითოეული მომსახურებისთვის
• IaC + პოლიტიკის შაბლონები (OPA/Conftest)

SRE

• საუკეთესო ბილიკების SLO ბარათები, burn-rate alerty, playbuks

ყოველთვიური ანგარიში არასწორი ბიუჯეტის შესახებ

DBRE

• DR დრილები, აღდგენის ტესტი, RPO/RTO გაფორმებულია

მიგრაციისა და ინდექსაციის პოლიტიკა

SecOps

• დაუცველობისა და პატჩის ფანჯრების სამმაგი
• DLP/PII კონტროლი, აუდიტის წვდომა

Release

• კანარის ნაბიჯები ნაგულისხმევი, მანქანა-როლბაკი
• Fich დროშები და kill-switch

Observability

• მეტრული/ეტიკეტის სტანდარტები, budget-deshbords
• Anti-noise (-- rum, multi-window), SLO ვიჯეტები

FinOps

• Chargeback/showback, rightsizing რეკომენდაციები
• „Cost per 9“, პროგნოზირება

12) ორგანიზაციის ანტი-შაბლონები

„DevOps არის ადამიანი“: „ვაგონების“ გადატვირთვა, დომენის მფლობელების არარსებობა.
„პლატფორმა = ბილეთის სალარო“: ყველაფერი სახელმძღვანელო თიკეტების საშუალებით, არ არსებობს თვითნაკეთი მომსახურება.
„SRE = მოვალეობის შემსრულებლები“: SLO და უფლებამოსილების გარეშე.
„უსაფრთხოება, როგორც გაჩერების ამწე“: მოგვიანებით ჩართვა, ნაცვლად „guardrails by design“.
„Observability = ლამაზი გრაფიკები“: actionable-alerts და 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. FinOps და ოპტიმიზაცია (მუდმივად): chargeback, rightsizing, „cost per 9“, ავტო პოლიტიკა.

15) მინი-FAQ

სად უნდა შეინახოთ SRE - პლატფორმაში ან პროდუქტებში?
ჰიბრიდი: სტრატეგიული SRE პლატფორმაში, კრიტიკულ დომენებში embedded-SRE.

ვინ ფლობს SLO სერვისებს?
სასურსათო ბრძანებები. SRE უზრუნველყოფს მეთოდოლოგიას, ტესტირებას და პროცესის კონტროლს.

როგორ ავარიდოთ თავი „ჩრდილის IT“?
მომსახურების კატალოგი, რომელიც აშკარაა OLAs- ით, სწრაფი თვითგამორკვევა და გამჭვირვალე ფასები (showback/chargeback).

შედეგი

ძლიერი ინფრასტრუქტურული ფუნქცია არის მკაფიო როლები + სასურსათო მიდგომა პლატფორმაზე + ხელშეკრულებები ინტერფეისებსა და მეტრიკებზე. დააფიქსირეთ RACI და OLAs, მიეცით თვითგამორკვევა და სტანდარტები, გაზომეთ ეფექტურობა KPI- ს თითოეული როლის მიხედვით და რეგულარულად გააუმჯობესეთ DevEx, SLO და ღირებულება. ეს შეამცირებს ოპერაციულ რისკებს, დააჩქარებს გამოშვებებს და ინფრასტრუქტურას პროგნოზირებს.