Մի պատմություն, որն ազդեց ամեն ինչի վրա

Իրականության թշնամիներ 12f-2-ով

Ապրիլի վերջին, երբ White Walkers-ը պաշարում էր Վինթերֆելը, մեզ հետ ավելի հետաքրքիր բան պատահեց. մենք անսովոր տարածում արեցինք: Սկզբունքորեն, մենք անընդհատ նոր հնարավորություններ ենք ներդնում արտադրության մեջ (ինչպես բոլորը): Բայց այս մեկն ուրիշ էր. Դրա մասշտաբներն այնպիսին էին, որ ցանկացած հնարավոր սխալ, որ մենք կարող էինք թույլ տալ, կազդեր մեր բոլոր ծառայությունների և օգտատերերի վրա: Արդյունքում, մենք ամեն ինչ դուրս բերեցինք ըստ պլանի, պլանավորված և հայտարարված պարապուրդի ժամանակահատվածում, առանց վաճառքի հետևանքների: Հոդվածն այն մասին է, թե ինչպես մենք հասանք դրան և ինչպես կարող է յուրաքանչյուրը կրկնել դա տանը:

Ես հիմա չեմ նկարագրի մեր կայացրած ճարտարապետական ​​և տեխնիկական որոշումները կամ չեմ պատմի, թե ինչպես է այդ ամենը աշխատում: Սրանք ավելի շուտ լուսանցքներում գտնվող նշումներ են այն մասին, թե ինչպես է տեղի ունեցել ամենադժվար թողարկումներից մեկը, որը ես դիտել եմ և որին ես ուղղակիորեն ներգրավված եմ եղել: Ես չեմ պնդում ամբողջականության կամ տեխնիկական մանրամասների մասին, գուցե դրանք հայտնվեն մեկ այլ հոդվածում։

Նախապատմություն + ինչ ֆունկցիոնալություն է սա:

Մենք կառուցում ենք ամպային հարթակ Mail.ru Cloud Solutions (MCS), որտեղ աշխատում եմ որպես տեխնիկական տնօրեն։ Եվ հիմա ժամանակն է ավելացնել IAM-ը (Identity and Access Management) մեր հարթակում, որն ապահովում է բոլոր օգտատերերի հաշիվների, օգտատերերի, գաղտնաբառերի, դերերի, ծառայությունների և այլնի միասնական կառավարում: Ինչու է դա անհրաժեշտ ամպում, ակնհայտ հարց է. օգտատիրոջ ամբողջ տեղեկատվությունը պահվում է դրանում:

Սովորաբար նման բաները սկսում են կառուցվել ցանկացած նախագծի հենց սկզբից։ Բայց պատմականորեն ամեն ինչ մի փոքր այլ է եղել MCS-ում: MCS-ը կառուցվել է երկու մասից.

• Openstack իր սեփական Keystone-ի թույլտվության մոդուլով,
• Hotbox (S3 պահեստավորում)՝ հիմնված Mail.ru Cloud նախագծի վրա,

որի շուրջ հետո հայտնվեցին նոր ծառայություններ։

Ըստ էության, դրանք երկու տարբեր տեսակի թույլտվություններ էին: Բացի այդ, մենք օգտագործեցինք Mail.ru-ի որոշ առանձին մշակումներ, օրինակ՝ Mail.ru-ի ընդհանուր գաղտնաբառի պահեստավորում, ինչպես նաև ինքնուրույն գրված openid միակցիչ, որի շնորհիվ SSO (վերջից մինչև վերջ թույլտվություն) տրամադրվեց Horizon վահանակում: վիրտուալ մեքենաների (բնական OpenStack UI):

