ოპერაციები და AI თანაშემწეები ოპერატორებისთვის

AI თანაშემწეები ოპერატორებისთვის

1) რატომ არის ეს აუცილებელი?

ოპერატორები იხრჩობიან ალერტებში, ლოგოებში და მიმოფანტულ არტეფაქტებში. AI ასისტენტი ჰეტეროგენულ სიგნალებს გასაგებ რეკომენდაციებად და მზა მოქმედებად აქცევს: სამჯერ უფრო სწრაფად, ნაკლები ხელით რუტინით, უფრო მაღალი SLO პროგნოზირებადი.

• შეამცირეთ MTTD/MTTR და ალერტის ხმაური.
• გააუმჯობესეთ ჰენდოვერების ხარისხი და პოსტ-ინციდენტის დოკუმენტაცია.
• „მძიმე რუტინის“ ავტომატიზაცია (კონტექსტის, მოხსენებების, თიკეტების ძებნა).
• დააფიქსირეთ პასუხების/კომუნიკაციების ერთიანი სტანდარტები.

2) განაცხადის სკრიპტები (ტოპ-12)

1. ინციდენტების სამჯერ: ალერტების ჯგუფი - მიზეზების ჰიპოთეზა - პრიორიტეტი/გავლენა.
2. მოქმედების რეკომენდაციები: „ახლა რა უნდა გავაკეთოთ“ runbook- ის ბმულებით და გაშვების ღილაკებით.
3. ავტო ცნობები (Incident TL; DR): მოკლე დარტყმა ინციდენტის არხისთვის/სტეიკჰოლდერებისთვის.
4. ცოდნის ძიება (RAG): სწრაფი პასუხები runbook/SOP/postmortems/ესკალაციის მატრიცა.
5. ტიკეტების/აპდეიტების წარმოქმნა: Jira/Status apdates შაბლონის მიხედვით.
6. ალერტის ანალიტიკა: „ხმაურიანი წესების“ იდენტიფიცირება, წინადადებები tuning.
7. Observability Q&A: „აჩვენეთ p99 bets-app 1 საათისთვის“ - მზა გრაფიკები/მოთხოვნები.
8. მოვაჭრე კონტექსტი: პროვაიდერის ანგარიში (კვოტები, SLA, ფანჯრები, ინციდენტები).
9. Predicative რჩევები: „burn-rate - + lag - მოამზადეთ faylover PSP“.
10. Handover Copilot: ცვლის პაკეტის შეგროვება დაშბორდების/თიკეტებისგან.
11. Postmortem Copilot: ქრონოლოგია dogs/tredes + მონახაზი Corrective/Preventive Actions.
12. ლოკალიზაცია/შეტყობინებების ტონი: სწორი, თანმიმდევრული კლიენტის აპდეიტები.

3) გადაწყვეტილების არქიტექტურა (მაღალი დონის)

წყაროები: მეტრიკა/ლოგები/ტრეისი (Observability), ticets/ინციდენტები, კონფისკაციები/ფიჩფლაგები, პროვაიდერის სტატუსები, SLO/OLA კატალოგი, runbook/SOP.
RAG ფენა (ძებნა ცოდნის მიხედვით): მარკირების დოკუმენტების ინდექსაცია (დომენი, ვერსია, თარიღი, მფლობელი). ვიუჰი „ოპერატორისთვის“.
ინსტრუმენტები (Tools/Actions): უსაფრთხო ოპერაციები: „scale-up HPA“, „კანარის პაუზა“, „ჩართეთ safe-mode“, „გადართეთ PSP“, „შექმნათ ticet“, „შეაგროვეთ გრაფიკები“. ყველა მოქმედება - ბროკერის/ორკესტრის საშუალებით აუდიტით.
Policy-guardrails: როლების უფლებები, HITL დადასტურება, ლიმიტები, მშრალი პროგონი (dry-run), ჟურნალი.
უსაფრთხოება: KMS/Secrets, PII ნიღბები, mTLS, მონაცემთა წვდომის აუდიტი.
ინტერფეისები: chat/პანელი NOC- ში, დაშბორდის ვიჯეტები, slash slash ბრძანებები.

