SLA/OLA პროვაიდერებით

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

SLI - გაზომილი ინდიკატორი (წვდომა, ლატენტობა p99, წარმატებით დამუშავებული ვებჰუკები, RPO/RTO).
SLO - SLI მიზნობრივი მნიშვნელობა გაზომვის ფანჯარისთვის (მაგალითად, 99. 9 %/30 დღე).
SLA - იურიდიულად სავალდებულო დოკუმენტი (SLO + პროცედურა + ანაზღაურება).
OLA არის შიდა მიზნები და პროცესები, რომლებიც უზრუნველყოფს SLA- ს შესაბამისობას.
UC (Underpinning Contract) - „სუბსტრატი“ მესამე პირებთან (არხები, მონაცემთა ცენტრი, CDN და ა.შ.).

საზღვრები: მკაფიოდ გამოყავით პროვაიდერის პასუხისმგებლობის სფერო (ღრუბელი/WAF/CDN/გადახდის კარიბჭე/KYC პროვაიდერი) თქვენი ზონიდან (კოდი, კონფისკაცია, კლიენტის პარამეტრები).

2) კრიტიკული მატრიცა და მოდელის არჩევანი

SLA სიღრმე, შემოწმების მოცულობა და OLA/UC მოთხოვნები დამოკიდებულია მატრიცაზე.

3) მეტრიკა და გაზომვის ფანჯრები

წვდომა (Availability): იმ დროის წილი, როდესაც მომსახურება ასრულებს მოთხოვნებს დაშვების შესაბამისად.
ლატენტობა: p95/p99 ძირითადი ოპერაციებისთვის; მხედველობაში მიიღება „ნელი წარმატება“.
მონაცემთა საიმედოობა: RPO (მონაცემთა მაქსიმალური დასაშვები დაკარგვა) და RTO (აღდგენის დრო).
გამტარუნარიანობა/ლიმიტები: გარანტირებული კვოტები (RPS/MBps).
ინტეგრაციის ხარისხი: მიწოდებული ვებჰუკების წილი - X წთ, 2xx პასუხების წილი, გამეორება და დედაპლაცია.
გაზომვის ფანჯარა: მიწის ნაკვეთი/მოცურების 30 დღე, გამონაკლისი (დაგეგმილი სამუშაოები) ლიმიტით.

• `Availability_ext = 1 − (Downtime_confirmed_outages / Total_minutes_in_window)`
• სად არის გარედან - დადასტურებული მიუწვდომელი მდგომარეობა გარე მონიტორინგისთვის და არა მხოლოდ პროვაიდერის სტატუსის გვერდზე.

4) SLA შინაარსი (სექციების შაბლონი)

1. საგანი და რეგიონი (მომსახურება, რეგიონები, API ვერსიები).
2. განმარტებები (SLI/SLO, „ინციდენტი“, „დაგეგმილი სამუშაოები“, „ფორსმაჟორი“).
3. მომსახურების მიზნები (SLO) მოთხოვნის კატეგორიებისა და რეგიონების მიხედვით.
4. მონიტორინგი და მტკიცებულებები: რა გზით, ვისი სენსორებით, რა სიხშირით.
5. ინციდენტები და ესკალაცია: არხები, რეაგირების/განახლების დრო, როლები.
6. ანაზღაურება: სესხები/ჯარიმები/პრემიები, ბარიერები, ფორმულები.
7. უსაფრთხოება და კონფიდენციალურობა: DPA, დაშიფვრა, ჟურნალები, დარღვევების შეტყობინებები.
8. მომსახურების ცვლილებები: დეპრესიები, ნოტიფიკაციის ფანჯარა, თავსებადობა.
9. უწყვეტობა და DR: RPO/RTO, აღდგენის ტესტები.
10. აუდიტი და შესაბამისობა: აუდიტის, ანგარიშგების, სერტიფიკაციის უფლება.
11. Exit Plan: მონაცემთა ექსპორტი, ვადები, ფორმატი, მიგრაციის დახმარება.
12. იურიდიული დებულებები: იურისდიქცია, ფორსმაჟორი, კონფიდენციალურობა, მოქმედების ვადა.

5) ფორმულირების მაგალითები (ფრაგმენტები)

5. 1 წვდომა და გაზომვა

"პროვაიდერი უზრუნველყოფს 99. 95% წვდომა ყოველ კალენდარულ თვეში. წვდომა იზომება მომხმარებლის გარე სინთეზური მონიტორინგით 3 რეგიონიდან 1 წუთის ინტერვალით. ჩაწერილი მიუწვდომლობა 2 რეგიონში ერთდროულად განიხილება SEV2 დონის ინციდენტად და ითვლება Downtime- ში"

