High Availability и SLA

High Availability и SLA

1) ტერმინები და ურთიერთობა ბიზნესთან

SLI (Service Level Indicator) - გაზომილი მომსახურების ინდიკატორი (მაგ. 2xx/3xx-T ms წარმატებული მოთხოვნების წილი).
SLO (Service Level Objective) - SLI მიზნობრივი მნიშვნელობა (მაგ. "99. მოთხოვნის 95% - 300 ms").
SLA (Service Level Agreement) - ხელშეკრულების ვალდებულება კლიენტის მიმართ (ჯარიმები/სესხები დარღვევის შემთხვევაში).
HA (მაღალი ავიაკომპანია) არის არქიტექტურული და ოპერაციული ზომები, რომლებიც საშუალებას გაძლევთ შეასრულოთ SLO/SLA.

პრინციპი: SLA ეყრდნობა SLO- ს, ხოლო SLO- ს დაკვირვებულ SLI- ს. თქვენ არ გპირდებით SLA- ს, რომ არ გაზომავთ.

2) „ცხრა“ და ხელმისაწვდომობის მათემატიკა

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

თანმიმდევრული ჯაჭვი (დამოკიდებულია „წითელ ბილიკზე“): „A _ total = Song A _ i“ (თითოეული კომპონენტი ამცირებს შედეგს).
კვანძების პარალელური აქტივი აქტივი: 'A _ total = 1 − 1 − A _ i)' (რეზერვი ზრდის შედეგს).

3) რა უნდა გავზომოთ (სწორი SLI)

მომხმარებლის სახე: საკვანძო ოპერაციების წარმატებული დასრულება (ლოგინი, ანაბარი, ჩეკი) და მათი ლატენტობა p99.
საათის დერეფანი: შემოღობილი მოცურების ფანჯრების გასწვრივ (5/30/60 წუთი) და რეგიონების გასწვრივ.
გამონაკლისები: „დაგეგმილი ფანჯრები“ გათვალისწინებულია SLO- ში, ხოლო SLA- ში - მხოლოდ იმ შემთხვევაში, თუ ეს ნათქვამია ხელშეკრულებაში.

• წვდომა: წარმატებული პასუხების წილი T.
• ხარისხი: p95/p99 latency.
• კომპოზიციები: „წარმატებული ანაბრების წილი 5 წმ“.

4) Error Budget და წვის სიჩქარე

Error Budget = `1 − SLO`. 99 წლისთვის. ყოველთვიური ფანჯრის 95% იძლევა 0. შეცდომების 05 %/მარტივი.
Burn-rate: ბიუჯეტის მოხმარების სიჩქარე (მაგ. 4 × ნიშნავს, რომ 6 საათში ჭამთ ყოველდღიურ ზღვარს).
პოლიტიკა: სწრაფი წვის დროს - გამოშვების გაჩერება, სტაბილიზაციის ფოკუსირება, მომავალი თავისუფალი.

5) HA არქიტექტურა: კვანძიდან რეგიონამდე

5. 1 კვანძი/მომსახურება

N + 1: მინიმუმ ერთი გადაჭარბებული რეპლიკა (დეპლიმენტი 2, PDB, ანტიბიოტიკი).
რესურსების იზოლაცია: CPU/RAM/IO ლიმიტები, პრიორიტეტები (PriorityClass).
Graceful shutdown/drain: ჭრილობის დროს მოთხოვნის ხარვეზის არარსებობა.

5. 2 ზონა/რეგიონი

Multi-AZ: რეპლიკები სხვადასხვა ზონაში, ჯვარედინი ზონის დაბალანსება, დამოუკიდებელი კვება/ქსელი.
Multi-region: აქტივი აქტივი (უფრო რთული: მონაცემები/თანმიმდევრულობა) ან აქტივი (უფრო მარტივი: RPO ზემოთ).
მონაცემები: CP ფულადი/შეკვეთებისთვის (კვორუმი/RAFT), EC/AP ქეში/ფანჯარისთვის.

5. 3 ქსელის ფენა და პერიმეტრი

L7-LB с health-checks, retry/timeout/circuit-breaking.
GSLB/DNS/Anycast გლობალური ტრაფიკისთვის, მოკლე TTL.
Egress კონტროლი და უკონტროლო არხები გარე PSP/პროვაიდერებამდე.

6) დეგრადაცია დაცემის ნაცვლად

