ოპერაციები და ალერტას ტევადობის მართვის სისტემები

ალერტები სისტემების შესაძლებლობებში

1) რატომ არის ეს აუცილებელი?

Capacitive Alerts აფრთხილებს ტექნიკურ ლიმიტებთან მიახლოების შესახებ ინციდენტამდე დიდი ხნით ადრე: „ჩვენ ჭერის 80% -ით ვართ - დროა გავაფორმოთ მასშტაბები“. სასურსათო ბიზნესისთვის ეს პირდაპირ ფულს ეხება: გამოტოვებული განაკვეთები/ანაბრები, სესიის ფრაქციები, ცოცხალი თამაშების შეფერხებები და პროვაიდერების უარყოფა = დაკარგული შემოსავალი, რეპუტაცია, ჯარიმები და გამოტოვება.

მიზნები:

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

2) ძირითადი ცნებები

შესაძლებლობები (კაპიტალი): მაქსიმალური სტაბილური გამტარუნარიანობა (RPS/TPS, კონექტორები, IOPS, throughput).
Headroom: რეზერვი მიმდინარე დატვირთვასა და შეზღუდვებს შორის.
SLO/SLA: პასუხის ხელმისაწვდომობის/დროის მიზნობრივი დონე; ალერტები უნდა იყოს „SLO-aware“.
Burn-rate: შეცდომების/ლატენტობის SLO ბიუჯეტის „დაწვის“ სიჩქარე.
High/Low Watermark: ზედა/ქვედა დონე ოპერაციებისა და მანქანების აღდგენისთვის.

3) სიგნალების არქიტექტურა და მონაცემთა წყაროები

ტელემეტრია: მეტრიკა (Prometheus/OTel), ლოგოები (ELK/ClickHouse), ტრეკები (OTel/Jaeger).
ფენის მიდგომა: ალერტები ფენების გასწვრივ (Edge-API - ბიზნეს სერვისები - სტრიქონები/სტრიქონები - BD/ქეში, ფაილური/ობიექტის საცავი და გარე პროვაიდერები).
კონტექსტი: ფიჩეფლაგები, გამოშვებები, მარკეტინგის კამპანიები, ტურნირები, გეო-განლაგება.
საბურავის ინციდენტი: Alertmanager/PagerDuty/Opsgenie/Slack; runbook- ის და ესკალაციის მატრიქსის მითითება.

4) ძირითადი მეტრიკა ფენებზე (რა უნდა აკონტროლოთ და რატომ)

Edge / L7

RPS, 95-/99-percentil latence, error rate (5xx/4xx), ღია კავშირები.
Rate-limits/quotas, drops на CDN/WAF/Firewall.

API-шлюз / Backend-for-Frontend

Saturation of vorkers/work pulu, მოთხოვნის ჯერი, timeouts of downstrims.
დეგრადაციის წილი (fallbacks, circuit-breakers).

ხაზი/Streeming (Kafka/Rabbit/Pulsar)

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).
წვეულება skew, ხელახალი ჩარევა, ISR (Kafka- სთვის), rettrai/ბაბუა ლეიტერი.

ასინქრონული ვორკერები

დავალებების ლოდინის დრო, რიგის სიგრძე, ვადაგასული SLA დავალებების პროცენტი.
Saturation CPU/Memory/FD ტყვიებზე.

კაში (Redis/Memcached)

Hit ratio, latence, evictions, მოძრავი მეხსიერება, დაკავშირებული მომხმარებლები/ops/s.
მტევანი: slots/შენიშვნები, failover events.

БД (PostgreSQL/MySQL/ClickHouse)

Active connections vs max, lock waits, replication lag, buffer/cache hit.
IOPS, read/write latency, checkpoint/flush, bloat/fragmentation.

ობიექტის/ფაილების საცავი

PUT/GET ლიტერატურა, 4xx/5xx, egress, მოთხოვნები/წმ, პროვაიდერის ლიმიტები.

გარე პროვაიდერები (გადახდები/KUS/თამაშების პროვაიდერები)

TPS ლიმიტები, QPS ფანჯრები, error rate/timeout, retrais, „cost per call“.

ინფრასტრუქტურა