4) UX ნიმუშები (რასაც ოპერატორი ხედავს)

ინციდენტების ბარათები: „ჰიპოთეზის სიმპტომი (რანჟირება) - 3 შემოთავაზებული ნაბიჯი - მითითებები ამ მოქმედების ღილაკზე“.
ერთი ინდუსტრიული ველი: „ჩამოაყალიბეთ handover პაკეტი ბოლო 4ch Payments- ისთვის“.
ნდობის/წყაროების განათება: „ემყარება: Grafana, Postgres logs, Runbook v3“.
Dry-Run ღილაკი: აჩვენეთ რა გაკეთდება და სად არის რისკები.
გადაწყვეტილებების ისტორია: ვინ დაადასტურა ნაბიჯი, შედეგი, დაბრუნება/წარმატება.

5) ინტეგრაცია და მოქმედებები (examples)

Observability: მზა PromQL/LogsQL/Trace ფილტრები, დაჭერის გრაფიკები.
Feature Flags: ჩართეთ safe რეჟიმი/დროშის გადატანა (დადასტურებით).
Release-canareika: შეჩერება/გამოტოვება; დაამატეთ სურათები გრაფიკზე.
K8s: წინასწარი skale HPA, დასრულების გადატვირთვა, PDB/Spread შემოწმება.
პროვაიდერები: PSP-X - PSP-Y მარშრუტის გადართვა; კვოტის შემოწმება.
კომუნიკაციები: აფდიტის პროექტი ინციდენტის არხში/სტატუსის გვერდი.
Tickets: Jira- ს შექმნა წინასწარი მონაკვეთებით.

6) უსაფრთხოებისა და კონფიდენციალურობის პოლიტიკა

როლების/დომენების წვდომა: ოპერატორი ხედავს მხოლოდ „საკუთარ“ სისტემებს და მინიმუმამდე საკმარის მონაცემებს.
სამოქმედო ჟურნალი: ვინ/როდის/რა დაადასტურა, შედეგი, დაბრუნება.
PII/საიდუმლოებები: შენიღბვა პასუხებში/ლოგოებში; „ნედლეული“ საიდუმლოებების მიუწვდომლობა.
შინაარსის შენახვა: მოპოვებული არტეფაქტების (RAG) ვერსიები TTL- ით და ეტიკეტირებით.
„მსჯელობის“ აკრძალვა, როგორც არტეფაქტი: ჩვენ ვიცავთ დასკვნებსა და ბმულებს წყაროებზე და არა მოდელის შიდა აზრებს.
ვენდორის საზღვრები: პერიმეტრის დატოვების მონაცემების მკაფიო სია (ნაგულისხმევი - ნული).

7) ეფექტურობის ხარისხი და მეტრიკა

• MTTD/MTTR ↓, Pre-Incident Detect Rate ↑, Change Failure Rate ↓, Handoff Quality Score ↑.
• Alert Fatigue (ალერტები ოპერატორზე/ცვლაზე), დრო პირველ ადაპტაციამდე.

• Acceptance (რეკომენდაციების მიღება), Time Saved/Case, Precision/Recall კლასებში (მაგალითად, P1), Hallucination Rate (არასწორი განცხადებები წყაროების გარეშე), Safety Incidentes = 0.

• Recall(P1) ≥ 0. 7, Precision ≥ 0. 6, Acceptance ≥ 0. 5, Time Saved - 25%, Hallucination - 2%, წყაროების სავალდებულო მითითებით.

8) სამრეწველო ინჟინერია და ცოდნის მენეჯმენტი

მოთხოვნის შაბლონები: ფორმულირების სტანდარტიზაცია (ქვემოთ - მაგალითები).
კონტექსტის ფენები: (ა) სისტემის წესები (უსაფრთხოება, პასუხების სტილი), (ბ) მოკლე კონტექსტი ცვლაში/დომენში, (გ) RAG ძებნა ახალი დოკუმენტების/გრაფიკების მიხედვით.
ცოდნის ვერსია: თითოეულ runbook/SOP აქვს 'id @ version' და თარიღი, AI აძლევს ბმულს და ვერსიას.
პასუხების შესაბამისობა: ჩვენ მოვითხოვთ მითითებებს მონაცემთა წყაროების/დაშბორდის ყველა ფაქტობრივი განცხადებისთვის.