Մեզ համար IAM-ի ստեղծումը նշանակում էր այդ ամենը միացնել մեկ միասնական համակարգի՝ ամբողջովին մերը: Միևնույն ժամանակ, մենք ճանապարհին չենք կորցնի որևէ ֆունկցիոնալություն, այլ հիմք կստեղծենք ապագայի համար, որը թույլ կտա թափանցիկորեն կատարելագործել այն՝ առանց վերամշակելու և մասշտաբավորել այն ֆունկցիոնալ առումով: Նաև սկզբում օգտատերերն ունեին ծառայություններից օգտվելու դերային մոդել (կենտրոնական RBAC, դերի վրա հիմնված մուտքի վերահսկում) և որոշ այլ մանրուքներ:

Առաջադրանքը ոչ տրիվիալ էր՝ python և perl, մի քանի backend, ինքնուրույն գրված ծառայություններ, մի քանի մշակող թիմեր և ադմիններ։ Եվ ամենակարևորը, մարտական ​​արտադրության համակարգում կան հազարավոր կենդանի օգտատերեր: Այս ամենը պետք է գրվեր և, որ ամենակարևորը, գլորվեր առանց զոհերի։

Ի՞նչ ենք պատրաստվում դուրս բերել:

Շատ կոպիտ ասած՝ մոտ 4 ամսում պատրաստեցինք հետեւյալը.

• Մենք ստեղծեցինք մի քանի նոր դևոններ, որոնք միավորում էին գործառույթները, որոնք նախկինում աշխատում էին ենթակառուցվածքի տարբեր մասերում: Մնացած ծառայություններին նշանակվել է նոր հետին պլան՝ այս դևերի տեսքով:
• Մենք գրել ենք գաղտնաբառերի և բանալիների մեր սեփական կենտրոնական պահեստը, որը հասանելի է մեր բոլոր ծառայությունների համար, որոնք կարող են ազատորեն փոփոխվել ըստ անհրաժեշտության:
• Մենք զրոյից գրել ենք Keystone-ի 4 նոր հետին պլաններ (օգտատերեր, նախագծեր, դերեր, դերերի նշանակումներ), որոնք, ըստ էության, փոխարինեցին նրա տվյալների բազան և այժմ գործում են որպես մեր օգտվողի գաղտնաբառերի մեկ պահեստ:
• Մենք սովորեցրել ենք մեր Openstack-ի բոլոր ծառայություններին գնալ երրորդ կողմի քաղաքականության ծառայության՝ իրենց քաղաքականության համար՝ փոխարենը յուրաքանչյուր սերվերից այս քաղաքականությունը տեղական կարդալու փոխարեն (այո, այսպես է աշխատում Openstack-ը լռելյայն):

Նման հիմնական վերամշակումը պահանջում է մեծ, բարդ և, ամենակարևորը, համաժամանակյա փոփոխություններ մի քանի համակարգերում, որոնք գրված են զարգացման տարբեր թիմերի կողմից: Հավաքվելուց հետո ամբողջ համակարգը պետք է աշխատի:

Ինչպե՞ս գլորել նման փոփոխությունները և չխաթարել դրանք: Նախ որոշեցինք մի փոքր նայել ապագային:

Տարածման ռազմավարություն

• Հնարավոր կլինի արտադրանքը մի քանի փուլով դուրս բերել, բայց դա երեք անգամ կավելացնի մշակման ժամանակը: Բացի այդ, որոշ ժամանակ մենք կունենայինք տվյալների բազաների ամբողջական ապասինխրոնիզացիա։ Դուք ստիպված կլինեք գրել ձեր սեփական համաժամացման գործիքները և երկար ժամանակ ապրել բազմաթիվ տվյալների պահեստներով: Եվ դա ստեղծում է ռիսկերի լայն տեսականի:
• Այն ամենը, ինչ կարելի էր թափանցիկ պատրաստել օգտատիրոջ համար, արվել է նախապես։ Այն տեւեց 2 ամիս։
• Մենք մեզ թույլ տվեցինք մի քանի ժամով անգործություն՝ միայն օգտագործողի գործողությունների համար՝ ռեսուրսներ ստեղծելու և փոխելու համար:
• Արդեն ստեղծված բոլոր ռեսուրսների շահագործման համար անընդունելի էր պարապուրդը։ Մենք նախատեսում էինք, որ թողարկման ընթացքում ռեսուրսները պետք է աշխատեն առանց ժամանակի և ազդեն հաճախորդների վրա:
• Մեր հաճախորդների վրա ազդեցությունը նվազեցնելու համար, եթե ինչ-որ բան այնպես չընթանա, մենք որոշեցինք գործարկել կիրակի երեկոյան: Ավելի քիչ հաճախորդներ են կառավարում վիրտուալ մեքենաները գիշերը:
• Մենք զգուշացրել ենք մեր բոլոր հաճախորդներին, որ տեղադրման համար ընտրված ժամանակահատվածում ծառայության կառավարումն անհասանելի կլինի:

Դիգրեսիա. ինչ է rollout-ը:

<զգուշություն, փիլիսոփայություն>

Յուրաքանչյուր ՏՏ մասնագետ կարող է հեշտությամբ պատասխանել, թե ինչ է rollout-ը: Դուք տեղադրում եք CI/CD, և ամեն ինչ ավտոմատ կերպով առաքվում է խանութ։ 🙂

Իհարկե սա ճիշտ է։ Բայց դժվարությունն այն է, որ կոդերի փոխանցման ավտոմատացման ժամանակակից գործիքների դեպքում ինքնին շրջանառության մասին հասկացողությունը կորչում է: Ինչպես եք մոռանում անիվի գյուտի էպիկականության մասին, երբ նայում եք ժամանակակից տրանսպորտին: Ամեն ինչ այնքան ավտոմատացված է, որ տեղադրումը հաճախ իրականացվում է առանց ամբողջական պատկերը հասկանալու:

Իսկ ամբողջ պատկերն այսպիսին է. Տարածումը բաղկացած է չորս հիմնական ասպեկտներից.

1. Կոդի առաքում, ներառյալ տվյալների փոփոխումը: Օրինակ՝ նրանց միգրացիաները։
2. Կոդի վերադարձը հետ գնալու ունակություն է, եթե ինչ-որ բան սխալ է: Օրինակ՝ կրկնօրինակների ստեղծման միջոցով։
3. Յուրաքանչյուր գործարկման/վերադարձի գործողության ժամանակը: Դուք պետք է հասկանաք առաջին երկու կետերի ցանկացած գործողության ժամկետը:
4. Ազդեցված ֆունկցիոնալությունը: Պետք է գնահատել ինչպես սպասվող դրական, այնպես էլ հնարավոր բացասական ազդեցությունները։

Այս բոլոր ասպեկտները պետք է հաշվի առնվեն հաջող ներդրման համար: Սովորաբար գնահատվում է միայն առաջին, կամ լավագույն դեպքում երկրորդ կետը, այնուհետև թողարկումը համարվում է հաջողված: Բայց երրորդն ու չորրորդն ավելի կարևոր են։ Ո՞ր օգտվողին կցանկանար, որ թողարկումը մեկ րոպեի փոխարեն տևեր 3 ժամ: Կամ եթե ինչ-որ ավելորդ բան ազդի թողարկման ընթացքում: Թե՞ մեկ ծառայության պարապուրդը կհանգեցնի անկանխատեսելի հետեւանքների։

Գործողություն 1..n, ազատման նախապատրաստում

Սկզբում մտածեցի համառոտ նկարագրել մեր հանդիպումները. ամբողջ թիմը, նրա մասերը, սուրճի կետերում քննարկումների կույտ, վեճեր, թեստեր, ուղեղային փոթորիկներ: Հետո մտածեցի, որ դա ավելորդ կլինի։ Չորս ամիսների զարգացումը միշտ բաղկացած է դրանից, հատկապես, երբ դուք գրում եք ոչ թե մի բան, որը կարելի է անընդհատ մատուցել, այլ մեկ մեծ հատկանիշ կենդանի համակարգի համար: Ինչն ազդում է բոլոր ծառայությունների վրա, բայց օգտատերերի համար ոչինչ չպետք է փոխվի, բացի «վեբ ինտերֆեյսի մեկ կոճակից»:

Մեր պատկերացումն այն մասին, թե ինչպես կարելի է դուրս գալ, փոխվեց յուրաքանչյուր նոր հանդիպումից և բավականին զգալիորեն: Օրինակ, մենք պատրաստվում էինք թարմացնել մեր ամբողջ բիլինգի բազան: Բայց մենք հաշվարկեցինք ժամանակը և հասկացանք, որ հնարավոր չէ դա անել ողջամիտ ժամկետում: Մեզ մոտ մեկ լրացուցիչ շաբաթ պահանջվեց բիլինգի տվյալների բազան բեկորելու և արխիվացնելու համար: Եվ երբ տեղակայման ակնկալվող արագությունը դեռ գոհացուցիչ չէր, մենք պատվիրեցինք լրացուցիչ, ավելի հզոր սարքավորում, որտեղ ամբողջ բազան քաշվեց: Այնպես չէ, որ մենք չէինք ուզում դա անել ավելի շուտ, բայց դուրս գալու ներկայիս անհրաժեշտությունը մեզ այլընտրանքներ չթողեց:

Երբ մեզանից մեկը կասկածներ ուներ, որ թողարկումը կարող է ազդել մեր վիրտուալ մեքենաների հասանելիության վրա, մենք մեկ շաբաթ անցկացրեցինք թեստեր, փորձեր, կոդերի վերլուծություն և հստակ հասկացանք, որ դա տեղի չի ունենա մեր արտադրության մեջ, և նույնիսկ ամենավստահելի մարդիկ համաձայնվեցին։ սրա հետ.

Միևնույն ժամանակ, տեխնիկական աջակցության տղաները կատարեցին իրենց անկախ փորձերը, որպեսզի հաճախորդների համար գրեն հրահանգներ միացման մեթոդների վերաբերյալ, որոնք պետք է փոխվեին թողարկումից հետո: Նրանք աշխատել են օգտվողների UX-ի վրա, պատրաստել հրահանգներ և տրամադրել անձնական խորհրդատվություն:

Մենք ավտոմատացրել ենք բոլոր հնարավոր գործառնությունները: Յուրաքանչյուր վիրահատություն գրված էր, նույնիսկ ամենապարզը, և անընդհատ թեստեր էին անցկացվում: Նրանք վիճեցին ծառայությունն անջատելու լավագույն միջոցի մասին՝ բաց թողնել դեյմոնը կամ արգելափակել մուտքը դեպի ծառայություն firewall-ով: Մենք ստեղծեցինք թիմերի ստուգացանկ յուրաքանչյուր փուլի համար և անընդհատ թարմացրինք այն: Մենք գծեցինք և անընդհատ թարմացրինք Gantt աղյուսակը բոլոր ներդրման աշխատանքների համար՝ ժամանակացույցերով:

Եւ այսպես…

Վերջնական ակտը, նախքան գլորումը

...ժամանակն է դուրս գալ:

Ինչպես ասում են՝ արվեստի գործը չի կարելի ավարտին հասցնել, միայն ավարտել դրա վրա աշխատելը։ Դուք պետք է կամքի ջանք գործադրեք՝ հասկանալով, որ ամեն ինչ չեք գտնի, բայց հավատալով, որ արել եք բոլոր ողջամիտ ենթադրությունները՝ նախատեսված բոլոր հնարավոր դեպքերի համար, փակել եք բոլոր կարևոր վրիպակները, և բոլոր մասնակիցներն արել են այն ամենը, ինչ կարող էին: Որքան շատ կոդ գլորես, այնքան ավելի դժվար է քեզ համոզել դրանում (բացի այդ, բոլորն էլ հասկանում են, որ հնարավոր չէ ամեն ինչ կանխատեսել):

Մենք որոշեցինք, որ պատրաստ ենք դուրս գալ, երբ համոզված եղանք, որ արել ենք հնարավոր ամեն բան՝ ծածկելու մեր օգտատերերի համար անսպասելի ազդեցությունների և խափանումների հետ կապված բոլոր ռիսկերը: Այսինքն, ամեն ինչ կարող է սխալ լինել, բացառությամբ.

