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 бөлу. Ішкі - қатаңырақ; сыртқы SLA ≤ 1-2 тоғыздан төмен.

3) SLI каталогы (референс)

3. 1 API/онлайн-сервистер

Сәттілік: 'SLI _ success = 1 − (5xx + timeout + business_error )/ all_requests'

Жасырындылығы: p95/p99 'http _ server _ duration _ seconds' маршруттар/әдістер/жалға алушылар бойынша

Өткізу қабілеті: 'RPS '/лимиттер/квоталар

Дұрыстығы: валидті жауаптардың үлесі (сигнатуралар, схемалар, инварианттар)

3. 2 Вебхактар/асинхронды жеткізілімдер

Жеткізу: T секундта расталған оқиғалардың үлесі және N ретрай ≤

Тапсырыс берушілер: ұзақ кідіріссіз жазылушылардың үлесі (пер-тенант)

3. 3 Деректер/ETL/DWH

Жаңалық (freshness): 'now − last_successful_ingest_ts'

Толықтығы: 'ingested _ rows/ expected_rows'

Дұрыстығы: сапа тексеруінен өткен жазбалар үлесі

Пайплайндар: мерзімге дейін аяқталған джоб үлесі

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 budget және өзгерістерді басқару

Бюджет (B): 'B = 1 − SLO'.
Бюджет шығысы (burn): нақты қателердің жол берілетін қателерге қатынасы.

• Артық шығын (burn> 1) → фичфриз, сенімділікке назар аудару.
• burn rate> X кезінде қысқа терезеде - инцидент және тамшы. шаралар.
• Жоспарлау: сенімділікке спринттің үлесі өткен кезеңдегі burn-мен корреляцияланады.

6) Алертинг: burn rate және көп терезелі ережелер

Идея: жылдам ағуды және баяу дрейфті ұстаймыз.

• Сыни: «1 сағат ішінде бюджеттің 2%» (жылдам өрт).
• Ескерту: «6 сағат ішінде 5% бюджет» (жайылмалы тозу).

• Тез оқиғалар үшін қысқа терезе (минут-сағат).
• Трендтер үшін ұзын терезе (6-24 сағат).
• Жасырындылығы: флаппингті басатын ≥ 5 мин табалдырығы бойынша алерт және трасса қозғалтқыштарымен байланыс.

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 метрикасы - exemplars → гистограммаларынан/есептеуіштерінен «нашар» трейстерге көшу.
Логи - себептердің көзі: таймауттар, бизнес-қателер кодтары, лимиттер.
Деректер үшін - lineage байланысы: «қандай джоба жаңалық метрикасын кешіктірді».

9) Келісімшарттар және SLA

• SLI/өлшеу/терезе әдісін анықтау.
• Ерекшеліктер (жоспарлы жұмыстар, форс-мажор).
• Тосын оқиғалар мен коммуникация рәсімі (статус-бет, RFO/RCA).
• Өтемақы (service credits) және сұрау тәртібі.
• Юрисдикциясы, қолданылу кезеңі, қайта қарау шарттары.

• СЛО-ны сәулет пен операциялық тәжірибеден гөрі ешқашан қатаң уәде бермеңіз.
• Ішкі SLO мен сыртқы SLA-ны бөліңіз.

10) Құны және басымдылығы

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

11) Рәсімдер мен есептілік

Апта сайынғы есептер: сервистер/жалға алушылар бойынша SLO орындау, бюджет шығысы, топ-себептер, жақсарту жоспарлары.
Постинциденттік RCA: бюджет бөліктерімен байланыстырамыз; түпкі себептерді жоюға міндеттер қоямыз.
Фичфриз: қосу/алу критерийлері.

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) Деректерге арналған SLO және ML (ерекшеліктері)

Толассыз SLO деректері: p99 жаңалық, p99 толықтығы, ақаулықтан кейін «қайта өңдеу» уақыты.
Деректердің келісімшарттары: күтілетін схемалар, көлемдер, шекті мерзімдер; бұзушылық → деректердің инциденті.
ML: SLO инференстің жасырындылығына, SLA фич-стор қолжетімділігіне, дрейф мониторингіне (модель сапасы - жеке тақырып, SLA-дан тыс).

15) Қауіпсіздікпен және құпиялылықпен интеграциялау

PII/құпиясыз SLI логтары; токенизация/бүркемелеу.
SLO/SLA өзгерістерінің және өзгермейтін журналдарда есептерді жариялаудың аудиті.
Реттеуші жолдар үшін (төлемдер/PII) - жеке, неғұрлым қатаң SLO.

16) Чек парақтары

Сервисті іске қосар алдында

• SLI «сәттілік/жасырындылық/өткізу қабілеті/жаңалық» анықталды.
• SLO және терезелер орнатылған; қателер бюджеті есептелген.
• burn-rate (қысқа + ұзын) күйге келтірілген.
• Дашбордтар RED + exemplars → трасса; инциденттердің рунибуктары.
• Көп жалға алынған тіліктер мен маңыздылық шегі.
• Фичфриз және есептілік рәсімі.

Пайдалану

• SLO/burn бойынша апта сайынғы есеп, hardening жоспарлары.
• Сәулет/жүктеме өзгерген кезде SLO қайта бағалау.
• Мерзімді «инцидент-жаттығулар» және рунибуктарды жаңарту.
• Телеметрия құнын және SLI санын бақылау.

17) Runbook’и

Runbook: p99/pay жылдам өсуі

1. Алерт р99> табалдырық → дашборд ашу → exemplar арқылы трейске өту.
2. CLIENT/SERVER-span тар аймақтарын/нұсқаларын салыстыру.
3. Деградацияны қосу (кэш/лимит/фоллбек), тәуелділік пәрменін хабарлау.
4. Тұрақтандырудан кейін - RCA, оңтайландыру міндеттері, SLO-өлшеулерді жаңарту.

Runbook: бюджет шығыны> аптасына 50%

1. Фичтерді қатыру, сенімділік басымдығын көтеру.
2. Қателерді кластерлеу: маршруттар/жалға алушылар/тәуелділіктер бойынша.
3. Түзетулерді шығару → үрдісті қалпына келтіруді растау.
4. Ретроспектива және аллергтерді/шектерді түзету.

18) FAQ

С: Қанша SLO керек?
О: Сыни пайдаланушы сценарийлерінің минимумы: табыс + жасырындылық. Қалғандарының бәрі - қажеттілігіне қарай.

С: Не жақсы - уақыт бойынша немесе сұрау бойынша қол жетімділік?
О: Сұрау бойынша - көбірек пайдаланушы метрикасы. Уақыт жағынан желілік компоненттер/инфра үшін ыңғайлы.

С: Неге орташа емес, p95?
О: Орташа құйрығын жасырады; пайдаланушы p95/p99 сезеді.

С: «Гайкаларды тым қатты бұрауға» қалай болмайды?
О: Шынайы мақсаттардан бастаңыз (тарихи деректер), содан кейін жетілуіне қарай қатаңдатыңыз.

• «Бақылау: логи, метрика, трассировка»
• «Бөлінген трассировкалар»
• «Аудит және өзгермейтін журналдар»
• «Веб-хаттарды жеткізу кепілдіктері»
• «In Transit/At Rest шифрлау»
• «Деректердің шығу тегі (Lineage)»