CPU/Memory/FD/IOPS/ქსელის ტესტირება კვანძებზე/საყრდენებზე/ASG.
HPA/VPA მოვლენები, pending pods, კონტეინერი OOM/Throttling.

5) Capacitive ალერტების ტიპები

1. სტატიკური ბარიერები

მარტივი და გასაგები: 'db _ connections> 80% max'. კარგია სიგნალის შუქურა.

2. ადაპტირებული (დინამიური) ბარიერები

ისინი ემყარება სეზონურობას და ტენდენციას (rolling windows, STL დაშლა). საშუალებას გაძლევთ დაიჭიროთ „უჩვეულოდ მაღალი კვირის ამ საათში/დღეს“.

3. SLO ორიენტირებული

ისინი მუშაობენ მაშინ, როდესაც error-budget სიჩქარეს X საათის ჰორიზონტზე SLO დაარტყამს.

4. პროგნოზული (forecast-alerts)

„მიმდინარე ტენდენციით 20 წუთის შემდეგ, ეტაპი 90% -ს მიაღწევს“. გამოიყენეთ ხაზოვანი/Robust/Prophet მსგავსი პროგნოზი მოკლე ფანჯრებზე.

5. კომპოზიციური (multi-signal)

ტრიგერიტი კომბინაციაში: 'queue _ lag' + 'consumer _ consumer _ cpu 85%' + 'autoscaling at max' - „საჭიროა ხელით ჩარევა“.

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

High/Low Watermark:

ზემოთ: გაფრთხილება 70-75%, კრეტა 85-90%. ქვემოთ: ჰისტერეზი 5-10 პროცენტული პუნქტით. ისე, რომ არ „დაასხით ზღურბლზე“.

დროებითი ფანჯრები და ჩახშობა:

'for: 5m' კრიტიკოსებისთვის, 'for: 10-15m' გაფრთხილებისთვის. Night-mode: გადაიტანეთ არაკრიტიკული ჩატი პეიჯინგის გარეშე.

ღონისძიების ჯგუფი:

დაჯგუფეთ მომსახურება/მტევანი/გეო, ისე რომ არ მიიღოთ ინციდენტის ბარათები.

Dependency-aware suppression:

თუ KYC პროვაიდერი გარედან და API შეცდომებით არის შედეგი ინტეგრაციის მფლობელის პეიჯიმი და არა ყველა მომხმარებელი.

დროებითი მარკეტინგის ფანჯრები:

აქციის დროს, ხმაურის ბარიერების გაზრდა „მოსალოდნელი ზრდისთვის“, მაგრამ SLO ალერტების ხელუხლებელი დატოვება.

7) წესების მაგალითები (ფსევდო-Prometheus)

BD კონექტორები:


ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

Kafka lag + auto skaling ზღვარზე:


ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

Burn-rate SLO (ლატენტობა API):


ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

Redis მეხსიერება და ევიკუაცია:


ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

გადახდის პროვაიდერი - ლიმიტები:


ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8) SLO მიდგომა და ბიზნესის პრიორიტეტი

სიგნალიდან ბიზნესზე გავლენის მოხდენამდე: კონტეინერის ალერტები უნდა იყოს მითითებული risk to SLO (სპეციფიკური თამაშები/გეო/მეტრიკა GGR, ანაბრის კონვერტაცია).
მრავალ დონის: გაფრთხილებები on-call მომსახურებისთვის; კრეტა - დომენის მფლობელის პეიჯი; SLO ვარდნა არის მთავარი ინციდენტი და გუნდური „კონსოლიდირებული“ არხი.
დეგრადაციის ficheflages: დატვირთვის ავტომატური დაქვეითება (ნაწილობრივი read-only, მძიმე შეცდომების შემცირება, ჯეკპოტის ბროდკასტების სიხშირის დაქვეითება, ცოცხალი თამაშების „მძიმე“ ანიმაციების გამორთვა).

9) ავტო სკეილინგი და „სწორი“ გამომწვევები

