Uptime ანგარიშები და SLA აუდიტი

1) რატომ გვჭირდება uptime ანგარიშგების ოფიციალური პროცესი

მომხმარებელთა ნდობა და ხელშეკრულების გამჭვირვალობა არის გაზომვის ერთიანი ტექნიკა, განმეორებითი გათვლები.
SLO მენეჯმენტი და შეცდომების ბიუჯეტი არის რელიზებთან და ინციდენტებთან წვდომის ფაქტის ერთობლიობა.
რეგულარული SLA სესხები არის ობიექტური ფორმულები, პროგნოზირებადი გადახდები/ტესტები.
იურიდიული სტაბილურობა - მტკიცებულებათა ბაზა, დამოუკიდებელი აუდიტი, იურიდიული ჰოლდი.

2) ტერმინები და საზღვრები

SLI Availability - წარმატებული შემოწმების/გარიგების წილი პერიოდისთვის.
SLO - შიდა მიზანი (მაგალითად, 99. 95% 28 დღეში).
SLA არის გარე ვალდებულება (მაგალითად, 99. 9 %/თვე + მომსახურების სესხი).
გაზომვის ფანჯარა - კალენდარული თვე (SLA) და rolling ფანჯრები (SLO).
Scope - რომელი კომპონენტები მოიცავს გაანგარიშებას (edge, API, გადახდები) და რომელი არა (admin პორტალი, non-bird).

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

1. სინთეზური (blackbox/headless) არის პირველადი SLI „მომხმარებლის თვალების ხელმისაწვდომობისთვის“.
2. Logs/მეტრიკა - დაადასტურებს უარის მასშტაბს და ბუნებას.
3. ბიზნეს მოვლენები - „ოპერაციის წარმატება“ (მაგალითად, გადახდა უფლებამოსილია).
4. სტატუსის გვერდი - საზოგადოებრივი კომუნიკაცია; შერწყმულია No.1-3 ფაქტებით.

შეუსაბამობებით: სინთეზის პრიორიტეტი სწორი ~ rum- ით 2 რეგიონიდან.

4) ხელმისაწვდომობის გაანგარიშების მეთოდოლოგია

4. 1 ძირითადი ფორმულა

Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)

4. 2 მრავალი რეგიონალური rum

ინციდენტი ითვლება, თუ დამოუკიდებელი რეგიონების N/ASN ერთდროულად აღირიცხება უარი.
რეკომენდებულია: N = 2 3-დან (EU/NA/APAC).

4. 3 SLI ტიპები

HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
SLI ბიზნესი: წარმატებული გარიგებები/ყველა მცდელობა (კლიენტის უარის თქმის გარდა).

4. 4 გამონაკლისი

დაგეგმილი maintenance ფანჯრები წინასწარ გამოცხადებული N საათის განმავლობაში და დაცული.
Force majeure for SLA- დან (მაგალითად, IX კატასტროფის პროვაიდერი) - მხოლოდ მტკიცებულებებისა და საჯარო შეტყობინებების თანდასწრებით.
კლიენტის შეცდომები/შეზღუდვები (@ ta exceeded, 4xx).

5) Maintenance Windows-

ხელშეკრულებაში შეთანხმებული დროებითი სლოტები (მაგალითად, შეიარაღებული 02: 00-04: 00 UTC + 0).
მარკერები 'maintenance = true' ალერტებში/პანელებში - გამონაკლისი SLI- დან.
შეტყობინების ბარიერი: მინიმუმ 5 სამუშაო დღეში (ან როგორც ხელშეკრულებაში).
ფანჯრის გარეთ - ითვლება SLA გავლენა.

6) Edge შემთხვევები და დამრგვალების წესები

Brownout (ნაწილობრივი გაუარესება): განიხილოს უარის თქმის წილი, და არა „0/1“.
Flapping: მინიმალური აღრიცხვის ერთეული - ნიმუშის ინტერვალი (მაგალითად, 30-60 წამი) + hysteresis (for: 2-5 წთ).
კლოკის დრიფტი: ყველა დრო UTC და ISO-8601; NTP სინქრონიზაცია.

