მოვალეობის შეცვლა და დავალებების გადაცემა

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

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

2) საფარის როლები და მოდელი

Primary on-call (P1) - პირველი პასუხი, სამჯერ, კოორდინაცია IC- ის მოსვლამდე.
მეორე ზოლი (P2) - ზურგჩანთა, რომელიც დაკავშირებულია გადატვირთვის/ესკალაციის დროს.
Duty Manager/IC-of-day არის SEV-1 + ინციდენტის ლიდერი.
Follow-the-sun (მრავალ დროში) ან Follow-the-moon (ღამის საფარი სხვა რეგიონებში).
დროებითი ფანჯრები: თავიდან აიცილოთ გამოშვება/სარისკო სამუშაოები ± 30 წუთი ცვლიდან.

3) როტაციის გრაფიკი (მაგალითები)

24/7, 8-საათიანი ცვლა: დილა/დღე/ღამე, 3 ბრიგადა, P1 + P2.
24/7, 12-საათიანი ცვლა: ნაკლები გადართვა, დაღლილობის რისკის ზემოთ - საჭიროა „კომპენსაციის ფანჯრები“.
5 × 8 (სამუშაო დღეები) + შაბათ აუზი: დღის პირველადი დაფარვა პროდუქტის გუნდის მიერ, შაბათ-კვირას - პლატფორმა/SRE.
ჰიბრიდი: სამუშაო დღეები „ოფისის დროს“, ღამით/შაბათ-კვირას - Follow-the-sun.

სამართლიანობის წესები: კალენდრის ბრუნვა, არდადეგების/შვებულების აღრიცხვა, მაქსიმალური N ღამის ცვლა პერიოდისთვის.

4) Shift Handover Card

• როდის და ვინ: 'თარიღი/დრო (UTC და ლოკალი)', - იუწყება იგი; კონტაქტები P1/P2.
• სისტემების სტატუსი: SLO/SLA შეჯამება, აქტიური ალერტები, ცნობილი დეგრადაციები.
• ღია ინციდენტები: ID, SEV, მიმდინარე ნაბიჯი, ვინ არის მფლობელი, შემდეგი მოქმედება/ETA.
• რისკები ცვლის ფანჯარაზე: დაგეგმილი სამუშაოები, გამოშვებები, მიგრაცია, შეზღუდული პირობები (პროვაიდერების კვოტები).
• კრიტიკული თიკეტები/დავალებები: პრიორიტეტი, ბლოკერები, ვადები.
• კომუნიკაციები გარეთ: აქტიური შეტყობინებები სტატუსის გვერდზე/კლიენტის განახლება.
• ცნობილი შემოვლითი მარშრუტები: ჩართულია დეგრადაციის წინა დროშები, დროებითი ლიმიტები.
• დომენი: გადახდის პროვაიდერები/KYC/CDN - მათი სტატუსები და მარშრუტიზაცია.
• Housekeeping: ვინ არის ხვალ, ხალხის მიუწვდომლობის ფანჯრები (მიტინგები/ფრენები).

5) ჩეკის სია „მე მივცემ ცვლილებას“ (მისცეს მხარე)

• განაახლა ცვლის ბარათი (ყველა ველი) და უზრუნველყო ბმული არხში '# oncall-handover'.
• თარგმნა „ზეპირი ცოდნა“ თიკეტებში/ნოტებში; არ არსებობს დავალებები „თავში“.
• ყველა ინციდენტს აქვს: SEV, მფლობელი, შემდეგი ნაბიჯი, შემდეგი განახლება.
• სტატუსის გვერდი და კლიენტის განახლება შეესაბამება რეალურ მდგომარეობას.
• გამორთულია ხმაურიანი/ყალბი ალერტები (პროცედურის შესაბამისად) ან აღნიშნა ბარათში.
• შემდეგი ცვლის ფანჯარაზე გადავამოწმე გარე პროვაიდერების კვოტები/ლიმიტები.
• სინქრონიზებული ხმით/ვიდეო კომუნიკაციით 5-10 წუთი (თუ SEV-1 + აქტიურია).
• დაფიქსირდა გადაცემის ფაქტი (bot/tiket), აღნიშნა მიმღებმა.

6) ჩეკის სია „მე ვიღებ ცვლას“ (მასპინძელი მხარე)

• წავიკითხე ბარათი, დავუსვი ღია კითხვები.
• ბოლო 2-4 საათში შეამოწმეს დაშბორდები SLO/alerta.
• დაადასტურა P1/P2- ის როლი ბოტში (ასისტენტი) და პეიჯერის ხმა/არხები.
• მიიღო აქტიური ინციდენტები და განაახლა აფთიაქების ტაიმერები.
• შეამოწმა დაგეგმილი სამუშაოები/გამოშვებები, გააუქმა სარისკო ოპერაციები პირველი 30 წუთის განმავლობაში.
• მან არხზე "ექო-შეტყობინება" გააკეთა: "მე მივიღე ცვლილება, აქტიური ინციდენტები:... აპდეიტი... "

7) კომუნიკაციის სტანდარტები

Каналы: `#oncall`, `#incident-warroom-<ID>`, `#statuspage`.

გაფართოების ინტერვალები: SEV-0: 15 წთ, SEV-1: 30 წთ, SEV-2 +: 60 წთ

