ოპერაციები და მენეჯმენტი - კონტექსტის გადაცემა ცვლებს შორის

კონტექსტის გადაცემა ცვლებს შორის

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

ცვლილება მოდის - სისტემა უკვე „გადის“. ჰენდოვერის ხარისხი პირდაპირ გავლენას ახდენს MTTR- ზე, ალერტის ხმაურზე და გამოშვების სტაბილურობაზე. კარგი ჰენდოვერი არის სწრაფი სახელმძღვანელო, მკაფიო რისკები და შემდეგი ნაბიჯები.

• გამორიცხეთ ინციდენტების, გამოშვებებისა და პროვაიდერების კონტექსტის დაკარგვა.
• შეამცირეთ ახალი ცვლის „შესვლის დრო“ წუთამდე და არა საათამდე.
• სტაბილიზაცია მოახდინეთ კრიტიკული გზების SLO (ანაბარი, განაკვეთი, თამაშის დაწყება, დასკვნა).
• გახადეთ კომუნიკაციები პროგნოზირებადი და დამოწმებული.

2) კარგი ჰენდოვერის პრინციპები

1. სტანდარტიზებული ფორმა (ერთი შაბლონი, ერთი ტერმინოლოგია).
2. ერთიანი ნიმუშები (ბმულები იგივე დაშბორდები/თიკეტები/runbook 'და).
3. ტაიმბოქსი (მოკლე „ბრიფინგი“ + „ლონგრიდი“ წერილობით).
4. Actionable: ბოლოს - დავალებების აშკარა სია „ვინ/რა/როდის“.
5. SLO ორიენტაცია: SLO/შეცდომების სტატუსი და არა „მოვლენების ლოგო“.
6. ტრეკირება: ნებისმიერი ფაქტი დასტურდება არტეფაქტით.

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

Lead ცვლა (გამგზავრება): ამზადებს ჰენდოვერის პაკეტს, ატარებს ბრიფინგს.
Lead ცვლა (მიღება): აფიქსირებს კითხვებს/რისკებს, ადასტურებს მიღებას.
ინციდენტის მენეჯერი: განახლებულია ინციდენტის დრო/არხი, აკონტროლებს SLA აფთიაქებს.
დომენის მფლობელები (Payments/Bets/Games/KYC): მათ სექციებში მათ „სტატუსი და რისკი“ აქვთ.
SRE/Observability: ისინი მხარს უჭერენ არტეფაქტებს (დაშბორდები, გამოშვების სურათები, ალერტები).

4) დრო და არხები

შეცვლამდე T-30 წუთი: გამავალი ცვლა გაყინავს სტატუსს, განაახლებს შაბლონს.
T-10 წუთი: სწრაფი ბრიფინგი (მაქსიმუმ 15-20 წუთი) ხმოვან/ვიდეო არხში.
T + 0: hendover პაკეტის გამოქვეყნება საერთო არხში „# ops-handover“.
T + 15 წუთი: მიმღები ცვლა ადასტურებს მიღებას და განმარტავს ღია საკითხებს.
ესკალაცია: ყველა „წითელი“ წერტილი დაუყოვნებლივ შესაბამისი გუნდის არხზე.

5) ჰენდოვერის პაკეტის სტრუქტურა (შაბლონი)

Handoff - <date, time, TZ>
Shift: <outgoing> → <receiving>
Overall SLO status (last 4h):
- API p95/p99: <values/trends>
- Error rate: <values/trends>
- Queue lag/DB connections/Cache: <brief>
Critical incidents:
- <INC-123>: status, impact, next update ETA, links (ticket, channel, postmortem draft)
Providers (PSP/KYC/studios):
- PSP-X: quotas/errors/fake <links>
- KYC-A: Webhook delays <links>
Releases/Features:
- In progress: <service>, stage (canary X%), gate/metrics, risk
- Scheduled: windows/locks/dependencies
Risks and observations:
- <briefly, with links and graphs>
Action items (before <time>):
- [Owner] <task>, readiness criterion
Useful links:
- Dashboard Overview, dependency map, escalation matrix, runbook 'and
On-call contacts:
- Domains/Names/Channels

6) მინი-SOP ჰენდოვერი

1. გამგზავრების ცვლა განაახლებს გამოშვების და დაშბორდის (SLO, პროვაიდერები, რიგები).
2. ბოლო 4 საათის განმავლობაში ამოწმებს „წითელ“ ალერტებს, აფიქსირებს სტატუსს/მიზეზს.
3. განაახლებს განყოფილებას „რისკები და დაკვირვებები“ (ტენდენციები/ეჭვები, არა ფაქტები).
4. ავსებს Action items- ს ვადებითა და მფლობელებით.
5. ის ატარებს ბრიფინგს: 10-15 წუთი, მკაცრად შაბლონის მიხედვით.
6. მიმღები ცვლა სვამს კითხვებს; საჭიროების შემთხვევაში - მფლობელებისთვის მყისიერი ესკალაცია.
7. მიღების დადასტურება: „მიღებული, კითხვები/არა“, პირველი ნაბიჯების სია.

7) ჰენდოვერის ხარისხის მეტრიკა (KPI)

Handoff Quality Score (HQS) - ჩეკის სიაში პაკეტის (0-100) ესკიზი.
Handoff Time - ბრიფინგის ხანგრძლივობა (სამიზნე დერეფანი 10-20 წუთი).
Acknowledgement SLA - დაშვების დადასტურება 15 წუთი.
Missing Context Rate არის ინციდენტების წილი „კონტექსტის დაკარგვით“ ცვლის შემდეგ.
Post-Handoff Incident Spike - ალერტების/ინციდენტების ზრდა პირველ 60 წუთში.
Action Items SLA არის ცვლილების შემდეგ დახურული დავალებების წილი.