1. Ազդել (մեզ համար սուրբ, ամենաթանկ) օգտագործողի ենթակառուցվածքը,
2. Ֆունկցիոնալությունը. մեր ծառայության օգտագործումը թողարկումից հետո պետք է լինի նույնը, ինչ նախկինում:

Գլորում դուրս

Երկու գլորում, 8-ը մի խանգարեք

Մենք օգտատերերի բոլոր հարցումների համար 7 ժամով ժամանակ ենք վերցնում: Այս պահին մենք ունենք և՛ ներդրման պլան, և՛ հետադարձ պլան:

• Ինքնին տեղադրումը տևում է մոտավորապես 3 ժամ:
• 2 ժամ թեստավորման համար։
• 2 ժամ՝ վերապահում փոփոխությունների հնարավոր հետդարձի համար:

Յուրաքանչյուր գործողության համար կազմվել է Gantt աղյուսակ, թե որքան ժամանակ է պահանջվում, ինչ է կատարվում հաջորդաբար, ինչ է կատարվում զուգահեռ:

Գանտի աղյուսակի մի կտոր, վաղ տարբերակներից մեկը (առանց զուգահեռ կատարման): Համաժամացման ամենաարժեքավոր գործիքը

Բոլոր մասնակիցներին որոշվում է ներդրման մեջ իրենց դերը, ինչ առաջադրանքներ են նրանք անում և ինչի համար են պատասխանատու: Մենք փորձում ենք յուրաքանչյուր փուլ հասցնել ավտոմատացման, գլորել այն, հետ գլորել այն, հավաքել արձագանքներ և նորից դուրս բերել:

Իրադարձությունների քրոնիկոն

Այսպիսով, կիրակի օրը՝ ապրիլի 15-ին, ժամը 29-ին 10 հոգի աշխատանքի է եկել։ Բացի հիմնական մասնակիցներից, ոմանք եկել էին պարզապես թիմին աջակցելու, ինչի համար հատուկ շնորհակալություն եմ հայտնում նրանց։

Հարկ է նաև նշել, որ մեր բանալիների փորձարկիչը արձակուրդում է։ Անհնար է դուրս գալ առանց փորձարկման, մենք ուսումնասիրում ենք տարբերակներ: Գործընկերներից մեկը համաձայնվում է փորձարկել մեզ արձակուրդից, ինչի համար նա արժանանում է մեծ երախտագիտության ողջ թիմից:

00:00. Դադարեցրեք
Մենք դադարեցնում ենք օգտատերերի հարցումները, կախում ենք տեխնիկական աշխատանք գրությամբ ցուցանակ: Մոնիտորինգը գոռում է, բայց ամեն ինչ նորմալ է։ Մենք ստուգում ենք, որ ոչինչ չի ընկել, բացի այն, ինչ պետք է ընկներ։ Եվ մենք սկսում ենք աշխատանքը միգրացիայի ուղղությամբ:

Յուրաքանչյուր ոք ունի տպագիր տեղադրման պլան կետ առ կետ, բոլորը գիտեն, թե ով ինչ է անում և որ պահին: Յուրաքանչյուր գործողությունից հետո մենք ստուգում ենք ժամկետները, որպեսզի համոզվենք, որ դրանք չենք գերազանցում, և ամեն ինչ ընթանում է ըստ պլանի: Նրանք, ովքեր ներկա փուլում ուղղակիորեն չեն մասնակցում ծրագրին, պատրաստվում են գործարկել առցանց խաղալիք (Xonotic, տիպ 3 quacks), որպեսզի չանհանգստացնեն իրենց գործընկերներին: 🙂

