GH GambleHub

ოპერაციებში როლები და მოვალეობები

1) რატომ უნდა შევინარჩუნოთ როლები

როლების მკაფიო განაწილება ამცირებს MTTA/MTTR- ს, აღმოფხვრის „ნაცრისფერ ზონებს“, აჩქარებს გამოშვებებს და SLO/შესაბამისობას რეპროდუქციულად აქცევს. როლები = პასუხისმგებლობა + უფლებამოსილება + ინტერფეისები (ვის ვწერთ, ვინ ვართ ესკალაცია, რა გადაწყვეტილებები არის უფლებამოსილი).

2) ძირითადი RACI მოდელი

R (Responsible) - ასრულებს სამუშაოს.
A (Accountable) - საბოლოო პასუხისმგებლობა ეკისრება და იღებს გადაწყვეტილებებს.
C (კონსულტაცია) - ექსპერტი, კონსულტაციებს უწევს/დროს.
მე (ინფორმირებული) - ინფორმაცია SLA- ს მიხედვით.

ზედა დონის მაგალითი:
პროცესიARCI
ინციდენტები (SEV-1/0)ICP1/P2, SRE, Owning TeamSecurity, Product, DataMgmt, Support
გამოშვებებიRelease Manager/OwnerDev, Platform/SRESecurity, QASupport, Mgmt
ცვლილებები (RFC/CAB)CAB ChairService OwnerSecurity, SRE, DataAffected teams
მომსახურების ფანჯრებიService OwnerPlatform/SREProduct, SupportCustomers/Partners
პოსტ-mortemaRCA LeadOwning Team, ScribeSecurity, Data, ProductMgmt

3) როლების კატალოგი (აღწერილობა და მოვალეობები)

3. 1 Incident Commander (IC)

მიზანი: ხელმძღვანელობს რეაგირებას SEV-1/0 ინციდენტზე.
უფლებამოსილება: SEV- ს გამოცხადება, გამოშვებების გაყინვა, ტრაფიკის გადართვა, ესკალაცია.
ძირითადი ამოცანები: დრო, გადაწყვეტილების მიღება, ფოკუსის შენარჩუნება, დავალებების განაწილება, Go/No-Go.
არტეფაქტები: ინციდენტის ბარათი, SLA განახლება, საბოლოო AAR.

3. 2 P1/P2 On-Call (Primary/Secondary)

მიზანი: პირველადი პასუხი და ტექნიკური მოქმედებები.
P1: სამჯერ, ფლეიბუკების გაშვება, კომუნიკაცია IC- სთან.
P2: bacap, რთული ცვლილებები, კონტექსტის შენარჩუნება, ქარიშხლის დროს - იღებს საბითუმო ნაკადს.

3. 3 SRE / Platform Engineer

მიზანი: პლატფორმისა და მოაჯირის საიმედოობა (SLO, ალერტები, GitOps, სკეიტი, DR).
დავალებები: SLI/SLO, ალერტული ჰიგიენა, პროგრესული გამოშვებები, ინფრასტრუქტურა, როგორც კოდი, capacity, observability.
ინციდენტის დროს: ფესვის დიაგნოზი, გამოტოვება/ხალხური, degrade-UX ჩართვა.

3. 4 Service Owner / Product Owner

მიზანი: მომსახურების ხარისხი ბიზნეს გაგებით.
დავალებები: SLO/პრიორიტეტების განსაზღვრა, გამოშვებების/ფანჯრების კოორდინაცია, მონაწილეობა Go/No-Go.
კომსი: გადაწყვეტილება, როდის და რა უნდა ეთქვა მომხმარებლებს კომსომთან ერთად.

3. 5 Release Manager

მიზანი: ცვლილებების უსაფრთხო მიწოდება.
დავალებები: გამოშვებების ორკესტრი, კარიბჭის ჩეკის კარიბჭე, კანარი/ცისფერი-მწვანე, გამოშვების ჩანაწერები, ინციდენტების დროს უფასო.

3. 6 CAB Chair / Change Manager

მიზანი: ცვლილების რისკის მართვა.
დავალებები: RFC პროცესი, გეგმა/backout, კონფლიქტების კალენდარი, მაღალი რანგის დამტკიცება.

3. 7 RCA Lead / Problem Manager

მიზანი: პოსტ-ინციდენტის ანალიზი, CAPA.
დავალებები: დრო, მტკიცებულება, გამოსწორება/თავიდან აცილება, კონტროლი D + 14/D + 30.

3. 8 Security (IR Lead, AppSec/CloudSec)

მიზანი: უსაფრთხოება და რეაგირება უსაფრთხოების ინციდენტებზე.
დავალებები: უსაფრთხოების მოვლენები, გასაღებების როტაცია, იზოლაცია, წინსვლა, მარეგულირებელი შეტყობინებები, WORM აუდიტი.

3. 9 DataOps / Analytics

მიზანი: მონაცემთა და იპლინების საიმედოობა.
დავალებები: სიახლე/ხარისხი (DQ), მონაცემთა კონტრაქტები, ხაზები, ზურგჩანთები, SLA BI/მოხსენებები.