Feature kill-switch (fich დროშები): გამორთეთ არა-კრიტიკული, შეინარჩუნეთ „წითელი გზა“.
გამარტივებულ ტრასებზე გადასვლა: სინქრონი - ასინქრონი/ხაზი, „დამუშავებულია“.
Rate-limit/კვოტები: უმჯობესია შეზღუდოთ ტრაფიკი, ვიდრე ყველას ჩამოაგდოთ.
Stale რეჟიმები: მისცეს ქეში/სტატიკური მონაცემები, თუ არ არის ხელმისაწვდომი origin.

7) დამოკიდებულების მართვა

დამოკიდებულების რუკა (სერვისის რუკა): სწორი/გარდამავალი, კრიტიკა, თითოეული SLO.
დაუცველი ბმულები: გარე პროვაიდერი SLA- ს გარეშე - იქცევა ქეში/ხაზში/დუბლიკატად.
Bulkhead იზოლაცია: სხვადასხვა კავშირების აუზები/კვოტები ნელი მარშრუტებისთვის.
Timeouts> Retries: მოკლე Timauts, მაქსიმუმ 1 retray imempotent ოპერაციებისთვის.

8) ოპერაციები და ცვლილებები

Change მენეჯმენტი: გამოშვებები კანარის/ცისფერი-მწვანე, SLO კარიბჭეების, ავტომატური გამოტოვების საშუალებით.
დაგეგმილი ფანჯრები: სტანდარტიზებული - სიგრძე, სიხშირე, კომუნიკაცია.
ინციდენტები: როლები (IC/Comms/Tech/DB), runbook 'და, პოსტმორტემები მაკორექტირებელი მოქმედებებით.
Security Ivents: კომპრომისზე - „პანიკის რეჟიმი“ (read-only/ნიშნები/როტაცია/დაბლოკვა).

9) დაკვირვება და ალერტინგი

RED მოდელი (Rate, Errors, Duration) თითოეული მარშრუტისთვის.
SLI დაშბორდები: წვდომა/ლატენტობა რეგიონში და კლიენტის სეგმენტში.
Burn-rate alerty: სწრაფი (1h, 14. 4 ×), ნელი (6h, 2 ×) - სიგნალი SLO- ს დაშლამდე.
ეგზემპლარები (Exemplars): გადასვლა მეტრიკიდან ტრასაზე _ id.
სინთეზური: ნიმუშები გარე წერტილებიდან (პერიმეტრი, გადახდის ფლეშ).

10) წინააღმდეგობის ტესტები

თამაშის დღეები: AZ/რეგიონების გამორთვის სცენარები, BD/ქეშის დეგრადაცია, გარე პროვაიდერების უარყოფა.
Chaos ინსტრუმენტები: ქსელის ფოლადები (latency/loss), kill-pods, CPU/IO გადატვირთვა.
DR-drills: RTO/RPO განვითარება Tier-0 სისტემებისთვის (იხ. „Bacaps and DR“).

11) SLA დიზაინი

„ხელმისაწვდომობის“ განმარტება: რაც ინციდენტად ითვლება (5xx, დრო> T, დომენის შეცდომები).
გაანგარიშების ფანჯარა: თვე/კვარტალი; დაგეგმილი სამუშაოების ჩართვა/გამორიცხვა.
სესხები/ჯარიმები: მასშტაბი (მაგ., 99. 9–99. 99% - X%, ქვემოთ - Y%).
კლიენტის მოვალეობები: ინტეგრაცია, რეტრაები გონივრულ ფარგლებში, შეზღუდვები.
ნოტიფიკაცია და კლიპების პროცედურა: ვადები, ფორმატი, მტკიცებულებების საფუძველი (ლოგოები/მეტრიკა).
ფორსმაჟორი: იურიდიული ფორმულირება და საზღვრები.

• "API ხელმისაწვდომობა SLI- სთვის "წარმატებული 500 ms" არ არის დაბალი 99. 95% კალენდარული თვის განმავლობაში. გამორიცხულია დაგეგმილი ფანჯრები (გამოცხადებული 60 წთ/თვე 48 საათში). 99 წელს. 90–99. 95% - სესხი 5%; 99. 80–99. 90% — 10%; <99. 80% — 25%.»

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

• Tier-0 (ფული/შეკვეთები): 99. 95–99. 99%, მულტფილმი-AZ, DR მზად არის.
• Tier-1 (ძირითადი ფიჩები): 99. 9–99. 95%, მულტფილმი-AZ.
• Tier-2 (არა კრიტიკული): 99. 5–99. 9%, დაუშვებელია ინციდენტების დეგრადაცია/გაჩერება.

13) HA ნიმუშები ფენებში