02:00. Շրջվել է
Հաճելի անակնկալ. մենք ավարտում ենք թողարկումը մեկ ժամ շուտ՝ շնորհիվ մեր տվյալների բազաների և միգրացիոն սկրիպտների օպտիմալացման: Ընդհանուր բղավեց, «գլորվեց»: Բոլոր նոր գործառույթները արտադրվում են, բայց առայժմ միայն մենք կարող ենք դրանք տեսնել ինտերֆեյսում: Բոլորը անցնում են թեստավորման ռեժիմի, նրանց դասավորում են խմբերի և սկսում են տեսնել, թե ինչ է տեղի ունեցել վերջում:

Դա այնքան էլ լավ չստացվեց, մենք դա հասկանում ենք 10 րոպե հետո, երբ ոչինչ միացված չէ կամ աշխատում է թիմի անդամների նախագծերում: Արագ համաժամեցում, մենք բարձրաձայնում ենք մեր խնդիրները, սահմանում ենք առաջնահերթությունները, բաժանվում ենք թիմերի և անցնում վրիպազերծման:

02:30. Երկու մեծ խնդիր ընդդեմ չորս աչքերի
Մենք երկու մեծ խնդիր ենք գտնում. Մենք հասկացանք, որ հաճախորդները չեն տեսնի միացված որոշ ծառայություններ, և խնդիրներ կառաջանան գործընկերների հաշիվների հետ: Երկուսն էլ պայմանավորված են որոշ եզրային դեպքերի միգրացիոն սկրիպտների անկատարությամբ: Մենք պետք է շտկենք այն հիմա:

Մենք գրում ենք հարցումներ, որոնք արձանագրում են սա, առնվազն 4 աչքով: Մենք փորձարկում ենք դրանք նախնական արտադրության ժամանակ՝ համոզվելու համար, որ նրանք աշխատում են և ոչինչ չեն կոտրում: Դուք կարող եք գլորվել հետագա: Միևնույն ժամանակ, մենք իրականացնում ենք մեր կանոնավոր ինտեգրման թեստավորումը, որը բացահայտում է ևս մի քանի խնդիր: Դրանք բոլորը փոքր են, բայց նաև վերանորոգման կարիք ունեն։

03:00. -2 խնդիր +2 խնդիր
Նախկին երկու մեծ խնդիրները շտկվել են, և գրեթե բոլոր մանրերը նույնպես։ Բոլոր նրանք, ովքեր չզբաղված են շտկումներով, ակտիվորեն աշխատում են իրենց հաշիվներում և հայտնում, թե ինչ են գտնում: Մենք առաջնահերթություն ենք տալիս, բաժանում ենք թիմերի միջև և թողնում առավոտվա համար ոչ կարևոր իրերը:

Մենք նորից անցկացնում ենք թեստերը, նրանք հայտնաբերում են երկու նոր մեծ խնդիր։ Սպասարկման բոլոր քաղաքականությունները ճիշտ չեն ստացվել, ուստի որոշ օգտվողների հարցումներ չեն անցնում թույլտվություն: Գումարած նոր խնդիր գործընկերների հաշիվների հետ: Եկեք շտապենք նայելու:

03:20. Արտակարգ իրավիճակների համաժամացում
Մեկ նոր խնդիր ուղղվեց։ Երկրորդի համար մենք կազմակերպում ենք արտակարգ համաժամացում։ Մենք հասկանում ենք, թե ինչ է կատարվում. նախորդ ուղղումը շտկեց մի խնդիր, բայց ստեղծեց մեկ այլ խնդիր: Մենք ընդմիջում ենք անում՝ պարզելու, թե ինչպես դա անել ճիշտ և առանց հետևանքների։

03:30. Վեց աչք
Մենք հասկանում ենք, թե ինչպիսին պետք է լինի բազայի վերջնական վիճակը, որպեսզի ամեն ինչ լավ լինի բոլոր գործընկերների համար: Մենք հարցում ենք գրում 6 աչքով, գլորում ենք նախաարտադրության մեջ, փորձարկում ենք, գլորում ենք արտադրության համար։