7) მაგალითები PromQL (სინთეზური - აფთიაქი)

promql probe_success{job="blackbox-http"} == 1

promql histogram_quantile(0.95, sum by (le, target) (rate(probe_http_duration_seconds_bucket[5m])))

promql sum_over_time((probe_success==1)[30d]) / (30246060)

promql sum by (target) (max_over_time((probe_success==0)[3m])) >= 2

8) SQL მაგალითები (ანგარიშის აგრეგაცია)

sql with checks as (
select target, ts, success -- success: 1/0 from synthetic_checks where ts >=:from and ts <:to
),
agg as (
select date_trunc('month', ts) m, target,
sum(success)::float / count() as availability from checks group by 1,2
)
select m, target, availability,
(1-availability) extract(epoch from (date_trunc('month', m) + interval '1 month' - date_trunc('month', m))) / 60 as downtime_minutes from agg;

sql select a.m, a.target, a.downtime_minutes, s.incident_id, s.start_utc, s.end_utc from monthly_downtime a left join statuspage_incidents s on a.m = date_trunc('month', s.start_utc)
and tstzrange(s.start_utc, s.end_utc) && daterange(a.m, a.m + interval '1 month');

9) ყოველთვიური ანგარიშის შაბლონი

yaml period: "2025-10-01..2025-10-31 (UTC)"
services:
- name: "API Edge"
sla: "99.90%"
measured_availability: "99.93%"
downtime:
total: "30m 14s"
windows:
- start: "2025-10-12T03:12Z"
end:  "2025-10-12T03:38Z"
impact: "EU+NA, HTTP 5xx spike, p95>2s"
root_cause: "DB connection pool exhaustion"
rca_link: "INC-20251012-0312"
slo_budget:
period_target: "0.10%"
consumed: "0.07%"
- name: "Payments API"
sla: "99.95%"
measured_availability: "99.97%"
summary:
sla_breaches: 0 service_credits: 0 maintenance:
announced: 2 total_duration: "48m"
signatures:
generated_at: "2025-11-01T10:00Z"
report_id: "SLA-2025-10-API"

10) SLA სესხები: გაანგარიშება და გამოყენება

სესხების ცხრილი: მაგალითად, 99. 0–99. 5% → 5% MRR; 98. 0–99. 0% 10% და ა.შ.
True-up: სესხი გამოიყენება, როგორც კრედიტი ნოტი შემდეგ ანგარიშზე.
ავტომატიზაცია: წესი "თუ 'measured _ availability <SLA' credit _ note. create()`».
ვიტრინა კლიენტისთვის: SLA Credits balance პორტატული ბარათი.

11) აუდიტი, მტკიცებულებები და იურიდიული ჰოლდი

აუდიტის ბილიკი: ვინ/რა/როდის გამოითვალა, ტექნიკის ვერსია, საკონტროლო თანხები.
Raw მონაცემები უცვლელია (append-only); კორექტირება - ცალკეული ჩანაწერებით.
Legal Hold: მონაცემთა დიაპაზონის გაყინვა (ნიმუშები, ლოგოები, ინციდენტის ბარათები, ალერტები).
არქივების რეპლიკა: დამოუკიდებელი საცავი (WORM/S3 Object Lock).

12) საზოგადოებრივი სტატუსის გვერდიანი კრეკი

სტატუს გვერდზე მომხდარ ინციდენტს უნდა ჰქონდეს დრო და კომპონენტები.
დროის/მასშტაბის შეუსაბამობა იქმნება discrepancy-record და ხორციელდება RCA.
ანგარიშის შედეგი შეიცავს „რეკონსტრუქციის ნოტების“ განყოფილებას.

13) ინციდენტები და მოხსენებები

თითოეული გაფორმების ფანჯარა შეესაბამება INC ბარათს (ID, SEV, მეპატრონე, RCA, CAPA).
მოხსენებაში: ბმული INC- ზე, მოკლე root cause, CAPA სტატუსი.
SEV-1- ისთვის: პოსტმორი დახურულიდან 48 საათი.

14) მონაცემთა ხარისხის კონტროლი

