Chaos Engineering 'համակարգերի կայունություն

Chaos Engineering 'համակարգերի կայունություն

1) Ինչու՞ քաոս ինժեներիան

Նպատակը 'ապացուցել պրոդ ճարտարապետության կայունությունը ոչ թե բառերով և դիագրամներով, այլ փորձերով։ Մենք միտումնավոր ստեղծում ենք վերահսկվող ձախողումներ, որպեսզի

ստուգել համակարգի վարքագծի և SLO-ի մասին վարկածները։

հայտնաբերել թաքնված SPOF, սխալ թայմաուտներ/ռետտա, կասկադային էֆեկտներ։

թիմերը 'game-days, runbook' s, հաղորդակցություն;

ձևավորել «լռելյայն կայունություն» մշակույթը, ոչ թե «հույս ունենք լավագույնին»։

Կարևոր է, որ Chaos Engineering-ը «կոտրել ամեն ինչ»։ Սա գիտական մեթոդ է: steady-state-state-ի վարկածը բացատրում է տեխնոլոգիական բարելավման վերջնական եզրակացության փորձը։

2) Փորձի հիմնական ցիկլը

1. Steady-state (ռուսական գիծ) 'ի՞ նչ SLI կայուն է։ (օրինակ, հաջողությունը կազմում է 500 մզ 99-ում։ 95%).
2. Վարկածը 'մեկ AZ p95 կորստի ժամանակ կաճի <10 տոկոսը, իսկ հասանելիությունը ՝ 3699։ 9%.

3. Փորձը 'պլանավորված ֆոլտ, սահմանափակ blast radius և stop-չափանիշներով։

4. Դիտարկումը 'metrics/treiss/logs, burn-rate SLO, բիզնես-SLI (օրինակ, հաջողակ դեպոզիտները)։

5. Բարելավումներ 'մենք գրանցում ենք գտածոները, փոխում ենք թայմաուտները/լիմիտները/միկրոօրգանիզացիան, թարմացնում ենք runbook-ը։

6. Ավտոմատիզացիա/ռելիզացիա 'կրկնում ենք գրաֆիկում, ավելացնում ենք CI/CD և game-days օրացույցները։

3) Պերիլա անվտանգության (safety first)

Blast radius: Մենք սկսում ենք նեղ 'մեկ pod/instans/երթուղի/namespace։

Guardrails: Alerts SLO burn-rate (արագ/դանդաղ), ռետրերի սահմանները, QPS սահմանափակումը, բյուջեն։

Stop-չափանիշներ. «Եթե error-rate> X% կամ p99> Y ms N րոպե - անմիջապես stop և rollback»։

Պատուհաններ 'on-call աշխատանքային ժամացույցներ, որոնք տեղեկացված են steikholders, սառեցված օրինագծեր։

Հաղորդակցություն ՝ IC/Tech lead/Comics, պարզ ջրանցք (War-room), հաղորդագրությունների ձև։

4) Մերժումների դասերը և վարկածների գաղափարները

Ցանցը 'ուշացում/ջիտթեր/կորուստ, մասնակի դիֆերենցիալ, ծառայությունների/PSA-ի միջև «ֆլիպող» կապը։

Կոմպյատ/108 ՝ գործընթացների սպանությունը, վերագրանցելով CPU-ն, սպառելով ալյումինե ձայնագրիչները, նեղ փամփուշտները։

Պիտեր և BD 'latency սկավառակների աճը, lag կրկնօրինակը, մեկ շարդի/առաջնորդի կանգառը, split-brain։

Կախվածությունը 'արտաքին API-ի քայքայումը, պրովայդերների սահմանները, 5xx/429 աճը։

Փոփոխությունների կառավարումը 'ձախողված թողարկումը, վատ ֆիչի դրոշը, partial rollout։

Պարիմետրը 'CDN-ը դեգրադացնում է, CSA/Anycript, WAF/bot-պաշտպանության ձախողումը։

Տարածաշրջանը/AZ 'ամբողջական կորուստ կամ «մասնակի» պատահականություն (մի փոքր ավելի վատ և անկանխատեսելի)։

5) Գործիքներ և տեխնոլոգիաներ

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.

Ամպերը ՝ AWS Fox Inject Simulae (FIS), Fox Domains ամպերի մոտ։