Triage:
"You are an SRE operator. Based on [Grafana: payments, Logs:psp_x, Incidents: last 24h]
group alerts into 3-5 hypotheses with probability, effect on SLO, and brief validation steps.
Answer: hypothesis cards + links"

Handover:
"Collect handover packet in last 4h for Payments domain:
SLO, incidents (ETA), releases/canaries, providers/quotas, risks/observations, action items.
Add links to panels and tickets"

9) პროცესებში ინტეგრაცია (SOP)

ინციდენტები: AI აქვეყნებს TL; DR ყოველ N წუთში, ამზადებს შემდეგ ETA- ს, გთავაზობთ ნაბიჯებს.
გამოშვებები: წინა და პოსტსაბჭოთა მოხსენებები; პრედიკულური რისკების მქონე ავტოგატი.
ცვლა: Handover პაკეტი იქმნება და იხსნება ჩეკის ფურცლის მიხედვით.
Postmortems: დროის მონახაზი + Corrective/Preventive Actions სია.
ანგარიში: ხმაურიანი ალერტებისა და tuning წინადადებების ყოველკვირეული დაიჯესტი.

10) დაშბორდი და ვიჯეტები (მინიმალური)

AI Ops Overview: მიღებული რეკომენდაციები, დაზოგული დრო, მოქმედების წარმატება/დაბრუნება.
Triaging Quality: Precision/Recall კლასებში, საკამათო შემთხვევები, ტოპ შეცდომები.
Knowledge Health: runbook/SOP საფარი, მოძველებული ვერსიები, ხარვეზები.
Alert Hygiene: ხმაურის წყაროები, კანდიდატის წესები tuning.
Safety & Audit: მოქმედების ლოგო, უარი თქვა მცდელობებზე, dry-run მოხსენებები.

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

„ჯადოსნური ყუთი ყველაფერს გადაწყვეტს“ - RAG- ს და ბმულების გარეშე, ფაქტების „გამოცნობით“.
შეუქცევადი მოქმედებების ავტომატიზაცია HITL/როლების/ლიმიტების გარეშე.
ძებნაში prod/stage არტეფაქტების შერევა.
საიდუმლოებები/PII თანაშემწის პასუხებსა და ლოგოებში.
ხარისხის მეტრიკის ნაკლებობა და სარგებლის შემდგომი შეფასება.
„ერთი ჩატი ყველა ამოცანისთვის“ - ბარათების, სტატუსებისა და ღილაკების გარეშე.

12) განხორციელების სია

• განისაზღვრება დომენები და სკრიპტები (სამჯერ, მოხსენებები, ჰანდოვერი, თიკეტები).
• RAG განლაგებულია: runbook/SOP/postmortems/ესკალაციის მატრიცები (ვერსიებით).
• ინტეგრაცია: Observability, Flags, Release, Tickets, Providers - უსაფრთხო tools.
• პოლიტიკოსები: როლები, HITL, ჟურნალი, dry-run, შენიღბვა PII/საიდუმლოებები.
• UX: ინციდენტის ბარათები, მოქმედების ღილაკები, ნდობა და ბმულები.
• მეტრიკი: AI-KPI და Ops-KPI + დაშბორდები.
• პროცესები: SOP ინციდენტებზე/გამოშვებებზე/ცვლაზე/პოსტმორტემაზე AI- ს მონაწილეობით.
• ოპერატორების მომზადების გეგმა და ასისტენტთან კომუნიკაციის წესები.

13) უსაფრთხო ავტომობილების მაგალითები

