KPI ենթակառուցվածքը aptaim

Ինչու՞ է դա անհրաժեշտ

KPI ենթակառուցվածքները վերածում են «զգացմունքները» կայունության մասին չափելի նպատակների, կառավարում են աշխատանքի իրականացումը և կիզակետը։ Ճիշտ մետրիկները կապում են տեխնոլոգիական SLI-ն բիզնես արդյունքների հետ (փոխադարձություն, Time-to-Wallet, LTV) և թույլ են տալիս պլանավորել զարգացումը, բեռը և vs հուսալիության նորարարությունները։

Հիմնական հասկացությունները ՝ SLI, SLO, SLA և սխալների բյուջե

SLI (Systel Level Indications) - չափված որակի ցուցանիշը 'հաջողակ հարցումների մասը, p95 latency, aptaim համար։

SLO (No Level Objective) - SLI-ի նպատակը (օրինակ ՝ "հաջողության թիվ 99։ 9 տոկոսը 30 օրվա ընթացքում")։

SLA (Agream) - արտաքին խոստում, որը չունի/վարկեր։ Միշտ արտադրվում է SLO-ից, բայց ոչ նրան։

Սխալների բյուջեն = '1 մգ SLO'։ Սա չափման պատուհանի համար «ձախողման» առավելագույն թույլատրելի մասն է։ Այն օգտագործվում է ռիսկային հաղորդագրությունների և փորձերի մասին որոշումներ կայացնելու համար։

Օրինակ

SLO հասանելիություն 99։ 30 օրվա ընթացքում 95 տոկոսը 0։ 05% ≈ 21. 6 րոպե «դանդաղ» օրացուցային ամսում։

Չորս «ոսկու» ազդանշան և ավելացված

1. Լատինականությունը (p50/p90/p95/p99, tail ավելի կարևոր է, քան միջին)։

2. Սխալներ (5xx/timeout/բիզնես սխալներ)։

3. Մոսկվա/բաց (RPS/QPS, MBps)։

4. Հագեցումը (CPU/RAM/IO/FD/միացում/GC/քվոտա)։

Բացի այդ, սառը մեկնարկը, հերթերը/բեկլոգը, դոպլոյի ժամանակը, SLO-complaens-ը։

SLI մոդելը տարբեր տեսակի ծառայությունների համար

HTTP/API

Հասանելիություն ՝ «(հաջողակ 2xx/3xx) - տրամաբանական սխալներ )/( բոլոր հարցումները)»

Լատինականությունը '«p95» հաջողակ հարցումների համար; նպատակը «տաք» երթուղիներով։

Որակը '«audience/scope» -ի հարցումների մասնաբաժինը ճիշտ է (առանց authZ-սխալների)։

Հերթեր/ասինխրոն

Հաղորդագրության մշակման ժամանակը 'p95 end-to-end 35N վայրկյան։

Backlog: Բժիշկ <X, պոչը p99 <Y.

Առաքման սխալ ՝ www.Z 210 մ։

BD/kash

Վիրահատությունների լատենտ ՝ p95 get/put/commit։

Հագեցումը 'connational pool usage, hit-ratio casha։

Սխալները ՝ timeouts, deadlocks, eviction storts։

CDN/կարգավիճակը

Hit Ratio: Ռուսաստանի մակարդակի; դեգրադացիան նվազեցնում է բեռի աճը origin-ի վրա։

POP-ի հասանելիությունը 'Anycript-դասավորությունը, մերժումները փոխհատուցվում են հարևանների կողմից։

Վճարումներ (բիզնես SLI)

Time-to-Wallet p95, դեպոզիտի հաջողությունը/%, PSA-ի ձախողումները։

Հասանելիության հաշվարկը և «դեղայքը»

Windows = «հաջողակ հարցումներ/բոլոր հարցումները» (2019, ոչ թե «aptaima»)։

Ենթակառուցվածքային հանգույցների համար այլընտրանքը '"կանաչ "/պատուհանի ժամանակը"։

Օրացույցի պատուհան ՝ 28-31 օր, սայթաքող պատուհանը 'վերջին 30/90 օրվա ընթացքում։

Աշխատանքային ժամացույցները/կրիտիկական պատուհանները 'backoffice-ի համար կարող է համարվել գրաֆիկայի ապտայմ (օրինակ ՝ տեղական ժամանակով 07: 00-22: 00)։

Կախվածության իրականացումը (պարզեցված)

Եթե A ծառայությունը կախված է B-ից և C-ից, համապատասխան հարցումների դեպքում

"Availability (A) no Av (B) no Av (C) - կարևոր է SLO տեղադրել սահմաններում։

SLO հավաքածուի օրինակ (օրինակ)

API Gateway: հասանելիություն 3699։ 95 %/30d; p95 latency 24120 մզ; սխալը 0։ 2%.
Nokout/Payments: դեպոզիտի հաջողությունը 498 է։ 5 %/30d; Time-to-Wallet p95 ≤ 90 с; PSP-timeouts ≤ 0. 3%.
Տվյալների բազա: p95 read 2410 ms; p95 write 2425 ms; replica lag p95 ≤ 150 мс.
Քաշ 'hit ratio 2485 տոկոսը; eviction storms = 0/30д.
Վճարումները ՝ p95 վերամշակումը 245 րոպե; ֆոլս-դրական թիվ 0։ 3%.