Ցանցը/wwww.Toxiproxy (TCP-yad), tc/netem, iptables, Envoy fox (wwww.ay/ab.ru), Istio fentinj.ru։

Գործընթացներ/07: «stress-ng», cgroups/CPU-throttle, www.k-l։

Ռուսական-միկրոօրգանիզացիա ՝ GSLB/MSweights, canary/blue-green, ֆեյլովեր ստուգումների համար։

6) Կոդավորման օրինակներ (Kubernetes)

6. 1 Dray/abant երթուղով (Istio Virtium Live)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

Վարկածն այն է, որ հաճախորդների թայմաուտները/ռետրերը և CB-ը կպահպանեն p95 <300 ms և error-rate <0։ 5%.

6. 2 Pod Kill (Chaos Mesh)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

Վարկածն այն է, որ հավասարակշռիչը և HPA-ն փոխհատուցում են loss-ը մեկ օրինակով առանց p99> 20 տոկոսի աճի։

6. 3 Ցանցային քաոս (BD)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

Վարկածն այն է, որ պուլերը/թայմաուտները/քեշը կնվազեցնեն ազդեցությունը։ p95 վճարումները կմնան SLO-ի լուծումը։

6. 4 Սկավառակի լցնում

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

Հիպոթեզը 'լոգարանների/քվոտաների/ալերտայի լուծարումը կաշխատի մինչև երթուղիների քայքայումը։

7) K8s-ից դուրս փորձարկումներ

7. 1 Toxiproxy (տեղական/ինտեգրացիոն)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7. 2 Envoy HTTP fox (պարիմետր/mesh)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7. 3 AWS FIS (գաղափարի օրինակ)

Փորձարկումը «սպանել» N% EC2-ում Scaling Group-ում, արհեստականորեն բարձրացնել EMS-latency-ը, անջատել NAT-GW-ը մեկ AZ-ում։

Ներկառուցված stop-չափանիշները CloudWatch SLO-մետրիկների վրա։

8) Քաոսի ընթացքում դիտարկման մեթրիկները

SLO/SLI: fraction of good requests, p95/p99, burn-rate.

RED մոդելը կրիտիկական ճանապարհներով (Rate, Errors, Duration)։

Պուլները 'p95, utilization-ի կապի սպասումը։

ԲԴ ՝ lag կրկնօրինակը, www.ks, dreef p95 հարցումը։

Ցանցը ՝ retransmits, RTT, dscp/ecn վարք։

Բիզնես-SLI 'գործարքների հաջողությունը (ավանդներ/չեկաուտ), վերադարձի/սխալների տոկոսը։

Հետքը 'ընտրովի թրեյսները (exemplars), ռելիզի սենսացիայի հարաբերակցությունը։

9) Ինտեգրումը SLO/Error-budget հետ

Պլանավորեք փորձարկումներ սխալների բյուջեի մեջ 'քաոսը չպետք է «քանդի» զանգվածային նպատակները։

Burn-rate ալերտները որպես ավտոմատ kill-switch։

Հաշվետվություններ. «Քանի՞ բյուջեներ են այրվել», «ինչ նշանաբաններ են steady-state»։

10) Game-days (ուսուցումներ)

Սցենարը ՝ կարճ լեգենդ (օրինակ ՝ «տարածաշրջանը-East»), խմբակցությունների քայլերը, SLO նպատակները, դերերը, ժամանակը։

Գնահատումը ՝ RTO/RPO իրական, հաղորդակցման որակը, runbook ճկունությունը։

Ռետրո 'սեփականատերերի և ժամկետների հետ բարելավումների ցանկը, փաստաթղթերի/դաշբորդի նորարարությունը։

11) Ավտոմատիզացիա և CI/CD

Smoke-chaos: Կարճ թեստեր staging-ի վրա յուրաքանչյուր մոդուլով (օրինակ, 1 pod-kill + 200 ms diay մեկ ուղղությամբ)։

Գիշերային/շաբաթական 'ավելի ծանր սցենարներ (5-15 րոպե) զեկույցով։

Պրոմո-գեյթ 'եթե r95/սխալ> շեմն է canary-avto-ratat-ի վրա։

Փորձարկումներ կատարելով (YAML + runbook + SLO-thresholds)։

12) Anti-patterna

