მოგესალმებით
მოგესალმებით
ვებ-მასშტაბის ფლოტი შეიცავს მრავალ მანქანას. ნებისმიერ მომენტში ზოგი ჯანმრთელია, ზოგი ირთვება, ზოგი დრეინავს, ზოგი კი მშვიდად არის გაფუჭებული. ფლოტი ამას გადარჩენს იმიტომ, რომ ყველა მანქანა მოთხოვნისამებრ პასუხობს ორ მარტივ კითხვას:
- /health — შემიძლია თუ არა ამჟამად რეალური მოთხოვნების მომსახურება?
- /version — რომელ კოდს ვუშვებ?
დამატებით მეტრიკის ენდპოინტი (ჩვეულებრივ /metrics), რომელიც ავლენს კაუნტერებსა და გეიჯებს მონიტორინგის ინსტრუმენტებისთვის, რომლებსაც შეუძლიათ მათი სკრეპინგი.
ეს გაკვეთილი გასწავლით, როგორ შევქმნათ ასეთი ენდპოინტები ისე, რომ ისინი რეალურად ასახავდნენ სინამდვილეს, რას ნიშნავს ოთხი ოქროსფერი სიგნალი პროქსის დონეზე, და როგორ მართავს დაკვირვებული მონაცემები სიმძლავრის გადაწყვეტილებებს.
გაკვეთილის დასასრულს თქვენ შეძლებთ:
- შექმნათ /health ენდპოინტი, რომელიც აღმოაჩენს რეალურ გზის (path) წარუმატებლობას, და არა მხოლოდ პროცესის სიცოცხლისუნარიანობას
- შექმნათ /version ენდპოინტი, რომელიც საშუალებას მოგცემთ გადამოწმოთ, რომ დეპლოი წარმატებით განთავსდა
- გამოიყენოთ ოთხი ოქროსფერი სიგნალი (latency, traffic, errors, saturation) პროქსის დონეზე
- დააკავშიროთ დაკვირვებული სურჯის მეტრიკები სიმძლავრის გადაწყვეტილებებთან: როდის გავზარდოთ სიმძლავრე, როდის გავაკეთოთ drain და როდის გავაგზავნოთ გვერდი (page)
- მსჯელობდეთ SLO-ებზე და შეცდომის ბიუჯეტის დაწვის სიჩქარეზე (error budget burn rate), როგორც ოპერაციული დისციპლინაზე, რომელიც პასუხობს კითხვას „რამდენად მნიშვნელოვანია ეს ჩვენთვის?“
ჯანმრთელობის შემოწმების ორი სახეობა
ცოცხლობა vs მზადყოფნა
ცოცხლობა (Liveness): პროცესი საერთოდ ცოცხალია? გამოიყენება ორკესტრატორების მიერ (Kubernetes, systemd), რათა გადაწყვიტონ, გადატვირთონ თუ არა პროცესი.
მზადყოფნა (Readiness): პროცესი მზად არის თუ არა ახლა რეალური ტრაფიკის მისაღებად? გამოიყენება ლოდბალანსერების მიერ, რათა გადაწყვიტონ, გაუგზავნონ თუ არა მოთხოვნები.
ეს განსხვავებული კითხვებია. პროცესი, რომელიც ცოცხალია, მაგრამ ვერ უკავშირდება თავის ბაზას, არის ცოცხალი, მაგრამ არ არის მზად. პროცესი, რომელიც იწყება, არის ცოცხალი, მაგრამ ჯერ კიდევ არ არის მზად.
ზედაპირული vs ღრმა ჯანმრთელობის შემოწმებები
ზედაპირული (Shallow): აბრუნებს {"status": "ok"}-ს, თუ HTTP ჰენდლერი გაეშვა. ტრივიალურია. აღმოაჩენს მხოლოდ პროცესის გათიშვას.
ღრმა (Deep): რეალურად ასრულებს ნამდვილ მოთხოვნის გზას. ამოწმებს, რომ მონაცემთა ბაზის კავშირების პული აბრუნებს კავშირს, ქეში ხელმისაწვდომია, დაყრდნობილი სერვისები პასუხობენ. აღმოაჩენს ფუნქციონალურ გაუმართაობებს, რომლებსაც ზედაპირული შემოწმებები ვერ ხედავენ.
კომპრომისი: ღრმა შემოწმებები უფრო ძვირი ჯდება (თითოეული არსებითად სინთეტიკური მოთხოვნაა) და შეუძლია გამოიწვიოს კასკადური ავარია (თუ ყველა რეპლიკის ჯანმრთელობის შემოწმება მონაცემთა ბაზას „დააბომბავს“, ნელი ბაზა გახდის ყველა რეპლიკას არაჯანსაღს, რაც მათ როტაციიდან ამოიღებს და სრულად ამოიწურება სიმძლავრე).
საუკეთესო პრაქტიკა: ზედაპირული შემოწმება სიცოცხლისუნარიანობისთვის (სწრაფი, იაფი, გარე დამოკიდებულებების გარეშე) და უფრო ღრმა შემოწმება მზადყოფნისთვის (კეშირებული შედეგები, დათმობილი სიხშირით, რათა არ „დააბომბოს“ დაყრდნობილი სერვისები).
ვერსიის ენდპოინტები
/version აბრუნებს git-ის კომიტს, აგების დროსა და სერვისის სახელს. დეპლოის შემდეგ თქვენ curl https://service.example.com/version აკეთებთ და ამოწმებთ, რომ დაბრუნებული კომიტი ემთხვევა იმას, რაც გააგზავნეთ. თუ არ ემთხვევა, დეპლოი ჩუმად ჩაიშალა.
/version-ის გარეშე, zastarebuli დეპლოი შეიძლება წარმატებულად გამოიყურებოდეს და საათობით იმალებოდეს.
მინიმალური პასუხის სტრუქტურა: {"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}.
ლატენცია, ტრაფიკი, შეცდომები, გაჯერებულობა
ოთხი რიცხვი ფარავს ოპერაციების უმეტესობას
Google SRE წიგნიდან. ოთხი სიგნალი, რომელსაც ზომავთ ყველა სერვისის დონეზე. თუ ამ ოთხს კარგად გაზომავთ, წარმოების პრობლემების უმეტესობას დაიჭერთ მომხმარებლებამდე.
ლატენცია: რამდენი დრო სჭირდება მოთხოვნას? აჩვენეთ განაწილებები, არა მხოლოდ საშუალო მნიშვნელობები. p99 (99-ე პერცენტილი ლატენცია) ბევრად უფრო მნიშვნელოვანია, ვიდრე საშუალო, რადგან „კუდის“ ლატენციაა ის, რასაც მომხმარებლები „ნელი“ სერვისად აღიქვამენ. სერვისს, რომელსაც აქვს 50 მწმ საშუალო და 5000 მწმ p99, აქვს რეალური პრობლემა, რომელსაც მომხმარებლების უმრავლესობა არასდროს ამჩნევს, მაგრამ ყველაზე ცუდად დაზარალებული 1% კი ძალიან კარგად გრძნობს.
ტრაფიკი: რამდენი მოთხოვნაა წამში? საერთო მოთხოვნები, თითოეული ენდპოინტის მიხედვით, სტატუს-კოდის მიხედვით, რეგიონის მიხედვით. ბაზური მაჩვენებლები ცნობილი უნდა იყოს; გააკეთეთ ალერტები ანომალიებზე (მკვეთრი ვარდნა = შემოსული ტრაფიკის პრობლემა; მკვეთრი ზრდა = მოთხოვნის მკვეთრი მატება ან თავდასხმა).
შეცდომები: წარუმატებელი მოთხოვნების წილი. გამიჯნეთ 4xx (კლიენტის შეცდომები — თქვენი ბრალი არაა) და 5xx (სერვერის შეცდომები — თქვენი ბრალია). თვალი ადევნეთ შეცდომების წილს ტრაფიკის პროცენტულად, არა აბსოლუტურ რაოდენობას, რათა ალერტები სწორად მუშაობდეს სხვადასხვა დატვირთვის დონეზე.
გაჯერებულობა (Saturation): რამდენად სავსეა სისტემა? CPU-ს გამოყენება, მეხსიერება, კავშირების პულის სიღრმე, რიგის სიგრძე. ეს არის წამყვანი ინდიკატორი. გაჯერებულობა იზრდება ლატენციისა და შეცდომების გაუარესებამდე. ტიერი, რომელიც 90%-იან გაჯერებულობაზეა, ერთი ცუდი წუთის მანძილზეა რიგის კოლაფსამდე.
პროქსის ტიერზე კონკრეტულად
თითოეული სიგნალი კიდეზე (edge layer) ნათლად ანათებს:
- ლატენცია პროქსიზე: TLS ჰენდშეიკის ხანგრძლივობა, upstream კავშირის დრო, მოთხოვნა-პასუხის საერთო დრო. განცალკევებულად უნდა იზომებოდეს, რადგან ისინი გზის სხვადასხვა ნაწილზე მდებარეობენ.
- ტრაფიკი პროქსიზე: საერთო მოთხოვნები/წმ, ბეკენდების მიხედვით განაწილება (ცხელი ბეკენდი მიუთითებს ლოდ-ბალანსერის დისბალანსზე), სტატუს-კოდების მიხედვით დაშლა.
- პროქსიზე შეცდომები: 4xx კლიენტებისგან (თქვენი მომხმარებლები არასწორ ბოლო წერტილებს იყენებენ), 5xx ბეკენდებიდან (თქვენი სერვისები ცუდად მუშაობენ), პროქსის შიდა შეცდომები (502 = ბეკენდი მიუწვდომელია, 504 = ბეკენდის დრო ამოიწურა).
- გაჯერებულობა პროქსიზე: TLS სესიების რაოდენობა, upstream კავშირების პულის სიღრმე, პროქსის CPU (TLS ტერმინაცია CPU-ს მძიმედ იყენებს).
პრო-რჩევა: 502-ების მკვეთრი ზრდა დაბალი ბეკენდის ლატენტობის პირობებში ნიშნავს, რომ ბეკენდი პასუხის გაცემამდე კავშირს წყვეტს (connection reset, კრაში ან OOM). 504-ების ზრდა კი ნიშნავს, რომ ბეკენდი ნელია, მაგრამ მაინც პასუხობს. წაიკითხეთ შეცდომის კოდი — ის გითხრათ, სად მდებარეობს პრობლემა.
სიგნალების წაკითხვა
თქვენს დაფაზე ბოლო 10 წუთში ჩანს შემდეგი:
- ტრაფიკი: 대략 სტაბილურია ~800 მოთხოვნა/წმ (ხუმრობა არ არის)
- ლატენტობა: p50 სტაბილურია 40მწმ-ზე, p99 კი 5 წუთში 200მწმ-დან 2,500მწმ-მდე გაიზარდა და კვლავ იზრდება
- შეცდომები: 4xx მაჩვენებელი სტაბილურია 0.3%-ზე (ნორმალური ფონური დონე); 5xx მაჩვენებელი გაიზარდა 0.1%-დან 1.2%-მდე (უმეტესად 504 Gateway Timeout)
- გაჯერებულობა: ბეკენდის CPU 5 წუთში 45%-დან 78%-მდე გაიზარდა; პროქსის CPU სტაბილურია 30%-ზე
როდის გავზარდოთ, როდის დავრეკოთ და როდის გავაღვიძოთ ადამიანი
კაპაციტეტის გადაწყვეტილებებს სჭირდებათ ტრიგერები
მეტრიკების დაკვირვება მარტივია. იცოდე, როდის უნდა იმოქმედო მათზე — ეს არის დისციპლინა.
გაზარდე კაპაციტეტი, როდესაც: გაჯერებულობა გადაკვეთს მდგრად საზღვარს (მაგ. backend CPU >70% 5 წუთის განმავლობაში), ან რიგის სიღრმე გადააჭარბებს სამიზნეს, ან p99 ლატენცია აღემატება SLO-ს. ტრიგერმა უნდა ამოისროლოს სანამ რამე გაფუჭდება, და არა მაშინ, როცა უკვე გაფუჭდა.
დაიცალე რეპლიკა, როდესაც: ის მუდმივად ნელი ან შეცდომებით სავსეა, ხოლო დანარჩენი რეპლიკები ჯანსაღია (ერთი რეპლიკის გადახურება ხშირად ჰოსტის დონის პრობლემაა, და არა აპლიკაციის), ან ახალი ვერსიის გაშვებისას, ან რეპლიკის გრაციული გამორთვისას.
გააღვიძე ადამიანი, როდესაც: SLO იწვება უფრო სწრაფად, ვიდრე ერორ ბიუჯეტი უძლებს, ან სატურაციის ტრიგერი ამოუშვებს და ავტოსკალირება ვერ იღებს, ან კასკადური ნიმუში ჩნდება (შეცდომის მაჩვენებელი + რიტრაის მაჩვენებელი ორივე იზრდება).
არ გააღვიძო, როდესაც: ერთი ცუდი წუთი თავისით გამოსწორდება, ან ფონური ბეჩ-ჯობები ქმნიან მოსალოდნელ პერიოდულ მწვერვალებს, ან ხმაური კვეთს ზღვარს (პრობლემა ზღვარშია, და არა სისტემაში).
SLO-ები და Error Budget-ის დაწვა
SLO (service level objective) განსაზღვრავს მისაღებ შესრულებას: „წარმატების მაჩვენებელი >= 99.9% 28-დღიან ფანჯარაში“. დამატებითი (0.1%) არის error budget.
Burn rate: რამდენად სწრაფად მოიხმარ თქვენ error budget-ს. თუ ბიუჯეტის 10%-ს 1 საათში წვავთ, მაშინ rate არის 240-ჯერ უფრო სწრაფი, ვიდრე მდგრადია (1 საათი არის 28-დღიანი ფანჯრის 1/672; 10%-ის დაწვა ამ დროში = 10% × 672 = 6720% პროექცია სრული პერიოდისთვის, როცა დასაშვებია მხოლოდ 100%).
Multi-window burn-rate alerts: გვერდზე გამოგიძახებთ, თუ როგორც მოკლე ფანჯარა (5 წუთი 14.4x rate-ით), ისე გრძელი ფანჯარა (1 საათი 6x rate-ით) უფრო სწრაფად წვავს ბიუჯეტს, ვიდრე მდგრადია. იჭერს როგორც სწრაფ გაუმართაობებს, ისე ნელი დეგრადაციებს.
რატომ არის ეს მნიშვნელოვანი capacity-სთვის: სერვისი, რომელიც მუშაობს 99.9% SLO-ზე 1%-იანი slack-ით, შეუძლია შთანთქას მცირე რყევები. სერვისი 99.93%-ზე (რომელიც ძლივს აკმაყოფილებს SLO-ს) ერთი ცუდი დღის მანძილზეა დარღვევამდე. Capacity-ის გადაწყვეტილებები უნდა მიზნად ისახავდეს კომფორტულ SLO მარჟას, და არა მინიმუმს, რომელიც ჯერ კიდევ აკმაყოფილებს მას.
Capacity-ის გადაწყვეტილება დაკვირვების ქვეშ
თქვენს სერვისს აქვს SLO — 99.9% წარმატებული მოთხოვნა 28 დღის განმავლობაში. მიმდინარე მდგომარეობა მონიტორინგიდან ბოლო 1 საათში:
- წარმატების მაჩვენებელი: 99.5% (შენარჩუნებულია 30 წუთის განმავლობაში)
- ბეკენდის CPU: ფლოტში საშუალოდ 82% (სამიზნე 70%)
- p99 ლატენცია: 800 მს (SLO სამიზნე: <500 მს)
- ტრაფიკი: 1,400 მოთხოვნა/წმ, ბაზურ 1,000-დან (40%-ით მეტი ნორმაზე; ტენდენცია კვლავ იზრდება)
- ავტოსკალირება: კონფიგურირებულია დაამატოს რეპლიკები, როცა CPU > 80% გაგრძელდება 5 წუთი; ამჟამად შუაშია სკალირების პროცესის, რომელიც ~90 წამში დაამატებს 3 რეპლიკას
შეიმუშავეთ გაშვების დაკვირვებადობის გეგმა
სინთეზი
ახლა თქვენ შეგიძლიათ შექმნათ /health, რომელიც დაიჭერს რეალურ წარუმატებლობებს, /version, რომელიც საშუალებას მოგცემთ გადამოწმოთ დეპლოები, ოთხი ოქროს სიგნალის დეშბორდი პროქსის დონეზე და კაპაციტეტის ტრიგერები, რომლებიც დაკავშირებულია SLO-ს დამწვრობის სიჩქარესთან.
გამოიყენეთ ყველა ოთხი.
თქვენი გუნდი უშვებს search.example.com-ს (ძებნის სერვისი, რომელიც განიხილებოდა წარუმატებლობის რეჟიმების გაკვეთილზე). გუნდს სურს გაუშვას დაკვირვებადობა, რომელიც პრობლემებს მომხმარებლებამდე დაიჭერს, ნათელი გვერდი-თუ-არა გადაწყვეტილების მატრიცით. SLO: 99.9% წარმატებული მოთხოვნა, p99 ლატენცია < 300 მწმ, 28-დღიანი ფანჯრით.
კურსის დახურვა
კურსის დახურვა
თქვენ დაასრულეთ ყველა ხუთი გაკვეთილი:
- პროქსიები და წყაროები: კიდის ფენის არქიტექტურა, რომელსაც თითქმის ყველა საჯარო ვებ-სერვისი იყენებს
- სტეიტლეს ჰორიზონტული სკალირება: რატომ მრავლდება იაფად სტეიტლეს დონე და როგორ უნდა დავადგინოთ მისი ზომა
- Ingress-ისა და Egress-ის გამიჯვნა: რატომ იქცევა ერთი ყუთი ორად და ის გაუმართაობის რეჟიმი, რომელიც ამას აიძულებს
- გაუმართაობის რეჟიმები და Blast Radius: SPOF-ები, კასკადები, პოსტმორტემები, უდანაშაულო სამოქმედო პუნქტები
- Observability და Capacity (ეს ბლოკი): რა უნდა გავზომოთ, რომ პრობლემები მომხმარებლებამდე გამოვლინდეს
მთავარი გზავნილი: ვებ-მასშტაბის განაწილებული სისტემა არ არის ჯადო. ეს არის მცირე რაოდენობის შაბლონების (reverse proxy, stateless replicas, ingress/egress split, bulkheads & circuit breakers, ოთხი ოქროსფერი სიგნალი) გააზრებული კომბინაცია. როგორც კი ამ შაბლონებს ამოიცნობ, მათ ყველა პროდაქშენ არქიტექტურაში ხედავ.
თანმხვედრი გაკვეთილები: geometry-of-* სერიის ხუთი გაკვეთილი იგივე მასალას გრაფთეორიისა და გეომეტრიის ენით წარმოადგენს. კარგად ერგება ნებისმიერ თანმიმდევრობას.
კარგად შეასრულეთ.