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

1) რა არის შესაძლებლობების დაგეგმვა და რატომ

შესაძლებლობების დაგეგმვა არის სისტემატური პროცესი, რომელიც აუცილებელია მიზნობრივი SLO- ს მისაღწევად, მინიმალური ღირებულებით. ჩვენ ვსაუბრობთ არა მხოლოდ CPU/მეხსიერებაზე, არამედ ქსელების გამტარუნარიანობაზე, შენახვაზე, BD/ქეშებზე, მოვლენების რიგებზე/ავტობუსებზე, გარე პროვაიდერებზე (გადახდები/KUS/ანტიფროდი), ასევე ადამიანურ რესურსებზე (on-call, მხარდაჭერა).

• შეასრულეთ SLO/SLAs თუნდაც მწვერვალებსა და დეგრადაციებში.
• მინიმუმამდე დაიყვანეთ TCO და მარტივი კაპიტალი (overprovisioning).
• შეამცირეთ ინციდენტების რისკი რესურსების ამოწურვისგან.
• უზრუნველყოს გამოშვებებისა და კამპანიების პროგნოზირება (მარკეტინგი, ტურნირები, ტოპ მატჩები).

2) შეყვანის მონაცემები და ჭეშმარიტების წყაროები

დაკვირვება: RPS/concarcarence, p50/p95/p99, error-rate, saturation (CPU, mem, disk IOPS, ქსელის pps/mbps), რიგების სიგრძე, rate limes.
ბიზნეს ღონისძიებები: კამპანიის კალენდარი, სეზონური (საღამოები/გამომავალი/მეგა-ტირაჟი), რეგიონები/იურისდიქციები.
Techdolg/fichi: roadmap გამოშვებები, არქიტექტურული ცვლილებები (მაგალითად, დაშიფვრა, ახალი ლოჯისტიკა).
პროვაიდერები: კვოტები და გადახდის კვოტები/KUS/საფოსტო/სერვისების ანტიფროიდი.
წარსულის ინციდენტები: სად არის ვიწრო ადგილი (BD, ქეში, L7 დაბალანსება, საბურავი, CDN, დისკი).

3) ძირითადი ცნებები და ფორმულები

Headroom - კონტეინერის რეზერვი: 'headroom = (მაქს _ სტაბილური _ RPS - ფაქტობრივი _ RPS )/მაქს _ სტაბილური _ RPS'.
მიზნობრივი მნიშვნელობა მწვერვალზე 20-40% (კრიტიკული ნაკადებისთვის).
Saturation - ოკუპირებული რესურსის თანაფარდობა ხელმისაწვდომზე (CPU%, მეხსიერება/GC, ნაერთები, file descriptors, IOPS, რიგის სიღრმე).
Throughput სტაბილურია - სიჩქარე, რომლის დროსაც p99 და error-rate ასრულებენ SLO- ს დიდი ხნის განმავლობაში (არა ერთჯერადი ასვლა).
Capacity Unit (CU) არის ნორმალიზებული ენერგიის ერთეული მომსახურებისთვის (მაგალითად, X RPS თითო pod vCPU = 1, RAM = 2 GiB).
სისტემური ლიმიტი - მაქსი დეგრადაციის გარეშე: 'N _ pods × CU ". მნიშვნელოვანია გავითვალისწინოთ shared დამოკიდებულება (BD/kash/საბურავი).

4) მოთხოვნის მოდელი: პროგნოზი

სტატისტიკური რიგები: ყოველკვირეული/ყოველდღიური სეზონურობა, არდადეგები, სპორტული ფინალები, რეგიონალური მწვერვალები.
კოჰორტები: ქვეყნებში, გადახდის პროვაიდერები, მოწყობილობები, VIP სეგმენტები.
ღონისძიების დელტა: კამპანიების/იარაღის/გამოშვებების/SEO გავლენა.
„რა მოხდება თუ“: + 50% ტრეფიკი 19: 00-22: 00 საათზე; A პროვაიდერის დაკარგვა - გადანაწილება B (ლატენტობის + 30%).
ნამდვილი დროის კორექტირება: წამყვანი მეტრიკის nowcasting (სესიების აღორძინება, მატჩის რიგები, კალათები).