«Կոտրել անցքը առանց փետուրների», չկա stop-չափանիշներ, ոչ on-call-ը իրական ռիսկ է։

Մեկ վարակիչ ակցիան գործընթացի փոխարեն։

Հաոսը առանց steady-state-ի, պարզ չէ, թե ինչ կարելի է համարել հաջողության/ձախողում։

Ավելցուկ հետքերը ինքնին-DDoS-ն են, երբ հետաձգվում են։

Անտեսելով բիզնես SLI-ը '«տեխնոլոգիական» հաջողությունները վճարումների/պատվերների ձախողման ժամանակ։

Փոստի վերլուծության և կատարելագործման սեփականատերերի բացակայությունը։

13) Ներդրման թուղթ (0-45 օր)

0-10 օր

Որոշել steady-state SLI (օգտագործող + բիզնես)։

Ընտրել գործիք (Chaos Mesh/Litmus/Toxiproxy/FIS)։

Նկարագրել փետուրները ՝ blase radius, stop-չափանիշներ, պատուհաններ, դերեր։

11-25 օր

Առաջին փորձարկումները 'pod-kill, 100-200 ms dray կրիտիկական apstrim, drop 1% ռուբլիա։

Տեղադրել burn-rate ալերտները, կապել kill-switch stop-չափանիշների հետ։

Անցկացնել առաջին game-day-ը, հավաքել ռետրո և ֆիքսներ։

26-45 օր

Ավելացնել AZ/կախվածության մակարդակի սցենարները (արտաքին PSA, BD-lag)։

Ավտոմատիզացնել nightly-քաոսը staging-ում։ պատրաստել «սեզոնային» սցենարներ (պիկի)։

Փորձերի կատալոգը և կազմակերպության համար հաշվետվությունները/SNE-ի համար։

14) Հասունության մետրերը

Կրիտիկական երթուղիների 3880 տոկոսը ունեն ռուսական փորձարկումներ և steady-state մետրեր։

Avto kill-switch-ն աշխատում է p99/error-rate շեմերը ավելացնելիս։

Եժեքվարտալ 'game-day մակարդակի AZ/տարածաշրջանի; 241 անգամ/մես - ռուսական կախվածության սցենարը։

MTTR-ը նվազում է բարելավման ցիկլից հետո, «էքսպոզիցիոն դեպրեսիայի» հարաբերակցությունը նվազում է։

«Անսպասելի» անկումների մասնաբաժինը իրական ձախողումների ժամանակ ձգտում է զրոյի։

Դաշբորդները ցույց են տալիս «կայունությունը» որպես KPI (burn-rate, վերականգնման ժամանակը, հաջողակ DR գործողությունների մասը)։

15) Guardrails-ի և stop-ի ձգողականների օրինակները

Stop 'http _ req _ failed> 1% 3 րոպե, «p99> 1000 ms' 3 պատուհան,» deposit _ success <99։ 5%`.

Blast radius-ի նվազումը 'մանիֆեստի մեքենան, GSLB-ի քաշը, fox-միգրացիայի անջատումը։

Stop-ի թիմը 'մեկ կոճակ/ջութակ տրամաբանական պատճառներից։

16) Մշակույթ և գործընթացներ

Հաոսը MSE-ռիթմի մի մի մասն է, ոչ թե «էքստրիմ»։

Թափանցիկ հաշվետվությունները, խոցելիության ճանաչումը, ուղղիչ գործողությունները։

Դասընթացը on-call, սիմուլյացիոն հաղորդակցություններ հաճախորդների հետ/գործընկերների հետ։

SLA/SLO-ի և ալգորիթմների հետ կապը, քաոսը պետք է բարձրացնի, ոչ թե պայթեցնել։

17) Եզրակացություն

Chaos Engineering-ը «հույսը ինը» վերածում է ապացուցված կայունության։ Ձևակերպեք steady-state, տեղադրեք փետուր, կոտրեք փոքր և վերահսկվող, դիտեք SLO-ը և բիզնես-SLI-ը, գրանցեք և ավտոմատիզացրեք բարելավումները։ Այդ ժամանակ իրական ձախողումները կդառնան կառավարվող իրադարձություններ 'կանխատեսելի RTO, պաշտպանված error-budget և թիմի պատրաստակամությունը առանց խուճապի։