Հուսալիություն, SRE և շահագործում

01SLI, SLO, SLA և error budget

Service Level Indicator-ը (SLI) օգտատիրոջ փորձառության չափում է, օրինակ՝ հաջողված request-ների բաժինը կամ 300 ms-ից արագ մատուցվածների բաժինը։ Service Level Objective-ը (SLO) այդ ցուցանիշի թիրախն է որոշակի ժամանակահատվածում. checkout-ի request-ների 99.9 տոկոսը հաջողվում է 30 օրվա ընթացքում։ Service Level Agreement-ը (SLA) հետևանքներով պայմանագիր է, սովորաբար՝ գումարի վերադարձով, և այն պետք է ավելի մեղմ լինի, քան ձեր ներքին SLO-ն, որպեսզի զգուշացում ստանաք մինչև այն խախտելը։ Error budget-ը կատարյալի և SLO-ի միջև տարբերությունն է. 99.9 տոկոսը թույլ է տալիս մոտ 43 րոպե ձախողում 30 օրում։ Քանի դեռ budget-ը մնում է, թողարկեք ֆունկցիաներ. երբ այն սպառվել է, առաջնահերթություն տվեք հուսալիության աշխատանքին։ SLI-ները չափեք այնտեղ, որտեղ օգտատերերն են դրանք զգում (load balancer-ի վրա կամ synthetic check-երով), և alert-եր ուղարկեք budget-ի արագ «այրման» դեպքում, ոչ թե CPU-ի ամեն թռիչքի համար։

1groups:
2  - name: api-slo
3    rules:
4      - alert: ApiErrorBudgetFastBurn
5        # 99.9% SLO: page if errors burn the budget 14.4x too fast
6        expr: |
7          (sum(rate(http_requests_total{job="api",status=~"5.."}[1h]))
8            / sum(rate(http_requests_total{job="api"}[1h]))) > (14.4 * 0.001)
9          and
10          (sum(rate(http_requests_total{job="api",status=~"5.."}[5m]))
11            / sum(rate(http_requests_total{job="api"}[5m]))) > (14.4 * 0.001)
12        for: 2m
13        labels:
14          severity: page
15        annotations:
16          summary: "API is burning its 30-day error budget too fast"

02On-call և միջադեպերի արձագանք

On-call նշանակում է, որ ինչ-որ մեկը պատասխանատու է արձագանքելու համար, երբ production-ը կոտրվում է՝ հստակ հերթափոխով, էսկալացիայի ճանապարհով և բավարար հանգստով։ Դա աշխատում է միայն այն դեպքում, եթե alert-երը գործողության ենթակա են. յուրաքանչյուր page պետք է նշանակի օգտատիրոջ համար տեսանելի խնդիր, որին հիմա մարդ է պետք՝ dashboard-ի և runbook-ի հղումով։ Մնացած ամեն ինչ գնում է ticket-ների հերթ։ Երբ միջադեպը սկսվում է, հետևեք պարզ հաջորդականության։ Հաստատեք (acknowledge) alert-ը։ Գնահատեք ազդեցությունը և հայտարարեք severity-ն։ Բաշխեք դերերը. incident commander, որը համակարգում է, մեկը, որն անմիջականորեն աշխատում է, և մեկը, որը հաղորդակցվում է օգտատերերի ու շահագրգիռ կողմերի հետ։ Նախ մեղմացրեք. rollback արեք deploy-ը, fail over արեք, անջատեք feature flag-ը, scale up արեք կամ արգելափակեք չարաշահող տրաֆիկը։ Root cause-ը փնտրեք միայն այն ժամանակ, երբ օգտատերերն արդեն ապահով են։ Ընթացքում timeline պահեք մեկ ալիքում և կանոնավոր ռիթմով status update-ներ հրապարակեք, նույնիսկ եթե ոչինչ չի փոխվել։

• Հայտնաբերել, հաստատել, գնահատել severity-ն, բաշխել դերերը։
• Մեղմացրեք մինչև ախտորոշելը. rollback-ը հաճախ ամենաարագ լուծումն է։
• Հաղորդակցվեք ժամանակացույցով. լռությունը միջադեպերն ավելի վատ է ցույց տալիս։
• Փակեք ստուգումով, հետո պլանավորեք postmortem-ը։