პუბლიკაცია TL; DR/ETA ინციდენტის არხში.
თიკეტის შექმნა/განახლება, არტეფაქტების დაკავშირება.
მეტრიკისა და ლოგების კითხვის თაობა/გაშვება (სისტემაში ცვლილებების გარეშე).
გამოშვების/დროშის სურათები გრაფიკებზე.
Playbuk dry-run- ის მომზადება (რაც გაკეთდება დადასტურების დროს).

14) როლები და პასუხისმგებლობა

Ops Owner: ბიზნეს შედეგები (MTTR, ხმაური), SOP განცხადება.
Observability/SRE: RAG, ინტეგრაცია, უსაფრთხოება და ხარისხის მეტრიკა.
Domain Leads: რეკომენდაციების შესაბამისობა, runbook/SOP შესაბამისობა.
Training/Enablement: ოპერატორების ონბორდი, „როგორ დაუკავშირდეთ AI- ს“, გამოცდები.
Compliance/Security: მონაცემთა პოლიტიკა, ლოგოების აუდიტი და შენახვა.

15) 30/60/90 - გაშვების გეგმა

• მფრინავი იმავე დომენზე (მაგალითად, Payments): სამჯერ, TL; DR, თიკეტები.
• ცოდნის ინდექსაცია (RAG) და ინციდენტების ბარათები, მოქმედების დენი-რუნი.
• ძირითადი მეტრიკა: Acceptance/Time Saved/Precision/Recall.

• დაამატეთ handover/postmortem კოპილოტი, ინტეგრაცია Flags/Release- სთან.
• ჩართეთ პრედიკულური რჩევები (burn-rate, lag) და ალერტის tuning წინადადებები.
• გაატარეთ ორი თამაშის დღე ასისტენტის გამოყენებით.

• გაფართოება Bets/Games/KYC, შაბლონების გაერთიანება.
• SOP- ის ფორმირება AI- სთან ერთად, KPI- ს კვარტალურ მიზნებში შეყვანა.
• ეკონომიკური ეფექტის ოპტიმიზაცია (ღირებულება/ინციდენტი, ზეგანაკვეთის შემცირება).

16) დამხმარე პასუხების მაგალითები (ფორმატები)

Symptom: p99 payments-api ↑ up to 420 ms (+ 35%) in 15 minutes
Hypotheses:
1) PSP-X timeouts (probable 0. 62) - outbound_error_rate growth, quota 88%
2) DB-connections (0. 22) — active/max=0. 82
3) Cash evikshens (0. 16) — evictions>0
Steps:
[Open PSP-X panel] [Check quota] [Enable safe-mode deposit]
[Payments-api canary pause]
References: Grafana (payments p99), Logs (psp-x), Runbook v3

SLO OK/Degraded, incidents: INC-457 ETA 18:30, canary bets-api 10%, PSP-X quota 85%.
Action items: @ squad-payments check out the feilover before 7 p.m.

Impact: deposit conversion − 3. 2% at 5pm-5.25pm
Timeline: 16:58 alert p99; 17:04 canary pause; 17:08 PSP- X→Y
Root cause: slow PSP-X responses when 90% quota is reached
Actions now: breaker tuning, auto-predictor quota> 0. 85, alert hygiene

17) FAQ

Q: რა არის პირველი ავტომატიზაცია?
A: ცნობები/თიკეტები/ცოდნის ძებნა - უსაფრთხოა და დაუყოვნებლივ დაზოგავს დროს. შემდეგ - წინამორბედი რჩევები და ნახევრად ავტომატური მოქმედებები HITL- ით.

Q: როგორ გავუმკლავდეთ „ჰალუცინაციებს“?
A: მხოლოდ RAG, მხოლოდ ბმულების პასუხები, წყაროების გარეშე პასუხების აკრძალვა, ხარისხის ოფლაინ შეფასება, სადავო პასუხების აღნიშვნა და დემონტაჟი რეტრო.

Q: შესაძლებელია თუ არა დამხმარე „ღილაკების დაწვის“ უფლება?
A: დიახ - შექცევადი და დაბალი კორექტირების ნაბიჯებისთვის (სურათები, ანაბეჭდები, dry-run, project-skale), დანარჩენი - HITL- ის და როლების საშუალებით.