Apdate ფორმატი: იმპორტი - დიაგნოზი - მოქმედებები - შემდეგი განახლება (დრო).
ესკალაცია: N წუთში პროგრესი არ არის TL/Platform/DB/Sec მატრიქსის დაკავშირება.
საკუთრების სიცხადე: თითოეულ მოქმედებას ჰყავს შემსრულებელი და ETA.

8) დავალებების გადაცემა (არა ინციდენტი)

გადაცემის კრიტერიუმები: დავალება ბლოკავს SLO/გამოშვებას/შესაბამისობას ან იწურება.
დიზაინი: „შემდეგი ნაბიჯის დეფინიცია“ და მოსალოდნელი შედეგი, ყველა არტეფაქტი (ლოგო/სურათები/გრაფიკა) ერთვის.
პრიორიტეტიზაცია: Kanban- swimlane „On-call Handover“.
ვადები: პროგრამებს აქვთ due-date; შეფერხებები ესკალაციას უწევს სამსახურის მფლობელს.

9) ავტომატიზაცია და ინტეგრაცია

როტაციის კალენდარი: სინქრონიზაცია პეიჯერთან; ბოტი აქვეყნებს „ვინ არის მოვალეობის შემსრულებელი“ ცვლის დასაწყისში.
ChatOps: '/handover start ', ბარათები წყაროებიდან (SLO სტატუსები, ღია ინციდენტები, გამოშვებები).
Ticeting: მფლობელის ავტომატური დანიშნულება P1/P2; ჭდეები „handover“.
სტატუსის გვერდი: ხიდი საზოგადოებრივი აპდეიტებისთვის შაბლონებით.
აუდიტი: გადაცემის ჟურნალი (ვინ/როდის მიიღო), კავშირი SEV- სთან და მოხსენებებთან.

10) დაღლილობისა და სტაბილურობის მენეჯმენტი

ლიმიტები: მაქსიმუმ X პეიჯი/საათი და Y ზედიზედ ღამით - გადასვლა P2/ესკალაციაზე.
Quiet hours არაკრიტიკული ალერტებისთვის (ტიკეტები პეიჯინგის ნაცვლად).
After-hours ანაზღაურება და post-incident rest.
ტრენინგი და გამოცდა ახალი on-call ინჟინრებისთვის.
ხმაურიანი ცვლის რეტროსპექტივები - ალერტებისა და პლეიბუკების tuning.

11) ცვლის და გადაცემათა ხარისხის მეტრიკა

Handover Defect: შეცვლის დროს კონტექსტის დაკარგვის ინციდენტების წილი.
MTTA ცვლის გარშემო: საშუალო/მწვერვალები ± 30 წუთის გადართვისგან.
Missed/late განახლება: ვადაგადაცილებული განახლება SEV- ზე.
Alert Hygiene:% ყალბი პეიზაჟები; ალერტები runbook/მფლობელის გარეშე.
Load per shift: padges/საათი, აქტიური მუშაობის საშუალო ხანგრძლივობა.
Satisfaction: NPS ცვლა (გამოკითხვა on-call), დაღლილობა მასშტაბით.

12) კავშირი ინციდენტის მენეჯმენტთან და RCA- სთან

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

13) უსაფრთხოება, შესაბამისობა და კონფიდენციალურობა

PII/საიდუმლოებები აკრძალულია ბარათების თავისუფალ ტექსტში; ბმულები უსაფრთხო საცავებზე.
წვდომა დროებითია: on-call უფლებები გაიცემა ცვლის ფანჯარაზე (JIT/JEA), კლავიშების როტაცია.
აუდიტის კვალი: immutable-log ვინ წაიკითხა/შეცვალა ბარათი და სტატუსის გვერდი.
რეგულირება: კლიენტის შეტყობინებების ვადები კონტროლდება ცვლის ბარათში.

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

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

15) შაბლონები

ცვლის ბარათის შაბლონი (შეკუმშული)

Shift: 2025-11-01 18: 00-02: 00 UTC (local: Europe/Kyiv 20: 00-04: 00)
P1: @duty-alex      P2: @duty-olga      IC: @ic-of-day
SLO Summary: API ok, Payments p95↑ by 12% (observation)
Active Incidents:
- INC-3421 (SEV-2): KYC's success is falling in the TR region. Owner: @ p1. Trail. step: switch 20% of traffic to provider B, update at 20:30 UTC.
Risks/jobs: 22:00 UTC - index migration to ClickHouse (read-only), owner @ data-ivan.
Providers: PSP-A green, KYC-A partially degrades TR.
Status page: post from 17:50 UTC; next update 20:30 UTC.
Next steps P1: 1) Check KYC switching effect; 2) Prepare canary 5% for v2 payments. 14.

ექო შეტყობინებების შაბლონი მიღებისას

[Took over shift] 18:02 UTC. Active: INC-3421 (SEV-2). Trail. update 18:30 UTC.
Checked alerts in 2h - no new P1s. Status page availability approx.

16) ყოველდღიური პრაქტიკა

Daily-ritual ცვლა: 5-10 წუთი ხმის სინქრონიზაცია აქტიური ინციდენტების დროს.
ბარათის ყოველკვირეული აუდიტი: შერჩევით შეამოწმეთ სისრულე/აქტუალობა.
თამაშის დღეები: სიმულაცია მრავალი პარალელური მოვლენით.
DOK კატალოგი: ბარათების/ჩეკის ფურცლების შაბლონები საცავებში, შურისძიება, როგორც კოდი.

17) შედეგი

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