HighLoad++, Եվգենի Կուզովլև (EcommPay IT).

Բոլորը խոսում են մշակման և թեստավորման գործընթացների, անձնակազմի վերապատրաստման, մոտիվացիայի բարձրացման մասին, բայց այդ գործընթացները բավարար չեն, երբ ծառայության մեկ րոպեի պարապուրդը հսկայական գումարներ է արժենում: Ի՞նչ անել, երբ ֆինանսական գործարքներ եք իրականացնում խիստ SLA-ի ներքո: Ինչպե՞ս բարձրացնել ձեր համակարգերի հուսալիությունը և սխալների հանդուրժողականությունը՝ հանելով մշակումն ու փորձարկումը հավասարումից:

Հաջորդ HighLoad++ համաժողովը կանցկացվի 6 թվականի ապրիլի 7-ին և 2020-ին Սանկտ Պետերբուրգում։ Մանրամասներ և տոմսեր ՈՒղեցույց. նոյեմբերի 9-ին, ժամը 18:00-ին։ HighLoad++ Մոսկվա 2018, Դելի + Կալկաթա դահլիճ. Թեզեր և ներկայացում.

Եվգենի Կուզովլև (այսուհետ՝ ԵՀ). - Ընկերներ, բարև: Ես Կուզովլև Եվգենի եմ: Ես EcommPay ընկերությունից եմ, կոնկրետ բաժինը EcommPay IT-ն է՝ ընկերությունների խմբի ՏՏ բաժինը։ Եվ այսօր մենք կխոսենք պարապուրդների մասին՝ այն մասին, թե ինչպես խուսափել դրանցից, ինչպես նվազագույնի հասցնել դրանց հետևանքները, եթե դա հնարավոր չէ խուսափել: Թեման հետևյալն է. «Ի՞նչ անել, երբ պարապուրդի մեկ րոպեն արժե $100»: Առաջ նայելով՝ մեր թվերը համեմատելի են։

Ի՞նչ է անում EcommPay ՏՏ-ն:

Ո՞վ ենք մենք։ Ինչո՞ւ եմ ես կանգնած այստեղ քո առջև։ Ինչու՞ ես իրավունք ունեմ ձեզ ինչ-որ բան ասել այստեղ: Իսկ ինչի՞ մասին ենք այստեղ ավելի մանրամասն խոսելու։

EcommPay ընկերությունների խումբը միջազգային գնորդ է: Մենք մշակում ենք վճարումներ ամբողջ աշխարհում՝ Ռուսաստանում, Եվրոպայում, Հարավարևելյան Ասիայում (Ամբողջ աշխարհում): Մենք ունենք 9 գրասենյակ, ընդհանուր առմամբ 500 աշխատակից, որոնց կեսից մոտավորապես ՏՏ մասնագետներ են։ Այն ամենը, ինչ անում ենք, այն ամենը, ինչից գումար ենք աշխատում, մենք ինքներս ենք արել:

Մենք ինքներս ենք գրել մեր բոլոր ապրանքները (և դրանցից բավականին շատ ենք. մեծ ՏՏ արտադրանքների մեր շարքում մենք ունենք մոտ 16 տարբեր բաղադրիչ): Մենք ինքներս ենք գրում, ինքներս մեզ զարգացնում։ Եվ այս պահին մենք օրական մոտ մեկ միլիոն գործարք ենք իրականացնում (միլիոնները երևի ճիշտ ասելու ձևն է)։ Մենք բավականին երիտասարդ ընկերություն ենք. մենք ընդամենը մոտ վեց տարեկան ենք:

6 տարի առաջ նման ստարտափ էր, երբ տղաները եկան բիզնեսի հետ միասին: Նրանց միավորել էր մի գաղափար (մի գաղափարից բացի ուրիշ բան չկար), մենք վազեցինք։ Ինչպես ցանկացած ստարտափ, մենք էլ ավելի արագ էինք վազում... Մեզ համար արագությունն ավելի կարևոր էր, քան որակը։

Ինչ-որ պահի մենք կանգ առանք. հասկացանք, որ այլևս չենք կարող ինչ-որ կերպ ապրել այդ արագությամբ և որակով, և պետք է նախ կենտրոնանալ որակի վրա: Այս պահին մենք որոշեցինք գրել նոր հարթակ, որը կլինի ճիշտ, մասշտաբային և հուսալի։ Նրանք սկսեցին գրել այս հարթակը (սկսեցին ներդրումներ կատարել, զարգացնել զարգացումը, թեստավորումը), բայց ինչ-որ պահի հասկացան, որ մշակումն ու թեստավորումը թույլ չեն տալիս հասնել ծառայության որակի նոր մակարդակի։

Դուք նոր ապրանք եք պատրաստում, այն դնում եք արտադրության մեջ, բայց այնուամենայնիվ ինչ-որ տեղ ինչ-որ բան սխալ կլինի։ Եվ այսօր մենք կխոսենք այն մասին, թե ինչպես հասնել որակի նոր մակարդակի (ինչպես մենք դա արեցինք, մեր փորձի մասին), զարգացումն ու փորձարկումը դուրս բերելով հավասարումից; մենք կխոսենք այն մասին, թե ինչն է հասանելի շահագործման համար. ինչ գործողություն կարող է անել ինքն իրեն, ինչ կարող է առաջարկել թեստավորմանը՝ որակի վրա ազդելու համար:

Անգործության ժամանակներ. Գործողության հրահանգներ.

Միշտ հիմնական անկյունաքարը, ինչի մասին մենք իրականում կխոսենք այսօր, դա պարապուրդն է: Սարսափելի խոսք. Եթե ​​մենք ունենք պարապուրդ, մեզ համար ամեն ինչ վատ է: Մենք վազում ենք բարձրացնելու, ադմինները պահում են սերվերը - Աստված մի արասցե չընկնի, ինչպես ասում են այդ երգում։ Ահա թե ինչի մասին կխոսենք այսօր։

Երբ մենք սկսեցինք փոխել մեր մոտեցումները, մենք կազմեցինք 4 պատվիրաններ. Ես դրանք ներկայացնում եմ սլայդներում.

Այս պատվիրանները բավականին պարզ են.

• Արագ բացահայտեք խնդիրը:
• Ազատվեք դրանից էլ ավելի արագ։
• Օգնեք հասկանալ պատճառը (ավելի ուշ՝ մշակողների համար):
• Եվ ստանդարտացնել մոտեցումները:

Ուզում եմ ձեր ուշադրությունը հրավիրել թիվ 2 կետի վրա, մենք խնդրից ազատվում ենք, ոչ թե լուծում։ Որոշում կայացնելը երկրորդական է. Մեզ համար առաջնայինն այն է, որ օգտատերը պաշտպանված է այս խնդրից։ Այն գոյություն կունենա ինչ-որ մեկուսացված միջավայրում, բայց այս միջավայրը կապ չի ունենա դրա հետ։ Փաստորեն, մենք կանցնենք խնդիրների այս չորս խմբի միջով (ոմանք՝ ավելի մանրամասն, որոշները՝ ավելի քիչ մանրամասն), ես ձեզ կասեմ, թե ինչ ենք օգտագործում, լուծումների ինչ համապատասխան փորձ ունենք։

Անսարքությունների վերացում. Ե՞րբ են դրանք տեղի ունենում և ի՞նչ անել դրանց դեմ:

Բայց մենք սկսելու ենք անսարք, սկսելու ենք թիվ 2 կետից՝ ինչպե՞ս արագ ազատվել խնդրից։ Խնդիր կա՝ պետք է շտկել։ «Ի՞նչ պետք է անենք սրա հետ կապված»: - հիմնական հարցը. Եվ երբ մենք սկսեցինք մտածել, թե ինչպես շտկել խնդիրը, մենք մեզ համար մշակեցինք որոշ պահանջներ, որոնք պետք է հետևեն անսարքությունների վերացմանը:

Այս պահանջները ձևակերպելու համար մենք որոշեցինք ինքներս մեզ հարց տալ. «Ե՞րբ ենք մենք խնդիրներ ունենում»: Իսկ խնդիրները, ինչպես պարզվեց, առաջանում են չորս դեպքում.

• Սարքավորումների ձախողում.
• Արտաքին ծառայությունները ձախողվեցին:
• Ծրագրաշարի տարբերակի փոփոխություն (նույն տեղակայումը):
• Պայթուցիկ բեռի աճ:

Մենք չենք խոսի առաջին երկուսի մասին. Սարքավորումների անսարքությունը կարող է լուծվել բավականին պարզ. դուք պետք է ամեն ինչ կրկնօրինակեք: Եթե ​​դրանք սկավառակներ են, ապա սկավառակները պետք է հավաքվեն RAID-ում, եթե սա սերվեր է, ապա սերվերը պետք է կրկնօրինակվի, եթե դուք ունեք ցանցային ենթակառուցվածք, ապա պետք է տրամադրեք ցանցային ենթակառուցվածքի երկրորդ օրինակը, այսինքն՝ վերցնեք այն և կրկնօրինակել այն: Իսկ եթե ինչ-որ բան չի ստացվում, դուք անցնում եք պահուստային էներգիայի: Դժվար է այստեղ ավելին ասել.