Սխալների բյուջե և փոփոխությունների կառավարում

Եթե սխալների բյուջեն սպառված է 50 տոկոսով + նախքան պատուհանի կեսը, ապա ներդրվում է «սառեցում» ֆիչ/սուլֆիդ, ֆոկուսի վրա։

Եթե բյուջեն դանդաղ է ծախսվում, կարող եք արագացնել փորձարկումները/կանարեյները։

Բյուջեի սպառումը կապեք կոնկրետ հաղորդագրությունների/միջադեպերի հետ '«rele.ru _ id» -ի միջոցով։

Alerting: Ինչպես «զանգահարել գիշերը» ապարդյուն

Ալերտները միայն SLO-դեգրադացիայով և կենսական կարևոր ախտանիշներով, ոչ թե յուրաքանչյուր մետրով։

Multi-71, multi-burn rate: Կարճ պատուհան (5-15 րոպե) + երկար (1-6 ժամ)։

Օրինակ ՝ «Burn rate 14-ը հինգ րոպեում և 6-րդ րոպեին 1 ժամվա ընթացքում», էջ on-call։

Հանգիստ ժամացույց ոչ-P1 ազդանշանների համար; պատասխանատվության երթուղի (ownership)։

Dashbords եւ տեսողական պրակտիկա

SLO վահանակ 'ծառայությունների համադրումը, մնացած բյուջեն, կախվածության քարտեզները։

Latency-վահանակ ՝ p50/p90/p95/p99, բաժանումը/tenants/երկրներին/ASN։

Error-վահանակ '108/պատճառներ, հարաբերակցություն թողարկումների/ֆիչֆլագների հետ։

Capacity վահանակ 'CPU/RAM/IO/network/FD/կոնեկտներ, միտումներ և կանխատեսումներ։

Բիզնես վահանակ 'փոխակերպում, Time-to-Wallet, դեպոզիտներ/եզրակացություններ, պաշտպանության ազդեցություն (WAF/հակատանկային)։

Միջադեպեր, MTTR և հետմորտեմներ

KPI արձագանքը

MTTD (հայտնաբերում), MTTA (ակեպտ), MTTR/MTTC (վերականգնում/զսպում), տոկոսն առանց RCA ժամանակի։

Պլեյբուսներ, ովքեր ուղեկցում են, թե ինչպես ներառել ֆիչֆլագները/բլոկները, ինչպես նվազեցնել թողարկումը, հաղորդակցումը բիզնեսի հետ։

Postmortem (blameless): փաստերը, ժամանակի գիծը, առաջին (այդ/գործընթացները), գործողությունները ՝ չարտոնված/երկար, ռեգրեսիայի թեստեր, ազդեցություն SLO-ի վրա։

Արտադրողականությունը, հագեցվածությունը և քայքայումը

Headro.ru: Ռուսական ռեսուրսների մատակարարումը (օրինակ, CPU <70 տոկոսը p95, RAM <75 տոկոսը p95)։

Hot paths: կրիտիկական երթուղիների ավելացումը; «p99» ավելի կարևոր է, քան միջին։

Degradation modes: kash-նոր, read-only, drop-shlifove կարևոր հարցումներ, "սահմանափակումներ/քվոտաներ։

Բանաձևերն ու օրինակները

1) Պահանջների հասանելիությունը

availability = (total_requests - error_requests) / total_requests

որտեղ 'error _ reques.ru' = 5xx + timeouts + բիզնես սխալները (կարգավորված է)։

2) Սխալների բյուջե (րոպե)

error_budget_minutes = window_minutes (1 - SLO)

Օրինակ ՝ 30 օր (43 200 րոպե), SLO 99։ 95% → 21. 6 նոյեմբերի, 2019

3) Burn rate

burn_rate = observed_error_ratio / (1 - SLO)

Եթե SLO 99-ը։ 9% (բյուջե 0։ 1%), իսկ սխալը 1% www.burn _ rate = 10 ռուբլիա։

4) Բաղադրիչ հասանելիություն

A_total ≈ A_gw × A_auth × A_db × A_psp

Փոքր անկումները բազմապատկորեն ծեծում են ընդհանուր A.

Չափման և բացառման քաղաքականությունները և բացառությունները

Չնախատեսված պատուհանները (միջադեպերը) հաշվի են առնվում։

Ծառայության պլանավորված պատուհանները հաշվարկվում են միայն եթե SLA-ն այդքան գրված է։ SLO-ի համար հաճախ չեն նշվում (կամ նշվում են որպես «planned _ downtime»)։

Սինթետիկ vs-ի իրական օգտագործողները 'օգտակար ունենալ երկու ջրանցքներ (RUM + սինթետիկ ստուգումներ)։

Արտեֆակտների օրինակներ