ნიმუშების ჰიგიენა:> აგენტების წარმატებული ნაკადების 99%, საგუშაგოების ნაკლებობა> 5 წუთი.
Anthi ხმაური: = rum + multi window, debounce.
მარშრუტების/ლოგების სიმულაცია ფიქსირდება და დოკუმენტირებულია.
მეთოდოლოგიის ტესტები: გამოთვლების ერთეულის ტესტები, ოქროს ფაილები ისტორიულ მონაცემებზე.

15) უსაფრთხოება და კონფიდენციალურობა

TLS/mTLS ingest- ისთვის, პაკეტების ხელმოწერა (HMAC).
PII გამოცემა ლოგოებში/მოხსენებებში; SLA ანგარიში არ უნდა გაამჟღავნოს პერსონალური მონაცემები.
RBAC/ABAC ანგარიშებზე; წვდომის კვალი იწერება აუდიტზე.

16) დაშბორდი და SLO ვიჯეტები (რა უნდა აჩვენოთ)

Overall availability მომსახურებისთვის თვეში/კვარტალში.
Downtime windows ერთად severity და დეტექტის არხი.
Error budget burn (fast/slow) და ტენდენციები.
Releases overlay - გამოთვლების ვიდეოები.
SLA credits forecast - მიმდინარე ტენდენციით.

17) განხორციელების გეგმა (3 გამეორება)

1. მოდელი და მონაცემები (2 კვირა): დაფიქსირება SLI/SLO/SLA, ჩართეთ 3,rum სინთეზური, შეაგროვეთ „ნედლეული“ DWH- ში.
2. გაანგარიშება და ანგარიში (2-3 კვირა): ფორმულები, SQL/PromQL, YAML/PDF შაბლონები, კლიენტის პორტალი, ავტომობილების სესხები.
3. აუდიტი და ავტომატიზაცია (3-4 კვირა): Legal Hold, reconciliation სტატუსის გვერდით, ხელმოწერილი ვებჰუკები, დებატების რეგულაციები.

18) ანგარიშის ხარისხის ჩამონათვალი

• განსაზღვრულია სკოპი, SLI, გაზომვის ტექნიკა და ფანჯარა.
• აქ არის -- rum და multi window; flapping თრგუნავს.
• გამონაკლისები (გამონაკლისები/ძირითადი მაჯერი) დოკუმენტირებულია.
• თითოეული დონის ფანჯარა უკავშირდება INC და RCA.
• SLA სესხები გამოითვლება და ასახულია ბილინგში.
• ჩვენ ვასრულებთ მოხსენებას (ფორმულების/მონაცემების ვერსიები).
• Audit Trail და Legal Hold შედის.
• საჯარო სტატუსის გვერდი შეთანხმებულია (ჩანაწერების ნოტები).

19) მინი-FAQ

რატომ არის სინთეტიკა მთავარი წყარო?
იგი ყველაზე ახლოს არის მომხმარებლის ბილიკთან და მოიცავს პერიმეტრს (DNS/CDN/WAF). მრიცხველები/ლოგები - დაზუსტებულია მიზეზი.

როგორ განვიხილოთ ნაწილობრივი დეგრადაცია?
დაბალანსებული დაბალანსება: წარუმატებლობის წილი × ფანჯრის ხანგრძლივობა და არა „ყველაფერი ან არაფერი“.

აუცილებელია „ნედლეულის“ შემოწმება?
დიახ. აუდიტი და ხელახალი გაანგარიშება დავის დროს - raw აუცილებელია.

შედეგი

Uptime ანგარიშები და SLA აუდიტი არ არის „ფიგურა თვის ბოლოს“, არამედ რეპროდუქციული გაზომვის, წესებისა და მტკიცებულებების სისტემა: სწორი SLI, érum შემოწმება, გამჭვირვალე ფორმულები, ინციდენტებთან და ბილინგთან დაკავშირებული კავშირი, გამონაკლისების კონტროლი და ლეგალური ჰოლდი. ჩაწერეთ ტექნიკა, ავტომატურად გაანგარიშება და სესხები, შეინახეთ აუდიტის მისაბმელი - და თქვენი SLA გახდება კონტროლირებადი, გასაგები და დაცული.