ინციდენტი ბოტი და ჩატის ოპერაციები

1) მიზანი და მნიშვნელობა

• ამცირებს MTTA/MTTR- ს რუტინის ავტომატიზაციის გამო;
• ქმნის ფაქტების ერთიან წრეს (SoT) და კომუნიკაციებს;
• უზრუნველყოფს მტკიცებულებებს (აუდიტი, დრო, SLA განახლება);
• ამცირებს დატვირთვას on-call- ზე და კონსოლებში „დაკრძალვას“.

2) როლები და RACI ჩატის ოპერაციებში

Incident Commander (IC) - ინციდენტის მფლობელი: გახსნა/დახურვა, პრიორიტეტი, გადაწყვეტილებები.
Comms Lead (CL) - ტექსტები და განახლებების გრაფიკი (გარე/შიდა).
Domain Leads (Payments/Games/Core/Infra) - ტექნიკური და ფიქსაცია.
Scribe - დრო, სამოქმედო ჟურნალი.
Bot Admin - ბოტის უფლებები/პოლიტიკა/ინტეგრაცია.

წესი: ერთ ინციდენტს აქვს ერთი IC და ერთი CL; როლის შეცვლა ბოტის აშკარა გუნდია.

3) ძირითადი სკრიპტები

1. ინციდენტის დაწყება: alert '/incident new p1 "Deposits EU down" "ბოტი ქმნის ბარათს, var-rum, დანიშნავს IC/CL, აყენებს პირველი აფთიაქის ტაიმერს.
2. Წარმოება: `/incident add-facts`, `/incident status set degraded`, `/incident assign @payments-lead`, `/incident timer 20m`.
3. კომუნიკაციები: '/incident publish status '(პროექტი CL), '/incident პარტნიორების შენიშვნა', '/incident regulator draft '.
4. Მოქმედებები: `/runbook psp-failover PSP1→PSP2`, `/feature toggle replay-center off 60m`, `/traffic shift 30% eu→uk`.
5. დახურვა და პოსტ-mortem: '/incident resolve ', მანქანის დროის შეგროვება, '/postmortem generate'.

4) ბოტის გუნდები (ბირთვი)

შექმნა/კლასიფიკაცია

`/incident new p{1|2|3|4} "<title>" [components=…] [regions=…]`

`/incident severity set p2`, `/incident tag add payments,psp`

ფლობა და როლი

`/incident ic @user`, `/incident comms @user`, `/incident assign @user [domain]`

ტაიმერები და SLO აფთიაქები

'/incident შემდეგი განახლება 15m ', '/incident remind' (bot pinguet CL), '/incident eta 18: 30 '

ფაქტები და სტატუსი

`/incident fact "auth-success PSP1 -25% TR/EU"`, `/incident status {investigating|degraded|monitoring|resolved}`

კომის პაკეტები

`/incident draft public|partners|regulator`, `/incident publish public`

ინტეგრაცია

'/runbook '(მანქანის მოქმედებების კატალოგი), '/dashboard link ', '/ticket create '

დახურვა/პოსტ-mortem

`/incident resolve [reason=…]`, `/postmortem generate`, `/postmortem assign @owner`

5) ინტეგრაცია (მინიმალური)

მონიტორინგი/Observability: alerts, SLI/SLO (burn-rate), dashbords lines.
Incident Manager (ITSM): სტატუსის/ველების ორმხრივი სინქრონიზაცია.
სტატუსის გვერდი: მონახაზები და პუბლიკაცია CL- ის საშუალებით (პოლიცია-კარიბჭე).
პროვაიდერები (PSP/KYC/თამაშის სტუდიები): კონტაქტების ცნობარები, სწრაფი წერილები/არხები.
Release/Feature Flags: კანარის ფეხები/გამოტოვება, გამოშვების ბმულები.
Runbooks/Auto-remediation: უსაფრთხო მოქმედებების კატალოგი guardrails- ით.
CMDB/მფლობელები: აფეთქების ღუმელის მანქანების დანიშნულება, ესკალაცია.
დროის საცავი: WORM/immutable აუდიტისთვის/პოსტ-mortems.

6) ბოტის არქიტექტურა

Gateway (Chat Adapter): Slack/Teams/Telegram ინტერფეისები.
Command Parser + Policy Engine: ავტორიზაცია, შესაბამისობა, SoD და დაშვება.
Orchestrator: ინციდენტების სცენარები, ტაიმერები, შეხსენებები.
Integrations Layer: ITSM მომხმარებლები, მონიტორინგი, სტატუსის გვერდი, გამოშვებები, runbooks.
Evidence Store: მოვლენები, ფაქტები, შეტყობინებების დიფები, ინვესტიციები (WORM).
Metrics & Audit: ხარისხის მეტრიკა, მოქმედების ლოგები, გუნდების კვალი.

7) პოლიტიკა, სამართალი და უსაფრთხოება

RBAC/ABAC: ვისაც შეუძლია შექმნას/დახურვა, შეცვალოს severity, გამოაქვეყნოს გარეთ.
SoD: Comms publish მოითხოვს CL- ს როლს; High-risk მოქმედებები (PSP როუტინგი, PII ექსპორტი) - ორმაგი კონტროლი.
JIT უფლებები: დომენის ლიდერების დროებითი გაცემა ინციდენტის დროს.
ხელმოწერა და დაშიფვრა: ვებჰუკი/სისტემების მოთხოვნები - HMAC/mTLS.
დაცვა „fat-finger“ - სგან: საშიში ბრძანებების დადასტურება, dry-run და TTL მოქმედება.
PII ჰიგიენა: შენიღბვა მონახაზებში/ლოგებში; PII აკრძალვა ღია არხებში.

