სისტემის სტატუსის გვერდები

1) რატომ გვჭირდება სტატუსის გვერდები

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

2) აუდიტორია და მათი მოთხოვნილებები

მოთამაშეები: მარტივი მითითება „მუშაობს/არსებობს პრობლემები“, ETA/ETR, გასაგები ტექსტი ჟარგონის გარეშე.
VIP/Affiliats/პარტნიორები: გავლენა ანაბარზე/განაკვეთებზე/ანგარიშგებაზე, დროის ფანჯრებზე, რეკომენდაციებზე (კამპანიების შეჩერება).
შიდა ბრძანებები: დეტალური დაშლა კომპონენტების/რეგიონების მიხედვით, კორელაცია KRI/SLO- სთან.
რეგულატორები და ბანკები/შეძენები: ინციდენტის ფაქტი, მოთამაშეთა/გარიგების გავლენა, ოფიციალურ შეტყობინებებზე მითითებები.

3) ჩვენების მოცულობა (კომპონენტების მოდელი)

პროდუქტის კომპონენტები: ავთენტიფიკაცია, ანაბრები, ფსონები, დასკვნები, პროფილი, პრემია, ცოცხალი თამაშები, ნაკადი.
ინფრასტრუქტურა: API კარიბჭე, BD, ქეში, შეტყობინებების ბროკერი, CDN/WAF, გადახდის პროვაიდერები, KYC/AML.
რეგიონები/მტევანი: GEO (EU/MEA/LATAM/APAC), ღრუბლოვანი რეგიონები, მონაცემთა ცენტრები.
სტატუსები: OK/დეგრადაცია/ნაწილობრივი მიუწვდომლობა/მიუწვდომელი/დაგეგმილი სამუშაოები.

4) სტატუსის პლატფორმის არქიტექტურა

4. 1 საჯარო vs პირადი

საჯარო: სტატიკური ვიტრინა (SPA/SSG) + ქეშირება, CDN, read-only API.
პირადი (შიდა): გაფართოებული მეტრიკა, KRI, ბმულები var-rum.

4. 2 მონაცემთა წყარო

მონიტორინგი და SLO: მეტრიკა (Prometheus/OTel), სინთეზური შემოწმებები, გარე პროვაიდერების პინგები.
ინციდენტის მენეჯმენტი: ინციდენტის ბარათი, დრო, გადაწყვეტილების სტატუსი.
ვებჰუკი PSP/KYC/თამაშის პროვაიდერები: ხელმისაწვდომობის/შეცდომების სიგნალები.
Comms Lead- ის სახელმძღვანელო განახლება დაცული კონსოლის მეშვეობით (აუდიტის ლოგოთი).

4. 3 განახლებების ნაკადი

მეტრიკი/KRI - ინციდენტის გამოვლენის, შექმნის/განახლების წესები - Comms Lead აქვეყნებს ბარათს/აფდიტებს, რეპლიკაციას საზოგადოებრივ გვერდზე და არხებზე (ელექტრონული ფოსტა/Telegram/Twitter/შიდა ჩეთები).

5) SLO ინციდენტების განახლებისა და ქცევისთვის

P1: პირველი განახლება 10 წუთი, შემდეგ სტაბილიზაციამდე 15-30 წუთი.
P2: პირველი განახლება 20 წუთი, შემდეგ ყოველ 45-60 წუთში.
P3/P4: პირველი განახლება 60-1440 წუთი, შემდეგ ფეხების გასწვრივ.
წესი: თუ ახალი არ არის, ჩვენ კვლავ ვაქვეყნებთ „უცვლელი“, მიუთითეთ შემდეგი განახლების დრო.

6) დაგეგმილი სამუშაოები

ანონსირების შაბლონი ფანჯრით, გავლენის ზონებით, გახანგრძლივების რისკით, უკან დახევის ნაბიჯებით.
სავალდებულო ლოკალიზაცია, ადგილობრივი დროის ზონები + UTC.
„კომუნიკაციების დაბლოკვის“ ჩართვა მიმდებარე არხებში ფანჯრის განმავლობაში.

7) ბლოკის შაბლონები გვერდზე

• სათაური, დონე (P1-P4), რომელიც გავლენას ახდენს კომპონენტებზე/რეგიონებზე.
• აფდიტის ფირზე (დრო, ავტორი/ბოტი, მოკლე ფაქტი, შემდეგი განახლება).
• მიმდინარე იმპორტი (პროცენტულად/მეტრიკებში), სამუშაო (თუ არსებობს).
• ETA/ETR (როდესაც გამოჩნდება), საფორტეპიანო კონტაქტები, პარტნიორების/რეგულატორების ბმულები.

დაგეგმილი სამუშაო ბარათი: ფანჯარა, რისკი, შემოწმების ჩამონათვალი ადრე/მის შემდეგ, გაუქმების კრიტერიუმები.

ისტორია: searchable არქივი თარიღით/კომპონენტებით (12 თვის განმავლობაში), ექსპორტი PDF/CSV.

8) ლოკალიზაცია და წვდომა

ენები: EN + საკვანძო ბაზრები (მაგალითად, TR/ES/PT-BR/PL/RO).
დრო: მომხმარებლის ლოკალი + UTC.
A11y: კონტრასტული ინდიკატორები, ალტ ტექსტები, სემანტიკური ნიშნები.
მობილური ვერსია სავალდებულოა.