04:00. Ամեն ինչ աշխատում է
Բոլոր թեստերն անցել են, ոչ մի կրիտիկական խնդիր տեսանելի չէ։ Ժամանակ առ ժամանակ թիմում ինչ-որ բան ինչ-որ մեկի մոտ չի ստացվում, մենք արագ արձագանքում ենք: Ամենից հաճախ ահազանգը կեղծ է: Բայց երբեմն ինչ-որ բան չի հասնում, կամ առանձին էջ չի աշխատում: Նստում ենք, շտկում, շտկում, շտկում։ Առանձին թիմը գործարկում է վերջին մեծ հնարավորությունը՝ վճարումը:

04:30. Անվերադարձ կետ
Մոտենում է անվերադարձ կետը, այսինքն՝ այն ժամանակը, երբ, եթե սկսենք հետ գլորվել, չենք դիմավորելու մեզ տրված պարապուրդը։ Բիլինգի հետ կապված խնդիրներ կան, որոնք ամեն ինչ գիտեն և գրանցում են, բայց համառորեն հրաժարվում են գումար դուրս գրել հաճախորդներից։ Առանձին էջերում, գործողություններում և կարգավիճակներում կան մի քանի վրիպակներ: Հիմնական ֆունկցիոնալությունն աշխատում է, բոլոր թեստերը հաջողությամբ են անցնում։ Մենք որոշում ենք, որ տեղակայումը տեղի է ունեցել, մենք հետ չենք գլորվելու։

06:00. Բաց է բոլորի համար UI-ում
Սխալները ուղղվեցին: Որոշները, որոնք չեն գրավում օգտատերերին, թողնված են ավելի ուշ: Մենք բացում ենք ինտերֆեյսը բոլորի համար: Մենք շարունակում ենք աշխատել վճարումների վրա՝ սպասելով օգտատերերի արձագանքներին և մոնիտորինգի արդյունքներին:

07:00. API-ի բեռնվածության հետ կապված խնդիրներ
Պարզ է դառնում, որ մենք փոքր-ինչ սխալ պլանավորել ենք մեր API-ի բեռնվածությունը և փորձարկել ենք այս բեռը, որը չի կարողացել բացահայտել խնդիրը: Արդյունքում հարցումների ≈5%-ը ձախողվում է։ Մոբիլիզացվենք ու փնտրենք պատճառը։

Billing-ը համառ է և նույնպես չի ցանկանում աշխատել: Որոշում ենք հետաձգել ավելի ուշ՝ փոփոխությունները հանգիստ իրականացնելու համար։ Այսինքն՝ դրա մեջ կուտակված են բոլոր ռեսուրսները, բայց հաճախորդներից դուրսգրումները չեն անցնում։ Իհարկե, սա խնդիր է, բայց ընդհանուր տարածման համեմատությամբ դա անկարևոր է թվում:

08:00. Ուղղել API-ն
Մենք բեռի համար ամրացրինք, խափանումներն անցան: Մենք սկսում ենք տուն գնալ:

10:00. Բոլորը
Ամեն ինչ ֆիքսված է։ Հանգիստ է մոնիտորինգում, և հաճախորդների մոտ թիմն աստիճանաբար գնում է քնելու: Բիլլինգը մնում է, վաղը կվերականգնենք։

Այնուհետև օրվա ընթացքում եղան հրապարակումներ, որոնք ամրագրեցին տեղեկամատյանները, ծանուցումները, վերադարձի կոդերը և հարմարեցումները մեր որոշ հաճախորդների համար:

Այսպիսով, թողարկումը հաջող էր: Դա, իհարկե, կարող էր ավելի լավ լինել, բայց մենք եզրակացություններ արեցինք այն մասին, թե ինչը մեզ բավարար չէր կատարելության հասնելու համար։

Ընդհանուր

Ծրագրին 2 ամսվա ակտիվ նախապատրաստման ընթացքում կատարվել է 43 առաջադրանք՝ մի քանի ժամից մինչև մի քանի օր տևողությամբ:

Տեղադրման ընթացքում.