3. 10 FinOps

მიზანი: მართვადი ღირებულება.
დავალებები: კვოტები/ლიმიტები, ანგარიშები/ერთეული, ბიუჯეტის კარიბჭეები, ოპტიმიზაცია (ლოგიკური მოცულობა, გაზი, სარეზერვო).

3. 11 Compliance / Legal

მიზანი: რეგულირებისა და კონტრაქტების შესაბამისობა.
დავალებები: შეტყობინებების დრო, რეცენზიები/ვადების უცვლელი, საჯარო ტექსტების კოორდინაცია.

3. 12 Support / Comms

მიზანი: კომუნიკაცია მომხმარებლებთან/შიდა სტეიკჰოლდერთან.
დავალებები: სტატუსის გვერდი, აპდეიტის განლაგება, შეტყობინებების სიხშირე და სიცხადე, უკუკავშირის შეგროვება.

3. 13 Vendor Manager / Provider Owner

მიზანი: ურთიერთობა გარე პროვაიდერთან (PSP/KYC/CDN და ა.შ.).
დავალებები: ესკალაცია, SLA/OLA, სარეზერვო მარშრუტები, ფანჯრების კოორდინაცია.

4) როლები ცვლაში და ესკალაციაში

ცვლილება: P1/P2 + IC-of-day (არ აერთიანებს P1- ს).
დროის ესკალაცია: P1 - P2 (5 წთ გარეშე ack), IC (10 წთ), Duty Manager (15 წთ).
Quiet Hours: P2/P3 სიგნალები არ იღვიძებს; უსაფრთხოების სიგნალები ყოველთვის.

5) ურთიერთქმედების ინტერფეისები (ვინ ვისთან და როგორ)

IC - Release Manager: freeze/rollback გადაწყვეტილებები.
IC - Comms: Apdate ტექსტები და სიხშირე.
SRE - DataOps: ბიზნეს SLI (გადახდების წარმატება, მონაცემთა სიახლე) SLO გარდერობებში.
Security Legal: შეტყობინებები უსაფრთხოების ინციდენტების შესახებ, შეტყობინებების დრო.
Vendor Owner - IC: პროვაიდერის სტატუსი, switchover/folback.

6) KPI როლებით (სახელმძღვანელოები)

IC: Time-to-Declare, შესაბამისობა Comms SLA, MTTR SEV-1/0.
P1/P2: MTTA, Time-to-First-Action, playbooks%.
SRE/Platform: SLO coverage, Alert Hygiene, მანქანის გამოტოვების% წარმატებულია.
Release Manager: Change Failure Rate, On-time windows, Mean Rollback Time.
RCA Lead: Postmortem Lead Time, CAPA Completion/Overdue, Reopen ≤ 5–10%.
Security: Mean Time to Contain, Secret/Cert Rotation Time.
DataOps: Freshness SLO Adherence, Success Rate ზურგჩანთები.
Comms: Status Accuracy, Complaint Rate/ინციდენტი.
FinOps: $/ერთეული, QoQ დაზოგვის%, კვოტების დაცვა.

7) როლების ბარათების შაბლონები

7. 1 IC ბარათი


Role: Incident Commander
Scope: SEV-1/0 (prod)
Decisions: declare SEV, freeze deploy, traffic shift, rollback/failover
Runbooks: rb://core/ic, rb://comms/status
SLA: TTD ≤10m, first comms ≤15m, updates q=15–30m
Escalations: Duty Manager (15m), Exec On-call (30m)

7. 2 ბარათი P1/P2


Role: Primary/Secondary On-call (service: checkout-api)
Runbooks: rb://checkout/5xx, rb://checkout/rollback
Tools: logs, traces, SLO board, feature flags
SLA: Ack ≤5m, first action ≤10m, handover at shift boundaries

7. 3 Release მენეჯერი


Role: Release Manager
Gates: tests, signatures, active_sev=none, SLO guardrails green 30m
Strategy: canary 1/5/25%, blue-green optional, auto-rollback on burn
Evidence: release annotations, diff configs, dashboards before/after

8) როლების პროცესები და მონაწილეობა (შეჯამება)

პროცესიICP1/P2SRE/PlatformOwnerReleaseCABSecurityDataOpsCommsVendor
ინციდენტიARRCIICCRC
გამოშვებაIICARCCCII
RFC/ფანჯარაIIRACACCCC
პოსტ-მორტემიARRCCICCII

A — Accountable, R — Responsible, C — Consulted, I — Informed.

9) ჩეკის ფურცლები

9. 1 როლების დანიშვნა

  • თითოეულ როლს აქვს მფლობელი, მოადგილე და დაფარვის ზონა.
  • აღწერილია უფლებამოსილება (რა გადაწყვეტილებების მიღება შეუძლია).
  • პლეიბუსები და საკომუნიკაციო არხები მიბმული არიან.
  • გამოქვეყნებულია SLA რეაქციის/კომუნის მიხედვით.
  • როლი ხელმისაწვდომია თითოეული სერვისის კატალოგში (CMDB).