5) წინადადების მოდელი: სად „იშლება“ ჯაჭვი

შეკითხვის კონვეიერი: Edge/CDN - L7 დაბალანსება - აპლიკაცია - ქეში - BD - გარე API, რიგის/ავტობუსის/დამუშავების/ETL.

• შესაძლებლობები (CU/ინსტანცია), მასშტაბურობა (ჰორიზონტი ./ვერტიკალური.) , შეზღუდვები (კონექტორები, pps, IOPS), დაგვიანება.
• უარის თქმის პოლიტიკოსები (rate limit, circuit breaker, დეგრადაცია).
• SLO ადგილობრივი და მათი ღვაწლი e2e-SLO- ში.

6) ნაკრძალი და შეცდომების ბიუჯეტი

ჩვენ ვუკავშირდებით headroom error budget- ს: ბიუჯეტზე ნაკლები რეზერვი.
კრიტიკული ნაკადებისთვის (გადახდა/გადამოწმება) - უფრო მაღალია headroom, მეორეხარისხოვანი - ქვემოთ.
ცივი/თბილი რეზერვები: გააქტიურებულია მწვერვალზე/ავარიებში.

7) მასშტაბები: ტაქტიკა

HPA (დატვირთვის მეტრიკის მიხედვით): RPS, ლატენტობა, რიგის სიგრძე, მომხმარებლის SLIs (better than CPU%).
VPA: რესურსების კორექტირება პოდიუმზე (უფრო ფრთხილად, ვიდრე stateful და p99 GC).
KEDA/გადამყვანები: გარე წყაროების მასშტაბები (Kafka lag, Redis list length, CloudQueue depth).
Warm pools/დათბობა: წინასწარ აღზრდილი ინსტანციები ცივი დაწყების თავიდან ასაცილებლად.
„Load-as-Code“ - ის მიდგომა: skale/limits/Taimauts/retray- ის პოლიტიკა ვერსირებულია და გადის მიმოხილვას.

8) რიგები, ზურგჩანთა და კუდის კონტროლი

მიზანია p99 ზვავის ფორმის ზრდის თავიდან აცილება.
ჩვენ შეზღუდავს პარალელიზმს და რიგის ზომას, შემოიღეთ დროებითი ფანჯრები და idempotence.
Hedging/Retry-budget: შეზღუდეთ მომხმარებლისა და სისტემის მთლიანი ბიუჯეტი.
Graceful degradation: მეორეხარისხოვანი ფირების გამორთვა გადატვირთვის დროს.

9) BD, ქეში და საცავი

BD: კონექტორების ლიმიტი, ჟურნალისტიკა/FSync, ინდექსები, მოთხოვნის გეგმა, replica lag, ცხელი კეისი/ცხრილი, გარიგების max TPS.
კეში: hit-ratio სეგმენტებში, „გამოტოვების ქარიშხალი“ გამოშვებისას/შეზღუდული შესაძლებლობის მქონე პირთათვის, გასაღებების განაწილება.
Storaj: IOPS/throughput, შეფერხებები, კომპრესია, TTL, ძველი ნაწილების/სნაიპშოტების გაწმენდა.
მიგრაციის სქემა: expand - migrate - contract, დაბლოკვის შეჩერების გარეშე.

10) მოვლენების ნაკადები და ETL

Kafka/საბურავი: წვეულებების, lag, ISR, compaction, მწარმოებლების/კონსიუმერების ლიმიტები.
ETL/batchs: გაშვების ფანჯრები, შესრულების დრო ბიუჯეტები, გავლენა prod storan- ზე (throttle I/O).
Idempotence და exactly-once-like კრიტიკული ფლეშ (გადახდა/ბალანსი).

11) ქსელი და პერიმეტრი