03Runbook-եր և blameless postmortem-ներ

Runbook-ը կարճ, գործնական ուղեցույց է հայտնի իրավիճակի համար. «սկավառակը 90 տոկոսից բարձր է», «հերթի backlog-ը աճում է», «վերականգնել բազան որոշակի պահի դրությամբ»։ Այն թվարկում է ախտանիշները, ստուգվող dashboard-ները, անվտանգ ախտորոշիչ հրամանները, լուծումը և երբ էսկալացիա անել։ Լավ runbook-երը թույլ են տալիս գիշերվա 3-ին հոգնած ինժեներին ճիշտ գործել, և դրանք լուծումն ավտոմատացնելու առաջին քայլն են։ Ցանկացած նշանակալի միջադեպից հետո գրեք postmortem. ինչ է տեղի ունեցել, timeline-ը, ազդեցությունը, ինչպես է հայտնաբերվել և լուծվել, նպաստող գործոնները և կոնկրետ հետագա գործողությունները՝ պատասխանատուներով և ժամկետներով։ Պահեք այն blameless. հարցրեք, թե ինչու համակարգը թույլ տվեց սխալը, ոչ թե ով արեց այն, որովհետև մարդիկ թաքցնում են տեղեկատվությունը, երբ վախենում են մեղադրանքից։ Վերանայեք հետագա գործողությունները մինչև ավարտը. առանց կատարված գործողությունների postmortem-ը պարզապես պատմություն է։

04High availability vs disaster recovery. RPO և RTO

High availability-ն (HA) ծառայությունն աշխատեցնում է կոմպոնենտի ձախողման ժամանակ. հավելվածի մի քանի instance, failover-ի համար պատրաստ բազայի replica, պահուստային load balancer-ներ, health check-եր, որոնք տրաֆիկը շրջանցում են ձախողումներից։ Disaster recovery-ն (DR) վերադառնալու մասին է այն բանից հետո, ինչը HA-ն չի կարող կլանել. ամբողջ ռեգիոնի outage, տվյալների վնասում, ransomware, պատահական DROP TABLE, որն ակնթարթորեն replicate է լինում բոլոր replica-ներին։ Երկու թիվ է սահմանում DR-ը։ Recovery Point Objective-ը (RPO) այն է, թե որքան տվյալ կարող եք թույլ տալ կորցնել՝ չափված ժամանակով. ժամային backup-ները նշանակում են մինչև մեկ ժամի կորուստ։ Recovery Time Objective-ը (RTO) այն է, թե որքան ժամանակ կարող եք անջատված մնալ վերականգնման ընթացքում։ Ավելի փոքր թվերն ավելի թանկ են. շարունակական WAL archiving և point-in-time recovery՝ փոքր RPO-ի համար, warm standby ենթակառուցվածք՝ փոքր RTO-ի համար։ Backup-ները պահեք սերվերից դուրս, գաղտնագրված և version արված, և վերականգնեք դրանք ժամանակացույցով։

• Replica-ները պաշտպանում են hardware-ի ձախողումից, ոչ թե վատ գրառումներից. դրանից պաշտպանում են backup-ները։
• Հետևեք 3-2-1 սկզբունքին. երեք պատճեն, երկու կրիչ, մեկը՝ այլ վայրում։
• Վերականգնման փորձը (restore drill) չափում է ձեր իրական RTO-ն։

05Chaos testing և ամենօրյա շահագործում

Chaos testing նշանակում է միտումնավոր ձախողումներ ներարկել՝ ստուգելու համար, որ համակարգը և թիմը սպասվածի պես են իրենց պահում։ Սկսեք փոքրից և անվտանգից. staging-ում սպանեք հավելվածի instance-ը, կանգնեցրեք Redis-ը, latency ավելացրեք վճարման API-ի mock-ին, լցրեք սկավառակը և տեսեք՝ արդյոք alert-երը գործարկվում են, retry-ները ճիշտ են աշխատում, և ծառայությունը նրբորեն է degrade լինում։ Game day-երը նույնն են անում մարդկանց հետ. փորձարկեք բազայի վերականգնում կամ failover՝ runbook-ը ձեռքին։ Ամենօրյա շահագործումն ավելի քիչ դրամատիկ է, բայց ավելի կարևոր. dashboard-ների և alert-ների վերանայում, անվտանգության թարմացումների կիրառում, սերտիֆիկատների և գաղտնիքների ռոտացիա, սկավառակի և բազայի աճի հետևում, backup job-երի և վերականգնման թեստերի ստուգում, լոգերի և հին build-երի մաքրում, դանդաղ query-ների tuning և կախվածությունների թարմ պահում։ Հետևեք toil-ին՝ կրկնվող ձեռքով աշխատանքին, և ավտոմատացրեք այն մասերը, որոնք ամեն շաբաթ վերադառնում են։

