აფთიაქის თვალყურის დევნება

1) რატომ უნდა აკონტროლოთ აფთიაქი

აფთიაქი არის იმ დროის წილი, როდესაც მომსახურება ხელმისაწვდომია მომხმარებლისთვის. ეს არის დაკვირვების „პირველი ხაზი“: დაუყოვნებლივ შეამჩნია მიუწვდომლობა, ქსელის დეგრადაცია, DNS/TLS გაუმართაობა, მარშრუტიზაციის პრობლემები ან CDN. მაღალი დატვირთული და რეგულირებული სისტემებისთვის (fintech, iGaming), აფთიაქი პირდაპირ გავლენას ახდენს შემოსავალზე, SLA- ს შესრულებაზე და ჯარიმებზე.

2) ტერმინები და ფორმულები

SLI წვდომა: 'SLI = (წარმატებული შემოწმება/ყველა შემოწმება) × 100%'.
SLO: სამიზნე ფანჯარა (ჩვეულებრივ 28-30 დღე), მაგალითად 99. 9%.
SLA: გარე ვალდებულება; ყოველთვის შიდა SLO.
MTBF/MTTR: საშუალო დრო წარუმატებლობებს შორის/საშუალო გამოჯანმრთელების დრო.

99. 0% - ~ 432 წთ მიუწვდომლობა

99. 9% -დან ~ 43 წუთი

99. 99% → ~4. 3 წუთი

99. 999% ~ 26 წამი

3) რა შემოწმებებია საჭირო (შავი ყუთი)

ამოქმედებულია გარე წერტილებიდან (სხვადასხვა რეგიონები/პროვაიდერები), რომ დაინახონ მომსახურება „კლიენტის თვალით“.

1. ICMP (ping) - ძირითადი ბადურა/კვანძის ხელმისაწვდომობა. სწრაფი, მაგრამ არ ასახავს ბიზნეს წარმატებას.
2. TCP კავშირი - პორტი უსმენს? სასარგებლოა ბროკერებისთვის/BD/SMTP.
3. HTTP/HTTPS - სტატუსის კოდი, სათაურები, ზომა, რედაქციები, პირველი ბაიტის დრო.
4. TLS/სერთიფიკატები - მოქმედების ხანგრძლივობა, ჯაჭვი, ალგორითმები, SNI, ოქმები.
5. DNS - A/AAA/CNAME, NS ჯანმრთელობა, განაწილება, DNSSEC.
6. GRPC - ზარის სტატუსი, deadline, მეტამონაცემები.
7. WebSocket/SSE - ხელი, კავშირის შენარჩუნება, მესიჯი-ექო.
8. მარაგი/მარშრუტი/CDN - სხვადასხვა POP, ქეში ჰაშის ტესტირება, გეო ვარიანტები.
9. გარიგების სინთეზური სცენარები (კლიშეები/ფორმები): „ლოგინი - ძებნა - ანაბარი (ქვიშის ყუთი)“.
10. Heartbeat/cron მონიტორინგი - მომსახურება ვალდებულია „პულსირება“ (ხბო წუთში ერთხელ); სიგნალი არ არის - შფოთვის.

• დააყენეთ ტაიმაუტები რეალურ UX- სთან უფრო ახლოს (მაგალითად, TTFB-300 ms, ტოტალური - 2 ს).
• შეამოწმეთ შინაარსის ასტერტი (საკვანძო სიტყვა/JSON ველი) ისე, რომ შეცდომით „200 OK“ არ ჩაითვალოს წარმატებულად.
• ამოიღეთ შემოწმებები დამოუკიდებელი პროვაიდერების და ქსელების საშუალებით (მრავალ ჰოპი, სხვადასხვა ASN).

4) თეთრი ყუთი და მომსახურების ჯანმრთელობა

Liveness/Readiness ნიმუშები ორკესტრისთვის (ცოცხალი პროცესები? მზად ხართ ტრაფიკის მისაღებად?).
დამოკიდებულების ჯანმრთელობა: BD, ქეში, მოვლენების ბროკერი, გარე API (გადახდები/KYC/AML).
Fich- დროშები/დეგრადაცია: პრობლემების შემთხვევაში, ჩვენ რბილად გამორთეთ კრიტიკული გზები.