Երկրորդը արտաքին ծառայությունների ձախողումն է։ Շատերի համար համակարգն ընդհանրապես խնդիր չէ, բայց մեզ համար՝ ոչ։ Քանի որ մենք մշակում ենք վճարումները, մենք ագրեգատոր ենք, որը կանգնած է օգտատիրոջ (ով մուտքագրում է իր քարտի տվյալները) և բանկերի, վճարային համակարգերի (Visa, MasterCard, Mira և այլն) միջև: Մեր արտաքին ծառայությունները (վճարային համակարգեր, բանկեր) հակված են ձախողման: Ո՛չ մենք, ո՛չ դուք (եթե ունեք նման ծառայություններ) չենք կարող ազդել դրա վրա:

Ի՞նչ անել այդ դեպքում: Այստեղ երկու տարբերակ կա. Նախ, եթե կարող եք, դուք պետք է ինչ-որ կերպ կրկնօրինակեք այս ծառայությունը: Օրինակ, եթե կարող ենք, մենք թրաֆիկը փոխանցում ենք մի ծառայությունից մյուսը. օրինակ, քարտերը մշակվել են Սբերբանկի միջոցով, Սբերբանկը խնդիրներ ունի. Երկրորդ բանը, որ մենք կարող ենք անել, արտաքին ծառայությունների խափանումը շատ արագ նկատելն է, և հետևաբար հաշվետվության հաջորդ մասում կխոսենք արձագանքման արագության մասին։

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

Այս չորս խնդիրներից մի քանիսը անմիջապես լուծվում են, եթե դուք ունեք ամպ: Եթե ​​դուք գտնվում եք Microsoft Azhur-ի, Ozone clouds-ում կամ օգտագործում եք մեր ամպերը՝ Yandex-ից կամ Mail-ից, ապա գոնե ապարատային անսարքությունը դառնում է նրանց խնդիրը, և ապարատային անսարքության համատեքստում ձեզ համար անմիջապես ամեն ինչ լավ է դառնում:

Մենք մի փոքր անսովոր ընկերություն ենք: Այստեղ բոլորը խոսում են «Կուբերնեցից», ամպերի մասին. մենք ոչ «Կուբերնեց» ունենք, ոչ ամպեր։ Բայց մենք ունենք ապարատային դարակաշարեր շատ տվյալների կենտրոններում, և մենք ստիպված ենք ապրել այս սարքաշարի վրա, մենք ստիպված ենք պատասխանատու լինել այդ ամենի համար: Ուստի այս համատեքստում կխոսենք։ Այսպիսով, խնդիրների մասին. Առաջին երկուսը հանվել են փակագծերից։

Ծրագրաշարի տարբերակի փոփոխություն: Հիմքեր

Մեր ծրագրավորողները արտադրության հասանելիություն չունեն: Ինչո՞ւ է այդպես։ Պարզապես մենք PCI DSS հավաստագրված ենք, և մեր մշակողները պարզապես իրավունք չունեն մտնել «արտադրանք»: Վերջ, վերջ։ Ընդհանրապես. Հետևաբար, զարգացման պատասխանատվությունն ավարտվում է հենց այն պահին, երբ մշակումը ներկայացնում է build-ը թողարկման համար:

Մեր երկրորդ հիմքը, որ ունենք, որը նույնպես մեզ շատ է օգնում, եզակի չփաստաթղթավորված գիտելիքների բացակայությունն է։ Հուսով եմ, որ դա նույնն է ձեզ համար: Քանի որ եթե դա այդպես չէ, դուք խնդիրներ կունենաք։ Խնդիրներ կծագեն, երբ այս եզակի, չփաստագրված գիտելիքը ճիշտ ժամանակին ճիշտ տեղում չհայտնվի: Ենթադրենք, դուք ունեք մեկ մարդ, ով գիտի, թե ինչպես պետք է տեղակայել կոնկրետ բաղադրիչ. մարդը այնտեղ չէ, նա արձակուրդում է կամ հիվանդ է, վերջ, դուք խնդիրներ ունեք:

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

Ծրագրաշարի տարբերակը փոխելու պահանջներ

Կան երեք պահանջներ.