06Multi-window, multi-burn-rate alerting

Burn rate-ը ցույց է տալիս, թե որքան արագ ես ծախսում error budget-ը պլանի համեմատ․ 1 burn rate-ը ծախսում է ճիշտ բյուջեն SLO-ի պատուհանի ընթացքում, 14.4-ը 30-օրյա բյուջեն ծախսում է մոտ երկու օրում։ SRE Workbook-ը խորհուրդ է տալիս համադրել մի քանի շեմ, որոնցից յուրաքանչյուրը ստուգվում է երկար և կարճ պատուհանով։ Page արա, երբ ամսական բյուջեի 2 տոկոսը ծախսվում է մեկ ժամում (burn rate 14.4, հաստատված 5 րոպեի ընթացքում) կամ 5 տոկոսը՝ վեց ժամում (burn rate 6, հաստատված 30 րոպեի ընթացքում)։ Ticket բաց, երբ 10 տոկոսը ծախսվում է երեք օրում (burn rate 1, հաստատված 6 ժամի ընթացքում)։ Երկար պատուհանը տալիս է նշանակալիություն, որպեսզի կարճ «ցատկերը» page չանեն․ կարճ պատուհանը թույլ է տալիս alert-ին դադարել խնդրի շտկումից անմիջապես հետո։ Օգտագործիր recording rule-եր՝ յուրաքանչյուր պատուհանի համար սխալների հարաբերակցությունը նախապես հաշվարկելու համար, որպեսզի alert-ների գնահատումը էժան մնա։

1groups:
2  - name: api-slo-recordings
3    rules:
4      - record: job:slo_errors:ratio_rate5m
5        expr: sum(rate(http_requests_total{job="api",status=~"5.."}[5m])) / sum(rate(http_requests_total{job="api"}[5m]))
6      - record: job:slo_errors:ratio_rate1h
7        expr: sum(rate(http_requests_total{job="api",status=~"5.."}[1h])) / sum(rate(http_requests_total{job="api"}[1h]))
8      - record: job:slo_errors:ratio_rate30m
9        expr: sum(rate(http_requests_total{job="api",status=~"5.."}[30m])) / sum(rate(http_requests_total{job="api"}[30m]))
10      - record: job:slo_errors:ratio_rate6h
11        expr: sum(rate(http_requests_total{job="api",status=~"5.."}[6h])) / sum(rate(http_requests_total{job="api"}[6h]))
12  # Page: (1h > 14.4*0.001 and 5m > 14.4*0.001) or (6h > 6*0.001 and 30m > 6*0.001)

07SLI-ների ճիշտ ընտրություն․ latency-ի histogram-ներ և կախվածություններ

Լավ SLI-ները լավ իրադարձությունների և վավեր իրադարձությունների հարաբերակցություններ են՝ չափված որքան հնարավոր է մոտ օգտատերերին։ Latency-ի համար օգտագործիր histogram-ներ՝ bucket-ների սահմաններով քո շեմերի վրա, հետո SLI-ն սահմանիր որպես, ասենք, 300 ms-ից արագ հարցումների մասնաբաժին․ ինստանսների միջև միջինացված percentile-ները մաթեմատիկորեն սխալ են, իսկ bucket-ների քանակները ճիշտ են գումարվում։ Բացառիր այն, ինչը քո ձախողումը չէ (կլիենտի 4xx սխալներ, health check-եր), բայց խիստ եղիր այն ամենի նկատմամբ, ինչը քոնն է․ 200 պատասխանը սխալի էջով ձախողում է։ Հաշվի առ կախվածությունները․ եթե քո ծառայությանը սինխրոն պետք են երեք այլ ծառայություններ՝ յուրաքանչյուրը 99.9 տոկոսով, քո հասանելի availability-ն 99.9 տոկոսից ցածր է, եթե չավելացնես ռեդունդանտություն, քեշավորում կամ graceful degradation։ Քո SLO-ն պետք է թույլ լինի կոշտ կախվածությունների արտադրյալից, կամ դրանցից մի քանիսը պետք է հանես կրիտիկական ուղուց։