9) უსაფრთხოება და შესაბამისობა

მხოლოდ მინიმალური საჭირო ტექნიკური დეტალები; არ გაამჟღავნოთ შიდა IP/ტოპოლოგია.
ყველა ცვლილება ხდება Comms Lead/Legal- ით PII/გადახდის თემებით.
პუბლიკაციების კონსოლი SSO/MFA, JIT უფლებები, აუდიტის ჟურნალი (ვინ/რა/როდის/რატომ).
WORM/immutable ისტორიის შენახვა; ჩანაცვლებისა და მასობრივი მოცილებისგან დაცვა.

10) ოპერაციებთან და მონაცემებთან ინტეგრაცია

ომის ოთახი: ორმხრივი კომუნიკაცია, ფაქტების შეგროვება ინციდენტის ბარათიდან.
SLO/SLI: საერთო სააფთიაქო გრაფიკის ჩვენება შეგიძლიათ გვერდზე (30/90 დღე).
PSP/KYC: გარე პროვაიდერების სტატუსის ბეიჯი (on/off/degraded) პასუხის ბოლო დროით.
ბიზნეს KPI: სურვილისამებრ, წარმატებული ანაბრების/განაკვეთების წილი ბოლო საათში (კონფიდენციალური მოცულობის გამჟღავნების გარეშე).

11) ანტისპამი და ხმაურისგან დაცვა

მოვლენების დედუპლიკაცია; დაკავშირებული ინციდენტების ჯგუფი.
Hold, სანამ გამოქვეყნდება ავტომატური აფდეიტები (მაგალითად, 2-3 წუთი) flapping ფილტრაციისთვის.
რეტროსპექტული კორექტირების პოლიტიკა (რედაქტირება მხოლოდ ნიშნით და მითითებით).

12) სტატუს კომუნიკაციის ხარისხის მეტრიკა

MTTA-Comms: პირველი საზოგადოებრივი განახლება.
Cadence adherence: განახლების სიხშირის დაცვა.
Consistence: არხებს შორის ფორმულირების დამთხვევა (0 განსხვავება - მიზანი).
Coverage: სტატუსის გვერდზე ასახული ინციდენტების წილი.
Repeat contacts: განმეორებითი ზარების შემცირება.
View Deflect: გვერდის ხედვის კორელაცია შემომავალი თიკეტების დაცემით.

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

• კომპონენტების/რეგიონების კატალოგი, დონის სქემა P1-P4; გვერდის დიზაინი; SSG/SPA და CDN არჩევანი; როლები (IC/Comms Lead).

• მონიტორინგისა და ინციდენტის ბარათების ინტეგრაცია; პუბლიკაციის კონსოლი (SSO/MFA, აუდიტი); შეტყობინებების შაბლონები და ლოკალიზაცია.

• გარე პროვაიდერების სინთეზური შემოწმებები, PSP/KYC სტატუსის ბეიჯები; ისტორია და ექსპორტი; დაგეგმილი მუშაობის პოლიტიკა.

• წვრთნები (tabletop) ტაიმერით; KPI- ს გაშვება; რეტროსპექტული ცვლილებების წესები; საზოგადოებრივი ჰაიდი „როგორ წაიკითხო სტატუსი“.

14) არტეფაქტები და შაბლონები

კომპონენტის მატრიცა: კომპონენტი - რეგიონები - SLO მფლობელები - ესკალაციის არხები.
პირველი აფთიაქის შაბლონი: რა ხდება, ვინ იმოქმედებს იმაზე, რასაც ვაკეთებთ, შემდეგი განახლება.
დახურვის შაბლონი: აღდგენის დრო, მიზეზი, პრევენციის ზომები, კომპენსაცია (თუ არსებობს).
რედაქტირების პოლიტიკა: ვისაც შეუძლია გამოაქვეყნოს/რედაქტირება, თუ როგორ ხდება კორექტირება, SLA ლოკალიზაცია.
Runbook „დაგეგმილი სამუშაოები“: ჩეკის ფურცლები ადრე/შემდეგ, კრიტერიუმები „go/no-go“, საკომუნიკაციო პაკეტი.

15) სპეციალური სცენარები

უსაფრთხოების/მონაცემების ინციდენტები: გამოქვეყნება მხოლოდ ლეგალურ/კომპლექსთან შეთანხმების შემდეგ; შესაძლებელია - ცალკეული პირადი ნაკადი რეგულატორებისთვის/ბანკებისთვის.
გეო-სპეციფიკური პრობლემები: გვერდი ავტომატურად განსაზღვრავს მომხმარებლის GEO და აჩვენებს პრიორიტეტულ ბლოკებს.
მრავალ ჩრდილში: ცალკეული ფილტრები/სტატუსის შემცირება ბრენდზე/ოპერატორზე; საერთო ინფრასტრუქტურა ცალკე ფირია.

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

დუმილი> 30 წუთი P1- ზე.
სხვადასხვა ციფრები/ფორმულირებები არხებში და სტატუსის გვერდზე.
ძალიან ტექნიკური დეტალები მომხმარებლის ენაზე თარგმნის გარეშე.
ინციდენტების ისტორიების წაშლა რეტროსპექტული ნიშნების ნაცვლად.
სახელმძღვანელო პუბლიკაციები audit ლოგოსა და უფლებების კონტროლის გარეშე.

17) შედეგი

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