Error Budgets և SLO կառավարում

1) Ինչու՞ SLO-ն և սխալների բյուջեն

SLO (Direct Level Objective) - օգտագործողի կողմից ընկալվող որակի ընդհանուր մակարդակը։ SLI - չափված մետրը; Error Budget-ը տեղադրված է պատուհանի շեղումների վրա (սովորաբար 30/90 օր)։

Սխալների բյուջեն «աբստրակցիայից» վերածում է կառավարվող ռեսուրսի. Երբ բյուջեն արագ այրվում է, մենք սառեցնում ենք ֆիչին և չինենկոյին։ Երբ առողջապահության բյուջեն, դուք կարող եք արագացնել օրինագծերը։

2) SLI ընտրություն. Ի՞ նչ կարելի է համարել «լավ»

Չափանիշը '«հաջողությամբ օգտագործողի տեսանկյունից»։

2. 1 Դասական SLI

Availability: հաջողակ հարցումների մի մասը (բացառությամբ հաճախորդի չեղյալ հայտարարված)։

«success = htttp _ status բանաձևը 2xx, 3xx, 404 և առանց թայմաուտի» (404 կարող է համարվել հաջողակ read API-ի համար, եթե դա սպասվող սեմանտիկ է)։

Latency: Հարցումների մասը ավելի արագ է, քան շեմը (օրինակ, p95-300 մզ)։

`good_latency = duration_ms ≤ 300`.

Freshness/Staleness: «Տվյալները X րոպեից բարձր չեն» (kash, windows և, գործակիցները)։

Quality 'արդյունքի ճիշտությունը (բիզնես վալիդատորների/backend-invariants)։

2. 2 Սահմաններ և հատվածներ

SLI-ն պետք է համարվի կարևոր հատվածներով '«rope», «tenault/brand», «region/jurisdiction», «payment _ provider»։ Դուք չեք «վերարտադրել» մեկ կրիտիկական գրիչի ձախողումը ամբողջ համակարգով։

3) Բանաձևերն ու բյուջեն

3. 1 Request-based (API-ի համար)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 Time-based (ֆոնային ծառայությունների/striming)

SLO_uptime = good_minutes / total_minutes

3. 3 Նպատակների օրինակ

API ընդհանուր ՝ 99։ 30 օրվա ընթացքում հասանելիության 9 տոկոսը բյուջեն = 0։ 1%.
Քննադատական հիբրիդային գրիչներ ՝ 99։ 95%; 07/որոնում: 99։ 5%.

Լատենտ ՝ p95-300 ms '/v1/payments ", p99-800 ms։

4) SLI-ի փոփոխությունը

4. 1 Սկզբունքներ

RED (Rate/Errors/Duration) ակնհայտ buckets։

Անպայման տեղադրեք «tenault», «region», «rope _ class» (առանց PII)։

Համարեք երկու մետր ՝ «հաջողություն» և «ամեն ինչ», իսկ latency-ի համար '«արագ» և «ամեն ինչ»։

4. 2 Օրինակ Prometheus (rate 5m)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) Alerta burn rate (multi-105, multi-burn)

5. 1 Գաղափար

Դիտարկենք, թե որ արագությամբ է այրվում բյուջեն նպատակի վերաբերյալ։ Եթե արագությունը բարձր է կարճ և երկար պատուհանի վրա 'ազդանշան։

5. 2 Շեմի պրոֆիլներ (SLO 99 համար։ 9%)

Փեյջինգ ՝ burn rate 2414։ 4 ռուբլիներ (բյուջեի 10 տոկոսը 1 ժամվա ընթացքում և 5 տոկոսը 6 ժամվա ընթացքում)։

Tiket: burn rate 356 ռուբլիներ (2 տոկոսը 6 ժամվա ընթացքում և 1 տոկոսը 24 ժամվա ընթացքում)։

5. 3 Կանոնների օրինակ (Prometheus, կեղծ)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

Նմանապես 6ch/210 ժամ տիկետի համար։

6) Կառավարման գրասենյակը. Գործընթացներ

6. 1 Հիբրիդային խաղեր

Եթե բյուջեի մնացորդը <25 տոկոսը և միտումը բացասական են '«կոդի սառեցում» ֆիչիի վրա, SDE/կայունության գերակայությունը։