თეთრი ნიმუშები არ ცვლის გარე შემოწმებებს: მომსახურება შეიძლება იყოს „ჯანმრთელი შიგნით“, მაგრამ მომხმარებლისთვის მიუწვდომელია DNS/TLS/მარშრუტის გამო.

5) გეოგრაფია და მრავალფეროვნება

დაიწყეთ სინთეზური ტრეფიკის ძირითადი რეგიონებიდან და კრიტიკული დამოკიდებულების პროვაიდერების გვერდით.
კვორუმი: ჩვენ აღვნიშნავთ ინციდენტს, თუ N- ს რეგიონებში ჩავარდნა (მაგალითად, 3 - დან 2) ადგილობრივი ანომალიების მოსაშორებლად.
კოჰორტების ბარიერი: ცალკეული SLI/SLO მნიშვნელოვანი სეგმენტებისთვის (ქვეყნები, VIP, სატელეკომუნიკაციო ოპერატორები).

6) ალერტის პოლიტიკა (მინიმალური ხმაური)

მულტფილმის რეგიონი + მულტფილმის ტესტი: პეიჯერი მხოლოდ შეთანხმებული მარცხით (მაგალითად, HTTP და TLS ერთდროულად, 2 რეგიონია).
დებუნსი: N თანმიმდევრული მარცხი ან ფანჯარა 2-3 წუთის წინ პეიჯის წინ.

• L1: on-call (წარმოების სერვისები).
• L2: ქსელი/პლატფორმა/უსაფრთხოება დამოკიდებულია მარცხის ხელმოწერაზე.
• მანქანის დახურვა: სტაბილური M წარმატებული შემოწმების შემდეგ.
• მშვიდი საათი/დათმობები: არა კრიტიკული შიდა სერვისებისთვის - მხოლოდ ტიკეტები, პეიჯერის გარეშე.

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

საჯარო (კლიენტი) და პირადი (შიდა) სტატუსის გვერდები.
ავტომატური ინციდენტები სინთეზიდან + სახელმძღვანელო პრეზენტაციებიდან.
შეტყობინებების შაბლონები: ნაპოვნი - იდენტიფიცირებული - გავლენა - შემოვლითი გზა - ETA - გადაწყდა - პოსტ-მუწუკები.
დაგეგმილი ფანჯრები: წინასწარ გამოცხადება, გამონაკლისის გათვალისწინება SLO- სგან ცალკე.

8) საგარეო დამოკიდებულების აღრიცხვა

თითოეული პროვაიდერისთვის (გადახდები, KYC, ბიულეტენები, CDN, ღრუბლები) - მათი შემოწმება რამდენიმე რეგიონიდან.
Failover მარშრუტები: მანქანის გადართვა ალტერნატიულ პროვაიდერზე სინთეზური სიგნალისთვის.
ცალკეული SLO პროვაიდერის დონეზე და ინტეგრირებული e2e-SLO.
შეთანხმდით SLA- ს პროვაიდერთან (სტატუს ვებჰუკი, მხარდაჭერის პრიორიტეტი).

9) დაშბორდი და საკვანძო ვიჯეტები

მსოფლიო რუკა შემოწმების მდგომარეობით (ტიპების მიხედვით: HTTP, DNS, TLS).
ინციდენტების დრო გამოშვების/დროშის პრეზენტაციებით.
P50/P95/P99 TTFB/TTL/ლატენტობა რეგიონებში.
კოჰორტების ხელმისაწვდომობა (ქვეყანა/პროვაიდერი/მოწყობილობა).
MTTR/MTBF, „დგომის წუთების“ ტენდენციები და ბიუჯეტის ხელმისაწვდომობა თვეში.
წარუმატებლობის ტოპ მიზეზები (TLS-expiry, DNS-resolving, 5xx, timeouts).

10) ინციდენტის პროცესი (ხანმოკლე სცენარი)