8) ავტომატიზაციის ნაკადები (მაგალითი)

Alert P1 bot ქმნის var-rum ('# inc-2025-11-01-001'), მორიგე მორიგე (IC, CL, Payments/Infra).
ის აკავშირებს დაშბორდებს/SLI, ხსნის თიკეტს ITSM- ში, ამზადებს პირველი საზოგადოებრივი აპდეიტის შაბლონს.
აყენებს ტაიმერებს: „შემდეგი განახლება 15 წუთის შემდეგ“, CL შეხსენებები.
Გვთავაზობს runbooks: “PSP reroute 30% → PSP2”, “degrade replay-center”, “autoscale settle-workers”.
გამოქვეყნებისთანავე, იგი აფიქსირებს ტექსტის ვერსიას და აქვეყნებს სტატუსის გვერდზე/სოციალურ ქსელებში (CL- ის საშუალებით).
დახურვის დროს - აგროვებს დროს, მეტრიკებს, პოსტმორტემის მონახაზს, VIP/პარტნიორების გაგზავნას.

9) დრო და მტკიცებულება

თითოეული მოვლენა ხდება: 'T + მმ: აღწერა, ავტორი/ბოტი, გუნდი, შედეგი, ბმულები'.
მხარს უჭერს შეტყობინებების რედაქტორებს (diff), რელიზების/ფიჩფლაგების/დაგეგმილი სამუშაოების მითითებას.
ექსპორტი: PDF/CSV აუდიტორებისა და რეგულატორებისთვის.

10) მეტრიკი (KPI/KRI ChatOps)

MTTA (ჩატი): ალერტიდან '/incident new '.
MTTS (setup): სანამ მზადაა vart-rum და დანიშნოს როლები.
Cadence adherence: საზოგადოებრივი აფთიაქების ინტერვალების დაცვა.
Runbook usage: ინციდენტების წილი ავტომატური მოქმედებებით.
Consistence score: შეუსაბამობები არხებს შორის = 0 - მიზანი.
Pager fatigue: სახელმძღვანელო პეიჯერების შემცირება იმავე/საუკეთესო SLO- სთვის.
Postmortem SLA: პოსტ-mortem- ის წილი, რომელიც შეგროვდა D + 5.

11) შაბლონების კატალოგი (ფრაგმენტები)

/incident new p1 "Deposits EU down" components=payments,deposits regions=EU

/incident draft public
/incident publish public

/runbook psp-failover PSP1→PSP2 30%
/feature toggle replay-center off 45m

/postmortem generate
/postmortem assign @owner

12) პროცესები

კომუნიკაციები: კავშირი „კომუნიკაცია ინციდენტებთან“ და „სისტემის სტატუსის გვერდები“.
დაკვირვება: სწრაფი ბმულები SLO/SLI და სინთეზზე; გრაფიკების წარდგენა.
ალერტინგი: P1/P2 ინციდენტის ავტომატური შექმნა; ერთჯერადი სიგნალის დედაპლატი.
მანქანების კორექტირება: ერთსაფეხურიანი runbooks guardrails- ით და გამოტოვებით.
Workflow Engine: human-tasks (4-eyes), ესკალაციის ტაიმერები, საკონტროლო სიები.

13) განხორციელების გზის რუკა (4-8 კვირა)

ნვე. 1-2: MVP ბრძანებები: '/incident new ', როლები (IC/CL), vart-rum, apdate timer, კომუნიკაცია ITSM- სთან და მონიტორინგი.
ნვე. 3-4: შეტყობინებების შაბლონები (საჯარო/პარტნიორები/რეგულატორები), სტატუსის გვერდი (პროექტი - პუბლიკაცია), დირექტორია 5-7 runbooks.
ნვე. 5-6: პოლიტიკა-as-code (RBAC/SoD/JIT), ორმაგი კონტროლი მაღალი რანგის, WORM ჟურნალი, KPI ChatOps dashboard.
ნვე. 7-8: tabletop სწავლებები P1/P2, ინტეგრაცია გამოშვებებთან/ფიჩფლაგებთან, პოსტ-მორტემის მანქანების შეგროვება, ლოკალიზაცია.

14) ანტიპატერები

„ყველაფერი ბოტის მეშვეობით“ guardrails- ის გარეშე, შემთხვევითი საშიში ქმედებები ხდება.
სტატუს გვერდზე გამოქვეყნება CL/იურიდიული მიმოხილვის როლის გარეშე.
ბრძანებები ლოგების/ვერსიების გარეშე არის დაუსაბუთებელი.
ჩატის რთული ფორმები (20 + ველი) - სიჩქარე ეცემა; უმჯობესია მოკლე ბრძანებები + ბმულები.
არ არსებობს apdate ტაიმერები - „დუმილი“ P1- ზე.
CMDB/მფლობელებთან ინტეგრაციის არარსებობა დანიშვნებში.

15) შედეგი

ინციდენტი ბოტი და ChatOps არ არის „გუნდებთან ერთად ბოტი“, არამედ ოპერაციული პლატფორმა: ინციდენტის სწრაფი დაწყება, აფდეიტის დისციპლინა, ავტომატური მოქმედებები უსაფრთხო შეზღუდვებით, დაკვირვებით და დადასტურებით. ასეთი წრე პროგნოზირებად ამცირებს MTTR- ს, აუმჯობესებს კომუნიკაციების ხარისხს და იცავს iGaming ბიზნესის შემოსავალს პიკის მომენტებში.