Провайдерлермен 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)`
• Мұнда outage - тек провайдердің мәртебе-беті бойынша ғана емес, сыртқы мониторинг бойынша қолайсыз күйі.

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' айдың 95% күнінде 450 мс ≤. Шектен асатын сұрау салулардың үлесі үшін себептері талданған есеп беріледі"

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 + сызба форматында тегін ұсынады; қосымша көші-қон қызметтері - Х тариф бойынша, Көшірмелерді жою актімен расталады"

6) OLA: сыртқы SLA үшін ішкі тірек

• Мақсаттары: p99 gateway ≤ 200 мс. Error rate ≤ 0. 3%, DR: RPO 0, RTO 30 мин.
• Жауапкершілігі: SRE-on-call, 24 × 7; жалпы дашбордтар мен алерттар.
• Процестер: релиздердегі хаос-смоук, PR перф-смоук, шейдинг эвристикасы.
• Гейтс: SLO/xaoc-тесті сәтсіз болған кездегі деплой блогы; runbook бағдарламасын міндетті түрде жаңарту.

7) Мониторинг және дәлелдемелер

Синтетика: сыртқы сынамалар (HTTP/TCP), пайдаланушы жолы, «баяу табыс».
RUM: әсерін растау үшін нақты пайдаланушы мониторингі.
Корреляция: 'provider', 'region', 'api _ 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 жіктеуі, war-room ашылуы, IC мақсаты.

2. Провайдерді «ыстық арна» арқылы хабардар ету, артефактілерді беру.

3. Айналма режимдер/фича-жалаулар (stale, шейдинг, rate-cap).

4. Бірлескен таймлайн, қалпына келтіру.

5. Постмортем + әрекет: лимиттер, кілттер, резервтік бағыттар конфигін жаңарту.

6. SLA бойынша кредиттерге бастамашылық ету, биллингте белгілеу.

9) Қауіпсіздік және DPA

DPA/құпиялылық: бақылаушы/процессордың рөлдері, деректер санаттары, заңдылық базасы, өңдеу мерзімдері/мақсаттары, субпроцессорлар және олардың SLA.
Шифрлау: TLS1. 2+, PFS; «тыныштықта» деректер, кілттерді басқару (KMS/HSM), ротация.
Аудит: қол жеткізу журналдары, бұзушылықтар туралы хабарламалар ≤ 72 сағ., сұрау салу бойынша пентест-есептер.
Оқшаулау: сақтау аймағы, келісімсіз әкетуге тыйым салу.

10) Supply Chain және үйлесімділік

SBOM/осалдықтар: CVSS-табалдырықтар саясаты және түзету мерзімдері (сыналды ≤ 7 күн, high ≤ 14).
API үйлесімділігі: келісімшарттық тесттер, «құмсалғыштар» және тұрақты фикстуралар.
Провайдердің өзгерістері: ерте релиз-ноталар, превью/бета-терезелер, кері үйлесімділік.

11) Көп өткізгіштік және фейловер

Active/Active: күрделірек және қымбат, бірақ жоғары қолжетімділік (консистенттілікті ескеріңіз).
Active/Passive: суық/жылы резерв, тұрақты DR жаттығулары.
Абстракциялар/адаптерлер: бірыңғай келісімшарт, денсаулық/құн/көміртегі факторы бойынша маршруттау (егер релевантты болса).
Лицензиялық/коммерциялық шарттар: төзімділік, деректерді шығаруға шектеу, egress құны.

12) Exit-жоспар және мерзімді репетициялар

Деректер/схемалар каталогы және көлемдері.
SDK/API төзімділік сценарийі (минимум - second source).
Құрғақ шығу тесті: экспорт/импорт, қалпына келтіру, инварианттарды тексеру.
Шығғаннан кейін сақтаудың/алып тастаудың заңды мерзімдері.

13) Келісімшарт және conformance тестілері

API сынамалары: оң/теріс, лимиттер, қателер мен ретрациялар.
Оқиғаларды/веб-хаттарды жеткізу: қолтаңба/уақыт/дедуп/қайталау.
Перф-базлайндар: 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, пайплайндардағы гейттер, көп жеткізушілер және нақты exit-жоспар провайдерлерге тәуелділікті сіздің платформаңыздың бақыланатын, өлшенетін және экономикалық жағынан болжанатын бөлігіне айналдырады.