5. 2 ძირითადი API ლატენტობა

"p99 პასუხის დრო 'POST/payments/authorize' არის 450 ms თვის დღის 95%. ბარიერის გადაჭარბებული მოთხოვნების წილისთვის გათვალისწინებულია ანგარიში მიზეზების ანალიზით"

5. 3 ინციდენტები და ესკალაცია

"S1: ack - 15 წუთი, აპდეიტები ყოველ 30 წუთში, მიზნობრივი აღდგენა - 2 საათი; S2: ack - 30 წუთი, აფდიტები - 60 წუთი; S3: შემდეგი სამუშაო დღე. არხები: ტელეფონი 24 × 7, ჩატის ხიდი, email"

5. 4 კომპენსაცია (სესხები)

If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%

სესხები არ გამორიცხავს ზიანის ანაზღაურების სხვა გზებს უხეში დაუდევრობით.

5. 5 დეპრესია და თავსებადობა

"მინიმუმ 180 დღის შეტყობინებები თავსებადობის დარღვევისთვის. პარალელური მხარდაჭერა vN და vN + 1 მინიმუმ 90 დღის განმავლობაში"

5. 6 გამოსავალი (Exit)

"დაშლის შემდეგ 30 დღის განმავლობაში, პროვაიდერი უზრუნველყოფს მონაცემთა სრულ ექსპორტს უფასოდ Parquet/JSON + სქემებში; დამატებითი მიგრაციის სერვისები - X- ის ტარიფით. ასლების განადგურება დასტურდება აქტით"

6) OLA: შიდა მხარდაჭერა გარე SLA- სთვის

• მიზნები: p99 gateway - 200 ms, error rate - 0. 3%, DR: RPO 0, RTO 30 წთ
• პასუხისმგებლობა: SRE-on-call, 24 × 7; ზოგადი დაშბორდები და ალერტები.
• პროცესები: რელიეფის ქაოსი, PR- ის პერფორაცია, Shading euristics.
• კარიბჭეები: უკანა ბლოკი SLO/xaoc ტესტის ჩავარდნის დროს; runbook- ის სავალდებულო განახლება.

7) მონიტორინგი და მტკიცებულებები

სინთეზური: გარე ნიმუშები (HTTP/TCP), მომხმარებლის გზა, „ნელი წარმატება“.
RUM: რეალური მომხმარებლის მონიტორინგი გავლენის დასადასტურებლად.
კორელაცია: ეტიკეტები 'provider', 'region', 'app_ method', 'incident _ id'.
არტეფაქტები: ეკრანის კადრები/ტრეისი/ლოგები, KPI ექსპორტი, ესკალაციების ქრონოლოგია.

rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}

8) ინციდენტები და ურთიერთქმედება

1. SEV კლასიფიკაცია, ომის ოთახი გახსნა, IC დანიშნულება.

2. პროვაიდერის შეტყობინება ცხელი არხის საშუალებით, არტეფაქტების გადაცემა.

3. შემოვლითი რეჟიმები/fich დროშები (stale, shading, rate-cap).

4. ერთობლივი დრო, აღდგენა.

5. Postmortem + მოქმედებები: ლიმიტების, გასაღებების, სარეზერვო მარშრუტების კონფისკაციის განახლება.

6. SLA- სთვის სესხების წამოწყება, ბილინგის დაფიქსირება.

9) უსაფრთხოება და DPA

DPA/კონფიდენციალურობა: კონტროლერის/პროცესორის როლები, მონაცემთა კატეგორიები, კანონის უზენაესობის ბაზა, დამუშავების დრო/მიზნები, სუბპროცესორები და მათი SLA.
დაშიფვრა: TLS1. 2+, PFS; მონაცემები „დასვენებისთვის“, კლავიშების მართვა (KMS/HSM), როტაცია.
აუდიტი: წვდომის ლოგოები, დარღვევების შეტყობინებები 72 საათი, პენტესტის მოხსენებები მოთხოვნით.
ლოკალიზაცია: შენახვის რეგიონი, ექსპორტის აკრძალვა თანხმობის გარეშე.

10) Supply Chain და თავსებადობა

SBOM/დაუცველობა: CVSS ბარიერების პოლიტიკა და კორექტირების დრო (კრიტიკა 7 დღე, მაღალი 14).
API- ს თავსებადობა: საკონტრაქტო ტესტები, „ქვიშის ყუთები“ და სტაბილური ფიქსაცია.
პროვაიდერის ცვლილებები: ადრეული გამოშვება-ნოტები, გადახედვა/ბეტა ფანჯრები, საპირისპირო თავსებადობა.

11) მრავალმხრივი და ყალბი