პერიმეტრი: CDN/edge, multi-CDN ან GSLB, WAF, rate-limit.
დაბალანსება: L7 outlier-ejection, taymauts/retrai, sticky/consistent-hash.
პროგრამები: ჰორიზონტალური skale, reading/liveness, PDB, topology spread.
მონაცემები: leader + replicas, érum for CP, kash L2, idempotence, PITR.
რიგები: მარცვლეული/მულტიკლასტერი, დედაპლატი, DLQ.
საიდუმლოებები/კონფისკაციები: GitOps, ატომური სნაიპერები, rollback.

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

SLA გაზომვისა და გარე სინთეზის ინსტრუმენტების გარეშე.
ერთიანი ზონა/მტევანი, როგორც SPOF.
უკონტროლო ჭრილობები არის „თავად-DDoS“.
გრძელი გარიგებები/მუტექსი ცხელ გზაზე.
„მძიმე“ მიგრაცია/გამოშვებები კანარის გარეშე და დაბრუნების გეგმა.
ინციდენტის დროს runbook- ის არარსებობა და სტეიკჰოლდერებთან კომუნიკაცია.

15) განხორციელების სიის სია (0-60 დღე)

0-15 დღე

განსაზღვრეთ კრიტიკული მომხმარებლის SLI, მიუთითეთ SLO Tier-0/1/2 დონეზე.
ჩართეთ burn-rate ალერტები, SLO დაშბორდები, სინთეზური პერიმეტრის შემოწმებები.
ამოიღეთ SPOF: 2 რეპლიკა, PDB, multi-AZ ფრონტებისა და კრიტიკული BD- სთვის.

16-40 დღე

შემოიღეთ კანარის გამოშვებები SLO გეიტინგით და მანქანის გამოტოვებით.
დამოკიდებულების რუკა + კვოტები/აუზები/ტაიმაუტები/SV თითოეული „წითელი ბილიკისთვის“.
დაგეგმილი ფანჯრებისა და კომუნიკაციების რეგულირება, ინციდენტის შეტყობინებების შაბლონები.

41-60 დღე

Game-day: AZ გამორთვა, გარე პროვაიდერის წარუმატებლობა, ტრაფიკის „ბნელი“.
ფაქტობრივად, SLA და სესხების დათვლა მომხმარებლებისთვის მოხსენებების გამოქვეყნებას წარმოადგენს.
გადასინჯვა „ცხრა ღირებულება“ და გადასვლა ტირაზე.

16) სიმწიფის მეტრიკა

კრიტიკული მარშრუტების 95% -ს აქვს SLI/SLO და burn-rate ალერტები.
SLO- ს შეცდომებს თან ახლავს ავტომობილების გაყინვა.
Multi-AZ საფარი Tier-0 = 100%, წარმატებული DR-drills - 1/კვარტალი.
„გამოვლენის - მიტინგების“ დრო p50 <5 წთ, p95 <15.
კორელაცია „გამოშვება - ინციდენტები“ - მიმდინარეობს და მცირდება (rollback rate).
ინციდენტების/სესხების შესახებ საჯარო ანგარიში - სამუშაო დღის განმავლობაში.

17) მაგალითები და სიპეტები

• სწრაფი: "SLO 99. 95%, ფანჯარა 1 საათი, burn - 14. 4× → page on-call».
• ნელი: „ფანჯარა 6 საათი, burn - 2 × ticket & მონიტორინგი“.

yaml circuit_breakers:
thresholds:
- max_connections: 200 max_pending_requests: 100 max_requests: 1000 max_retries: 1 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

yaml analysis:
templates:
- name: slo-burn metrics:
- name: error-rate successCondition: result < 0. 005 provider: prometheus

SLI: fraction_of_good_requests = good(HTTP 2xx/3xx ≤ 500ms) / all(requests)
SLO: ≥ 99. 95% per calendar month, per region

18) დასკვნა

High Availability არ არის მხოლოდ მტევანი და რეპლიკები, არამედ არქიტექტურის, პროცესებისა და მეტრიკის კოორდინირებული ნაკრები: მკაფიო SLI/SLO, რეალისტური SLA, ეკონომიკასთან „ცხრა“, დაცემის ნაცვლად დეგრადაცია, ტაიმაუტების/კვოტების დისციპლინა, რეგულარული წვრთნები და გამჭვირვალე კომუნიკაცია. გააკეთეთ გაზომილი და კონტროლირებადი ხელმისაწვდომობა - და ეს გახდება კონკურენტული უპირატესობა და არა ლატარია.