L4/L7 დაბალანსება: limits კავშირი, syn backload, TLS offload, session reuse.
CDN/Edge: საგუშაგო, ქეშის პოლიტიკა origin დატვირთვის შესამცირებლად.
შიდა ლიმიტები: pps/mbps VPC/ქვესახეობებში, egress ღირებულება (FinOps).

12) მულტირეგიონი, DR და იურისდიქცია

სტრატეგიები: აქტიური (GSLB/Anycast), აქტიური (ცხელი/თბილი/ცივი DR).
N + 1 რეგიონში: გაუძლოს AZ/რეგიონის დაკარგვას SLO core ნაკადის შენარჩუნებისას.
იურიდიული ლოკალიზაცია: ტრეფიკის/მონაცემების დაყოფა ქვეყნებში, სხვადასხვა ლიმიტები და SLO პროვაიდერებისთვის.
DR ტესტები: რეგულარული თამაშის დღეები რეალური დატვირთვის გადაცემით.

13) გარე პროვაიდერები: კვოტები და მარშრუტები

გადახდა/KYC/ანტიფროდიული/ფოსტა/SMS: TPS კვოტები, ბურსტი, დღის ლიმიტები.
მულტი-პროვაიდერი: მარშრუტიზაცია ლატენტობის/წარმატების თვალსაზრისით, SLO per პროვაიდერი, ავტომობილი-ფეილოვერი.
SLA კონტრაქტები: e2e-SLO კორესპონდენცია, ესკალაციის არხები, სტატუს ვებჰუკი.

14) FinOps: ღირებულება და ეფექტურობა

TCO: compute + storage + ქსელის egress + ლიცენზია/პროვაიდერები + მოვალეობა.
Unit Economics: 1k მოთხოვნის ღირებულება/1 სადეპოზიტო ოპერაცია/1 KYC.
ოპტიმიზაცია: right-sizing, spot/prefix ფასდაკლება, ქეშის ქეში, dedlogs/ტრეკები, შენახვის ცივი დონე.
დატვირთვის დროულად გადაცემა: არა კრიტიკული ბრძოლები „ღამის“ ფანჯრებში და იაფი რეგიონებში.

15) დაშბორდი და ანგარიშები (მინიმალური ნაკრები)

• მიმდინარე დატვირთვა ბმულებზე სტაბილური throughput.
• Headroom სერვისებსა და რეგიონებში; პროგნოზი 24/72 საათისთვის.
• KPI FinOps: $1k მოთხოვნა, $/ანაბარი.

• ტოპ ვიწრო ადგილები (p99, სატურნა, ლაგი), რეზერვი DR- სთვის.

• პროვაიდერების წარმატება/ლატენტობა და ლიმიტები; ტრეფიკის წილი მარშრუტებზე.

• გაფართოების/ინდექსების/ოპტიმიზაციის გეგმა, მოსალოდნელი დაზოგვა/შესაძლებლობების ზრდა.

16) პროცესები და როლები

RACI: პლატფორმა (ინფრა/კლასტერები/დაბალანსება), BD/მონაცემები (ინდექსები, რეპლიკაცია), მომსახურების ბრძანებები (პროფილირება/ქეში), SRE (SLO, ალერტები), Sec/Compliance (კრიპტო/ჟურნალები), ფინანსები (ბიუჯეტი).
რიტმი: ყოველკვირეული capacity მიმოხილვა (საგზაო რუკა, პროგნოზი, რისკები), ყოველთვიური FinOps მოხსენებები, კვარტალური DR ტესტები.
Change Management: დიდი კამპანიები/გამოშვებები გადის capacity-gate (ქვემოთ ჩამოთვლილი სია).

17) გამოშვებისა და კამპანიების სია (capacity-gate)

• მწვერვალზე დატვირთვის პროგნოზი და „+ x% გადაუდებელი კუდი“.
• ხელმისაწვდომი headroom core ნაკადებისთვის (გადახდები/KUS/ლოგინი).
• პროვაიდერებს დაადასტურეს კვოტები; ალტერნატიული მარშრუტები აქტიურია.
• HPA/KEDA ბარიერები და warm-pool მორგებულია.
• შემოწმებულია რიგები/ლიმიტები და დეგრადაცია (პლეიბუკები მზად არიან).
• კანარის წილები და მანქანის დაბრუნება შედის.
• დაშბორდები/ალერტები შემოწმებულია.
• DR გეგმა და ესკალაციის კონტაქტები აქტუალურია.

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

