ინციდენტი ბოტი და ჩატის ოპერაციები
1) მიზანი და მნიშვნელობა
ინციდენტის ბოტი არის ინციდენტის მართვის ინტერფეისი პირდაპირ კორპორატიული ჩატიდან (Slack/Teams/Telegram): ტექსტის ერთი შეყვანა ათეულობით სისტემაში. ის:- ამცირებს 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} "
`/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
დახურვა/პოსტ-mortem
`/incident resolve [reason=…]`, `/postmortem generate`, `/postmortem assign @owner`
5) ინტეგრაცია (მინიმალური)
მონიტორინგი/Observability: alerty, 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) შაბლონების კატალოგი (ფრაგმენტები)
P1 შექმნა:
/incident new p1 "Deposits EU down" components=payments,deposits regions=EU
პირველი საზოგადოებრივი განახლება (CL მეშვეობით):
/incident draft public
/incident publish public
Routing PSP და fick- ის დეგრადაცია:
/runbook psp-failover PSP1→PSP2 30%
/feature toggle replay-center off 45m
Post-mortem:
/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 dashbord.
ნვე. 7-8: tabletop სწავლებები P1/P2, ინტეგრაცია გამოშვებებთან/ფიჩფლაგებთან, პოსტ-მორტემის მანქანების შეგროვება, ლოკალიზაცია.
14) ანტიპატერები
„ყველაფერი ბოტის მეშვეობით“ guardrails- ის გარეშე, შემთხვევითი საშიში ქმედებები ხდება.
სტატუს გვერდზე გამოქვეყნება CL/იურიდიული მიმოხილვის როლის გარეშე.
ბრძანებები ლოგოების/ვერსიების გარეშე არის დაუსაბუთებელი.
ჩატის რთული ფორმები (20 + ველი) - სიჩქარე ეცემა; უმჯობესია მოკლე ბრძანებები + ბმულები.
არ არსებობს apdate ტაიმერები - „დუმილი“ P1- ზე.
CMDB/მფლობელებთან ინტეგრაციის არარსებობა დანიშვნებში.
15) შედეგი
ინციდენტი ბოტი და ChatOps არ არის „გუნდებთან ერთად ბოტი“, არამედ ოპერაციული პლატფორმა: ინციდენტის სწრაფი დაწყება, აფდეიტის დისციპლინა, ავტომატური მოქმედებები უსაფრთხო შეზღუდვებით, დაკვირვებით და დადასტურებით. ასეთი წრე პროგნოზირებად ამცირებს MTTR- ს, აუმჯობესებს კომუნიკაციების ხარისხს და იცავს iGaming ბიზნესის შემოსავალს პიკის მომენტებში.