• SLI = լավ իրադարձություններ / վավեր իրադարձություններ՝ սահող պատուհանում։
• Latency SLI՝ histogram-ի bucket-ներից, ոչ թե միջինացված percentile-ներից։
• Կոշտ կախվածությունները սահմանափակում են քո հասանելի SLO-ն։

08Անվտանգ փոփոխություն․ progressive delivery և արագ rollback

Ինցիդենտների մեծ մասն առաջանում է փոփոխություններից․ դեպլոյներ, կոնֆիգուրացիայի թարմացումներ, միգրացիաներ, սերտիֆիկատների կամ DNS-ի խմբագրումներ։ Նվազեցրու յուրաքանչյուր փոփոխության blast radius-ը։ Դեպլոյ արա աստիճանաբար․ նախ մեկ ինստանս կամ տրաֆիկի փոքր տոկոս (canary), համեմատիր դրա error rate-ը և latency-ն մնացածի հետ, հետո ընդլայնիր։ Կոդի դեպլոյը տարանջատիր ֆիչերի թողարկումից flag-երով, որպեսզի վատ ֆիչն անջատվի առանց վերադեպլոյի։ Տվյալների բազայի միգրացիաները դարձրու backward compatible, որպեսզի հավելվածի նախորդ տարբերակը դեռ աշխատի սխեմայի փոփոխությունից հետո․ դա rollback-ը հնարավոր է պահում։ Որտեղ հնարավոր է, ավտոմատացրու rollback-ը canary-ի ձախողման դեպքում։ Բիզնեսի պիկային իրադարձությունների շուրջ սառեցրու ռիսկային փոփոխությունները։ Հետևիր change failure rate-ին և վերականգնման ժամանակին․ դրանք ցույց են տալիս, թե արդյոք delivery-ն ավելի անվտանգ է դառնում, և հուսալիության շահույթների մեծ մասը գալիս է այստեղից, ոչ թե ավելի շատ սարքավորումներից։

09Backup-ներ, որոնք վերականգնվում են․ PITR, անփոփոխելիություն և վարժանքներ

PostgreSQL-ի համար point-in-time recovery-ն համադրում է պարբերական base backup-ը WAL սեգմենտների անընդհատ արխիվացման հետ, այնպես որ կարող ես վերականգնել ցանկացած պահի, օրինակ՝ պատահական DELETE-ից մեկ րոպե առաջ։ pgBackRest-ի և WAL-G-ի նման գործիքները կառավարում են սեղմումը, գաղտնագրումը, retention-ը և զուգահեռ վերականգնումը object storage-ից։ Backup-ները պաշտպանիր նույն սպառնալիքներից, ինչ պրոդակշնը․ օգտագործիր առանձին credentials, որոնք հավելվածի սերվերները չունեն, միացրու object versioning կամ object lock, որպեսզի ransomware-ը կամ կոտրված սերվերը չկարողանա դրանք ջնջել, և պատճենիր երկրորդ տարածաշրջան կամ provider։ Հետո չափիր։ Պլանավորված վարժանքը վերջին backup-ը վերականգնում է նոր սերվերի վրա, գործարկում ամբողջականության ստուգումներ և մի քանի հավելվածային հարցում և գրանցում, թե որքան ժամանակ տևեց։ Այդ տևողությունը քո իրական RTO-ն է․ վերականգնելի ամենանոր տվյալների տարիքը քո իրական RPO-ն է։

1# pgBackRest: full backup weekly, differential daily, WAL archived continuously
2pgbackrest --stanza=main --type=full backup
3pgbackrest --stanza=main --type=diff backup
4pgbackrest --stanza=main info
5 
6# Restore to just before a bad DELETE (run on a fresh server)
7pgbackrest --stanza=main --delta \
8  --type=time "--target=2026-11-05 14:31:00+00" \
9  --target-action=promote restore