SLO/SLA жана метрика

SLO/SLA жана метрика

1) Терминдер жана иерархия

SLI (Service Level Indicator) - "колдонуучу бизди көргөндөй" өлчөнүүчү көрсөткүч: ийгиликтүү суроо-талаптардын үлүшү, p95 жашыруун, маалыматтардын сергектиги, ийгиликтүү иштетилген батчалардын үлүшү ж.б.
SLO (Service Level Objective) - байкоо интервалында (28/30/90 күн) SLI максаттуу мааниси. Мисалы: "99. 9% суроо/төлөө 400 мс ≤ аяктайт".
Error budget — 1 − SLO. SLO менен 99. 9% бюджет каталар = 0. 1% убакыт/суроо.
SLA (Agreement) - юридикалык жактан маанилүү тейлөө деңгээли: SLO, өлчөө, өзгөчөлүктөр, компенсациялар/айыптар кирет.

2) Долбоорлоо принциптери

Белгилери> ички метрика. SLI чыныгы колдонуучу тажрыйбасын чагылдырышы керек.
негизги SLI аз саны. Кызмат үчүн - 2-5 негизги: ийгилик, жашыруун, өткөрүү жөндөмдүүлүгү/сергектик, тууралык.
Критикалык жолдорду камтуу. Ар бир бизнес скрипт үчүн (checkout, login, webhook, ETL-жүктөө) - SLI/SLO сиздин топтому.
"Ийгиликтин" катуу семантикасы. "Код 200" эмес, "колдонуучу өз убагында жооп алды жана валиден натыйжасы".
Тышкы жана ички SLO бөлүү. Ички - катуураак; төмөнкү 1-2 тогуз тышкы SLA ≤.

3) SLI каталогу (шилтеме)

3. 1 API/онлайн кызматтар

Ийгилик: 'SLI _ success = 1 − (5xx + timeout + business_error )/ all_requests'

Жашыруун: p95/p99 'http _ server _ duration _ seconds' маршруттар/ыкмалар/ижарачылар боюнча

Өткөрүү жөндөмдүүлүгү: 'RPS '/лимиттер/квоталар

Тактык: валиддик жооптордун үлүшү (белгилер, схемалар, инварианттар)

3. 2 Webhook/асинхрондук жеткирүү

Жеткирүү: T секунд жана ≤ N retrains тастыкталган окуялардын үлүшү

Кардарлар: узакка созулбаган абоненттердин үлүшү (пер-тенант)

3. 3 Маалымат/ETL/DWH

Freshness: 'now − last_successful_ingest_ts'

Толук: 'ingested _ rows/ expected_rows'

Тууралыгы: сапаттуу текшерүүдөн өткөн жазуулардын үлүшү

Payplayns: мөөнөтү бүткөрүлгөн JOB үлүшү

3. 4 Мобилдик/кардарлар SDK

Кардарлардын ийгилиги: өлүмгө ката жок сессиялардын үлүшү

round-trip Латентность: Рендерге суроо-талаптын p95

Кэш-хиттер: Кэш кызмат үлүшү (аткаруу белгиси катары)

4) Формулалар жана максаттардын мисалдары

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99. 95% '30 күн → error budget = 0. 05% суроо.

• `uptime = (obs_window − downtime) / obs_window`

• ' SLO _ latency = p95 (route = "/pay") ≤ 400 ms' 7 күндүк кесилиштерде, кэш жылуулардан тышкары (1%)

• ' SLO _ freshness (dataset =" orders") ≤ 10 min' p99 24 саат.

5) Error бюджет жана өзгөрүүлөрдү башкаруу

Бюджет (B): 'B = 1 − SLO'.
Бюджеттин чыгымы (burn): иш жүзүндөгү каталардын жол берилгендерге катасы.

• Ашыкча керектөө (burn> 1) → fichfries, ишенимдүүлүккө басым.
• burn rate> X кыска терезеде - окуя жана капчык. чаралар.
• Пландоо: ишенимдүүлүк боюнча спринт үлүшү өткөн мезгил ичинде burn менен байланышат.

6) Alerting: burn rate жана көп терезе эрежелери

Идея: тез агып жана жай жылып кармап.

• Критикалык: "1 саатта бюджеттин 2%" (тез өрт).
• Эскертүү: "6 саатта бюджеттин 5% ы" (сойлоп жүрүүчү деградация).

• Кыска терезе (мүнөт-саат) тез окуялар үчүн.
• тенденциялар үчүн узун терезе (6-24 саат).
• Латенттүүлүк: p99 боюнча alert> босого ≥ 5 мин, Fapping басуу жана трасса менен байланыш.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) Көп ижара (multi-tenant) жана сегменттөө

SLI/SLO ижарачылар/пландар/региондор боюнча эсептелет, антпесе медиана ийгиликсиздиктерди "жабат".
Статистикалык мааниси үчүн окуялардын минималдуу саны (guard-rails).
SLA (мисалы, "Pro 99. 9%, Free 99. 5%»).

8) байкоо жана байкоо менен байланыш

SLI Metrics - гистограммалар/exemplars менен эсептегичтерден → "жаман" соодага өтүү.
Логи - себептердин булагы: таймауттар, бизнес каталарынын коддору, лимиттер.
Маалыматтар үчүн - lineage менен байламта: "кандай джоба сергектик метрикасын кечеңдеткен".