HPA/VPA: მიზნები არა მხოლოდ CPU/Memory, არამედ ბიზნეს მეტრებში (RPS, queue lag, p99 latency).
Warm-up timings: გაითვალისწინეთ ცივი დასაწყისი და პროვაიდერის ლიმიტები (ASG spin-up, კონტეინერების ბილეთები, გაათბეთ ქეში).
Guardrails: გაჩერებული პირობები შეცდომების ზვავის ზრდის დროს; „სკეილერის პრობლემისგან“ დაცვა.
Capacity-playbooks: სად და როგორ დავამატოთ ხიბლი/წვეულება/რეპლიკა, როგორ გადანაწილდეს ტრეფიკი რეგიონებში.

10) პროცესი: დიზაინიდან ოპერაციამდე

1. ლიმიტების რუქა: თითოეული ფენისთვის „ჭეშმარიტი“ bottleneck ლიმიტების შეგროვება (max conns, IOPS, TPS, èttas პროვაიდერები).
2. მეტრული პრედექტორების არჩევანი: რა სიგნალები მიანიშნებს ყველას წინაშე „N წუთის განმავლობაში“.
3. ბარიერების დიზაინი: მაღალი/დაბალი + SLO-burn + კომპოზიციური.
4. თითოეული კრეტისთვის Runbook: დიაგნოზის ნაბიჯები („რა უნდა გახსნათ“, „რომელი ბრძანებები“, „სად უნდა ესკალაცია“), სამი მოქმედების ვარიანტი: სწრაფი შემოვლითი, სკალირება, დეგრადაცია.
5. ტესტირება: დატვირთვის სიმულაცია (chaos/game days), ალერტების „მშრალი გაშვება“, ანტი-ხმაურის შემოწმება.
6. შურისძიება და შვილად აყვანა: სიგნალის მფლობელი = სამსახურის მფლობელი. მფლობელის გარეშე - არ არის პეიჯი.
7. რეტროსპექტივები და tuning: ცრუ/გამოტოვებული ყოველკვირეული ანალიზი; მეტრიკა „MTTA (ack), MTTD, MTTR, Noise/Signal Ratio“.

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

CPU> 90% პანიკა: ლაზერული/queues- სთან კორელაციის გარეშე, ეს შეიძლება ნორმალური იყოს.
„ერთი ბარიერი ყველასთვის“: სხვადასხვა რეგიონი/დროის ზონა - სხვადასხვა ტრაფიკის პროფილები.
ალერტი გარეშე runbook: პეიჯი მკაფიო მოქმედების გარეშე ამცირებს on-call.
სიბრმავე პროვაიდერების მიმართ: გარე კვოტები/ლიმიტები ხშირად პირველი არიან, ვინც „დაარღვია“ სკრიპტები (PSP, KYC, ანტიფროდი, თამაშების პროვაიდერები).
არ არსებობს ჰისტერეზია: „ხერხი“ საზღვარზე 80 %/79%.

12) iGaming/finplatform მახასიათებლები

გრაფიკის მწვერვალები: პრემიერ დრო, ტურნირების ფინალი, დიდი მატჩები; წინასწარ გაზარდეთ მიზნობრივი შენიშვნები და შეავსეთ ქეში.
Live strimes და jecpots: სამაუწყებლო გამომძიებლების აურზაური - ბროკერებზე/ვებსაიტებზე შეზღუდვები.
გადახდა და KYC: პროვაიდერების ფანჯრები, ანტი-ფროიდის ესკიზი; შეინახეთ სარეზერვო მარშრუტები და დეპოზიტების „გრეის რეჟიმი“.
გეო-ბალანსი: პროვაიდერის ადგილობრივი წარუმატებლობები - გადაადგილება მეზობელ რეგიონში, სადაც არის headroom.
პასუხისმგებლობა: ფსონების/ჯეკპოტების დაკარგვის რისკის შემთხვევაში - დომენის გუნდის მყისიერი პეიჯი + ბიზნეს შეტყობინება.

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

Capacity Overview: headroom ფენებში, ტოპ 3 სარისკო მონაკვეთი, burn-rate SLO.
Stream & Queues: lag, backlog growth, consumer saturation, HPA state.
DB & Cache: connects, repl-lag, p95/p99 latency, hit ratio, evictions.
Providers: TPS/ფანჯრები/კვოტები, timeouts/errors, ზარის ღირებულება.
Release/Feature Context: გამოშვებები/ficeflages მრუდის გვერდით.

14) განხორციელების სია