8) პაკეტის ხარისხის შემოწმება (შეფასება HQS)

• სავსეა SLO/საკვანძო მეტრიკა 4 საათში ტენდენციებით.
• ყველა „წითელი“ ალერტა ჩამოთვლილია მიზეზებით/ბმულებით.
• ინციდენტები: ნომერი, სტატუსი, გავლენა, შემდეგი განახლება (დრო).
• პროვაიდერები: კვოტები/შეცდომები/ფეილოვერი, ბოლო ცვლილებები.
• გამოშვებები/ფიჩები: ეტაპი, რისკები, კარიბჭეები/კანარი.
• მოქმედება: მფლობელი, ვადა, მზადყოფნის კრიტერიუმი.
• ბმულები: დაშბორდები, არხები, runbook 'და, ესკალაციის მატრიცა.
• კონტაქტები on-call და სარეზერვო საკომუნიკაციო არხები.

9) დაშბორდი „ჰენდოვერისთვის“ (მინიმალური)

Operations Overview: p95/p99, error rate, capacity headroom, queue lag.
Incidents Board: ღია ინციდენტები, ETA განახლება, გავლენა.
Release & Feature: კანარი, შედარება „წინ/მის შემდეგ“, ავტო კარიბჭეები.
Providers Panel: კვოტები, ტაიმაუტები, cost/1k calls, გადართვა.
Dependence Map: პრობლემური ნეკნები (latency/errors/retries).

10) ალერტა ჰენდოვერების ხარისხზე (იდეები)

ALERT HandoffNotPublished
IF handoff_published == 0 AND within(10m, shift_change) == true
LABELS {severity="warning", team="ops"}

ALERT HandoffAckSLA
IF handoff_ack_minutes > 15
LABELS {severity="warning", team="ops"}

ALERT MissingActionOwners
IF count_over_time(handoff_action_items{owner=""}[1h]) > 0
LABELS {severity="warning", team="ops"}

ALERT PostHandoffIncidentSpike
IF incidents_rate_60m_after_shift > baseline_14d 1. 5
LABELS {severity="info", team="ops"}

11) კომუნიკაციები და აპდეიტის ფორმატი

[HH: MM] Handoff published. SLO OK/Degraded. Incidents: INC-123 (ETA 18:30), releases: bets-api canary 10%. Risks: PSP-X 85% quota. Action items: @ squad-payments until 7pm to check out the feilover.

• კრიტიკული წერტილებისთვის პირადი ჩეთების გარეშე - მხოლოდ საერთო არხები.
• ნებისმიერი „წითელი“ ზონა არის დაუყოვნებელი ძაფი მფლობელებთან.
• ყველა გადაწყვეტილება/კომპრომისი - წერილობით, მონაცემებზე დაყრდნობით.

12) დომენის მახასიათებლები (iGaming)

Payments: პრიორიტეტი: ანაბრის კონვერტაცია და ავტორიზაციის დრო, Faylover PSP მარშრუტები, პროვაიდერების ლიმიტები.
Bets: კოეფიციენტების/ქეშების განახლება, ნაკადის/ხაზის დატვირთვა, გამოთვლების შეფერხება.
Games/Live: სამაუწყებლო აურზაური (ჯეკპოტები/ნაკადები), ვებსაიტების ლიმიტები, UI დეგრადაცია.
KYC/AML: ინსპექტირების ხაზი, პროვაიდერების SLA, მწვერვალების მგრძნობელობა.

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

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

14) ინტეგრაცია და არტეფაქტები

გამოშვების სურათები გრაფიკებზე, ავტომატური ტრანსმისიები hendover- ზე.
ლინუქსი unfurling: ჩანართი dashbords/tickets საკვანძო მეტრიკის გადახედვით.
Runbook სავალდებულო: თითოეული „წითელი“ ზონა, რომელიც პირდაპირ კავშირშია კონკრეტულ runbook- ზე.
ესკალაციის მატრიცა: შაბლონში - ერთი შესაბამისი დოკუმენტი.

15) შენახვის პოლიტიკა და აუდიტი

ჰენდოვერები - ინახება ცენტრალურად (გეოსი, თარიღი/დრო, ავტორები).
HQS ყოველკვირეული აუდიტი და „ცუდი“ ჰენდოვერების შერჩევითი ანალიზი.
შაბლონის გადასინჯვა კვარტალურია ან პოსტმორტემების შედეგების მიხედვით.

16) სწრაფი დაწყება (30 დღე)

კვირა 1: შაბლონის, როლისა და დროის დამტკიცება; პილოტის გაშვება იმავე ხაზზე (მაგალითად, Payments).
კვირა 2: ჩართეთ დაშბორდები „ჰენდოვერისთვის“, ალერტები HandoffNotPublished/AckSLA.
კვირა 3: შემოიღეთ HQS ბაზარი და შეამოწმეთ ჰენდოვერების 10%.
კვირა 4: გაფართოება Bets/Games/KYC- ზე, ჩაატარეთ რეტროსპექტივა, განაახლეთ SOP.

17) პაკეტის „რისკის ბარათის“ მაგალითი

Risk: PSP-X hits 90% quota in prime time
Impact: rise in deposit refusals, SLO payments at risk
Signals: outbound_error_rate, quota_usage_ratio
Mitigation: raise PSP-Y up to 20% of traffic in advance, enable token cache
Owner/ETA: integrations@oncall / до 18:00

18) FAQ

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

Q: როგორ გავუმკლავდეთ „სიმართლის სხვადასხვა ვერსიას“?
A: არტეფაქტების გაერთიანება: ერთიანი დაშბორდები, გამოშვების ჩანაწერები, SSOT SLA- სთვის; ლაინერი მხოლოდ მათზე.

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