Կանարեկային ֆորումները պետք է ունենան առանձին SLO-srez («deployae»)։ environment="canary"`).

6. 2 Բեքլոգի գերակայությունը

Բաշխեք թիմի կարողությունը համամասնորեն այրման արագության և եկամուտների վրա ազդելու համար։

Հիմնավորեք համապատասխան պարտքը մետրերով. <<ֆիքս X-ը կնվազեցնի burn rate-ը Y% -ով>>։

6. 3 Փոստի պատահականություն

Յուրաքանչյուր պատահար 'RCA և «ֆիքս, որը չի կարելի նետել» (actionable), վերահսկողությունը «վերադարձավ SLO-ում»։

7) SLO-ն որպես կոդ

7. 1 SLO մանիֆեստի օրինակ (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 Կանոնների գեներացիա

Օգտագործեք գեներատորներ (slo-generae, pyrra, sloth), որպեսզի ավտոմատ ստեղծեք կանոններ, dashbords և շարժիչներ։

8) Դեգրադացիա և պաշտպանություն SLO

Load shedder 'արագ պատասխաններ տալ առանց «թանկ» կախվածության գագաթնակետին։

Cache & stale: `stale-while-revalidate` для read.

Rate/Concurrency limits: Պաշտպանում է backends; կարևոր երթուղիները գերակայությունն են։

Circuit/Timeout: արագ թայմաուտներ և «fallback» ճյուղեր։

Feature flags-ը 'մեկ կոճակի ծանր ֆիգուրի անջատումը։

9) SLO դիտարկումը

Dashbords: SLO actws target, բյուջեի մնացորդը, burn rate ,/պրովայդերների։

Հարաբերակցությունը 'SLO-ի «անցքից» exemplar-ից է հատուկ trace trace/pupaila։

Հաշվետվություններ ՝ ամեն շաբաթ 'միտումներ, բյուջեի սպառում, դեգրադացիայի լավագույն պատճառները։

10) Անտիպատերնի

Մեկ «գլոբալ» SLO-ն ամբողջ մրցույթի համար քողարկում է խնդիրները։ Սեգմենտացեք։

«99. 99 տոկոսը ամեն ինչի վրա" բացառությամբ արժեքի և իրականության։ Ընտրեք նպատակները աշխատանքային փորձից։

Alerts CPU/heap փոխարեն burn rate/SLO-ի փոխարեն։

Անտեսելով 4x/երկար ռեդիրետները, որոնք փչացնում են UX-ը։

Անթափանց պատուհանը (rolling vs օրացույցը) համեմատում է «խնձոր apelsins» -ի հետ։

11) iGaming/ֆինանսական առանձնահատկությունները

Փողի ճանապարհները (դեպոզիտներ/եզրակացություններ) 'առանձին SLO-ն ավելի բարձր է, քան ընդհանուր մակարդակը (օրինակ ՝ 99։ Հասանելիության 95 տոկոսը; p95 24250 ms)։

PMS/KYC-ի պրովայդերներ 'SLO յուրաքանչյուր պրովայդերի համար + ալերտներ իրենց ներդրման համար burn; երթուղիների ավտոմատ փոխակերպումը (smart routing)։

Իրավասություններ/տենանտներ ՝ SLO և բյուջեներ '«region/jurisdiction/brand», որպեսզի տեղական խնդիրը «չթափի» գլոբալ մետրը։

Պատասխանատու խաղը 'SLO-ն լիմիտների/ինքնաբացարկի օգտագործման ժամանակ (compliant-բանաձևեր)։

Աուդիտ/կարգավորիչ, պահեք SLO-ի հաշվետվությունները և խմբագրությունները։ թափանցիկությունը ներքին աուդիտների համար։

12) Չեկ-թուղթ պատրաստակամության համար

• SLIS (availability/latency/quality/freshness) և հատվածներ (rome/tenae/region)։
• Նպատակները (SLO) իրական են, համաձայնեցված են բիզնեսի հետ։ կա 30/90 օր rolling պատուհան։
• Ալերտները burn rate-ով մուլտֆիլմերով (լանդշաֆտ/ticet)։
• SLO որպես կոդ (կանոնների գեներատոր/dashbords); հաշվետվությունները։
• Մետրոպոլիտենի խաղացողները կապված են բյուջեի մնացորդի վրա. կանարյան կտրվածքներ։
• Քայքայման մեխանիզմները (shedder, cache stale, circuit, limits) իրականացվել և փորձարկվել են։
• Metrick metrick (exemplars), պարզ runbooks։
• Ֆինանսական/միգրացիոն ճանապարհները 'առանձին SLO/alerta; PMS/KYC-ն բաժանված է։
• Medretro միջադեպերի և ներդրումների մասին, որոնք հիմնված են burn-ի վրա։

13) TL; DR

SLI-ի իրականացումը արժեքով, տվեք իրական SLO-ը, և կառավարեք Error Budget-ի և burn rate-ի միջոցով մուլտֆիլմերով։ Միացրեք SLO-կոդը, հիբրիդային խաղերը և դեգրադացիան պլանով։ Սեգմենտացեք/տենանտամ/տարածաշրջաններով; փողի ճանապարհների համար պահեք ավելի խիստ նպատակներ և առանձին ալտերտեր։