9) Келишимдер жана SLA

• SLI аныктоо/өлчөө ыкмасы/терезе.
• Өзгөчөлүктөр (пландуу иштер, форс-мажор).
• Окуя жана байланыш тартиби (статус-бет, RFO/RCA).
• Компенсация (service credits) жана суроо тартиби.
• Юрисдикция, колдонуу мөөнөтү, кайра кароо шарттары.

• Эч качан ачык СЛОну архитектура жана операциялык практикадан катуу убада кылбаңыз.
• ички SLO жана тышкы SLA бөлүп.

10) Наркы жана артыкчылыктуу

тогуздун баасы сызыктуу өсөт. «99. 9% → 99. 99%" = башка архитектуралык класс (N + 1, мультизона, актив-актив).
SLOну эң баалуу колдонуучу аракеттерине коюңуз.
Телеметрия наркын көзөмөлдөө: downsampling, квота, реплика жана класстары боюнча сактоо.

11) Жол-жоболор жана отчеттуулук

Жумалык отчеттор: сервистер/ижарачылар боюнча SLO аткарылышы, бюджеттин чыгашасы, топ-себептер, жакшыртуу пландары.
Постинцидент RCA: бюджеттин бөлүктөрү менен байланышкан; себептерин жоюуга тапшырма беребиз.
Fichfries: киргизүү/алып салуу критерийлери.

12) Үлгүлөр (тез баштоо үчүн)

12. 1 SLO карта (мисал)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 стол "жетилген SLO"

13) Эрежелердин үлгүлөрү (фрагменттери)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) маалыматтар жана ML үчүн SLO (өзгөчөлүктөрү)

SLO маалыматтар аркылуу: p99 сергектик, p99 толуктугу, "кайра иштетүү" убакыт ийгиликсиз кийин.
Маалыматтар контракттары: күтүлгөн схемалар, көлөмдөр, мөөнөттөр; → маалыматтарды бузуу.
ML: SLO Infenerce жашыруун, SLA Fich Store жеткиликтүүлүгү, Drift мониторинг (сапаты модель - өзүнчө тема, SLA тышкары).

15) Коопсуздук жана купуялык менен интеграция

PII/сырлары жок SLI Логи; токенизация/маскировка.
SLO/SLA өзгөрүүлөрүн жана өзгөрүлбөгөн журналдарда отчетторду жарыялоону текшерүү.
Жөнгө салуучу жолдор үчүн (төлөмдөр/PII) - өзүнчө, катуу SLO.

16) Чек-баракчалар

Кызмат/Чич башталганга чейин

• SLI аныкталган "ийгилик/жашыруун/кубаттуулугу/сергектик".
• берилген SLO жана терезелер; бюджети эсептелген.
• орнотулган burn-rate алерт (кыска + узун).
• Dashbord RED + exemplars → жолдор; инциденттердин рунибуки.
• Көп ижара тилкелери жана маанилүүлүк босоголору.
• Fichfries тартиби жана отчеттуулук.

Иштетүү

• SLO/burn жумалык отчет, hardening пландары.
• Архитектура/жүктү өзгөртүүдө SLO кайра баалоо.
• Мезгил-мезгили менен "окуя-машыгуу" жана Рунибук жаңылоо.
• Телеметрия наркын жана SLI санын көзөмөлдөө.

17) Runbook’и

Runbook: тез өсүшү p99/pay

1. Alert p99> босого → ачык дашборд → exemplar боюнча барып, соода.
2. тар CLIENT/SERVER-SPAN табуу, региондорду/нускасын салыштыруу.
3. Деградацияны күйгүзүү (кэш/лимит/фоллбек), көз карандылык командасына кабарлоо.
4. турукташтыруу кийин - RCA, оптималдаштыруу милдеттери, SLO-өлчөө тактоо.

Runbook: бюджеттик чыгымдар> 50% жумасына

1. Чичтерди тоңдуруп, ишенимдүүлүктүн артыкчылыгын көтөрүү.
2. Каталарды кластерлештирүү: каттамдар/ижарачылар/көз карандылыктар боюнча.
3. Оңдоолорду чыгаруу → тенденцияны калыбына келтирүүнү ырастоо.
4. Retrospective жана alerts/босоголор тууралоо.

18) FAQ

S: канча SLO керек?
О: Критикалык колдонуучу жагдайлар боюнча минималдуу: ийгилик + жашыруун. Калгандарынын баары - зарылчылыкка жараша.

S: Жакшыраак эмне - убакыттын өтүшү менен же суроо-талап боюнча?
A: Суроо-талап боюнча - көбүрөөк колдонуучу метрика. Убакыттын өтүшү менен тармактык компоненттер/infra үчүн ыңгайлуу.

S: Эмне үчүн p95 эмес, орточо?
О: Орто куйругун жашырат; колдонуучу p95/p99 сезет.

С: Кантип "гайкаларды" өтө катуу бурмалоого болбойт?
A: реалдуу максаттар менен баштоо (тарыхый маалыматтар), андан кийин жетилген сайын катуулатуу.

• "Байкоо: Логи, метрика, трек"
• "Бөлүштүрүлгөн жолдор"
• "Аудит жана өзгөрүлбөгөн журналдар"
• "Webhook жеткирүү кепилдиктери"
• "In Transit/At Rest шифрлөө"
• "Маалыматтардын келип чыгышы (Lineage)"