„CPU <70% ყველაფერი კარგია“: დამოკიდებულების შეზღუდვების უგულებელყოფა (BD კონექტორები, IOPS, რიგები).
ცენტრალიზებული „შავი ყუთი“ მეტრული რგოლის გარეშე - შეუძლებელია იმის გაგება, თუ სად არის ზღვარი.
ქეშის სტრატეგიის არარსებობა - გამოშვებისას გამოტოვება კლავს ორიგინს.
Retray limes hardcod ბიუჯეტების გარეშე - მოთხოვნის ქარიშხალი.
„ერთი გადახდის მიმწოდებელი“ არის მწვერვალზე უარის თქმის წერტილი.
თბილი რეზერვების უგულებელყოფა ცივი დასაწყისია, როგორც ინციდენტების მიზეზი.
არ არსებობს პერიოდული DR ტესტები - გეგმა არ მუშაობს საჭიროების შემთხვევაში.

19) მინი კალციუმი (მაგალითი)

სერვისი X: სტაბილურად 350 RPS pod (vCPU = 1, RAM = 2 GiB). მიზანია 5,000 RPS, headroom 25%.
საჭირო სიმძლავრე = '5000/0. 75 = 6667 RPS`.
პოდოვი = 'ceil (6667/350) = 20'. გარდა ამისა, warm-pool 15% კიდევ 3 pod.
BD: 12k TPS ლიმიტი, მიმდინარე სესხი 9k TPS, მწვერვალი პროგნოზი 10. 5k TPS - რეზერვი 1. 5k (14%). საჭიროა: ინდექსები/შარდინგი/რეპლიკები ან ქეშირება 8-მდე შემცირებისთვის. 5k.

Provider A (KYC): კვოტა 120 rps, მწვერვალი 95 rps, კამპანია + 40%, 133 rps> კვოტები, მარშრუტიზაცია 70% A/30% B

20) დანერგვის შაბლონი

1. აღწერეთ e2e ბილიკი და ვიწრო ადგილები.
2. შეიყვანეთ CU და გაზომეთ თითოეული ფენის სტაბილური throughput.
3. ყველა ბმულზე დააკონკრეტეთ მეტრიკა და p99.
4. ჩამოაყალიბეთ მოვლენების/კამპანიების/გამოშვებების კალენდარი.
5. გააკეთეთ პროგნოზი კოჰორტებისა და სკრიპტების შესახებ „თუ“.
6. უზრუნველყოს headroom per-stream და per-რეგიონი (მითითება error budget).
7. კონფიგურაცია HPA/VPA/KEDA + warm-pools, limites/retrai/რიგები.
8. შეამოწმეთ პროვაიდერის კვოტები, ჩართეთ მულტფილმის მარშრუტები.
9. შეაგროვეთ დაშბორდები და ყოველკვირეული რითმი capacity მიმოხილვა.
10. კვარტალურად - DR სწავლებები და მოდელის გადასინჯვა.

21) შედეგი

შესაძლებლობების დაგეგმვა არის პროგნოზების მართვადი კავშირი, არქიტექტურული შეზღუდვები და ღირებულება და არა „CPU- ს დამატება“. როდესაც e2e ბილიკის თითოეულ ფენას აქვს გაზომილი კონტეინერი, ხოლო headroom და დეგრადაციის სტრატეგიები უკავშირდება SLO და error budget- ს, მაშინ პიკის დატვირთვა, კამპანიები და უბედური შემთხვევები წყვეტს სიურპრიზს. ეს მიდგომა ამცირებს ინციდენტების რისკს, სტაბილიზაციას უწევს ბიზნეს მეტრებს და ხარჯების ოპტიმიზაციას ახდენს.