აქტივობა/აქტივობა: უფრო რთული და ძვირი, მაგრამ ხელმისაწვდომობა უფრო მაღალია (გაითვალისწინეთ თანმიმდევრულობა).
Active/Passive: ცივი/თბილი რეზერვი, რეგულარული DR ტრენინგი.
აბსტრაქციები/გადამყვანები: ერთი კონტრაქტი, ჯანმრთელობის/ღირებულების/ნახშირბადის ფაქტორის მარშრუტიზაცია (თუ ეს მიზანშეწონილია).
ლიცენზირებული/კომერციული პირობები: ტრანსპორტირება, მონაცემების გაშვების შეზღუდვა, egress- ის ღირებულება.

12) Exit გეგმა და პერიოდული რეპეტიციები

მონაცემთა კატალოგი/სქემები და მოცულობა.
SDK/API ტოლერანტობის სცენარი (მინიმალური - საშუალო წყარო).
მშრალი გასასვლელი ტესტი: ექსპორტი/იმპორტი, აღდგენა, ინვარიანტების შემოწმება.
გასვლის შემდეგ შენახვის/მოცილების იურიდიული ვადა.

13) ხელშეკრულების ტესტები და კონსულტაცია

API- ის ნიმუშები: პოზიტიური/ნეგატივი, ლიმიტები, შეცდომები და რეაგირება.
მოვლენების/ვებჰუკების მიტანა: ხელმოწერა/დრო/ბაბუა/გამეორება.
Perf bandlines: p99, გამტარუნარიანობა; პროვაიდერის გამოცემის ტესტები.
ჯვარედინი რეგიონი: ერთი რეგიონის დეგრადაცია არ უნდა დაირღვეს SLO გლობალურად.

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

SLA „სტატუსის გვერდზე“ გარე გაზომვების გარეშე.
იგივე მიზნები ყველა რეგიონისთვის/ენდოინტისთვის.
აუდიტის უფლების არარსებობა და ინციდენტების დეტალური ჟურნალები.
არ არსებობს OLA/UC - გარე ვალდებულებები შიგნით ვერავინ შეასრულებს.
გაურკვეველი exit გეგმა - მიმწოდებლის მძევლობა.
„ჯარიმები მხოლოდ სესხებით“ შეწყვეტის უფლების გარეშე სისტემატური დარღვევების შემთხვევაში.
დეპრესიები გარდამავალი ფანჯრის გარეშე.

15) არქიტექტორის ჩეკის სია

1. განსაზღვრულია SLI/SLO საკვანძო ფლეშ და რეგიონებისთვის?
2. შეირჩა გარე მონიტორინგის მეთოდი და მტკიცებულებათა ბაზა?
3. SLA ასახავს ინციდენტებს, ესკალაციას, დაგეგმილი სამუშაოების ფანჯრებს და გამონაკლისების ზღვარს?
4. არსებობს საკრედიტო მასშტაბები/ჯარიმები და N- ის დარღვევების შეწყვეტის უფლება?
5. DPA/უსაფრთხოება: დაშიფვრა, ჟურნალები, შეტყობინებები, სუბპროცესორები, ლოკალიზაცია?
6. საკონტრაქტო ტესტები და ქვიშის ყუთები?
7. შიდა OLA/UC უზრუნველყოფს გარე SLO- ს შესრულებას?
8. DR: გამოცხადებულია RPO/RTO, ტარდება ტრენინგი, არის მოხსენებები?
9. Exit გეგმა: ექსპორტის ფორმატები, ვადები, „მშრალი გასვლის“ პრაქტიკა?
10. CI/CD- ის კარიბჭეები ბლოკავს გამოშვებებს, რომლებიც ზრდის SLA დარღვევის რისკს?

16) მინი მაგალითები (ესკიზები)

16. 1 პროვაიდერის რისკის „დატვირთვის კარიბჭის“ პოლიტიკა

yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"

16. 2 „ინციდენტის მტკიცებულებების“ ექსპორტი

bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '.      {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl

16. 3 ვებჰუკის საკონტრაქტო ტესტი (ფსევდო კოდი)

python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency

დასკვნა

SLA/OLA არა მხოლოდ „იურიდიული ქაღალდი“, არამედ რისკისა და ხარისხის მართვის არქიტექტურული მექანიზმია. სწორი მეტრიკა და ფანჯრები, გარე მონიტორინგი, მკაფიო ინციდენტებისა და კომპენსაციის პროცედურები, შიდა OLA/UC, plines კარიბჭეები, მულტფილმის მომწოდებლები და რეალური exit გეგმა პროვაიდერების დამოკიდებულებას თქვენი პლატფორმის კონტროლირებად, გაზომილ და ეკონომიკურად პროგნოზირებად ნაწილად აქცევს.