• նոր և փոխված դևեր - 5 հատ, փոխարինելով 2 մոնոլիտ;
• Տվյալների շտեմարաններում փոփոխություններ. օգտատերերի տվյալների հետ մեր բոլոր 6 տվյալների բազաները տուժել են, ներբեռնումներ են կատարվել երեք հին տվյալների բազաներից մեկ նորի վրա;
• ամբողջովին վերափոխված ճակատ;
• ներբեռնված կոդի քանակը՝ 33 հազար տող նոր ծածկագիր, ≈ 3 հազար տող կոդ թեստերում, ≈ 5 հազար տող միգրացիոն կոդ;
• բոլոր տվյալները անձեռնմխելի են, ոչ մի հաճախորդի վիրտուալ մեքենա չի վնասվել: 🙂

Լավ պրակտիկա լավ ներդրման համար

Նրանք մեզ առաջնորդեցին այս դժվարին իրավիճակում։ Բայց, ընդհանուր առմամբ, օգտակար է դրանց հետևել ցանկացած թողարկման ժամանակ: Բայց որքան բարդ է շրջանառությունը, այնքան ավելի մեծ դեր են խաղում դրանք:

1. Առաջին բանը, որ դուք պետք է անեք, հասկանալն է, թե ինչպես է թողարկումը կարող է ազդել կամ կազդի օգտատերերի վրա: Կլինի՞ պարապուրդ: Եթե ​​այո, ապա ո՞րն է պարապուրդը: Ինչպե՞ս դա կանդրադառնա օգտատերերի վրա: Որո՞նք են հնարավոր լավագույն և վատագույն սցենարները: Եվ ծածկեք ռիսկերը:
2. Պլանավորեք ամեն ինչ. Յուրաքանչյուր փուլում դուք պետք է հասկանաք ներդրման բոլոր ասպեկտները.
   • կոդի առաքում;
   • կոդի վերադարձ;
   • յուրաքանչյուր գործողության ժամանակը;
   • ազդել ֆունկցիոնալությունը.
3. Խաղացեք սցենարների միջով, մինչև հայտնագործման բոլոր փուլերը, ինչպես նաև դրանցից յուրաքանչյուրի ռիսկերը ակնհայտ դառնան: Եթե ​​կասկածներ ունեք, կարող եք ընդմիջել և առանձին քննել կասկածելի փուլը։
4. Յուրաքանչյուր փուլ կարող է և պետք է բարելավվի, եթե այն օգնի մեր օգտատերերին: Օրինակ, դա կնվազեցնի պարապուրդի ժամանակը կամ կվերացնի որոշ ռիսկեր:
5. Հետադարձ փորձարկումը շատ ավելի կարևոր է, քան կոդերի առաքման փորձարկումը: Պետք է ստուգել, ​​որ ետ վերադարձի արդյունքում համակարգը կվերադառնա իր սկզբնական վիճակին, և դա հաստատեք թեստերով։
6. Այն ամենը, ինչ հնարավոր է ավտոմատացնել, պետք է ավտոմատացված լինի: Այն ամենը, ինչ հնարավոր չէ ավտոմատացնել, պետք է նախապես գրվի խաբեության թերթիկի վրա:
7. Գրանցեք հաջողության չափանիշը. Ի՞նչ գործառույթ պետք է հասանելի լինի և որ ժամին: Եթե ​​դա տեղի չունենա, գործարկեք հետադարձ պլան:
8. Եվ ամենակարեւորը՝ մարդիկ։ Յուրաքանչյուր ոք պետք է տեղյակ լինի, թե ինչ է անում, ինչու և ինչ է կախված իր գործողություններից:

Եվ մեկ նախադասությամբ, լավ պլանավորման և մշակման դեպքում դուք կարող եք դուրս բերել այն ամենը, ինչ ցանկանում եք, առանց վաճառքի հետևանքների: Նույնիսկ մի բան, որը կազդի արտադրության մեջ ձեր բոլոր ծառայությունների վրա:

Source: www.habr.com