9. 2 ცვლილება და ჰანდოვერი

  • ცვლის ბარათი განახლებულია (აქტიური ინციდენტები, რისკები, ფანჯრები).
  • JIT/JEA- ს წვდომა შემოწმებულია.
  • ექო შეტყობინება არხში: „შეცვლა მიღებულია/ექსპლუატაციაში“.

9. 3 მარხვის ინციდენტი

  • AAR ჩატარდა, დაინიშნა RCA.
  • CAPA მფლობელებთან/ვადებთან ერთად, D + 14/D + 30 კონტროლი.
  • განახლებულია ფლეიბუქები/ალერტები/პოლიტიკოსები.

10) ანტი შაბლონები

გაურკვეველი „ვინ გადაწყვეტს“ შეფერხებას და ძალისხმევას.
IC შერწყმულია P1- სთან - ხელმძღვანელობის დაკარგვა.
საზოგადოებრივი კომუნები ლეგალური/კომსომთან კოორდინაციის გარეშე.
გამოშვება Release Manager- ის და კარიბჭეების გარეშე არის CFR ზრდა.
როლების სარეზერვო ნაკლებობა (დაავადება/შვებულება).
„გმირობა“ პროცესის ნაცვლად: ჩვენ ხელით დაზოგავთ, მაგრამ არ ვაფიქსირებთ მოაჯირს.
როლები არ არის ასახული CMDB/სერვისის კატალოგში, დაკარგული ესკალაცია.

11) ინსტრუმენტებში ინტეგრაცია

ChatOps: команды `/who oncall`, `/declare sev1`, `/freeze`, `/rollback`, `/status update`.
კატალოგი/CMDB: მომსახურებას აქვს მფლობელი, on-call, SLO, dashboards, playbooks, ფანჯრები.
Alert-as-Code: თითოეულ Page- ს აქვს ნაგულისხმევი owner და pleybook.
GitOps: IC/Release- ის გადაწყვეტილებები აისახება გამოცემების და თიკეტების ჩანაწერებში.

12) სიმწიფის განაწილების მეტრიკა

Coverage როლები კატალოგებში: კრიტიკული სერვისების 100% -ზე მეტი.
On-call SLA: Ack p95-5 წუთი; Page Storm p95 კონტროლდება.
Postmortem SLA: პროექტი 72ch; CAPA completion ≥ 85%.
Change governance:% მაღალი დონის ცვლილებები RFC/CAB- სთან - 95%.
Comms: Adherence ≥ 95%, Complaint Rate ↓ QoQ.

13) მინი შაბლონები

13. 1 RACI მომსახურებისთვის (ფაილი რეპოში)

yaml service: payments-api roles:
owner: team-payments oncall: oncall-payments ic: ic-of-the-day raci:
incident:  {A: ic-of-the-day, R: oncall-payments, C: security,data, I: mgmt,comms}
releases:  {A: release-manager, R: dev,platform, C: security, I: support}
changes:  {A: cab, R: owner, C: sre,security, I: affected-teams}
postmortem: {A: rca-lead, R: owner, C: security,data, I: mgmt}

13. 2 როლის პროფილი (Markdown)


Role: Duty Manager
Purpose: Escalation and SEV-1/0
Powers: Assign ICs, reallocate resources, approve freeze
Inputs: # war-room channel, SLO dashboards, IC reports
Outputs: resolutions, post-factual report, CAPA escalations

14) შედეგი

ოპერაციები სტაბილურია, როდესაც როლები გამჭვირვალეა, უზრუნველყოფილია უფლებამოსილებებით და ინტეგრირებულია ინსტრუმენტებში. როლების კატალოგი, RACI, მკაფიო ინტერფეისები და მეტრიკა თითოეული როლისთვის გადააქცევს ინციდენტებს, გამოშვებებს და ცვლილებებს კონტროლირებად პროცესებში: გადაწყვეტილებები სწრაფად მიიღება, რისკები კონტროლდება და მომხმარებლები ხედავენ სტაბილურ მომსახურებას.

Contact

დაგვიკავშირდით

დაგვიკავშირდით ნებისმიერი კითხვის ან მხარდაჭერისთვის.ჩვენ ყოველთვის მზად ვართ დაგეხმაროთ!

ინტეგრაციის დაწყება

Email — სავალდებულოა. Telegram ან WhatsApp — სურვილისამებრ.

თქვენი სახელი არასავალდებულო
Email არასავალდებულო
თემა არასავალდებულო
შეტყობინება არასავალდებულო
Telegram არასავალდებულო
@
თუ მიუთითებთ Telegram-ს — ვუპასუხებთ იქაც, დამატებით Email-ზე.
WhatsApp არასავალდებულო
ფორმატი: ქვეყნის კოდი და ნომერი (მაგალითად, +995XXXXXXXXX).

ღილაკზე დაჭერით თქვენ ეთანხმებით თქვენი მონაცემების დამუშავებას.