• Մենք պետք է արագ հետ գցենք տեղակայումը:
• Մենք պետք է նվազագույնի հասցնենք անհաջող տեղակայման ազդեցությունը:
• Եվ մենք պետք է կարողանանք արագ տեղակայվել զուգահեռաբար։
  Հենց այդ հերթականությամբ։ Ինչո՞ւ։ Որովհետև, առաջին հերթին, նոր տարբերակ տեղադրելիս արագությունը կարևոր չէ, բայց ձեզ համար կարևոր է, եթե ինչ-որ բան սխալ է, արագ հետ գլորվել և նվազագույն ազդեցություն ունենալ: Բայց եթե դուք ունեք մի շարք տարբերակներ արտադրության մեջ, որոնց համար պարզվում է, որ սխալ կա (կապույտ, տեղակայում չկար, բայց կա սխալ), ապա ձեզ համար կարևոր է հետագա տեղակայման արագությունը: Ի՞նչ ենք մենք արել այս պահանջները բավարարելու համար։ Մենք դիմեցինք հետևյալ մեթոդաբանությանը.

  
  
  Դա բավականին հայտնի է, մենք երբեք չենք հորինել այն. սա Կապույտ/Կանաչ տեղակայումն է: Ինչ է դա? Դուք պետք է ունենաք պատճեն սերվերների յուրաքանչյուր խմբի համար, որոնց վրա տեղադրված են ձեր հավելվածները: Պատճենը «ջերմ» է. դրա վրա երթևեկություն չկա, բայց ցանկացած պահի այս տրաֆիկը կարող է ուղարկվել այս պատճենին: Այս պատճենը պարունակում է նախորդ տարբերակը: Եվ տեղակայման պահին ծածկագիրը տեղադրում եք ոչ ակտիվ պատճենում: Այնուհետև դուք փոխում եք տրաֆիկի մի մասը (կամ ամբողջը) նոր տարբերակին: Այսպիսով, երթևեկության հոսքը հին տարբերակից նորին փոխելու համար անհրաժեշտ է կատարել միայն մեկ գործողություն. անհրաժեշտ է փոխել հավասարակշռիչը հոսանքին հակառակ, փոխել ուղղությունը՝ մեկ հոսանքով մյուսը: Սա շատ հարմար է և լուծում է արագ փոխարկման և արագ հետադարձի խնդիրը:

  Այստեղ երկրորդ հարցի լուծումը մինիմալացումն է՝ դուք կարող եք ուղարկել ձեր տրաֆիկի միայն մի մասը նոր գիծ, ​​նոր կոդով տող (թող լինի, օրինակ, 2%)։ Իսկ այս 2%-ը 100% չեն։ Եթե ​​դուք կորցրել եք ձեր տրաֆիկի 100%-ը անհաջող տեղակայման պատճառով, դա սարսափելի է, եթե կորցրել եք ձեր տրաֆիկի 2%-ը, դա տհաճ է, բայց դա սարսափելի չէ: Ավելին, օգտատերերը, ամենայն հավանականությամբ, չեն էլ նկատի դա, քանի որ որոշ դեպքերում (ոչ բոլորում) նույն օգտատերը, սեղմելով F5, կտեղափոխվի մեկ այլ, աշխատանքային տարբերակ։

  Կապույտ/կանաչ տեղակայում: Երթուղիավորում

  Այնուամենայնիվ, ամեն ինչ այնքան էլ պարզ չէ «Կապույտ/Կանաչ տեղակայում»... Մեր բոլոր բաղադրիչները կարելի է բաժանել երեք խմբի.

  • սա ճակատային հատվածն է (վճարման էջերը, որոնք տեսնում են մեր հաճախորդները);
  • վերամշակման միջուկ;
  • ադապտեր վճարային համակարգերի հետ աշխատելու համար (բանկեր, MasterCard, Visa...):

  Եվ այստեղ կա մի նրբերանգ՝ նրբությունը տողերի միջև երթուղիների մեջ է: Եթե ​​դուք պարզապես փոխում եք տրաֆիկի 100%-ը, ապա այս խնդիրները չեք ունենա: Բայց եթե ցանկանում եք փոխել 2%-ը, սկսում եք հարցեր տալ. «Ինչպե՞ս դա անել»: Ամենապարզ բանը ուղիղ է. դուք կարող եք կարգավորել Round Robin-ը nginx-ում պատահական ընտրությամբ, և դուք ունեք 2% դեպի ձախ, 98% դեպի աջ: Բայց սա միշտ չէ, որ հարմար է:

  Օրինակ, մեր դեպքում օգտվողը փոխազդում է համակարգի հետ մեկից ավելի հարցումներով: Սա նորմալ է. 2, 3, 4, 5 հարցումներ. ձեր համակարգերը կարող են նույնը լինել: Եվ եթե ձեզ համար կարևոր է, որ օգտատիրոջ բոլոր հարցումները գան նույն տողում, որով առաջին հարցումն է եկել, կամ (երկրորդ կետ) օգտատիրոջ բոլոր հարցումները փոխարկիչից հետո գան նոր գիծ (նա կարող էր ավելի վաղ սկսել աշխատել այդ գծի հետ: համակարգ, անջատումից առաջ), - ապա այս պատահական բաշխումը ձեզ համար հարմար չէ: Այնուհետև կան հետևյալ տարբերակները.

  
  
  Առաջին տարբերակը, ամենապարզը, հիմնված է հաճախորդի հիմնական պարամետրերի վրա (IP Hash): Դուք ունեք IP, և այն բաժանում եք աջից ձախ IP հասցեով: Այնուհետև իմ նկարագրած երկրորդ դեպքը կաշխատի ձեզ համար, երբ տեղակայումը տեղի ունեցավ, օգտվողը կարող էր արդեն սկսել աշխատել ձեր համակարգի հետ, և տեղակայման պահից բոլոր հարցումները կգնան նոր տող (նույնը, ասենք):

  Եթե ​​ինչ-ինչ պատճառներով դա ձեզ չի համապատասխանում, և դուք պետք է հարցումներ ուղարկեք այն գիծ, ​​որտեղ եկել է օգտատիրոջ նախնական, նախնական հարցումը, ապա ունեք երկու տարբերակ...
  Առաջին տարբերակը՝ կարող եք գնել վճարովի nginx+: Գոյություն ունի Sticky sessions մեխանիզմ, որը օգտատիրոջ սկզբնական խնդրանքով սեսիա է հատկացնում օգտատիրոջը և կապում այն ​​մեկ կամ մի այլ հոսանքին հակառակ: Օգտագործողի բոլոր հետագա հարցումները սեսիայի կյանքի ընթացքում կուղարկվեն նույն վերին հոսքին, որտեղ տեղադրվել է նիստը:

  Սա մեզ չէր համապատասխանում, քանի որ մենք արդեն ունեինք սովորական nginx: Nginx+-ին անցնելը այնքան էլ թանկ չէ, պարզապես մեզ համար դա ինչ-որ չափով ցավոտ էր և այնքան էլ ճիշտ չէր: «Sticks Sessions»-ը, օրինակ, մեզ մոտ չաշխատեց այն պարզ պատճառով, որ «Sticks Sessions»-ը թույլ չի տալիս երթուղում կատարել «Կամ-կամ»-ի հիման վրա: Այնտեղ կարող եք նշել, թե ինչ է անում մենք «Sticks Sessions»-ը, օրինակ՝ IP հասցեով կամ IP հասցեով և թխուկներով կամ հետպարամետրով, բայց «Կամ-կամ»-ն այնտեղ ավելի բարդ է:

  Այսպիսով, մենք եկանք չորրորդ տարբերակին. Մենք վերցրեցինք nginx-ը ստերոիդների վրա (սա openresty է) - սա նույն nginx-ն է, որը լրացուցիչ աջակցում է վերջին սկրիպտների ներառմանը: Դուք կարող եք գրել վերջին սկրիպտը, տալ նրան «բաց հանգիստ», և այս վերջին սկրիպտը կկատարվի, երբ գա օգտագործողի հարցումը:

  Եվ մենք, փաստորեն, նման սցենար գրեցինք, ինքներս մեզ «openresti» դրեցինք և այս սցենարում դասավորում ենք 6 տարբեր պարամետրեր՝ «Or» շաղկապմամբ: Կախված այս կամ այն ​​պարամետրի առկայությունից, մենք գիտենք, որ օգտվողը եկել է այս կամ այն ​​էջին, այս կամ այն ​​տողին:

  Կապույտ/կանաչ տեղակայում: Առավելություններն ու թերությունները

  Իհարկե, երևի հնարավոր էր մի փոքր ավելի պարզեցնել (օգտագործել նույն «Sticky Sessions»-ը), բայց մենք ունենք նաև այնպիսի նրբերանգ, որ ոչ միայն օգտատերը մեզ հետ շփվում է մեկ գործարքի մեկ մշակման շրջանակներում... Բայց վճարային համակարգերը նաև փոխազդում են մեզ հետ. գործարքը մշակելուց հետո (վճարային համակարգին հարցում ուղարկելով), մենք ստանում ենք «coolback»:
  Եվ ասենք, եթե մեր շղթայի ներսում կարողանանք օգտատիրոջ IP հասցեն փոխանցել բոլոր հարցումներում և բաժանել օգտատերերին IP հասցեի հիման վրա, ապա մենք նույն «վիզան» չենք ասի. լինել միջազգային (կայքում և Ռուսաստանում)... Խնդրում ենք տրամադրել մեզ օգտատիրոջ IP հասցեն լրացուցիչ դաշտում, ձեր արձանագրությունը ստանդարտացված է»! Պարզ է, որ չեն համաձայնի։

  
  
  Հետևաբար, սա մեզ մոտ չաշխատեց. մենք բացել ենք: Համապատասխանաբար, երթուղիներով մենք ստացանք այսպիսի բան.

  Կապույտ/կանաչ տեղակայումն ունի, համապատասխանաբար, իմ նշած առավելություններն ու թերությունները:

  Երկու թերություն.

  • դուք պետք է անհանգստանաք երթուղղման հետ;
  • երկրորդ հիմնական թերությունը ծախսն է։

  Ձեզ անհրաժեշտ են երկու անգամ ավելի շատ սերվերներ, ձեզ անհրաժեշտ են երկու անգամ ավելի շատ գործառնական ռեսուրսներ, դուք պետք է երկու անգամ ավելի շատ ջանք ծախսեք այս ամբողջ կենդանաբանական այգին պահպանելու համար:

  Ի դեպ, առավելությունների թվում կա ևս մեկ բան, որը նախկինում չեմ նշել՝ դու ռեզերվ ունես բեռի աճի դեպքում։ Եթե ​​դուք ունեք բեռի պայթյունավտանգ աճ, դուք ունեք մեծ թվով օգտատերեր, ապա դուք պարզապես ներառում եք երկրորդ տողը 50-ից 50 բաշխման մեջ, և դուք անմիջապես կունենաք x2 սերվերներ ձեր կլաստերում, մինչև կլուծեք ավելի շատ սերվերներ ունենալու խնդիրը:

  Ինչպե՞ս արագ տեղակայել:

  Մենք խոսեցինք այն մասին, թե ինչպես լուծել նվազագույնի հասցնելու և արագ վերադարձի խնդիրը, բայց հարցը մնում է. «Ինչպե՞ս արագ տեղակայվել»:

  
  
  Այստեղ դա կարճ է և պարզ:

  • Դուք պետք է ունենաք CD համակարգ (Շարունակական առաքում), առանց դրա չեք կարող ապրել: Եթե ​​ունեք մեկ սերվեր, կարող եք ձեռքով տեղակայել: Մենք ունենք մոտ մեկուկես հազար սերվեր և մեկուկես հազար բռնակներ, իհարկե, մենք կարող ենք այս սենյակի չափով բաժին հիմնել միայն տեղակայելու համար:
  • Տեղակայումը պետք է լինի զուգահեռ: Եթե ​​ձեր տեղակայումը հաջորդական է, ապա ամեն ինչ վատ է: Մեկ սերվերը նորմալ է, ամբողջ օրը մեկուկես հազար սերվեր կտեղակայեք։
  • Կրկին, արագացման համար սա, հավանաբար, այլևս անհրաժեշտ չէ: Տեղակայման ժամանակ նախագիծը սովորաբար կառուցվում է: Դուք ունեք վեբ-նախագիծ, կա ֆրոնտ-end մաս (այդտեղ վեբ փաթեթ եք անում, npm-ն եք կազմում՝ նման բան), և այս գործընթացը, սկզբունքորեն, կարճատև է՝ 5 րոպե, բայց այս 5 րոպեն կարող է. լինել քննադատական. Ահա թե ինչու, օրինակ, մենք դա չենք անում. մենք հանեցինք այս 5 րոպեները, տեղադրեցինք արտեֆակտներ:

    Ի՞նչ է արտեֆակտը: Արտեֆակտը հավաքված շինություն է, որի բոլոր հավաքման մասերն արդեն ավարտված են: Մենք այս արտեֆակտը պահում ենք արտեֆակտ պահեստում: Ժամանակին մենք օգտագործում էինք երկու այդպիսի պահեստ՝ դա Nexus-ն էր, իսկ այժմ՝ jFrog Artifactory): Սկզբում օգտագործեցինք «Nexus»-ը, քանի որ սկսեցինք կիրառել այս մոտեցումը java հավելվածներում (դա լավ էր համապատասխանում դրան): Հետո այնտեղ տեղադրեցին PHP-ով գրված հավելվածներից մի քանիսը. և «Nexus»-ն այլևս հարմար չէր, և, հետևաբար, մենք ընտրեցինք jFrog Artefactory-ն, որը կարող է արտեֆակտորացնել գրեթե ամեն ինչ: Մենք նույնիսկ հասել ենք նրան, որ այս արտեֆակտի պահոցում մենք պահում ենք մեր սեփական երկուական փաթեթները, որոնք հավաքում ենք սերվերների համար:

  Պայթուցիկ բեռի աճ

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

  Մենք նոր համակարգ ենք գրել՝ սպասարկմանը միտված է, մոդայիկ, գեղեցիկ, ամենուր աշխատող, ամենուր հերթեր, ամենուր ասինքրոն։ Եվ նման համակարգերում տվյալները կարող են հոսել տարբեր հոսքերի միջոցով: Առաջին գործարքի համար կարող է օգտագործվել 1-ին, 3-րդ, 10-րդ աշխատողը, երկրորդ գործարքի համար՝ 2-րդ, 4-րդ, 5-րդ: Եվ այսօր, ենթադրենք, առավոտյան դուք ունեք տվյալների հոսք, որն օգտագործում է առաջին երեք աշխատողներին, իսկ երեկոյան այն կտրուկ փոխվում է, և ամեն ինչ օգտագործում է մյուս երեք աշխատողներին:

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

  
  
  Մենք սահմանել ենք մեր պահանջները։ Այս պահանջները բավականին պարզ են. որ լինի Ծառայությունների հայտնաբերում, պարամետրիզացիա. ամեն ինչ ստանդարտ է նման մասշտաբային համակարգեր կառուցելու համար, բացառությամբ մեկ կետի՝ ռեսուրսների մաշվածության: Մենք ասացինք, որ պատրաստ չենք ամորտիզացնել ռեսուրսները, որպեսզի սերվերները տաքացնեն օդը։ Վերցրինք «Հյուպատոսը», վերցրինք «Նոմադը», որը ղեկավարում է մեր աշխատողներին։

  Ինչո՞ւ է սա մեզ համար խնդիր: Եկեք մի փոքր հետ գնանք. Այժմ մենք ունենք շուրջ 70 վճարային համակարգեր: Առավոտյան երթևեկությունը անցնում է Սբերբանկով, այնուհետև, օրինակ, Սբերբանկը ընկավ, և մենք այն միացնում ենք այլ վճարային համակարգի: Մինչ Սբերբանկը 100 աշխատող ունեինք, իսկ դրանից հետո մեկ այլ վճարային համակարգի համար պետք է կտրուկ ավելացնել 100 աշխատող։ Եվ ցանկալի է, որ այս ամենը տեղի ունենա առանց մարդկային մասնակցության։ Որովհետև եթե կա մարդկային մասնակցություն, 24/7 պետք է նստի ինժեներ, ով պետք է միայն դա անի, քանի որ նման խափանումները, երբ 70 համակարգ կանգնած է քո հետևում, պարբերաբար լինում են։

  Հետևաբար, մենք նայեցինք Nomad-ը, որն ունի բաց IP, և գրեցինք մեր սեփականը, Scale-Nomad - ScaleNo, որն անում է մոտավորապես հետևյալը. այն հետևում է հերթի աճին և նվազեցնում կամ ավելացնում է աշխատողների թիվը՝ կախված դինամիկայից: հերթի. Երբ մենք դա արեցինք, մենք մտածեցինք. «Գուցե մենք կարող ենք բացել այն»: Հետո նրանք նայեցին նրան, նա երկու կոպեկի պես պարզ էր։

  Առայժմ մենք բաց աղբյուր չենք ունեցել, բայց եթե հանկարծ զեկույցից հետո, հասկանալուց հետո, որ քեզ նման բան է պետք, քեզ դա պետք է, իմ կոնտակտները վերջին սլայդում են, խնդրում եմ գրիր ինձ։ Եթե ​​գոնե 3-5 հոգի լինի, հովանավորելու ենք։

  
  
  Ինչպես է դա աշխատում? Եկեք նայենք: Նայելով առաջ. ձախ կողմում մեր մոնիտորինգի մի հատվածն է՝ սա մեկ տող է, վերևում՝ իրադարձությունների մշակման ժամանակը, մեջտեղում՝ գործարքների քանակը, ներքևում՝ աշխատողների թիվը:

  Եթե ​​նայեք, այս նկարում թերություն կա։ Վերևի աղյուսակում աղյուսակներից մեկը խափանվել է 45 վայրկյանում. վճարային համակարգերից մեկն իջել է: Անմիջապես 2 րոպեում երթևեկությունը բերվեց, և հերթը սկսեց աճել մեկ այլ վճարային համակարգում, որտեղ աշխատող չկար (մենք չօգտագործեցինք ռեսուրսները, ընդհակառակը, ռեսուրսը ճիշտ տնօրինեցինք): Չէինք ուզում տաքանալ, մինիմալ թիվ կար՝ մոտ 5-10 աշխատող, բայց չկարողացան դիմանալ։

  Վերջին գրաֆիկը ցույց է տալիս «կուզ», ինչը պարզապես նշանակում է, որ «Սկալենոն» կրկնապատկել է այս գումարը: Եվ հետո, երբ գրաֆիկը մի փոքր ընկավ, նա մի փոքր կրճատեց այն՝ աշխատողների թիվը ինքնաբերաբար փոխվեց։ Այդպես է աշխատում այս բանը։ Մենք խոսեցինք թիվ 2 կետի մասին՝ «Ինչպես արագ ազատվել պատճառներից»։

  Մոնիտորինգ. Ինչպե՞ս արագ բացահայտել խնդիրը:

  Այժմ առաջին կետն է՝ «Ինչպե՞ս արագ բացահայտել խնդիրը»: Մոնիտորինգ! Մենք պետք է արագ հասկանանք որոշ բաներ. Ի՞նչ բաներ պետք է արագ հասկանանք:

  
  
  Երեք բան.

  • Մենք պետք է արագ հասկանանք և հասկանանք մեր սեփական ռեսուրսների կատարողականը։
  • Մենք պետք է արագ հասկանանք ձախողումները և վերահսկենք մեզ համար արտաքին համակարգերի աշխատանքը:
  • Երրորդ կետը տրամաբանական սխալների բացահայտումն է: Սա այն դեպքում, երբ համակարգը աշխատում է ձեզ համար, ամեն ինչ նորմալ է բոլոր ցուցանիշների համաձայն, բայց ինչ-որ բան այն չէ:

  Ես երևի ձեզ այդքան զով բան չեմ ասի այստեղ: Ես կլինեմ կապիտան Օբվիզը: Մենք փնտրեցինք այն, ինչ կա շուկայում: Մենք ունենք «զվարճալի կենդանաբանական այգի»: Ահա այսպիսի կենդանաբանական այգի մենք ունենք հիմա.

  
  
  Մենք օգտագործում ենք Zabbix սարքաշարը վերահսկելու, սերվերների հիմնական ցուցանիշները վերահսկելու համար: Մենք օգտագործում ենք Okmeter տվյալների բազաների համար: Մենք օգտագործում ենք «Գրաֆանա» և «Պրոմեթևս» բոլոր մյուս ցուցիչների համար, որոնք չեն համապատասխանում առաջին երկուսին, ոմանք՝ «Գրաֆանա» և «Պրոմեթևս», իսկ որոշները՝ «Գրաֆանա»՝ «Influx» և Telegraf:

  Մեկ տարի առաջ մենք ուզում էինք օգտագործել New Relic-ը: Հիանալի բան, ամեն ինչ կարող է անել: Բայց որքան կարող է ամեն ինչ անել, այնքան թանկ է։ Երբ մենք հասանք 1,5 հազար սերվերի ծավալի, մի վաճառող եկավ մեզ մոտ և ասաց. «Եկեք պայմանագիր կնքենք հաջորդ տարվա համար»: Մենք նայեցինք գինը և ասացինք, որ ոչ, մենք դա չենք անի: Հիմա մենք հրաժարվում ենք New Relic-ից, ունենք մոտ 15 սերվեր մնացել New Relic-ի մոնիտորինգի տակ։ Գինը բացարձակապես վայրենի է ստացվել։

  Եվ կա մեկ գործիք, որը մենք ինքներս ենք կիրառել՝ սա Debugger-ն է: Սկզբում մենք այն անվանեցինք «Բագեր», բայց հետո անցավ անգլերենի ուսուցիչը, կատաղի ծիծաղեց և այն վերանվանեց «Դեբագեր»։ Ինչ է դա? Սա գործիք է, որն իրականում յուրաքանչյուր բաղադրիչի վրա 15-30 վայրկյանում, ինչպես համակարգի «սև արկղը», փորձարկում է բաղադրիչի ընդհանուր կատարողականությունը:

  Օրինակ, եթե կա արտաքին էջ (վճարման էջ), նա ուղղակի բացում է այն և նայում, թե ինչպես պետք է այն երևա։ Եթե ​​սա մշակվում է, նա ուղարկում է փորձնական «գործարք» և համոզվում, որ այս «գործարքը» գալիս է: Եթե ​​սա կապ է վճարային համակարգերի հետ, մենք համապատասխանաբար ուղարկում ենք թեստային հարցում, որտեղ կարող ենք, և տեսնում ենք, որ մեզ մոտ ամեն ինչ կարգին է:

  Ի՞նչ ցուցանիշներ են կարևոր մոնիտորինգի համար:

  Ի՞նչն ենք մենք հիմնականում վերահսկում: Ի՞նչ ցուցանիշներ են մեզ համար կարևոր։

  
  

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

  Վերջին կետը «բիզնես», «բիզնես» մետրիկ է: Եթե ​​ցանկանում եք վերահսկել նույնը, դուք պետք է սահմանեք մեկ կամ երկու չափումներ, որոնք ձեզ համար հիմնական ցուցանիշներն են: Մեր ցուցանիշը թողունակությունն է (սա հաջող գործարքների քանակի հարաբերակցությունն է գործարքների ընդհանուր հոսքին): Եթե ​​դրա մեջ ինչ-որ բան փոխվում է 5-10-15 րոպե ընդմիջումով, դա նշանակում է, որ մենք խնդիրներ ունենք (եթե այն արմատապես փոխվում է):

  Այն, ինչ մեզ համար թվում է, մեր տախտակներից մեկի օրինակն է.

  
  
  Ձախ կողմում կա 6 գրաֆիկ, սա ըստ տողերի՝ աշխատողների և հերթերի հաղորդագրությունների քանակի։ Աջ կողմում - RPS, RTS: Ստորև ներկայացված է նույն «բիզնեսի» ցուցանիշը: Իսկ «բիզնեսի» չափման մեջ մենք կարող ենք անմիջապես տեսնել, որ ինչ-որ բան սխալ է տեղի ունեցել երկու միջին գրաֆիկներում... Սա ընդամենը մեկ այլ համակարգ է, որը կանգնած է մեր հետևում, որը ընկել է:

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

  
  
  Գրաֆիկը ցույց է տալիս, որ վճարային համակարգերից մեկը սկսել է արձագանքել 3 վայրկյանում. մենք խնդիրներ ունենք: Ավելին, այս բանը կարձագանքի, երբ խնդիրներ սկսվեն՝ 20-30 վայրկյան ընդմիջումով։

  Իսկ մոնիտորինգի սխալների երրորդ դասը, որը գոյություն ունի, տրամաբանական մոնիտորինգն է:

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

  
  
  Ի՞նչ նկատի ունեմ տրամաբանական մոնիտորինգ ասելով: Դե, պատկերացրեք. դուք ինքներդ ձեզ համակարգ եք դարձնում (օրինակ, Tinder կլոն); դու պատրաստեցիր, գործարկեցիր: Հաջողակ մենեջեր Վասյա Պուպկինը դրեց այն իր հեռախոսին, այնտեղ տեսնում է մի աղջկա, հավանում է նրան… և նմանը չի գնում աղջկա մոտ. նմանը գնում է նույն բիզնես կենտրոնի անվտանգության աշխատակից Միխալիչին: Մենեջերը իջնում ​​է ներքև և հետո զարմանում. «Ինչո՞ւ է անվտանգության աշխատակից Միխալիչն այդքան հաճելի ժպտում նրան»:

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

  Սա այն մասին էր, թե ինչպես արագ բացահայտել խնդիրը:

  Ինչպես որոշել տեղակայման պատճառները

  Խնդիրների երրորդ խումբը, որը մենք լուծում ենք, խնդիրը բացահայտելուց հետո, դրանից ազատվելուց հետո լավ կլինի հասկանալ զարգացման, թեստավորման պատճառը և ինչ-որ բան անել դրա դեմ: Համապատասխանաբար, մենք պետք է հետաքննենք, մենք պետք է բարձրացնենք գերանները:

  
  
  Եթե ​​մենք խոսում ենք տեղեկամատյանների մասին (հիմնական պատճառը տեղեկամատյաններն են), ապա մեր տեղեկամատյանների մեծ մասը գտնվում է ELK Stack-ում. գրեթե բոլորն ունեն նույնը: Ոմանց մոտ կարող է ELK-ով չլինի, բայց եթե լոգերը գիգաբայթով ես գրում, ուրեմն վաղ թե ուշ կգաս ELK: Մենք դրանք գրում ենք տերաբայթերով:

  
  
  Այստեղ խնդիր կա. Մենք ուղղեցինք այն, ուղղեցինք օգտատիրոջ սխալը, սկսեցինք պեղել այն, ինչ կա, բարձրացանք Կիբանա, այնտեղ մուտքագրեցինք գործարքի id-ը և ստացանք այսպիսի ոտքի ծածկոց (շատ բան է ցույց տալիս): Եվ այս ոտնաթաթի մեջ բացարձակապես ոչինչ պարզ չէ։ Ինչո՞ւ։ Այո, քանի որ պարզ չէ, թե որ մասը որ աշխատողինն է, որ մասը որ բաղադրիչին։ Եվ այդ պահին մենք հասկացանք, որ մեզ հետագծում է պետք՝ նույն OpenTracing-ը, որի մասին ես խոսեցի։

  Մենք սա մտածեցինք մեկ տարի առաջ, մեր ուշադրությունը ուղղեցինք դեպի շուկան, և այնտեղ երկու գործիք կար՝ Zipkin-ը և Jaeger-ը: «Ջագերը» իրականում այդպիսի գաղափարական ժառանգորդ է, «Զիպկինի» գաղափարական ժառանգորդը։ Zipkin-ում ամեն ինչ լավ է, բացառությամբ, որ այն չգիտի ինչպես ագրեգացնել, չգիտի ինչպես ներառել տեղեկամատյանները հետքի մեջ, միայն ժամանակի հետք: Եվ «Ջագերը» սատարեց դրան։

  Մենք նայեցինք «Jager»-ին. կարող եք գործիքավորել հավելվածներ, կարող եք գրել Api-ով (այդ ժամանակ PHP-ի համար Api ստանդարտը, սակայն, հաստատված չէր. սա մեկ տարի առաջ էր, բայց հիմա արդեն հաստատվել է), բայց այնտեղ բացարձակապես ոչ մի հաճախորդ չի եղել: «Լավ», մտածեցինք մենք և գրեցինք մեր սեփական հաճախորդին: Ի՞նչ ստացանք։ Մոտավորապես այսպես է թվում.

  
  
  Jaeger-ում յուրաքանչյուր հաղորդագրության համար ստեղծվում են բացվածքներ: Այսինքն՝ երբ օգտատերը բացում է համակարգը, յուրաքանչյուր մուտքային հարցումի համար տեսնում է մեկ կամ երկու բլոկ (1-2-3՝ օգտատիրոջ մուտքային հարցումների քանակը, բլոկների քանակը)։ Օգտատերերի համար հեշտացնելու համար մենք ավելացրել ենք պիտակներ տեղեկամատյաններում և ժամանակի հետքերում: Համապատասխանաբար, սխալի դեպքում մեր հավելվածը մատյանը կնշի համապատասխան Error թեգով։ Դուք կարող եք զտել ըստ Սխալի պիտակի և կցուցադրվեն միայն այն տարածքները, որոնք պարունակում են այս բլոկը սխալով: Ահա թե ինչ տեսք կունենա, եթե ընդլայնենք միջակայքը.

  
  
  Թակի ներսում կա մի շարք հետքեր։ Այս դեպքում սրանք երեք փորձնական հետքեր են, իսկ երրորդ հետքը մեզ ասում է, որ սխալ է տեղի ունեցել: Միևնույն ժամանակ, այստեղ մենք տեսնում ենք ժամանակային հետք. մենք վերևում ունենք ժամանակային սանդղակ, և մենք տեսնում ենք, թե որ ժամանակային միջակայքում է գրանցվել այս կամ այն ​​տեղեկամատյանը:

  Համապատասխանաբար, մեզ մոտ ամեն ինչ լավ ընթացավ։ Մենք գրել ենք մեր սեփական ընդլայնումը և այն բաց կոդով ենք գրել: Եթե ​​ցանկանում եք աշխատել հետագծման հետ, եթե ցանկանում եք աշխատել «Jager»-ի հետ PHP-ում, կա մեր ընդլայնումը, համեցեք օգտագործել, ինչպես ասում են.

  
  
  Մենք ունենք այս ընդլայնումը. այն OpenTracing Api-ի հաճախորդ է, այն պատրաստված է որպես php-extence, այսինքն՝ ձեզ անհրաժեշտ կլինի այն հավաքել և տեղադրել համակարգում: Մեկ տարի առաջ ուրիշ բան չկար։ Այժմ կան այլ հաճախորդներ, որոնք նման են բաղադրիչներին: Այստեղ ամեն ինչ կախված է ձեզանից. կամ դուք կոմպոզիտորով դուրս եք մղում բաղադրիչները, կամ օգտագործում եք ձեր ընդլայնումը:

  Կորպորատիվ ստանդարտներ

  Մենք խոսեցինք երեք պատվիրանների մասին. Չորրորդ պատվիրանը մոտեցումների ստանդարտացումն է: Ինչի՞ մասին է սա։ Խոսքը սրա մասին է.

  
  
  Ինչու՞ է այստեղ «կորպորատիվ» բառը: Ոչ այն պատճառով, որ մենք մեծ կամ բյուրոկրատական ​​ընկերություն ենք, ոչ: Ես ուզում էի օգտագործել «կորպորատիվ» բառն այստեղ այն համատեքստում, որ յուրաքանչյուր ընկերություն, յուրաքանչյուր ապրանք պետք է ունենա իր չափանիշները, այդ թվում՝ դուք: Ի՞նչ չափանիշներ ունենք։

  
  

  • Մենք ունենք տեղակայման կանոնակարգ: Մենք առանց նրա ոչ մի տեղ չենք շարժվում, չենք կարող։ Շաբաթական մոտ 60 անգամ ենք տեղակայում, այսինքն՝ գրեթե անընդհատ տեղակայում ենք։ Միևնույն ժամանակ, մենք, օրինակ, տեղակայման կանոնակարգում տաբու ունենք ուրբաթ օրը տեղակայումների վերաբերյալ. սկզբունքորեն մենք չենք տեղակայում:
  • Մենք պահանջում ենք փաստաթղթեր. Ոչ մի նոր բաղադրիչ չի արտադրվում, եթե դրա համար փաստաթղթեր չկան, նույնիսկ եթե այն ծնվել է մեր RnD մասնագետների գրչի տակ: Մենք նրանցից պահանջում ենք տեղակայման հրահանգներ, մոնիտորինգի քարտեզ և կոպիտ նկարագրություն (ինչպես կարող են գրել ծրագրավորողները), թե ինչպես է աշխատում այս բաղադրիչը և ինչպես լուծել այն:
  • Մենք լուծում ենք ոչ թե խնդրի պատճառը, այլ այն, ինչ ես արդեն ասացի։ Մեզ համար կարևոր է պաշտպանել օգտվողին խնդիրներից:
  • Մենք թույլտվություններ ունենք. Օրինակ, մենք չենք համարում այն ​​խափանումը, եթե երկու րոպեի ընթացքում կորցրել ենք երթևեկի 2%-ը: Սա հիմնականում ներառված չէ մեր վիճակագրության մեջ։ Եթե ​​տոկոսային առումով ավելի շատ է, թե ժամանակավոր, արդեն հաշվում ենք։
  • Իսկ մենք միշտ հետմահու ենք գրում։ Ինչ էլ որ պատահի մեզ հետ, ցանկացած իրավիճակ, երբ ինչ-որ մեկը աննորմալ վարքագիծ է դրսևորել արտադրության մեջ, կարտացոլվի հետմահու: Հետմահու դա փաստաթուղթ է, որտեղ դուք գրում եք, թե ինչ է կատարվել ձեզ հետ, մանրամասն ժամանակացույց, թե ինչ եք արել այն ուղղելու համար և (սա պարտադիր արգելափակում է) ինչ եք անելու, որպեսզի դա չպատահի ապագայում: Սա պարտադիր է և անհրաժեշտ հետագա վերլուծության համար:

  Ի՞նչն է համարվում պարապուրդ:

  
  
  Ինչի՞ հանգեցրեց այս ամենը։

  Սա հանգեցրեց նրան, որ (մենք ունեինք կայունության հետ կապված որոշակի խնդիրներ, դա չէր սազում ոչ հաճախորդներին, ոչ մեզ) վերջին 6 ամիսների ընթացքում մեր կայունության ցուցանիշը 99,97 էր: Կարելի է ասել, որ սա այնքան էլ շատ չէ։ Այո, մենք ձգտելու բան ունենք։ Այս ցուցանիշի մոտ կեսը կայունությունն է, կարծես թե, ոչ թե մեր, այլ մեր վեբ հավելվածի firewall-ը, որը կանգնած է մեր առջև և օգտագործվում է որպես ծառայություն, բայց հաճախորդները թքած ունեն դրա վրա:

  Մենք սովորեցինք գիշերը քնել: Վերջապես! Վեց ամիս առաջ մենք չէինք կարող։ Եվ արդյունքների հետ կապված այս գրառման վրա ես կցանկանայի մեկ նշում կատարել. Անցած գիշեր հրաշալի զեկույց եղավ միջուկային ռեակտորի կառավարման համակարգի մասին։ Եթե ​​մարդիկ, ովքեր գրել են այս համակարգը, կարող են լսել ինձ, խնդրում եմ մոռանալ այն, ինչ ես ասացի «2%-ը պարապուրդի ժամանակ չէ»: Ձեզ համար 2%-ը պարապուրդ է, նույնիսկ եթե երկու րոպեով:

  Այսքանը: Ձեր հարցերը.

  
  

  Հավասարակշռողների և տվյալների բազայի միգրացիայի մասին

  Հարց հանդիսատեսից (այսուհետ՝ Բ). – Բարի երեկո։ Շատ շնորհակալ եմ նման ադմինիստրատորի հաշվետվության համար: Կարճ հարց ձեր հավասարակշռողների մասին: Դուք նշեցիք, որ ունեք WAF, այսինքն, ինչպես հասկացա, ինչ-որ արտաքին հավասարակշռող եք օգտագործում...

  EK: – Ոչ, մենք օգտագործում ենք մեր ծառայությունները որպես հավասարակշռող: Այս դեպքում WAF-ը մեզ համար բացառապես DDoS պաշտպանության գործիք է:

  IN: – Կարո՞ղ եք մի քանի խոսք ասել հավասարակշռողների մասին:

  EK: – Ինչպես արդեն ասացի, սա openresty սերվերների խումբ է: Այժմ մենք ունենք 5 պահեստային խմբեր, որոնք արձագանքում են բացառապես... այսինքն՝ սերվեր, որն աշխատում է բացառապես openresty-ով, այն միայն վստահեցնում է տրաֆիկը։ Համապատասխանաբար, հասկանալու համար, թե որքան ենք մենք պահում, մենք այժմ ունենք մի քանի հարյուր մեգաբիթանոց կանոնավոր երթևեկություն: Նրանք գլուխ են հանում, լավ են զգում, նույնիսկ չեն լարում իրենց։

  IN: - Նաև մի պարզ հարց. Ահա Կապույտ/Կանաչ տեղակայումը: Ինչ եք անում, օրինակ, տվյալների բազայի միգրացիաների հետ:

  EK: - Լավ հարց է! Տեսեք, Կապույտ/Կանաչ տեղակայման դեպքում մենք յուրաքանչյուր տողի համար առանձին հերթեր ունենք: Այսինքն, եթե մենք խոսում ենք իրադարձությունների հերթերի մասին, որոնք փոխանցվում են աշխատողից աշխատող, ապա կան առանձին հերթեր կապույտ գծի և կանաչ գծի համար: Եթե ​​մենք խոսում ենք բուն տվյալների բազայի մասին, ապա մենք միտումնավոր նեղացրել ենք այն, որքան կարող ենք, ամեն ինչ տեղափոխել ենք գործնականում հերթերի մեջ, տվյալների բազայում մենք պահում ենք միայն գործարքների փաթեթ: Եվ մեր գործարքների փաթեթը նույնն է բոլոր տողերի համար: Տվյալների բազան այս համատեքստում. մենք այն չենք բաժանում կապույտի և կանաչի, քանի որ կոդի երկու տարբերակներն էլ պետք է իմանան, թե ինչ է կատարվում գործարքի հետ:

  Ընկերնե՛ր, ես նաև մի փոքրիկ մրցանակ ունեմ ձեզ խթանելու՝ գիրք: Եվ ես պետք է արժանանամ այն ​​լավագույն հարցի համար։

  IN: - Բարեւ Ձեզ. Շնորհակալություն զեկույցի համար: Հարցը սա է. Դու մշտադիտարկում ես վճարումները, վերահսկում ես ծառայությունները, որոնց հետ շփվում ես... Բայց ինչպե՞ս ես վերահսկում, որ մարդ ինչ-որ կերպ գա քո վճարման էջ, վճարում կատարի, և նախագիծը նրան գումար փոխանցի։ Այսինքն՝ ինչպե՞ս եք վերահսկում, որ երթը հասանելի է և ընդունել է ձեր հետադարձ զանգը։

  EK: – «Վաճառականը» մեզ համար այս դեպքում ճիշտ նույն արտաքին ծառայությունն է, ինչ վճարային համակարգը: Մենք վերահսկում ենք վաճառականի արձագանքման արագությունը:

  Տվյալների բազայի կոդավորման մասին

  IN: - Բարեւ Ձեզ. Ես մի փոքր առնչվող հարց ունեմ. Դուք ունեք PCI DSS զգայուն տվյալներ: Ես ուզում էի իմանալ, թե ինչպես եք պահում PAN-ները հերթերում, որոնց մեջ պետք է տեղափոխեք: Դուք որևէ գաղտնագրում օգտագործու՞մ եք: Եվ սա հանգեցնում է երկրորդ հարցին՝ ըստ PCI DSS-ի, անհրաժեշտ է պարբերաբար վերագաղտնագրել տվյալների բազան փոփոխությունների դեպքում (ադմինիստրատորների հեռացում և այլն)՝ ի՞նչ է պատահում այս դեպքում հասանելիության հետ։

  
  
  EK: -Հրաշալի հարց! Նախ, մենք PAN-ները հերթերում չենք պահում: Մենք սկզբունքորեն իրավունք չունենք PAN-ը որևէ տեղ հստակ ձևով պահել, ուստի մենք օգտագործում ենք հատուկ ծառայություն (մենք այն անվանում ենք «Կադեմոն») - սա ծառայություն է, որն անում է միայն մեկ բան. այն հաղորդագրություն է ստանում որպես մուտքագրում և ուղարկում: դուրս կոդավորված հաղորդագրություն: Եվ մենք ամեն ինչ պահում ենք այս կոդավորված հաղորդագրությամբ: Համապատասխանաբար, մեր բանալին երկարությունը մեկ կիլոբայթի տակ է, այնպես որ սա լուրջ և հուսալի է:

  IN: – Ձեզ հիմա 2 կիլոբայթ է պետք:

  EK: – Կարծես թե հենց երեկ 256 էր... Դե, էլ որտե՞ղ։

  Ըստ այդմ՝ սա առաջինն է։ Եվ երկրորդ, լուծումը, որը գոյություն ունի, այն աջակցում է վերագաղտնագրման ընթացակարգին. կան երկու զույգ «keks» (բանալիներ), որոնք տալիս են «տախտակամածներ», որոնք գաղտնագրում են (բանալին բանալիներն են, dek-ը գաղտնագրող բանալիների ածանցյալներն են) . Եվ եթե ընթացակարգը սկսվում է (դա տեղի է ունենում կանոնավոր, 3 ամսից մինչև ± որոշ), մենք ներբեռնում ենք նոր զույգ «տորթեր», և մենք նորից կոդավորում ենք տվյալները: Մենք ունենք առանձին ծառայություններ, որոնք ջնջում են բոլոր տվյալները և գաղտնագրում դրանք նոր ձևով. Տվյալները պահվում են այն բանալի նույնացուցիչի կողքին, որով այն գաղտնագրված է: Համապատասխանաբար, հենց որ մենք կոդավորում ենք տվյալները նոր բանալիներով, մենք ջնջում ենք հին բանալին։

  Երբեմն վճարումները պետք է կատարվեն ձեռքով...

  IN: – Այսինքն, եթե ինչ-որ գործողության համար գումարի վերադարձ է եկել, դուք դեռ կոդավորում եք այն հին բանալիով:

  EK: - Այո:

  IN: -Հետո ևս մեկ փոքրիկ հարց. Երբ ինչ-որ ձախողում, անկում կամ միջադեպ է տեղի ունենում, անհրաժեշտ է ձեռքով իրականացնել գործարքը: Նման իրավիճակ կա.

  EK: - Այո երբեմն.

  IN: -Որտեղի՞ց եք դուք ստանում այս տվյալները: Թե՞ դուք ինքներդ եք գնում այս պահեստարան:

  EK: – Ոչ, լավ, իհարկե, մենք ունենք ինչ-որ back-office համակարգ, որը պարունակում է ինտերֆեյս մեր աջակցության համար: Եթե ​​մենք չգիտենք, թե ինչ կարգավիճակում է գործարքը (օրինակ, քանի դեռ վճարային համակարգը չի պատասխանել թայմաուտով), մենք a priori չգիտենք, այսինքն՝ վերջնական կարգավիճակը վերագրում ենք միայն լիարժեք վստահությամբ։ Այս դեպքում մենք գործարքը վերագրում ենք ձեռքով մշակման հատուկ կարգավիճակի: Առավոտյան, հաջորդ օրը, հենց որ աջակցությունը տեղեկատվություն է ստանում, որ այս կամ այն ​​գործարքները մնում են վճարային համակարգում, նրանք ձեռքով մշակում են դրանք այս ինտերֆեյսում:

  
  
  IN: -Մի երկու հարց ունեմ. Դրանցից մեկը PCI DSS գոտու շարունակությունն է. ինչպե՞ս եք գրանցում դրանց միացումը: Այս հարցը պայմանավորված է նրանով, որ մշակողը կարող էր որևէ բան տեղադրել տեղեկամատյաններում: Երկրորդ հարցը. ինչպե՞ս եք բացում թեժ շտկումները: Տվյալների բազայում բռնակներ օգտագործելը տարբերակներից մեկն է, բայց կարող են լինել անվճար թեժ շտկումներ. ի՞նչ ընթացակարգ է այնտեղ: Իսկ երրորդ հարցը, հավանաբար, կապված է RTO-ի, RPO-ի հետ։ Ձեր հասանելիությունը 99,97 էր, գրեթե չորս ինը, բայց ինչպես ես հասկացա, դուք ունեք երկրորդ տվյալների կենտրոն, երրորդ տվյալների կենտրոն և հինգերորդ տվյալների կենտրոն... Ինչպե՞ս եք դրանք համաժամացնում, կրկնօրինակում և մնացած ամեն ինչ:

  EK: - Սկսենք առաջինից. Առաջին հարցը գերանների մասին էր: Երբ մենք գրում ենք տեղեկամատյաններ, մենք ունենք շերտ, որը քողարկում է բոլոր զգայուն տվյալները: Նա նայում է դիմակին և լրացուցիչ դաշտերին: Համապատասխանաբար, մեր տեղեկամատյանները դուրս են գալիս արդեն դիմակավորված տվյալներով և PCI DSS սխեմայով: Սա թեստավորման բաժնին հանձնարարված կանոնավոր խնդիրներից է։ Նրանցից պահանջվում է ստուգել յուրաքանչյուր առաջադրանք, ներառյալ տեղեկամատյանները, որոնք նրանք գրում են, և սա սովորական առաջադրանքներից մեկն է կոդերի վերանայման ժամանակ, որպեսզի վերահսկեն, որ մշակողը ինչ-որ բան չի գրել: Սրա հետագա ստուգումները տեղեկատվական անվտանգության բաժնի կողմից պարբերաբար իրականացվում են շաբաթը մեկ անգամ. վերջին օրվա տեղեկամատյանները ընտրովի են վերցվում և դրանք անցնում են հատուկ սկաներ-անալիզատորի միջոցով թեստային սերվերներից՝ ամեն ինչ ստուգելու համար:
  Թեժ շտկումների մասին. Սա ներառված է մեր տեղակայման կանոնակարգում: Մենք ունենք առանձին դրույթ թեժ շտկումների վերաբերյալ: Մենք հավատում ենք, որ մենք գործարկում ենք թեժ շտկումներ շուրջօրյա, երբ դա մեզ անհրաժեշտ է: Հենց որ տարբերակը հավաքվում է, հենց այն գործարկվում, հենց որ մենք ունենում ենք արտեֆակտ, մենք ունենք հերթապահ համակարգի ադմինիստրատոր, որը զանգահարում է աջակցության կողմից, և նա այն տեղադրում է այն պահին, երբ դա անհրաժեշտ է:

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

  IN: - Եթե երկրորդն ես ստացել, ինչո՞ւ երրորդը չես ստացել: Որովհետև ոչ ոք դեռ ուղեղը չի բաժանել...

  EK: - Բայց մենք չունենք Պառակտված ուղեղ: Հաշվի առնելով այն հանգամանքը, որ յուրաքանչյուր հավելված ղեկավարվում է մուլտիմաստերի կողմից, մեզ համար նշանակություն չունի, թե որ կենտրոնում է հայտնվել հարցումը: Մենք պատրաստ ենք այն փաստին, որ եթե մեր տվյալների կենտրոններից մեկը ձախողվի (մենք հենվում ենք դրա վրա) և օգտագործողի հարցման կեսին անցնում է երկրորդ տվյալների կենտրոնին, մենք իսկապես պատրաստ ենք կորցնել այս օգտվողին. բայց դրանք կլինեն միավորներ, բացարձակ միավորներ։

  IN: - Բարի երեկո. Շնորհակալություն զեկույցի համար: Դուք խոսեցիք ձեր վրիպազերծիչի մասին, որն իրականացնում է որոշ փորձնական գործարքներ արտադրության մեջ: Բայց պատմեք մեզ թեստային գործարքների մասին: Որքա՞ն է այն խորանում:

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

  IN: -Որտե՞ղ եք կտրում: Այստեղ Core-ն ուղարկեց...

  EK: – Մենք այս դեպքում «Kor»-ի հետևում կանգնած ենք թեստային գործարքների համար... Մենք ունենք այնպիսի բան, ինչպիսին է երթուղին. «Kor»-ը գիտի, թե որ վճարային համակարգ ուղարկի. մենք ուղարկում ենք կեղծ վճարային համակարգ, որը պարզապես տալիս է http ազդանշան և այսքանը:

  IN: – Ասացեք, խնդրում եմ, ձեր դիմումը գրված է եղել մեկ հսկայական մոնոլիտով, թե՞ այն բաժանել եք որոշ ծառայությունների կամ նույնիսկ միկրոսերվիսների:

  EK: – Մենք մոնոլիտ չունենք, իհարկե, ունենք սպասարկման վրա հիմնված հավելված։ Մենք կատակում ենք, որ մեր ծառայությունը պատրաստված է մոնոլիտներից, դրանք իսկապես բավականին մեծ են: Դժվար է դա անվանել միկրոծառայություններ, բայց դրանք ծառայություններ են, որոնց շրջանակներում աշխատում են բաշխված մեքենաների աշխատողները:

  Եթե ​​սերվերի ծառայությունը վտանգված է...

  IN: -Այդ դեպքում ես ունեմ հաջորդ հարցը. Նույնիսկ եթե դա մոնոլիտ լիներ, դուք դեռ ասացիք, որ ունեք այս ակնթարթային սերվերներից շատերը, դրանք բոլորը հիմնականում մշակում են տվյալներ, և հարցն այն է. , ունե՞ն ինչ-որ մուտքի հսկողություն։ Նրանցից ով ինչ կարող է անել: Ո՞ւմ հետ կապվեմ, ի՞նչ տեղեկությունների համար:

  
  
  EK: -Այո, միանշանակ։ Անվտանգության պահանջները բավականին լուրջ են։ Նախ, մենք ունենք տվյալների բաց տեղաշարժեր, իսկ նավահանգիստները միայն այն նավահանգիստներն են, որոնց միջոցով մենք նախապես ակնկալում ենք երթևեկության տեղաշարժը։ Եթե ​​բաղադրիչը հաղորդակցվում է տվյալների բազայի հետ (ասենք, Muskul-ի հետ) 5-4-3-2-ի միջոցով, ապա նրա համար բաց կլինի միայն 5-4-3-2-ը, և այլ նավահանգիստներ և այլ երթևեկության ուղղություններ հասանելի չեն լինի: Բացի այդ, դուք պետք է հասկանաք, որ մեր արտադրության մեջ կան մոտ 10 տարբեր անվտանգության օղակներ: Եվ նույնիսկ եթե հավելվածը ինչ-որ կերպ վտանգի ենթարկվի, Աստված մի արասցե, հարձակվողը չի կարողանա մուտք գործել սերվերի կառավարման վահանակ, քանի որ սա այլ ցանցային անվտանգության գոտի է:

  IN: – Եվ այս համատեքստում ինձ համար առավել հետաքրքիրն այն է, որ դուք որոշակի պայմանագրեր ունեք ծառայությունների հետ՝ ինչ կարող են անել, ինչ «գործողությունների» միջոցով կարող են կապվել միմյանց հետ... Իսկ նորմալ հոսքի դեպքում որոշ կոնկրետ ծառայություններ որոշակի պահանջներ են տալիս։ շարքը, մյուս կողմից՝ «գործողությունների» ցուցակը: Նրանք կարծես թե չեն դիմում ուրիշներին նորմալ իրավիճակում, և նրանք ունեն պատասխանատվության այլ ոլորտներ: Եթե ​​դրանցից մեկը վտանգի ենթարկվի, կկարողանա՞ խաթարել այդ ծառայության «գործողությունները»։

  EK: - Ես հասկանում եմ. Եթե ​​նորմալ իրավիճակում այլ սերվերի հետ կապն ընդհանրապես թույլատրված էր, ապա այո։ Համաձայն SLA պայմանագրի, մենք չենք վերահսկում, որ ձեզ թույլ են տալիս միայն առաջին 3 «գործողությունները», և ձեզ թույլ չեն տալիս 4 «գործողությունները»: Սա, հավանաբար, մեզ համար ավելորդ է, քանի որ մենք արդեն ունենք 4 մակարդակի պաշտպանության համակարգ, սկզբունքորեն, սխեմաների համար: Մենք նախընտրում ենք պաշտպանվել ուրվագծերով, այլ ոչ թե ներսի մակարդակով։

  Ինչպես են աշխատում Visa-ն, MasterCard-ը և Sberbank-ը

  IN: – Ուզում եմ հստակեցնել մի կետ՝ օգտատերերին տվյալների կենտրոնից մյուսին անցնելու վերաբերյալ: Որքան գիտեմ, Visa-ն և MasterCard-ը գործում են 8583 երկուական համաժամանակյա պրոտոկոլով, և այնտեղ կան միքսեր: Եվ ես ուզում էի իմանալ, հիմա մենք նկատի ունենք անցումը՝ ուղղակիորեն «Visa» և «MasterCard», թե՞ վճարային համակարգերից առաջ, մինչև պրոցեսինգը:

  EK: -Սա միքսերից առաջ։ Մեր խառնուրդները գտնվում են նույն տվյալների կենտրոնում:

  IN: – Կոպիտ ասած, կապի մեկ կետ ունե՞ք։

  EK: – «Visa» և «MasterCard»՝ այո: Պարզապես այն պատճառով, որ Visa-ն և MasterCard-ը պահանջում են բավականին լուրջ ներդրումներ ենթակառուցվածքներում, որպեսզի կնքեն առանձին պայմանագրեր, օրինակ, երկրորդ զույգ խառնուրդներ ստանալու համար: Դրանք վերապահված են մեկ տվյալների կենտրոնի ներսում, բայց եթե Աստված մի արասցե մեր տվյալների կենտրոնը, որտեղ կան Visa-ի և MasterCard-ի հետ միանալու խառնուրդներ, մեռնի, ապա մենք կունենանք կապ կորած Visa-ի և MasterCard-ի հետ...

  IN: -Ինչպե՞ս կարելի է դրանք վերապահել: Ես գիտեմ, որ Visa-ն սկզբունքորեն թույլ է տալիս միայն մեկ կապ:

  EK: – Սարքավորումներն իրենք են մատակարարում։ Ամեն դեպքում, մենք ստացել ենք սարքավորումներ, որոնք ամբողջությամբ ավելորդ են ներսում։

  IN: – Այսինքն ստենդը իրենց Connects Orange-ից է:

  EK: - Այո:

  IN: – Բայց ինչ վերաբերում է այս դեպքին. եթե ձեր տվյալների կենտրոնը անհետանա, ինչպե՞ս կարող եք շարունակել օգտագործել այն: Թե՞ երթեւեկությունը պարզապես կանգ է առնում։

  EK: - Ոչ: Այս դեպքում մենք ուղղակի թրաֆիկը կփոխանցենք այլ ալիքի, որը, բնականաբար, ավելի թանկ կլինի մեզ համար և ավելի թանկ՝ մեր հաճախորդների համար։ Բայց երթևեկությունը չի անցնի Visa-ի, MasterCard-ի մեր անմիջական կապի միջոցով, այլ պայմանական Սբերբանկի միջոցով (շատ չափազանցված):

  Ես կատաղի ներողություն եմ խնդրում, եթե վիրավորել եմ Սբերբանկի աշխատակիցներին։ Բայց մեր վիճակագրության համաձայն, ռուսական բանկերի շարքում Սբերբանկը ամենից հաճախ ընկնում է: Մի ամիս չի անցնում, որ Սբերբանկում ինչ-որ բան չընկնի:

  
  
  

  Մի քանի գովազդ 🙂

  Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, ամպային VPS մշակողների համար $4.99-ից, մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. Ամբողջ ճշմարտությունը VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19 դոլարից կամ ինչպես կիսել սերվերը: (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):

  Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 հեռուստացույց $199-ից Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին Ինչպես կառուցել ենթակառուցվածքի կորպ. դաս՝ 730 եվրո արժողությամբ Dell R5xd E2650-4 v9000 սերվերների օգտագործմամբ մեկ կոպեկի համար:

Source: www.habr.com