Նոր որոնվածի release notes-ում գրված է՝ «սխալների ուղղում և արտադրողականության բարելավում»։ Արտահայտության երկրորդ կեսը ոչ ոք չի չափում։ Ձեռքով ռեգրեսիան ինժեներից խլում է 2–3 օր յուրաքանչյուր թողարկման համար, և ամեն ժամկետ դրանից մի քանի կետ է հանում, առաջինը՝ ամենաերկարները. կոնվերգենցիան լրիվ աղյուսակով, կադրերի չափերով գործարկումը, 40 կետանոց ստուգաթերթը։ Այդ ցուցակը մենք վերածում ենք ռեգրեսիոն հավաքածուի, որը վերագործարկվում է որոնվածի, կոնֆիգուրացիայի կամ թողարկման ամեն փոփոխության վրա և արդյունքը համեմատում Ձեր հաստատած վերջին build-ի հետ։
Ստենդը
CloudLAB-ի բաժանորդագրության դեպքում սարքը սեսիաների միջև մնում է ստենդում։ Ավտոմատ կոմուտացիան այն միացնում է ստենդի գեներատորներին կամ մեր սեփական տրաֆիկի գեներատորին, ուստի գործարկմանը պետք չեն ո՛չ հայտ, ո՛չ էլ ինժեներ սենյակում։ Սարքը կարգավորվում է իր API-ով, իսկ եթե API չկա, սկրիպտն աշխատում է կոնսոլի կամ վեբ ինտերֆեյսի հետ՝ ավելի դանդաղ և ինտերֆեյսի փոփոխության դեպքում խափանվելու ռիսկով։
Յուրաքանչյուր test case կոդ է Ձեր ռեպոզիտորիայում՝ տոպոլոգիա, սարքի կոնֆիգուրացիա, տրաֆիկի պրոֆիլ, բեռի աստիճաններ, տևողություն, pass չափանիշ։ Ձեր CI job-ը կանչում է հավաքածուն API-ով կամ CLI-ով՝ build-ի համարով, և վճիռը ստանում է unit թեստերի կողքին, գիշերային ժամանակացույցն օգտագործում է նույն մուտքի կետը։ Թե ինչու պետք է անվտանգության պլատֆորմները վերստուգել ամեն թարմացումից հետո, քննարկել ենք առանձին գրառման մեջ։ Այստեղ խոսքը մեխանիկայի մասին է։
Ինչ ենք ստուգում
- Սկզբնական վիճակ. սարքի հաղորդած որոնվածի տարբերակը, սկրիպտով կիրառված կոնֆիգուրացիան, հաշվիչները առաջին test case-ից առաջ և վերջինից հետո
- Throughput և latency 1G-ից 100G պորտերում՝ Ձեր կադրերի չափերով և տրաֆիկի պրոֆիլով, baseline-ի դիմաց
- Latency p99 բեռի յուրաքանչյուր աստիճանում, որտեղ կոդի ավելի դանդաղ ճանապարհը հաճախ երևում է ավելի շուտ, քան կշարժվի առավելագույն արագությունը
- Կոնվերգենցիա և failover երթուղիների կամ սեսիաների լրիվ աղյուսակով. կապուղու կորուստ, հարևանի կորուստ, HA փոխարկում, ընդհատումը յուրաքանչյուր հոսքի համար միլիվայրկյաններով
- Ֆունկցիոնալ ստուգաթերթ՝ 40-ից 150 կետ, յուրաքանչյուրի համար տրաֆիկի capture, հայտնի խնդիրները նշված են որպես known
- Անվտանգության արտադրողականություն միացված ստուգմամբ. throughput, միացումներ վայրկյանում, միաժամանակյա սեսիաներ
- Դրեյֆ. յուրաքանչյուր KPI վերջին build-երի ընթացքում՝ կողք կողքի
Յուրաքանչյուր KPI ունի թույլատրելի շեղում, որը համաձայնեցվում է Ձեր թիմի հետ առաջին ավտոմատ գործարկումից առաջ՝ մի քանի տոկոս throughput-ի համար, ֆիքսված սահման միլիվայրկյաններով կոնվերգենցիայի համար, զրո ֆունկցիոնալ կետի համար։ Baseline-ը առաջին լրիվ գործարկումն է այն build-ի վրա, որին Դուք վստահում եք։ Այն պահվում է կոնֆիգուրացիայի, տրաֆիկի պրոֆիլի և ստենդի սխեմայի հետ, որպեսզի հաջորդ գործարկումները համեմատվեն նույնի հետ։
Ինչն է սովորաբար խափանվում
Լուռ ռեգրեսիա։ Գիշերային գործարկման օրինակ միջուկային երթուղիչի build-ի վրա. ստուգաթերթի 38 կետից 37-ն անցնում է, կոնվերգենցիան սահմանի ներսում է, 1518 բայթ կադրերով throughput-ը 6 %-ով ցածր է նախորդ build-ից, latency p99-ը 70 % բեռի դեպքում աճել է 18 %-ով։ Release notes-ում դրանցից ոչ մեկը չկա։ Գործարկումը տևում է 2 ժ 40 ր առանց մարդկանց, և կարմիր արդյունքը pipeline-ում է 06:10-ին։ Ձեռքով 40 կետանոց ստուգաթերթը միջուկային երթուղիչի որոնվածի համար տևում է 2 օր։
Դրեյֆ։ KPI-ը, որը յուրաքանչյուր թողարկման հետ կորցնում է 1 %, անցնում է ամեն առանձին ստուգում և մեկ տարի անց 6 %-ով ցածր է։ Նախորդ build-ի հետ ամեն համեմատություն կանաչ է, հաստատված baseline-ի հետ համեմատությունը՝ ոչ։ Հաշվետվությունը պահում է երկուսն էլ։
Կեղծ տագնապ բարձրացնող հավաքածու։ Առաջին շաբաթներին կարմիր գործարկումը հաճախ հենց հավաքածուի մեղքն է՝ վեբ ձև, որտեղ դաշտը տեղափոխվել է, այլ տրաֆիկի պրոֆիլով վերցված baseline, զրոյական շեղում KPI-ի համար, որը գործարկումների միջև տատանվում է 2 %-ով։ Յուրաքանչյուր նման դեպք ուղղվում է հավաքածուում և գրանցվում, որպեսզի հետագայում կարմիր սյունը ցույց տա սարքը։
Ինչ կա հաշվետվության մեջ
Մեկ էջ, որը Ձեր թիմը կարդում է 5 րոպեում՝ ինչ է փոխվել վերջին հաստատված build-ից հետո, pass, fail կամ known յուրաքանչյուր կետի համար, KPI-ների diff-ը նախորդ build-ի և baseline-ի նկատմամբ, տրենդը։ Դրա հետևում՝ գեներատորի վիճակագրությունը, սարքի հաշվիչները առաջ և հետո, յուրաքանչյուր ձախողված կետի capture-ը, կոնսոլի լոգը։ Սկրիպտները, կոնֆիգուրացիան, շեմերը և գործարկումների պատմությունը փոխանցվում են Ձեր ռեպոզիտորիա փաստաթղթերով, ուստի հավաքածուն աշխատում է նաև Ձեր լաբորատորիայում։ Առաջին հավաքածուն պահանջում է 3 շաբաթից՝ սկսած ձեռքով գործարկումից, որը տալիս է թեստի պլանը և baseline-ը։
Որտեղից սկսել
Ուղարկեք մեզ այն ցուցակը, որը գործարկում եք թողարկումից առաջ, սարքի մոդելը և թե ինչպես է Ձեր pipeline-ը գործարկում job-երը։ Մենք պատասխանում ենք թեստի պլանի նախագծով՝ կետերը, ստենդի սխեման և ժամկետները։ Սկրիպտները և հաշվետվությունը մնում են Ձեզ, և Դուք կարող եք այն ցույց տալ վենդորին։ Գրեք մեզ կամ տեսեք, թե էլ ինչ է անում ստենդը։