1. მუშაობს მულტფილმის რეგიონი/მრავალ ტიპის ალერტი.
2. მოვალეობის შემსრულებელი ადასტურებს, მოიცავს გამოშვებების გაყინვას, აცნობებს მფლობელებს.
3. სწრაფი დიაგნოზი: DNS/TLS/CDN სტატუსი, უახლესი გამოშვებები, შეცდომების გრაფიკი.
4. შემოვლითი: მარშრუტის შეცვლა, ფოლკლორული შინაარსი/პროვაიდერი, დეგრადაციის რეჟიმის ჩართვა.
5. აღდგენა: შემოწმება, რომ სინთეზური/რეალური ტრაფიკი მწვანეა.
6. კომუნიკაცია სტატუსის გვერდზე; ინციდენტის დახურვა.
7. RCA და მოქმედება items: შესწორებები, ტესტები, ალერტები, პლეიბუსები.

11) SLA/SLO ანგარიშები

ყოველთვიური მოხსენებები: აფთიაქი სერვისების/რეგიონების შესახებ, წუთიერი დგომა, MTTR, მიზეზები.
შედარება SLA- სთან: სესხები/ანაზღაურება, თუ გამოიყენება.
კვარტალური შურისძიება: ბარიერების განახლება, სინთეზის განაწილება, დამოკიდებულების სია.

12) შემოწმების შაბლონები (მაგალითი)

• მეთოდი: 'GET/healthz/public' (საიდუმლოების გარეშე).
• ტაიმუთი: 2 გვ, retry: 1.
• წარმატება: „2xx“, სათაური 'X-App-Version' არის წარმოდგენილი, JSON ველი '„status“: „კარგი“.

• ვადა> 14 დღე, მოქმედი ჯაჭვი, ოქმები 'TLS 1. 2 + ', სწორი SNI.

• პასუხის დრო 100 ms, A/AAAA ჩანაწერები შეესაბამება გეგმას, არ არსებობს SERVFAIL/REFUSED.

• Webhuk '/beat/{ სერვისის} '5 წუთში ერთხელ; ზედიზედ 2 სიგნალის არარსებობაა alert L2 (ფონის დავალებები/ETL).

13) განხორციელების შემოწმების სია

• მულტიმედიური რეგიონალური გარე შემოწმებები (HTTP/TCP/DNS/TLS/ღრმა სცენარები).
• ორკესტრის თეთრი გამოცდები.
• კრიტიკული/არაკრიტიკული ტრასების გამიჯვნა, დეგრადაციის დროშები.
• კვორუმი და დებატები ალერტებში, ესკალაციასა და მანქანის დახურვაში.
• საჯარო და შიდა სტატუსის გვერდები, შეტყობინებების შაბლონები.
• ცალკეული შემოწმებები და SLO გარე პროვაიდერებისთვის + ავტომატური failover.
• Dashboards: რუქა, დრო, გადაჭარბებული წუთები, MTTR/MTBF.
• რეგულარული მოხსენებები SLA/SLO და პოსტ-ინციდენტი RCA.

14) ხშირი შეცდომები

მხოლოდ ping/პორტი NTTR/შინაარსის გარეშე - „მწვანე“ ფაქტობრივი მიუწვდომლობით.
მონიტორინგის ერთი წერტილი ყალბი პოზიტიური/უარყოფითი დასკვნებია.
TLS/DNS კონტროლის არარსებობა მოულოდნელი სისწრაფეა შეფერხების/misconfig- ის გამო.
ზედმეტი ხმაური: ალერტები ერთი წარუმატებლობისთვის ერთი რეგიონიდან/ტიპის გადამოწმებიდან.
არ არსებობს კავშირი ცვლილებებთან - არ არსებობს Dashboard- ში გამოშვებებისა და დროშების სურათები.
დაუზუსტებელი დამოკიდებულებები - გადახდის პროვაიდერი დაეცა, ხოლო ზოგადი სტატუსი „მწვანე“.

15) შედეგი

აფთიაქის თვალყურის დევნება არ არის მხოლოდ „URL სიარული“. ეს არის სინთეზური შემოწმების სისტემა რეალური რეგიონებიდან, გონივრული ალერტები ხმაურის გარეშე, გამჭვირვალე კომუნიკაცია სტატუს გვერდების საშუალებით, საგარეო დამოკიდებულებების აღრიცხვა და მკაცრი მოხსენებები. Aptime- ის სწორად აშენებული მონიტორინგი ამცირებს MTTR- ს, იცავს SLA- ს და ინარჩუნებს მომხმარებლის გამოცდილების პროგნოზირებას.