KQL/PromQL (գաղափարներ) (գաղափարներ)

SLI սխալը (5xx + timeouts) հինգ րոպեում

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (բիզնես SLI օրինագծերով)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Կախվածության և կասկադի կառավարումը

SLO պայմանագրերը թիմերի միջև ՝ gateway no auth nowallet PLS։

Degradation policies: Երբ կախվածությունը նվազում է, ծառայությունը անցնում է «պարզեցված ռեժիմին»։

Feature flags: ոչ-քննադատական գործառույթների անջատումը, «մոխրագույն արտադրությունը», որպեսզի նվազեցնի latency պոչերը։

Capacity Planning և կանխատեսումներ

Շչոմեսը։ RPS/MBps կանխատեսումը միտումների և իրադարձությունների մասին (մրցույթներ, խաղեր, գործողություններ)։

Load testing «ոսկե ճանապարհներով», առանձին թեստեր PSA/2019 համար։

Պիկի պահուստը ՝ 1-ի գործակիցը։ 3×–2. 0 մգ սպասվող բեռից։

Chek-SLO/KPI ներդրման ցուցակը

1. Որոշել քննադատական օգտագործողական ճանապարհները և համաձայնել SLI-ի «հաճախորդի տեսանկյունից»։

2. Ընտրել SLO և պատուհանի նպատակները (30/90 օր); հաշվարկել սխալների բյուջեն։

3. Ներկառուցել նետաձիգների հավաքումը դռների/ծառայությունների մեջ, նորմալացնել բանալիը/պատճառները։

4. Տեղադրեք burn-rate ալտերտները (կարճ + երկար պատուհան), երթուղայնացումը և on-call։

5. Տեսողականացնել SLO-complaens-ը, կապել թողարկումների/ֆիչֆլագների հետ։

6. «Բյուջեն փոփոխությունների դեմ» քաղաքականությունը և սառեցման գործընթացը։

7. Հետադարձ հայացքներ և RCA յուրաքանչյուր ավելցուկ, ռեգրեսիայի թեստեր։

8. Եռամսյակային ստուգել SLO-ը բյուջեի իրական օգտագործման և բիզնեսի նպատակների վրա։

Տիպիկ սխալներ

Նրանք չափում են «պինգինգի ապթայմը» 'անտեսելով դիմումների սխալները։

SLO-ն տեղադրվում է «պահեստի մասին» (99։ 999 տոկոսը), բայց անհասանելի են և ոչինչ չեն լուծում։

Ալտերտերը ցածր մակարդակի չափումներով օգտագործողի ախտանիշների փոխարեն։

Կախվածության քարտեր չկան, պարզ չէ, թե որտեղ է այրվում։

SLO կապ չկա թողարկումների հետ, պարզ չէ, թե ով է «ուտել» բյուջեն։

P99 պոչերի անտեսումը լավ միջին է, բայց վատ UX VIP օգտագործողները։

Հատուկ iGaming/fintech համար

Պիկի գրաֆիկի վրա 'խաղեր/ivents/ակցիաներ, նախապես բարձրացնել capacity, տաքացնել kash/CDN, ներառել հատուկ limits։

Բիզնես-SLI: Time-to-Wallet, դեպոզիտի/եզրակացության հաջողությունը, «վճարման արագությունը» p95; dashbords արմատում։

PMS/գործընկերներ 'առանձին SLO/dashbords պրովայդերների վրա, երթուղիների ավտոմատ փոխանցում։

Antibot/antifrod: չպետք է դուրս գա սխալների բյուջեն, առանձնացրեք "օրինաչափական բլոկները" տեխնիկական սխալներից "։

Կարգավորիչ 'ամսագրերի պահպանումը, SLO/SLA-ի վերարտադրումը, միջադեպերի հաշվետվությունները։

FAQ

Արդյո՞ ք SLO-ից պլանային աշխատանք է պետք։

Սովորաբար ոչ, SLO-ն արտահայտում է օգտագործողի փորձառությունը։ SLA-ի համար կարող եք վերապահել բացառությունները։

Ինչու՞ p95, ոչ թե միջին։

Միջինը քողարկում է պոչերը։ UX-ը որոշում է պոչերը (p95/p99)։

Կարո՞ ղ է մեկ SLO-ն ամբողջ ապրանքի վրա։

Պետք է ծառը SLO 'ագրեգատ արտադրանքով և աղջիկներին քննադատական ճանապարհներով/բաղադրիչներով։

Արդյունքը

KPI ենթակառուցվածքի ուժեղ համակարգը SLI-ի օգտագործողն է, իրական SLO-ն, սխալների բյուջեն որպես փոփոխությունների կառավարման լծակ, խելացի ալերտինգը և դեղորայքային և RCA-ի կարգապահությունը։ Միացրեք տեխնոլոգիական ցուցանիշները բիզնես մետրերի հետ, ավտոմատիզացրեք հավաքումը և տեսողականությունը, և ենթակառուցվածքը կդառնա կանխատեսելի, իսկ ապթայմը, որը վերահսկվում է նույնիսկ գագաթնակետային սցենարներում։