Провайдерлер менен SLA/OLA

1) Терминдер жана чек

SLI - өлчөнүүчү индикатор (жеткиликтүүлүк, p99 латенттүүлүк, ийгиликтүү иштетилген вебхактар, RPO/RTO).
SLO - өлчөө терезеси үчүн SLI максаттуу мааниси (мисалы, 99. 9 %/30 күн).
SLA - юридикалык жактан милдеттүү документ (SLO + жол-жоболор + ордун толтуруу).
OLA - SLAнын сакталышын камсыз кылган ички максаттар жана процесстер.
UC (Underpinning Contract) - үчүнчү жактар (каналдар, маалымат борбору, CDN ж.б.) менен "субстрат".

Чек аралар: так камсыз кылуу жоопкерчилигин бөлүү (булут/WAF/CDN/төлөм шлюзы/KYC) сиздин аймак (коду, , кардарлардын жөндөөлөрү).

2) Criticity Matrix жана модель тандоо

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' ≤ 450 мс айдын 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 Чыгуу (Чыгуу)

"Токтотулгандан кийин 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 боюнча перф-смоук, шейдинг эвристикасы.
• Гейтс: 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. Айланма режимдер/Ficha желектери (stale, shading, rate-cap).

4. Биргелешкен таймлайн, калыбына келтирүү.

5. Постмортем + иш-аракеттер: лимиттердин, ачкычтардын, резервдик каттамдардын конфигин жаңыртуу.

6. SLA боюнча кредиттерди демилгелөө, биллингге бекитүү.

9) Коопсуздук жана DPA

DPA/купуялык: контроллер/процессордун ролдору, маалымат категориялары, мыйзамдуулук базасы, кайра иштетүү мөөнөттөрү/максаттары, субпроцессорлор жана алардын SLA.
Шифрлөө: TLS1. 2+, PFS; маалыматтар "тынч", ачкычтарды башкаруу (KMS/HSM), айлануу.
Аудит: кирүү протоколдору, мыйзам бузуулар жөнүндө билдирүүлөр ≤ 72 саат, суроо-талап боюнча пентест-отчеттор.
Локализация: сактоо аймагы, макулдугусуз экспорттоого тыюу салуу.

10) Supply Chain жана шайкештиги

SBOM/алсыздыгы: CVSS босого саясаты жана тактоо мөөнөтү (сындап ≤ 7 күн, жогорку ≤ 14).
API шайкештиги: келишимдик тесттер, "кум" жана туруктуу fixtures.
Провайдердин өзгөрүүлөрү: эрте релиз-ноталар, алдын ала/бета-терезелер, тескери шайкештик.

11) Көп өткөргүч жана Feylover

Active/Active: татаал жана кымбат, бирок жогорку жеткиликтүүлүк (консистенттүүлүгүн эске алуу).
Active/Passive: муздак/жылуу камдык, үзгүлтүксүз окутуу DR.
Абстракциялар/адаптерлер: бирдиктүү келишим, ден соолук/нарк/көмүртек фактору боюнча маршрутизация (эгерде тиешелүү болсо).
Лицензиялык/коммерциялык шарттар: чыдамкайлык, маалыматтарды чыгарууну чектөө, egress наркы.

12) Exit планы жана мезгил-мезгили менен даярдык

Маалыматтар/схемалар жана көлөмдөр каталогу.
SDK/API (минималдуу - second source).
"Кургак чыгуу" сыноо: экспорт/импорт, калыбына келтирүү, инварианттарды текшерүү.
Юридикалык сактоо мөөнөтү/чыккандан кийин алып салуу.

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

API үлгүлөрү: оң/терс, чектер, каталар жана ретра.
Иш-чараларды/вебхуктарды жеткирүү: кол тамга/убакыт/дедуп/кайталоо.
Perf-негиздери: p99, өткөрүү; провайдердин релиз-эскертүүлөрү боюнча регресс-тесттер.
Кросс-аймак: бир аймактын деградациясы SLOну глобалдуу түрдө бузбашы керек.

14) Анти-үлгүлөрү

SLA "статус-бетинде" тышкы өлчөмдөрү жок.
Бардык аймактар/эндпоинттер үчүн бирдей максаттар.
Аудитке укуктардын жана инциденттердин деталдуу журналдарынын жоктугу.
Эч кандай OLA/UC → тышкы милдеттенмелер ичинде аткарууга эч ким жок.
Белгисиз чыгуу планы → жеткирүүчү барымтага.
"Айыптар кредиттер менен гана" системалуу бузуулар болгон учурда токтотууга укугу жок.
өткөөл терезеси жок Депрекейттер.

15) Архитектордун чек тизмеси

1. Негизги флоу жана региондор үчүн SLI/SLO аныкталган?
2. Тышкы мониторинг ыкмасы жана далил базасы тандалдыбы?
3. SLA инциденттерди, эскалацияларды, пландуу иштердин терезелерин жана өзгөчөлүктөрдүн чегин белгилейт?
4. Кредиттик шкала/айыптар жана N бузуулар учурунда токтотуу укугу барбы?
5. DPA/коопсуздук: шифрлөө, журналдар, билдирүүлөр, субпроцессорлор, локализация?
6. Paypline келишимдик тесттер жана Sandbox?
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 Келишим сыноо Webhook (psevdocode)

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, payplayns, multi-берүүчүлөр жана реалдуу exit-план сиздин платформанын контролдонуучу, өлчөнгөн жана экономикалык жактан алдын ала турган бөлүгүнө провайдерлерге көз карандылыкты айландырат.