„ჭეშმარიტი“ ლიმიტებისა და მფლობელების სია.
მეტრიული პრედექტორების რუკა + ფენებს შორის კავშირი.
სტატიკური ბარიერები + ჰისტერეზი.
SLO-burn-alertes კრიტიკულ ბილიკებზე (ანაბარი, განაკვეთი, ცოცხალი თამაშის დაწყება).
პროგნოზული ალერტები რიგში/სტრიმები/კონექტები.
Suppression/maintenance ფანჯარა; პოლიტიკის ანტი-ხმაური.
Runbook 'და გუნდებით, გრაფიკებით, დეგრადაციის ფიჩეფლაგებით.
ყოველკვირეული ცრუ პროცესების ანალიზი და tuning.
მარკეტინგული კამპანიებისა და ივენტების კალენდრის აღრიცხვა.

15) runbook შაბლონის მაგალითი (შემოკლებით)

სიგნალი: 'StreamBacklogAtRisk'

მიზანი: lag> 10 მილიონი ზრდის თავიდან აცილება და დამუშავების შეფერხება> 5 წთ

დიაგნოზი (3-5 წუთი):

1. შეამოწმეთ 'hpa _ desired/max', throttle/oom.

2. იხილეთ 'rate' '', განაწილება პარტიებისთვის (skew).

3. ბროკერის შემოწმება (ISR, under-replicated, ქსელი).

მოქმედებები:

გაზარდეთ consumer-replicas + N- ით, გაზარდეთ max-in-flight.
პრიორიტეტული აუზის ჩართვა „კრიტიკულ ტოპიკებში“.
დროებით შეამცირეთ მეორადი დამუშავების სიხშირე/enrichment.
თუ 'ASG at max' - მოითხოვოს დროებითი uplift ღრუბლიდან; პარალელურად - ჩართეთ მძიმე ფუნქციების დეგრადაცია.
დაბრუნება: „ჩვეულებრივი ტრაფიკის“ პროფილზე დაბრუნება 'lag <1 მილიონი' 15 წუთის შემდეგ.
ესკალაცია: კაფკას კლასტერის მფლობელი, შემდეგ SRE პლატფორმა.

16) KPI და სიგნალის ხარისხი

Coverage: კრიტიკული ბილიკების% დახურული capacitive ალერტებით.
ხმაური/სიგნალი: არაუმეტეს 1 ყალბი პეიჯი on-call/კვირაში.
MTTD/MTTR: კეპის ინციდენტები გამოვლენილია SLO დარტყმებამდე 5 წუთით ადრე.
Proactive saves: თავიდან აიცილეთ ინციდენტები (პოსტმორტემების მიხედვით).

17) სწრაფი დაწყება (კონსერვატიული ნაგულისხმევი)

BD: გაფრთხილება კონექტების 75 %/IOPS/lat; კრეტა 85%, ჰისტესეზი 8-10 პროცენტული პუნქტით.
ქეში: 'hit <0. 9 'და' evictions> 0 '> 5 წთ - გაფრთხილება;' used _ mem> 85% '- კრეტა.
რიგები: 'lag' ზრდა> 3c საშუალოდან 30d + 'hpa at max' - კრეტა.
API: `p99 > SLO1. 3 '10 წუთი - გაფრთხილება;' burn-rate> 4 '15 წუთი - კრეტა.
პროვაიდერები: 'throughput> 90% კვოტები' - გაფრთხილება; 'timeouts> 5%' - კრეტა.

18) FAQ

Q: რატომ არ შეგიძლიათ უბრალოდ „CPU> 80%“?
A: კონტექსტის გარეშე/რიგები არის ხმაური. CPU თავისთავად არ არის ტოლი რისკის წინაშე.

Q: საჭიროა ადაპტირებული ბარიერები?
ა: დიახ, ყოველდღიური/ყოველკვირეული სეზონურობისთვის - ისინი ამცირებენ ცრუ ოპერაციებს.

Q: როგორ გავითვალისწინოთ მარკეტინგი/ტირიფი?
A: კამპანიის კალენდარი - გრაფიკები გრაფიკებზე + ანტი-ხმაურის დროებითი კორექტირება, მაგრამ SLO ალერტებს არ შეეხოთ.