Բոլորը խոսում են մշակման և փորձարկման գործընթացների, անձնակազմի վերապատրաստման, մոտիվացիայի բարձրացման մասին, բայց այս գործընթացները բավարար չեն, երբ ծառայության մեկ րոպեի դադարը արժենում է աստղաբաշխական գումարներ: Ի՞նչ անել, երբ ֆինանսական գործարքներ եք իրականացնում խիստ SLA-ի ներքո: Ինչպե՞ս բարձրացնել ձեր համակարգերի հուսալիությունը և խափանումների նկատմամբ հանդուրժողականությունը՝ հանելով մշակումն ու փորձարկումը հավասարումից:
Հաջորդ HighLoad++ կոնֆերանսը տեղի կունենա 6 թվականի ապրիլի 7-2020-ը Սանկտ Պետերբուրգում: Մանրամասները և տոմսերը՝ մինչև Նոյեմբերի 9, 18:00։ HighLoad++ Մոսկվա 2018, Դելի + Կալկաթայի դահլիճ։ Աբստրակտներ և .
Եվգենի Կուզովլև (այսուհետ՝ Է.Կ.). - Բարև ձեզ։ Իմ անունը Եվգենի Կուզովլև է։ Ես EcommPay-ից եմ, EcommPay IT ընկերությունների խմբի IT ստորաբաժանում։ Եվ այսօր մենք կխոսենք անսարքությունների մասին՝ ինչպես խուսափել դրանցից, ինչպես նվազագույնի հասցնել դրանց հետևանքները, եթե չեք կարողանում խուսափել դրանցից։ Թեման է՝ «Ի՞նչ անել, երբ անսարքության մեկ րոպեն արժե 100 դոլար»։ Առաջ նայելով՝ մեր թվերը համեմատելի են։
Ի՞նչ է անում EcommPay IT-ն։
Ո՞վ ենք մենք։ Ինչո՞ւ եմ ես կանգնած այստեղ՝ ձեր առջև։ Ինչո՞ւ եմ ես իրավունք ունեմ ձեզ այստեղ ինչ-որ բան ասելու։ Եվ ի՞նչ ենք մենք այստեղ ավելի մանրամասն քննարկելու։
EcommPay ընկերությունների խումբը միջազգային ձեռքբերող է: Մենք վճարումներ ենք մշակում ամբողջ աշխարհում՝ Ռուսաստանում, Եվրոպայում, Հարավարևելյան Ասիայում (ամբողջ աշխարհում): Մենք ունենք 9 գրասենյակ, ընդհանուր առմամբ 500 աշխատակից, և նրանց կեսից մի փոքր պակասը ՏՏ մասնագետներ են: Ամեն ինչ, ինչ մենք անում ենք, ամեն ինչ, ինչից մենք գումար ենք վաստակում, մենք ինքներս ենք արել:
Մենք ինքներս ենք գրել մեր բոլոր արտադրանքները (և մենք բավականին շատ ունենք դրանք՝ մեր խոշոր IT արտադրանքի շարքում մենք ունենք մոտ 16 տարբեր բաղադրիչներ). մենք ինքներս ենք գրում դրանք, մենք ինքներս ենք մշակում դրանք։ Եվ այս պահին մենք օրական իրականացնում ենք մոտ մեկ միլիոն գործարք (միլիոններ՝ դա, հավանաբար, ճիշտ բառն է)։ Մենք բավականին երիտասարդ ընկերություն ենք՝ մենք ընդամենը մոտ վեց տարեկան ենք։
6 տարի առաջ դա ստարտափ էր, երբ տղաները եկան բիզնեսով։ Նրանց միավորեց գաղափարը (գաղափարից բացի ուրիշ ոչինչ չկար), և մենք վազեցինք։ Ինչպես ցանկացած ստարտափ, մենք ավելի արագ վազեցինք... Մեզ համար արագությունն ավելի կարևոր էր, քան որակը։
Ինչ-որ պահի մենք կանգ առանք. մենք հասկացանք, որ այլևս չենք կարող ապրել այդ արագությամբ և որակով, և որ առաջին հերթին պետք է զբաղվենք որակով։ Այդ պահին մենք որոշեցինք գրել նոր հարթակ, որը կլինի ճիշտ, մասշտաբային և հուսալի։ Մենք սկսեցինք գրել այս հարթակը (մենք սկսեցինք ներդրումներ կատարել, մշակել և փորձարկել), բայց ինչ-որ պահի հասկացանք, որ մշակումն ու փորձարկումը թույլ չեն տալիս մեզ հասնել ծառայությունների որակի նոր մակարդակի։
Դուք ստեղծում եք նոր ապրանք, այն դնում եք արտադրության մեջ, բայց միևնույն է, ինչ-որ տեղ ինչ-որ բան այնպես չի գնում։ Եվ այսօր մենք կխոսենք այն մասին, թե ինչպես հասնել որակի նոր մակարդակի (ինչպես ենք դա արել, մեր փորձի մասին), հանելով մշակումն ու փորձարկումը հավասարումից։ Մենք կխոսենք այն մասին, թե ինչ է հասանելի շահագործման համար՝ ինչ կարող է անել գործողությունն ինքնին, ինչ կարող է առաջարկել փորձարկմանը՝ որակի վրա ազդելու համար։
Անգործության ժամանակներ։ Շահագործման պատվիրաններ։
Այսօր մենք միշտ խոսելու ենք հիմնական անկյունաքարի մասին՝ անգործության ժամանակը։ Սարսափելի բառ է։ Եթե մենք անգործության ժամանակ ունենք, ամեն ինչ վատ է մեզ համար։ Մենք վազում ենք այն միացնելու, ադմինիստրատորները պահում են սերվերը. Աստված մի արասցե, որ այն ընկնի, ինչպես երգում են այդ երգում։ Ահա թե ինչի մասին ենք մենք այսօր խոսելու։
Երբ սկսեցինք փոխել մեր մոտեցումները, մենք ձևավորեցինք 4 պատվիրան։ Ես դրանք ներկայացրել եմ սլայդների վրա։
Այս պատվիրանները բավականին պարզ են.
- Արագորեն նույնականացրեք խնդիրը։
- Ազատվեք դրանից նույնիսկ ավելի արագ։
- Օգնեք հասկանալ պատճառը (հետագայում՝ մշակողների համար):
- Եվ ստանդարտացրեք մոտեցումները։
Թույլ տվեք ձեր ուշադրությունը հրավիրել #2 կետի վրա։ Մենք ազատվում ենք խնդրից, այլ ոչ թե լուծում ենք այն։ Դրա լուծումը երկրորդական է։ Մեզ համար առաջնայինն այն է, որ օգտատերը պաշտպանված լինի այս խնդրից։ Այն կգոյություն ունենա որոշակի մեկուսացված միջավայրում, բայց այս միջավայրը որևէ կերպ չի կապվի նրա հետ։ Իրականում մենք կանդրադառնանք խնդիրների այս չորս խմբերին (ոմանք՝ ավելի մանրամասն, ոմանք՝ ավելի քիչ մանրամասն), ես ձեզ կասեմ, թե ինչ ենք օգտագործում, ինչ փորձ ունենք լուծումների հարցում։
Խնդիրների լուծում. Ե՞րբ են դրանք տեղի ունենում և ի՞նչ անել դրանց հետ կապված։
Բայց մենք կսկսենք հերթականությամբ, կսկսենք #2 կետից՝ ինչպե՞ս արագ ազատվել խնդրից։ Կա խնդիր՝ մենք պետք է այն վերացնենք։ «Ի՞նչ պետք է անենք դրա հետ»՝ գլխավոր հարցը։ Եվ երբ մենք սկսեցինք մտածել, թե ինչպես վերացնել խնդիրը, մենք մեզ համար մշակեցինք որոշ պահանջներ, որոնց պետք է հաջորդի խնդիրների վերացումը։
Այս պահանջները ձևակերպելու համար մենք որոշեցինք ինքներս մեզ հարցնել. «Ե՞րբ ենք մենք խնդիրներ ունենում»: Եվ խնդիրները, ինչպես պարզվեց, առաջանում են չորս դեպքում.
- Սարքավորումների ձախողում։
- Արտաքին ծառայությունների ձախողում։
- Ծրագրային ապահովման տարբերակի փոփոխություն (նույն տեղակայումը):
- Բեռի պայթյունավտանգ աճ։
Մենք չենք խոսի առաջին երկուսի մասին։ Սարքավորումների խափանումը լուծվում է բավականին պարզ. դուք պետք է ամեն ինչ կրկնօրինակեք։ Եթե սրանք սկավառակներ են, սկավառակները պետք է հավաքվեն RAID-ում, եթե սա սերվեր է, սերվերը պետք է կրկնօրինակվի, եթե դուք ունեք ցանցային ենթակառուցվածք, դուք պետք է տեղադրեք ցանցային ենթակառուցվածքի երկրորդ պատճենը, այսինքն՝ դուք վերցնում և կրկնօրինակում եք։ Եվ եթե ինչ-որ բան խափանվում է, դուք անցնում եք պահուստային հզորությունների։ Այստեղ դժվար է ավելին ասել։
Երկրորդը՝ արտաքին ծառայությունների խափանումն է։ Համակարգերի մեծ մասի համար սա ընդհանրապես խնդիր չէ, բայց ոչ մեզ համար։ Քանի որ մենք վճարումներ ենք մշակում, մենք ագրեգատոր ենք, որը կանգնած է օգտատիրոջ (ով մուտքագրում է իր քարտի տվյալները) և բանկերի, վճարային համակարգերի (Visa, MasterCard, Mira և այլն) միջև։ Մեր արտաքին ծառայությունները (վճարային համակարգեր, բանկեր) հակված են խափանվել։ Ո՛չ մենք, ո՛չ էլ դուք (եթե ունեք նման ծառայություններ) չեք կարող ազդել դրա վրա։
Ի՞նչ անել այդ դեպքում։ Կան երկու տարբերակ։ Նախ, եթե կարող եք, պետք է ինչ-որ կերպ կրկնօրինակեք այս ծառայությունը։ Օրինակ, եթե կարող ենք, մենք տեղափոխում ենք տրաֆիկը մեկ ծառայությունից մյուսը. օրինակ, մենք մշակում ենք քարտեր Սբերբանկի միջոցով, Սբերբանկն ունի խնդիրներ՝ մենք [պայմանականորեն] տեղափոխում ենք տրաֆիկը Raiffeisen-ին։ Երկրորդ բանը, որ մենք կարող ենք անել, շատ արագ նկատել արտաքին ծառայությունների խափանումը, ուստի արձագանքման արագության մասին կխոսենք զեկույցի հաջորդ մասում։
Իրականում, այս չորսից մենք կարող ենք կոնկրետ ազդել ծրագրային ապահովման տարբերակների փոփոխության վրա՝ ձեռնարկել գործողություններ, որոնք կհանգեցնեն բարելավման տեղակայումների համատեքստում և բեռի պայթյունային աճի համատեքստում: Իրականում մենք դա արեցինք: Ահա, կրկին, մի փոքր դիտողություն ...
Այս չորս խնդիրներից մի քանիսը անմիջապես լուծվում են, եթե դուք ունեք ամպային ծառայություն։ Եթե դուք գտնվում եք Microsoft Azure-ի, Ozon-ի ամպերում, օգտագործում եք մեր ամպերը, Yandex-ը կամ Mail-ը, ապա առնվազն սարքային խափանումը դառնում է նրանց խնդիրը, և սարքային խափանման համատեքստում ամեն ինչ անմիջապես լավ է դառնում ձեզ համար։
Մենք մի փոքր ոչ ստանդարտ ընկերություն ենք։ Այստեղ բոլորը խոսում են Kubernetes-ի, ամպերի մասին. մենք ո՛չ Kubernetes ունենք, ո՛չ էլ ամպեր։ Բայց մենք ունենք սարքավորումների դարակներ շատ տվյալների կենտրոններում, և մենք ստիպված ենք ապրել այս սարքավորումներով, մենք ստիպված ենք պատասխանատու լինել այս ամենի համար։ Հետևաբար, մենք կխոսենք այս համատեքստում։ Այսպիսով, խնդիրների մասին։ Առաջին երկուսը բաց են թողնված։
Ծրագրային ապահովման տարբերակի փոփոխություն։ Հիմունքներ
Մեր մշակողները մուտք չունեն արտադրության։ Ինչո՞ւ։ Մենք PCI DSS հավաստագրված ենք, և մեր մշակողները պարզապես իրավունք չունեն մտնել արտադրության մեջ։ Այսքանը, վերջ։ Անկասկած։ Հետևաբար, մշակողի պատասխանատվությունն ավարտվում է հենց այն պահին, երբ մշակողը փոխանցել է կառուցվածքը թողարկման համար։
Մեր երկրորդ հիմքը, որը մենք ունենք և որը նույնպես շատ է օգնում մեզ, եզակի չփաստաթղթավորված գիտելիքների բացակայությունն է։ Հուսով եմ՝ դուք նույնն ունեք։ Որովհետև եթե դուք չունեք, խնդիրներ կունենաք։ Խնդիրներ կառաջանան, երբ այս եզակի չփաստաթղթավորված գիտելիքները ճիշտ ժամանակին և ճիշտ տեղում չեն լինի։ Ենթադրենք, որ դուք ունեք մեկ անձ, ով գիտի, թե ինչպես տեղակայել որոշակի բաղադրիչ՝ անձը տեղում չէ, նա արձակուրդում է կամ հիվանդ է, այսքանը, դուք խնդիրներ ունեք։
Եվ երրորդ հիմքը, որին մենք հասանք։ Մենք դրան հասանք ցավի, արյան, արցունքների միջով. մենք եկանք այն եզրակացության, որ մեր ցանկացած կառուցվածք պարունակում է սխալներ, նույնիսկ եթե այն սխալներից զերծ է։ Մենք ինքներս որոշեցինք. երբ մենք ինչ-որ բան տեղակայում ենք, երբ ինչ-որ բան ներմուծում ենք արտադրության մեջ, մենք ունենք սխալներով կառուցվածք։ Մենք ձևավորեցինք այն պահանջները, որոնք մեր համակարգը պետք է բավարարի։
Ծրագրային ապահովման տարբերակը փոխելու պահանջները
Այս պահանջներից երեքը կան.
- Մենք պետք է արագ հետ վերցնենք տեղակայումը։
- Մենք պետք է նվազագույնի հասցնենք անհաջող տեղակայման հետևանքները։
- Եվ մենք պետք է կարողանանք արագ տեղակայվել զուգահեռաբար։
Այդ հերթականությամբ։ Ինչո՞ւ։ Որովհետև, նախևառաջ, նոր տարբերակ տեղակայելիս արագությունը կարևոր չէ, բայց կարևոր է, որ դուք արագորեն հետ գնաք նախորդ տարբերակից և նվազագույն ազդեցություն ունենաք, եթե ինչ-որ բան այնպես չգնա։ Բայց եթե արտադրության մեջ ունեք տարբերակների մի ամբողջություն, որոնց համար պարզվում է, որ կա սխալ (պատահաբար տեղակայում չի եղել, բայց սխալը կա), ապա ձեզ հետաքրքրում է հաջորդ տեղակայման արագությունը։ Ի՞նչ արեցինք մենք այս պահանջները բավարարելու համար։ Մենք դիմեցինք հետևյալ մեթոդաբանությանը.
Սա բավականին հայտնի է, մենք այն ընդհանրապես չենք հորինել՝ դա Կապույտ/Կանաչ տեղակայումն է։ Ի՞նչ է դա։ Դուք պետք է ունենաք պատճեն սերվերների յուրաքանչյուր խմբի համար, որտեղ գտնվում են ձեր ծրագրերը։ Պատճենը «տաք» է. դրա վրա երթևեկություն չկա, բայց ցանկացած պահի այս երթևեկությունը կարող է ուղարկվել այս պատճենին։ Այս պատճենը պարունակում է նախորդ տարբերակը։ Եվ տեղակայման պահին դուք տեղադրում եք կոդը ոչ ակտիվ պատճենի վրա։ Այնուհետև երթևեկության մի մասը (կամ ամբողջը) տեղափոխում եք նոր տարբերակի։ Այսպիսով, երթևեկության հոսքը հին տարբերակից նորը փոխելու համար անհրաժեշտ է անել միայն մեկ բան. անհրաժեշտ է փոխել վերևի հոսքում գտնվող հավասարակշռիչը, փոխել ուղղությունը՝ մեկ վերևի հոսքից մյուսը։ Սա շատ հարմար է և լուծում է արագ անցման, արագ հետադարձման խնդիրը։Ահա երկրորդ հարցի՝ մինիմալացման լուծումը. դուք կարող եք ձեր տրաֆիկի միայն մի մասը (ասենք՝ 2%) ուղարկել նոր տող, նոր կոդով տող։ Եվ այդ 2%-ը 100% չէ։ Եթե դուք կորցնում եք տրաֆիկի 100%-ը անհաջող տեղակայման պատճառով՝ դա վախենալու է, եթե կորցնում եք տրաֆիկի 2%-ը՝ դա տհաճ է, բայց վախենալու չէ։ Ավելին, օգտատերերը, ամենայն հավանականությամբ, նույնիսկ չեն նկատի դա, քանի որ որոշ դեպքերում (ոչ բոլոր դեպքերում) նույն օգտատերը, F5 սեղմելով, կհասնի մեկ այլ, աշխատող տարբերակի։
Կապույտ/կանաչ տեղակայում։ Ուղղորդում
Սակայն, դա այնքան էլ պարզ չէ, որքան «Կապույտ/Կանաչ տեղակայելը»... Մեր բոլոր բաղադրիչները կարելի է բաժանել երեք խմբի՝
- սա է առջևի մասը (վճարման էջերը, որոնք տեսնում են մեր հաճախորդները)։
- մշակման միջուկ;
- ադապտեր վճարային համակարգերի հետ աշխատելու համար (բանկեր, MasterCard, Visa և այլն):
Եվ այստեղ կա մի նրբերանգ՝ նրբերանգը գծերի միջև երթուղայնացման մեջ է։ Եթե պարզապես փոխեք երթևեկության 100%-ը, այս խնդիրները չեք ունենա։ Բայց եթե ուզում եք փոխարկել 2%-ը, սկսում եք հարցեր տալ. «Ինչպե՞ս դա անել»։ Ամենապարզը՝ ուղիղ կետին անցնելը. կարող եք nginx-ում պատահական ընտրություն կատարել՝ Round Robin, և կունենաք 2%-ը ձախ, 98%-ը՝ աջ։ Բայց սա միշտ չէ, որ հարմար է։
Օրինակ, մեր դեպքում օգտատերը փոխազդում է համակարգի հետ մեկից ավելի հարցումներով։ Սա նորմալ է. 2, 3, 4, 5 հարցում՝ ձեր համակարգերը կարող են նույնը լինել։ Եվ եթե ձեզ համար կարևոր է, որ բոլոր օգտատիրոջ հարցումները գան նույն տողում, որտեղից եկել է առաջին հարցումը, կամ (երկրորդ կետ) բոլոր օգտատիրոջ հարցումները գան նոր տող անցումից հետո (նա կարող էր սկսել աշխատել համակարգի հետ ավելի վաղ՝ անցումից առաջ), ապա այս պատահական բաշխումը ձեզ չի համապատասխանում։ Այդ դեպքում կան հետևյալ տարբերակները.
Առաջին տարբերակը, ամենապարզը, հիմնված է հաճախորդի հիմնական պարամետրերի վրա (IP Hash): Դուք ունեք IP, և այն բաժանում եք ձախ և աջ IP-ի վրա: Այնուհետև ձեզ համար կաշխատի իմ նկարագրած երկրորդ դեպքը. երբ տեղակայումը տեղի ունենա, օգտատերը կարող է արդեն սկսել աշխատել ձեր համակարգի հետ, և տեղակայման պահից բոլոր հարցումները կգնան նոր տող (ասենք՝ նույն տողին):Եթե ինչ-ինչ պատճառներով սա ձեզ չի համապատասխանում և դուք պետք է հարցումներ ուղարկեք այն տողին, որտեղից եկել է օգտատիրոջ սկզբնական հարցումը, ապա դուք ունեք երկու տարբերակ...
Առաջին տարբերակը՝ կարող եք վերցնել վճարովի nginx+: Այն ունի Sticky sessions կոչվող մեխանիզմ, որը օգտատիրոջ սկզբնական հարցման դեպքում ստեղծում է սեսիա օգտատիրոջ համար և կապում այն մեկ կամ մեկ այլ վերին հոսանքի հետ: Սեսիայի ողջ ընթացքում օգտատիրոջ բոլոր հետագա հարցումները կուղարկվեն նույն վերին հոսանքին, որտեղ սեսիան կարգավորվել է:Սա մեզ մոտ չաշխատեց, քանի որ մենք արդեն ունեինք սովորական nginx: Nginx+-ին անցնելը պայմանավորված չէր նրանով, որ թանկ է, պարզապես մի փոքր ցավոտ էր մեզ համար և ոչ այնքան ճիշտ: Օրինակ, Sticky Sessions-ը մեզ մոտ չաշխատեց այն պարզ պատճառով, որ Sticky Sessions-ը թույլ չի տալիս երթուղայնացում «Either-Or»-ի հիման վրա: Այնտեղ կարող եք նշել, թե ինչ է անում Sticky Sessions-ը, օրինակ՝ IP-ով կամ IP-ով և cookie-ներով, կամ էլ փոստային պարամետրով, բայց «Either-Or»-ն ավելի բարդ է:
Ահա թե ինչու մենք եկանք չորրորդ տարբերակին։ Մենք nginx-ը վերցրեցինք «ստերոիդների» վրա (սա openresty է)՝ սա նույն nginx-ն է, որը լրացուցիչ աջակցում է last scripts-ի ներառմանը։ Դուք կարող եք գրել last script, այն տեղափոխել «openresty» ռեժիմ, և այս last script-ը կկատարվի, երբ օգտատիրոջ հարցումը գա։
Եվ մենք իրականում գրեցինք նման սկրիպտ, սահմանեցինք մեզ «openrest» և այս սկրիպտում անցում ենք կատարում 6 տարբեր պարամետրերով՝ «Կամ» միացնելով։ Կախված այս կամ այն պարամետրի առկայությունից, մենք գիտենք, որ օգտատերը հասել է այս կամ այն էջին, այս կամ այն տողին։
Կապույտ/կանաչ տեղակայում։ Առավելություններ և թերություններ
Իհարկե, դա, հավանաբար, կարելի էր մի փոքր ավելի հեշտ անել (օգտագործելով նույն «Stick Sessions»-ը), բայց մենք ունենք նաև այս նրբերանգը, որ ոչ միայն օգտատերն է մեզ հետ փոխազդում մեկ գործարքի մշակման շրջանակներում… Այլև վճարային համակարգերը նույնպես փոխազդում են մեզ հետ. գործարքը մշակելուց հետո (վճարային համակարգին հարցում ուղարկելով), մենք ստանում ենք սառեցման հրաման։
Եվ ասենք, եթե մեր սխեմայի ներսում մենք կարող ենք փոխանցել օգտատիրոջ IP-ն բոլոր հարցումներում և բաժանել օգտատերերին IP-ի հիման վրա, ապա նույն Visa-ին չենք ասի. «Տղերք, մենք այնքան ռետրո ընկերություն ենք, մենք մի տեսակ միջազգային ենք (կայքում և Ռուսաստանում)... Բայց խնդրում եմ, մեզ փոխանցեք օգտատիրոջ IP-ն լրացուցիչ դաշտում, ձեր արձանագրությունը ստանդարտացված է»! Իհարկե, նրանք չեն համաձայնվի։
Այսպիսով, դա մեզ մոտ չաշխատեց՝ մենք ստեղծեցինք openresty: Հետևաբար, routing-ի միջոցով ստացանք հետևյալը.Կապույտ/կանաչ տեղակայումը, համապատասխանաբար, ունի իմ նշած առավելություններն ու թերությունները։
Կան երկու թերություններ.
- դուք պետք է անհանգստանաք երթուղայնացման հետ կապված։
- Երկրորդ էական թերությունը ծախսն է։
Ձեզ անհրաժեշտ է կրկնակի շատ սերվերներ, ձեզ անհրաժեշտ է կրկնակի շատ գործառնական ռեսուրսներ, դուք պետք է կրկնակի շատ ջանք ծախսեք այս ամբողջ կենդանաբանական այգին պահպանելու համար։
Ի դեպ, առավելությունների շարքում կա ևս մեկ բան, որի մասին ես նախկինում չեմ խոսել. դուք ունեք ռեզերվ բեռի աճի դեպքում: Եթե դուք ունեք բեռի պայթյունավտանգ աճ, ձեզ մոտ են եկել մեծ թվով օգտատերեր, ապա դուք պարզապես ներառում եք երկրորդ տողը 50/50 բաշխման մեջ, և ձեր կլաստերում անմիջապես կունենաք x2 սերվեր, մինչև չլուծեք ավելի շատ սերվերներ ունենալու խնդիրը:
Ինչպե՞ս արագ տեղակայում իրականացնել։
Մենք խոսել ենք այն մասին, թե ինչպես լուծել նվազագույնի հասցնելու և արագ հետադարձելու խնդիրը, բայց հարցը մնում է. «Ինչպե՞ս արագ տեղակայել»։
Այստեղ ամեն ինչ հակիրճ և պարզ է։- Դուք պետք է ունենաք CD համակարգ (շարունակական մատակարարում). առանց դրա չեք կարող անել։ Եթե ունեք մեկ սերվեր, կարող եք տեղակայել ձեռքով։ Մենք ունենք մոտ մեկուկես հազար սերվեր և մեկուկես հազար՝ ձեռքով, դա պարզ է՝ կարող ենք այս դահլիճի չափ բաժին տեղադրել պարզապես տեղակայելու համար։
- Տեղակայումը պետք է լինի զուգահեռ։ Եթե ձեր տեղակայումը հաջորդական է, ապա ամեն ինչ վատ է։ Մեկ սերվերը լավ է, դուք ամբողջ օրը կտեղակայեք մեկուկես հազար սերվեր։
- Կրկին, արագության համար սա, հավանաբար, անհրաժեշտ չէ: Տեղակայման ժամանակ նախագիծը սովորաբար հավաքվում է: Դուք ունեք վեբ նախագիծ, կա առջևի մաս (դուք այնտեղ ստեղծում եք վեբ փաթեթ, կառուցում եք npm՝ նման մի բան), և այս գործընթացը հիմնականում կարճ է՝ 5 րոպե, բայց այս 5 րոպեները կարող են կարևոր լինել: Ահա թե ինչու մենք, օրինակ, դա այսպես չենք անում. մենք հեռացնում ենք այս 5 րոպեները, մենք տեղակայում ենք արտեֆակտները:
Ի՞նչ է արտեֆակտը։ Արտեֆակտը կոմպիլացված կառուցվածք է, որի ամբողջ ասեմբլերի մասն արդեն ավարտված է։ Մենք այս արտեֆակտը պահում ենք արտեֆակտների պահոցում։ Մենք միաժամանակ օգտագործել ենք երկու նման պահոց՝ Nexus-ը և այժմ՝ jFrog Artifactory-ն։ Սկզբում մենք օգտագործել ենք Nexus-ը, քանի որ սկսել ենք այս մոտեցումը կիրառել Java ծրագրերում (այն լավ էր հարմար դրա համար)։ Այնուհետև մենք այնտեղ տեղադրեցինք PHP-ով գրված մի քանի ծրագրեր, և Nexus-ը այլևս հարմար չէր, և այդ պատճառով մենք ընտրեցինք jFrog Artefactory-ն, որը կարող է գրեթե ամեն ինչ ձևակերպել։ Մենք նույնիսկ հասանք այն կետին, որ այս արտեֆակտների պահոցում պահում ենք մեր սեփական բինար փաթեթները, որոնք մենք կոմպիլացնում ենք սերվերների համար։
Բեռի պայթյունային աճ
Մենք խոսեցինք ծրագրային ապահովման տարբերակը փոխելու մասին։ Հաջորդը, ինչ մենք ունեցանք, բեռի պայթյունային աճն է։ Այստեղ, ես հավանաբար հասկանում եմ, որ բեռի պայթյունային աճը այդքան էլ ճիշտ բան չէ…
Մենք գրեցինք նոր համակարգ՝ այն ծառայությունների վրա կենտրոնացած է, նորաձև, գեղեցիկ, աշխատողներ ամենուրեք, հերթեր ամենուրեք, ասինխրոն ամենուրեք։ Եվ նման համակարգերում տվյալները կարող են անցնել տարբեր հոսքերով։ Առաջին գործարքի համար կարող է ներգրավվել 1-ին, 3-րդ, 10-րդ աշխատողը, երկրորդ գործարքի համար՝ 2-րդ, 4-րդ, 5-րդը։ Եվ այսօր, ենթադրենք, առավոտյան դուք ունեք տվյալների հոսք, որը ներառում է առաջին երեք աշխատողներին, իսկ երեկոյան այն կտրուկ փոխվում է, և ամեն ինչ ներգրավում է մյուս երեք աշխատողներին։
Եվ ահա պարզվում է, որ դուք պետք է ինչ-որ կերպ մասշտաբավորեք աշխատողների թիվը, պետք է ինչ-որ կերպ մասշտաբավորեք ձեր ծառայությունները, բայց միևնույն ժամանակ թույլ չտաք ռեսուրսների չափազանց մեծացում։
Մենք մեզ համար սահմանեցինք պահանջները։ Այս պահանջները բավականին պարզ են. պետք է լինի ծառայության հայտնաբերում, պարամետրացում՝ ամեն ինչ ստանդարտ է նման մասշտաբային համակարգեր կառուցելու համար, բացառությամբ մեկ կետի՝ ռեսուրսների արժեզրկման։ Մենք ասացինք, որ պատրաստ չենք արժեզրկել ռեսուրսները, որպեսզի սերվերները տաքացնեն օդը։ Մենք վերցրեցինք «Consul»-ը, վերցրեցինք «Nomad»-ը, որը կառավարում է մեր աշխատողներին։Ինչո՞ւ է սա մեզ համար խնդիր։ Թույլ տվեք մի փոքր հետ կանգնել։ Այժմ մենք ունենք մոտ 70 վճարային համակարգ։ Առավոտյան երթևեկությունն անցնում է Սբերբանկով, ապա, օրինակ, Սբերբանկը անջատվում է, և մենք այն անցում ենք կատարում մեկ այլ վճարային համակարգի։ Սբերբանկից առաջ մենք ունեինք 100 աշխատող, իսկ դրանից հետո մենք պետք է արագ 100 աշխատող հավաքագրենք մեկ այլ վճարային համակարգի համար։ Եվ ցանկալի է, որ այս ամենը տեղի ունենա առանց մարդկային միջամտության։ Որովհետև եթե կա մարդկային միջամտություն, այնտեղ պետք է լինի ինժեներ 24/7, որը պետք է զբաղվի միայն դա, քանի որ նման խափանումները, երբ ձեր հետևում կա 70 համակարգ, պարբերաբար են լինում։
Այսպիսով, մենք նայեցինք Nomad-ին, որն ունի բաց IP, և գրեցինք մեր սեփականը՝ Scale-Nomad – ScaleNo-ն, որն անում է հետևյալը. այն վերահսկում է հերթի աճը և կրճատում կամ ավելացնում աշխատողների թիվը՝ կախված հերթի փոփոխության դինամիկայից: Երբ մենք դա արեցինք, մտածեցինք. «Գուցե պետք է այն բաց կոդով դարձնենք»: Հետո նայեցինք դրան. այն այնքան պարզ է, որքան երկու կոպեկ:
Մենք դեռ այն բաց կոդով չենք դարձրել, բայց եթե հաշվետվությունից հետո, հասկանալով, որ ձեզ նման բան է պետք, հանկարծակի դրա կարիքը ունենաք, իմ կոնտակտները վերջին սլայդում են՝ խնդրում եմ գրեք ինձ։ Եթե մեզ միանա առնվազն 3-5 մարդ՝ մենք այն կբաց կոդով կդարձնենք։
Ինչպե՞ս է այն աշխատում։ Տեսնենք։ Առաջ նայելով՝ ձախ կողմում մեր մոնիթորինգի մի մասն է. սա մեկ տող է, վերևում՝ իրադարձության մշակման ժամանակը, մեջտեղում՝ գործարքների քանակը, ներքևում՝ աշխատողների քանակը։Եթե նայեք, այս նկարում կա խափանում։ Վերին գրաֆիկում գրաֆիկներից մեկը 45 վայրկյանում խափանվեց՝ վճարային համակարգերից մեկը անջատվեց։ 2 րոպեով երևաց նաև երթևեկությունը, և հերթը սկսեց մեծանալ մեկ այլ վճարային համակարգում, որտեղ աշխատողներ չկային (մենք չէինք օգտագործում ռեսուրսները՝ ընդհակառակը, մենք ճիշտ էինք օգտագործում ռեսուրսը)։ Մենք չէինք ուզում տաքացնել՝ աշխատողների նվազագույն թիվ կար՝ մոտ 5-10, բայց նրանք չկարողացան հաղթահարել։
Վերջին գրաֆիկը ցույց է տալիս «կուզ», որը պարզապես ասում է, որ «Սկալենոն» այս թիվը կրկնապատկել է։ Եվ հետո, երբ գրաֆիկը մի փոքր իջել է, այն մի փոքր նվազել է՝ աշխատողների թիվը ավտոմատ կերպով փոխվել է։ Ահա թե ինչպես է այս բանը գործում։ Մենք խոսեցինք #2 կետի մասին՝ «Ինչպես արագորեն ազատվել պատճառներից»։
Մոնիթորինգ։ Ինչպե՞ս արագորեն բացահայտել խնդիրը։
Հիմա առաջին կետն է՝ «Ինչպե՞ս արագորեն բացահայտել խնդիրը»։ Մոնիթորինգ։ Մենք պետք է արագ հասկանանք որոշակի բաներ։ Ի՞նչ բաներ պետք է արագ հասկանանք։
Երեք բան!- Մենք պետք է արագ հասկանանք և արագորեն հասկանանք մեր սեփական ռեսուրսների արդյունավետությունը։
- Մենք պետք է արագ հասկանանք խափանումները և վերահսկենք մեզանից դուրս գտնվող համակարգերի աշխատանքը։
- Երրորդ կետը տրամաբանական սխալների հայտնաբերումն է։ Սա այն դեպքն է, երբ համակարգը ձեզ համար աշխատում է, բոլոր ցուցանիշներով ամեն ինչ կարգին է, բայց ինչ-որ բան այն չէ։
Այստեղ ես հավանաբար շատ հետաքրքիր բաներ չեմ պատմի։ Ես կլինեմ Կապիտան Ակնհայտը։ Մենք փնտրում էինք շուկայում եղածը։ Մենք ունեինք «զվարճալի կենդանաբանական այգի»։ Ահա թե ինչ կենդանաբանական այգի ունենք հիմա։
Մենք օգտագործում ենք Zabbix-ը սարքավորումների, սերվերի հիմնական ցուցիչների մոնիթորինգի համար։ Մենք օգտագործում ենք OkMeter-ը տվյալների բազաների համար։ Մենք օգտագործում ենք Grafana-ն և Prometheus-ը բոլոր մյուս ցուցիչների համար, որոնք չեն համապատասխանում առաջին երկուսին, և դրանցից մի քանիսը Grafana-ի և Prometheus-ի հետ, իսկ մի քանիսը Grafana-ի հետ Influx-ի և Telegraf-ի հետ։Մեկ տարի առաջ մենք ուզում էինք օգտագործել New Relic-ը։ Այն հիանալի բան է, այն կարող է անել ամեն ինչ։ Բայց որքան էլ որ այն կարող է անել ամեն ինչ, այն նաև թանկ է։ Երբ մենք հասանք 1,5 հազար սերվերի ծավալի, մեզ մոտ եկավ մի մատակարար և ասաց. «Եկեք պայմանագիր կնքենք հաջորդ տարվա համար»։ Մենք նայեցինք գինը և ասացինք. «Ոչ, մենք դա չենք անի»։ Հիմա մենք հրաժարվում ենք New Relic-ից, մեզ մոտ մոտ 15 սերվեր է մնացել New Relic-ի հսկողության տակ։ Գինը բացարձակապես անհավանական էր։
Եվ կա մեկ գործիք, որը մենք ինքներս ենք ներդրել՝ դա Debugger-ն է։ Սկզբում մենք այն անվանում էինք «Bagger», բայց հետո մի անգլերենի ուսուցիչ եկավ, վայրի ծիծաղեց և վերանվանեց այն «Debugger»։ Ի՞նչ է դա։ Դա մի գործիք է, որը, ըստ էության, յուրաքանչյուր բաղադրիչի վրա 15-30 վայրկյանում, որպես համակարգի «սև արկղ», թեստեր է անցկացնում բաղադրիչի ընդհանուր աշխատանքի համար։
Օրինակ, եթե դա արտաքին էջ է (վճարման էջ), նա պարզապես բացում է այն և նայում, թե ինչ տեսք պետք է ունենա։ Եթե այն մշակվում է, նա գործարկում է փորձնական «գործարք»՝ ստուգում է, որ այս «գործարքը» հասնի իր նպատակին։ Եթե դա կապ է վճարային համակարգերի հետ, մենք համապատասխանաբար գործարկում ենք փորձնական հարցում, որտեղ հնարավոր է, և ստուգում ենք, որ մեզ մոտ ամեն ինչ կարգին է։
Ո՞ր ցուցանիշներն են կարևոր վերահսկելու համար։
Ի՞նչն ենք մենք հիմնականում վերահսկում։ Ո՞ր ցուցանիշներն են մեզ համար կարևոր։
- Առջևի վահանակների վրա արձագանքման ժամանակը / RPS-ը շատ կարևոր ցուցանիշ է։ Այն անմիջապես արձագանքում է, որ ձեզ հետ ինչ-որ բան այն չէ։
- Բոլոր հերթերում մշակված հաղորդագրությունների քանակը։
- Աշխատողների թիվը։
- Ճիշտության հիմնական չափանիշները։
Վերջին կետը «գործարարություն» է, «գործարար» չափանիշը։ Եթե ցանկանում եք վերահսկել նույն բանը, ապա պետք է սահմանեք մեկ կամ երկու չափանիշ, որոնք ձեզ համար հիմնական ցուցանիշներն են։ Մեր չափանիշը թողունակությունն է (հաջողված գործարքների թվի և գործարքների ընդհանուր հոսքի հարաբերակցությունը)։ Եթե ինչ-որ բան փոխվում է 5-10-15 րոպեի ընթացքում, ապա մենք խնդիրներ ունենք (եթե այն կտրուկ փոխվում է)։
Մեզ համար այն մեր տախտակներից մեկի օրինակ է.
Ձախ կողմում կան 6 գրաֆիկներ, որոնք համապատասխանաբար աշխատողների և հերթերում գտնվող հաղորդագրությունների քանակն են՝ տողերի երկայնքով։ Աջ կողմում կան RPS-ը և RTS-ը։ Ստորև նույն «բիզնես» չափանիշն է։ Իսկ «բիզնես» չափանիշի վրա մենք անմիջապես կարող ենք տեսնել, որ երկու միջին գրաֆիկների վրա ինչ-որ բան այն չէ… Դա պարզապես ևս մեկ համակարգ էր, որը խափանվեց, որը մեր հետևում է։Երկրորդ բանը, որ մենք պետք է անեինք, արտաքին վճարային համակարգերի անկման մոնիթորինգն էր։ Այստեղ մենք վերցրեցինք OpenTracing-ը՝ մեխանիզմ, ստանդարտ, մոդել, որը թույլ է տալիս հետևել բաշխված համակարգերին, և մի փոքր փոփոխեցինք այն։ OpenTracing ստանդարտ մոդելը ասում է, որ մենք կառուցում ենք յուրաքանչյուր առանձին հարցման հետք։ Մեզ դա պետք չէր, և մենք այն փաթեթավորեցինք ամփոփ, ագրեգացիոն հետքի մեջ։ Մենք ստեղծեցինք մի գործիք, որը թույլ է տալիս հետևել մեր հետևում գտնվող համակարգերի արագությանը։
Գրաֆիկը ցույց է տալիս, որ վճարային համակարգերից մեկը սկսել է արձագանքել 3 վայրկյանում. մենք խնդիրներ ունենք։ Միևնույն ժամանակ, այս սարքը կարձագանքի, երբ խնդիրները սկսվեն, 20-30 վայրկյանի ընթացքում։Եվ գոյություն ունեցող մոնիթորինգի սխալների երրորդ դասը տրամաբանական մոնիթորինգն է։
Անկեղծ ասած, չգիտեի՝ ինչ նկարեմ այս սլայդի վրա, որովհետև երկար ժամանակ շուկայում փնտրում էինք մեզ հարմար մի բան։ Ոչինչ չգտանք, ուստի ստիպված էինք ինքներս անել դա։
Ի՞նչ եմ նկատի ունենում տրամաբանական մոնիթորինգ ասելով։ Պատկերացրեք՝ դուք ձեզ համար համակարգ եք ստեղծում (օրինակ՝ Tinder-ի կլոն). դուք այն պատրաստել եք, գործարկել։ Հաջողակ մենեջեր Վասյա Պուպկինը այն տեղադրել է իր հեռախոսի վրա, այնտեղ տեսնում է մի աղջկա, հավանում է նրան... և նմանակը չի հասնում աղջկան՝ նմանակը հասնում է նույն բիզնես կենտրոնի անվտանգության աշխատակից Միխալիչին։ Մենեջերը իջնում է ներքև, ապա զարմանում. «Ինչո՞ւ է այս անվտանգության աշխատակից Միխալիչը նրան այդքան հաճելի ժպտում»։Նման իրավիճակներում... Մեզ համար այս իրավիճակը մի փոքր այլ կերպ է հնչում, քանի որ (ես գրել եմ) դա այնպիսի հեղինակության կորուստ է, որը անուղղակիորեն հանգեցնում է ֆինանսական կորուստների: Մենք ունենք հակառակ իրավիճակը. մենք կարող ենք ուղղակի ֆինանսական կորուստներ կրել, օրինակ, եթե գործարքը հաջողությամբ իրականացրել ենք, բայց այն անհաջող է եղել (կամ հակառակը): Մենք ստիպված էինք գրել մեր սեփական գործիքը, որը դինամիկայով հետևում է հաջող գործարքների քանակին որոշակի ժամանակահատվածում՝ հիմնվելով բիզնեսի ցուցանիշների վրա: Մենք շուկայում ոչինչ չգտանք: Սա հենց այն գաղափարն է, որը ես ուզում էի փոխանցել: Շուկայում այս տեսակի խնդիրը լուծելու համար ոչինչ չկա:
Սա վերաբերում էր այն բանին, թե ինչպես արագորեն հայտնաբերել խնդիրը։
Ինչպես որոշել տեղակայման պատճառները
Երրորդ խումբ խնդիրներ, որոնք մենք լուծում ենք, խնդիրը բացահայտելուց հետո է, դրանից ազատվելուց հետո լավ կլինի հասկանալ մշակման, փորձարկման պատճառը և ինչ-որ բան անել դրա հետ կապված։ Համապատասխանաբար, մենք պետք է հետաքննենք, պետք է գրանցենք տվյալներ։
Եթե խոսքը գրանցամատյանների մասին է (հիմնական պատճառը գրանցամատյաններն են), մեր գրանցամատյանների մեծ մասը ELK Stack-ում է. գրեթե բոլորն էլ այդպես ունեն։ Ոմանց մոտ գուցե ոչ ELK-ում, բայց եթե գրանցամատյանները գրում եք գիգաբայթերով, ապա վաղ թե ուշ կհասնեք ELK-ին։ Մենք դրանք գրում ենք տերաբայթերով։
Այստեղ խնդիր կա։ Մենք այն շտկեցինք, օգտատիրոջ սխալը ուղղեցինք, սկսեցինք փորփրել, ինչ կար այնտեղ, մտանք Kibana, այնտեղ մուտքագրեցինք գործարքի ID-ն և ստացանք այս գրանցամատյանը (շատ բան է ցույց տալիս)։ Եվ այս գրանցամատյանում բացարձակապես ոչինչ պարզ չէ։ Ինչո՞ւ։ Որովհետև պարզ չէ, թե որ մասը որ աշխատողին է վերաբերում, որ մասը որ բաղադրիչին է վերաբերում։ Եվ այդ պահին մենք հասկացանք, որ մեզ անհրաժեշտ է հետևումը՝ նույն OpenTracing-ը, որի մասին ես խոսեցի։Մենք մեկ տարի առաջ մտածեցինք այդ մասին, մեր ուշադրությունը սևեռեցինք շուկայի վրա, և այնտեղ կային երկու գործիք՝ Zipkin-ը և Jaeger-ը: Jaeger-ը, ըստ էության, գաղափարական իրավահաջորդն է, Zipkin-ի գաղափարական իրավահաջորդը: Zipkin-ում ամեն ինչ լավ է, բացառությամբ այն բանի, որ այն չի կարող ագրեգացնել, չի կարող ներառել գրանցամատյանները հետևման մեջ, միայն ժամանակի հետևումը: Եվ Jaeger-ը աջակցում էր դրան:
Մենք դիտարկեցինք «Էգեր»-ը. կարելի էր գործիքավորել ծրագրեր, կարելի էր գրել API-ով (այդ ժամանակ PHP-ի API ստանդարտը, սակայն, հաստատված չէր. սա մեկ տարի առաջ էր, իսկ հիմա հաստատվել է), բայց բացարձակապես ոչ մի հաճախորդ չկար։ «Լավ», մտածեցինք մենք և գրեցինք մեր սեփական հաճախորդը։ Ի՞նչ ստացանք։ Մոտավորապես այսպիսի տեսք ունի այն.
«Էգեր»-ում յուրաքանչյուր հաղորդագրության համար ստեղծվում են տարածություններ։ Այսինքն, երբ օգտատերը բացում է համակարգը, նա տեսնում է մեկ կամ երկու բլոկ յուրաքանչյուր մուտքային հարցման համար (1-2-3՝ օգտատիրոջից ստացված այնքան մուտքային հարցում, որքան բլոկներ են եղել)։ Օգտատերերի համար ավելի հեշտ դարձնելու համար մենք գրանցամատյաններին ավելացրել ենք թեգեր և ժամանակի հետևում։ Համապատասխանաբար, սխալի դեպքում մեր ծրագիրը կնշի գրանցամատյանը համապատասխան Սխալի թեգով։ Դուք կարող եք զտել Սխալի թեգով, և կցուցադրվեն միայն այն տարածությունները, որոնք պարունակում են այս սխալով բլոկը։ Ահա թե ինչպես է այն երևում, եթե մենք ընդարձակենք տարածությունը.
Սպանի ներսում կա հետքերի հավաքածու։ Այս դեպքում սրանք երեք փորձարկման հետքեր են, և երրորդ հետքը մեզ ասում է, որ սխալ է տեղի ունեցել։ Միևնույն ժամանակ, այստեղ մենք տեսնում ենք ժամանակի հետք. վերևում ունենք ժամանակի սանդղակ, և մենք տեսնում ենք, թե որ ժամանակահատվածում է գրանցվել այս կամ այն գրանցամատյանը։Հետևաբար, մեզ համար ամեն ինչ լավ ընթացավ։ Մենք գրեցինք մեր սեփական ընդլայնումը և այն դարձրեցինք բաց կոդով։ Եթե ուզում եք աշխատել հետևողականության հետ, եթե ուզում եք աշխատել PHP-ում «Eger»-ի հետ, ահա մեր ընդլայնումը, որը կարող եք օգտագործել, ինչպես ասում են՝
Մեզ համար այս ընդլայնումը OpenTracing Api-ի հաճախորդ է, որը ստեղծվել է որպես php-ընդլայնում, այսինքն՝ դուք պետք է այն հավաքեք և համակարգը տեղադրեք դրա տակ։ Մեկ տարի առաջ ուրիշ ոչինչ չկար։ Հիմա կան այլ հաճախորդներ, որոնք նման են բաղադրիչների։ Այստեղ ամեն ինչ կախված է ձեզանից. կամ դուք ներբեռնում եք բաղադրիչները composer-ով, կամ օգտագործում եք ձեզ համար նախատեսված ընդլայնումը։Կորպորատիվ ստանդարտներ
Մենք խոսեցինք երեք պատվիրանների մասին։ Չորրորդ պատվիրանը մոտեցումները ստանդարտացնելու մասին է։ Ինչի՞ մասին է այն։ Այն մոտավորապես հետևյալն է.
Ինչո՞ւ է այստեղ օգտագործվում «կորպորատիվ» բառը։ Ոչ թե որովհետև մենք մեծ կամ բյուրոկրատական ընկերություն ենք, ոչ։ Ես ուզում էի «կորպորատիվ» բառն այստեղ օգտագործել այն համատեքստում, որ յուրաքանչյուր ընկերություն, յուրաքանչյուր ապրանք պետք է ունենա իր սեփական չափանիշները, այդ թվում՝ ձերը։ Ի՞նչ չափանիշներ ունենք մենք։- Մենք ունենք տեղակայման կանոնակարգ։ Առանց դրա մենք ոչ մի տեղ չենք շարժվում, չենք կարող։ Մենք շաբաթական մոտ 60 անգամ տեղակայվում ենք, այսինքն՝ գրեթե անընդհատ տեղակայվում ենք։ Միևնույն ժամանակ, օրինակ, մեր տեղակայման կանոնակարգում ուրբաթ օրերին տեղակայվելու վերաբերյալ տաբու կա. հիմնականում, մենք տեղակայում չենք անում։
- Մեզ անհրաժեշտ է փաստաթղթավորում։ Ոչ մի նոր բաղադրիչ արտադրության մեջ չի մտնում առանց փաստաթղթավորման, նույնիսկ եթե այն ստեղծվել է մեր RnD մասնագետների կողմից։ Մենք պահանջում ենք, որ նրանք տրամադրեն տեղակայման հրահանգներ, մոնիթորինգի քարտեզ և մոտավոր նկարագրություն (ինչպես կարող են գրել ծրագրավորողները), թե ինչպես է աշխատում բաղադրիչը և ինչպես լուծել դրա խնդիրները։
- Մենք լուծում ենք ոչ թե խնդրի պատճառը, այլ խնդիրը՝ ինչն արդեն ասացի։ Մեզ համար կարևոր է պաշտպանել օգտատիրոջը խնդիրներից։
- Մենք ունենք հանդուրժողականության սահմաններ։ Օրինակ, մենք չենք համարում դա դադար, եթե երկու րոպեի ընթացքում կորցրել ենք երթևեկության 2%-ը։ Սկզբունքորեն, սա մեր վիճակագրության մեջ չի հաշվվում։ Եթե դա ավելի շատ տոկոսային կամ ժամանակային առումով է, մենք արդեն հաշվում ենք այն։
- Եվ մենք միշտ գրում ենք հետմահու եզրակացություններ: Ինչ էլ որ պատահի մեզ հետ, ցանկացած իրավիճակ, երբ արտադրության մեջ ինչ-որ բան այնպես չի ընթացել, դա կարտացոլվի հետմահու եզրակացության մեջ: Հետմահու եզրակացությունը փաստաթուղթ է, որտեղ դուք գրում եք, թե ինչ է տեղի ունեցել, մանրամասն ժամանակացույց, ինչ եք արել դա շտկելու համար և (սա պարտադիր բլոկ է!) ինչ եք անելու, որպեսզի դա ապագայում չկրկնվի: Սա պարտադիր է, անհրաժեշտ է հետագա վերլուծության համար:
Ի՞նչն է համարվում դադարի ժամանակ։
Ինչի՞ հանգեցրեց այս ամենը։Սա հանգեցրեց նրան, որ (մենք որոշակի կայունության խնդիրներ ունեինք, սա ո՛չ մեր հաճախորդներին էր հարմար, ո՛չ էլ մեզ) վերջին 6 ամիսների ընթացքում մեր կայունության ցուցանիշը կազմել է 99,97: Կարելի է ասել, որ սա շատ չէ: Այո, մենք ունենք ինչ-որ բանի ձգտելու: Այս ցուցանիշի մոտ կեսը մեր վեբ հավելվածի firewall-ի կայունությունն է, որը մեր առջև է և օգտագործվում է որպես ծառայություն, բայց հաճախորդները դա չեն հետաքրքրում:
Մենք սովորեցինք գիշերը քնել։ Վերջապես։ Վեց ամիս առաջ մենք չէինք կարողանում։ Եվ արդյունքների հետ կապված՝ կցանկանայի մեկ դիտողություն անել։ Երեկ երեկոյան միջուկային ռեակտորի կառավարման համակարգի վերաբերյալ հրաշալի զեկույց էր։ Եթե այս համակարգը գրող մարդիկ լսում են ինձ, խնդրում եմ մոռացեք, թե ինչ ասացի «2%-ը պարապուրդի ժամանակ չէ»։ Ձեզ համար 2%-ը պարապուրդի ժամանակ է, նույնիսկ եթե դա երկու րոպե է։
Այսքանը առայժմ։ Ձեր հարցերը։
Հավասարակշռողների և տվյալների բազայի միգրացիայի մասին
Հարց լսարանից (այսուհետ՝ Բ): – Բարի երեկո: Շատ շնորհակալ եմ նման վարչական հաշվետվության համար: Կարճ հարց՝ ձեր հավասարակշռիչների թեմայով: Դուք նշեցիք, որ ունեք WAF, այսինքն՝ ինչպես ես հասկանում եմ, օգտագործում եք ինչ-որ արտաքին հավասարակշռիչ…
EC: - Ոչ, մենք մեր սեփական ծառայություններն ենք օգտագործում որպես հավասարակշռող միջոց։ Այս դեպքում WAF-ը մեզ համար բացառապես DDoS պաշտպանության գործիք է։
IN: – Կարո՞ղ եք մի քանի խոսք ասել հավասարակշռողների մասին։
EC: - Ինչպես արդեն ասացի, սա openresty-ում սերվերների խումբ է։ Մենք այժմ ունենք դրանցից 5 խումբ՝ պահուստավորված, որոնք արձագանքում են բացառապես... այսինքն՝ սերվեր, որի վրա openresty-ն տեղադրված է բացառապես, այն միայն պրոքսի է անում տրաֆիկը։ Համապատասխանաբար, հասկանալու համար, թե որքան ենք մենք աջակցում. մեր կանոնավոր տրաֆիկի հոսքը այժմ մի քանի հարյուր մեգաբիթ է։ Նրանք հաղթահարում են, լավ են անում, նույնիսկ չեն լարվում։
IN: - Մի պարզ հարց էլ։ Ահա Կապույտ/Կանաչ տեղակայումը։ Եվ ի՞նչ եք անում, օրինակ, տվյալների բազայից տեղափոխությունների հետ։
EC: - Լավ հարց է։ Տեսեք, Կապույտ/Կանաչ տեղակայման մեջ մենք ունենք առանձին հերթեր յուրաքանչյուր տողի համար։ Այսինքն, եթե խոսքը աշխատողից աշխատող փոխանցվող իրադարձությունների հերթերի մասին է, ապա կան առանձին հերթեր կապույտ և կանաչ գծերի համար։ Եթե խոսքը վերաբերում է տվյալների բազային, ապա մենք այն հնարավորինս նեղացրել ենք, գրեթե ամեն ինչ տեղափոխել ենք հերթերի մեջ, տվյալների բազայում մենք պահում ենք միայն գործարքների կույտը։ Եվ գործարքների կույտը նույնն է բոլոր տողերի համար։ Այս համատեքստում տվյալների բազայի դեպքում՝ մենք այն չենք բաժանում կապույտ և կանաչի, քանի որ կոդի երկու տարբերակներն էլ պետք է իմանան, թե ինչ է կատարվում գործարքի հետ։
Ընկերներ, ես ունեմ ևս մեկ փոքրիկ մրցանակ, որը կխրախուսի ձեզ՝ գիրք։ Եվ ես պետք է այն տամ լավագույն հարցին։
IN: - Բարև ձեզ։ Շնորհակալություն հաշվետվության համար։ Ահա հարցը։ Դուք հետևում եք վճարումներին, հետևում եք այն ծառայություններին, որոնց հետ շփվում եք... Բայց ինչպե՞ս եք հետևում, որ անձը ինչ-որ կերպ մտել է ձեր վճարման էջ, կատարել վճարում, և նախագիծը նրան գումար է փոխանցել։ Այսինքն՝ ինչպե՞ս եք հետևում, որ մարքեթինգային ընկերությունը հասանելի է և ընդունել է ձեր հետադարձ զանգը։
EC: – Մեզ համար «վաճառողը» այս դեպքում ճիշտ նույն արտաքին ծառայությունն է, ինչ վճարային համակարգը։ Մենք հետևում ենք «վաճառողի» արձագանքի արագությանը։
Տվյալների բազայի կոդավորման մասին
IN: - Բարև ձեզ։ Ես մի փոքր կապակցված հարց ունեմ։ Դուք ունեք զգայուն տվյալներ PCI DSS-ի համաձայն։ Ես ուզում էի իմանալ, թե ինչպես եք պահում PAN-ները հերթերում, որոնց պետք է վերահասցեագրել։ Արդյո՞ք դուք օգտագործում եք որևէ կոդավորում։ Եվ այստեղից էլ՝ երկրորդ հարցը. PCI DSS-ի համաձայն, անհրաժեշտ է պարբերաբար վերակոդավորել տվյալների բազան փոփոխությունների դեպքում (ադմինիստրատորների ազատում և այլն) - ինչպե՞ս է դա տեղի ունենում մատչելիության հետ։
EC: - Հիանալի հարց է։ Նախ, մենք PAN-ները չենք պահում հերթերում։ Սկզբունքորեն, մենք իրավունք չունենք PAN-ները բաց տեսքով պահել որևէ տեղ, ուստի մենք օգտագործում ենք հատուկ ծառայություն (մենք այն անվանում ենք «Keydemon»). սա ծառայություն է, որը միայն մեկ բան է անում. այն ընդունում է հաղորդագրությունը որպես մուտքային տվյալ և վերադարձնում է կոդավորված հաղորդագրություն։ Եվ մենք ամեն ինչ պահում ենք այս կոդավորված հաղորդագրությամբ։ Հետևաբար, մեր բանալու երկարությունը մեկ կիլոբայթից պակաս է, ուստի այն իսկապես լուրջ և հուսալի է։IN: – Հիմա 2 կիլոբայթ պե՞տք է։
EC: – Երեկ կարծես 256-ն էին... Ուրիշ որտե՞ղ։
Հետևաբար, սա առաջին բանն է։ Եվ երկրորդ, գոյություն ունեցող լուծումը աջակցում է վերակոդավորման ընթացակարգին՝ կան երկու զույգ «կեկեր» (բանալիներ), որոնք տալիս են կոդավորող «դեկեր» (բանալիներ՝ սրանք բանալիներ են, դեկերը՝ կոդավորող բանալիների ածանցյալներ են)։ Եվ ընթացակարգի մեկնարկի դեպքում (դա տեղի է ունենում պարբերաբար՝ 3 ամսից մինչև ± մոտավորապես) մենք բեռնում ենք «կեկերի» նոր զույգ, և մենք ունենում ենք տվյալների վերակոդավորում։ Մենք ունենք առանձին ծառայություններ, որոնք արդյունահանում են բոլոր տվյալները, կոդավորում դրանք նոր եղանակով. տվյալները ունեն այն բանալու նույնականացուցիչը, որով դրանք կոդավորվում են, և պահվում են մոտակայքում։ Հետևաբար, հենց որ մենք կոդավորում ենք տվյալները նոր բանալիներով, մենք ջնջում ենք հին բանալիները։
Երբեմն վճարումները պետք է կատարել ձեռքով…
IN: - Այսինքն, եթե որևէ գործարքի համար վերադարձված գումարը ստացվել է, դուք առայժմ այն կվերծանե՞ք հին բանալիով։
EC: - Այո:
IN: - Ապա ևս մեկ փոքր հարց։ Երբ տեղի է ունենում որևէ ձախողում, անկում, միջադեպ, անհրաժեշտ է գործարքը կատարել ձեռքով։ Նման իրավիճակ է պատահում։
EC: - Այո, պատահում է։
IN: - Որտեղի՞ց եք ստանում այս տվյալները։ Կամ ինքներդ ձեռքով եք գնում այս պահեստ։
EC: - Ոչ, լավ, պարզ է՝ մենք ունենք որոշ հետին գրասենյակային համակարգ, որը պարունակում է մեր աջակցության համար նախատեսված ինտերֆեյս։ Եթե մենք չգիտենք գործարքի կարգավիճակը (օրինակ՝ մինչև վճարային համակարգի ժամկետի ավարտը), մենք ապրիորի չգիտենք, այսինքն՝ վերջնական կարգավիճակը տալիս ենք միայն այն ժամանակ, երբ լիովին վստահ ենք։ Այս դեպքում մենք գործարքը տեղափոխում ենք ձեռքով մշակման հատուկ կարգավիճակի մեջ։ Հաջորդ օրը՝ առավոտյան, հենց որ աջակցության ծառայությունը ստանում է տեղեկատվություն, որ այս կամ այն գործարքները մնում են վճարային համակարգում, նրանք ձեռքով մշակում են դրանք այս ինտերֆեյսում։
IN: – Ես մի քանի հարց ունեմ։ Դրանցից մեկը PCI DSS գոտու շարունակությունն է. ինչպե՞ս եք հանում գրանցամատյանները դրանց կոնտուրից։ Այս հարցը ծագում է այն պատճառով, որ մշակողը կարող էր գրանցամատյաններում տեղադրել ցանկացած բան։ Երկրորդ հարցը՝ ինչպե՞ս եք տեղադրում արագ շտկումները։ Ձեռքով տվյալների բազայում՝ դա մեկ տարբերակ է, բայց կարող են լինել անվճար արագ շտկումներ՝ ի՞նչ ընթացակարգ կա այնտեղ։ Եվ երրորդ հարցը, հավանաբար, կապված է RTO-ի, RPO-ի հետ։ Ձեր հասանելիությունը 99,97 էր, գրեթե չորս ինն, բայց ինչպես ես հասկանում եմ, դուք ունեք երկրորդ տվյալների կենտրոն, երրորդ տվյալների կենտրոն և հինգերորդ տվյալների կենտրոն… Ինչպե՞ս եք կարգավորում դրանց համաժամեցումը, կրկնօրինակումը, մնացած ամեն ինչ։EC: - Սկսենք առաջինից։ Առաջին հարցը վերաբերում էր գրանցամատյաններին։ Երբ մենք գրում ենք գրանցամատյաններ, կա մի շերտ, որը թաքցնում է բոլոր զգայուն տվյալները։ Այն նայում է դիմակին և լրացուցիչ դաշտերին։ Համապատասխանաբար, մեր գրանցամատյանները դուրս են գալիս արդեն թաքցված տվյալներով և PCI DSS ուրվագծերով։ Սա թեստավորման բաժնին տրված կանոնավոր առաջադրանքներից մեկն է։ Նրանք պարտավոր են ստուգել յուրաքանչյուր առաջադրանք, այդ թվում՝ իրենց գրած գրանցամատյանները, և սա կոդի վերանայման ընթացքում կանոնավոր առաջադրանքներից մեկն է՝ վերահսկելու համար, որ մշակողը ինչ-որ բան չի գրանցել։ Հետագա ստուգումը տեղեկատվական անվտանգության բաժնի կողմից պարբերաբար իրականացվում է մոտավորապես շաբաթը մեկ անգամ. վերջին օրվա գրանցամատյանները ընտրողաբար վերցվում են և փորձարկման սերվերներից անցնում են հատուկ սկաներ-վերլուծիչի միջով՝ այս ամենը ստուգելու համար։
Թեժ շտկումների մասին։ Սա ներառված է մեր տեղակայման կանոնակարգերում։ Մենք ունենք առանձին կետ թեժ շտկումների մասին։ Մենք կարծում ենք, որ մենք թեժ շտկումները տեղակայում ենք շուրջօրյա, երբ դրանց կարիքն ունենք։ Հենց որ տարբերակը կոմպիլացվում է, հենց որ այն գործարկվում է, հենց որ մենք ունենում ենք արտեֆակտ, մենք ունենք հերթապահ համակարգի ադմինիստրատոր աջակցության ծառայությունից, և նա տեղակայում է այն այն պահին, երբ դա անհրաժեշտ է։«Չորս ինների» մասին։ Այն թիվը, որը մենք հիմա ունենք, իսկապես հասել ենք, և մենք դրան ձգտում էինք մեկ այլ տվյալների կենտրոնում։ Հիմա մենք ունենք երկրորդ տվյալների կենտրոն, և մենք սկսում ենք երթուղիներ կազմել դրանց միջև, և խաչաձև տվյալների կենտրոնների կրկնօրինակման խնդիրը իրականում ոչ տրիվիալ խնդիր է։ Մենք ժամանակին փորձեցինք լուծել այն տարբեր միջոցներով. փորձեցինք օգտագործել նույն «Տարանտուլան»՝ այն մեզ մոտ չաշխատեց, անմիջապես կասեմ ձեզ։ Հետևաբար, մենք հասանք այն կետին, որ «զգայարանների» պատվերը կատարում ենք ձեռքով։ Փաստորեն, մեր ասինխրոն ռեժիմում անհրաժեշտ համաժամեցման «փոփոխություն - արված» յուրաքանչյուր ծրագիր աշխատում է տվյալների կենտրոնների միջև։
IN: - Եթե երկրորդն ունես, ինչո՞ւ երրորդը դեռ չի հայտնվել։ Որովհետև Split-brain-ը դեռ ոչ ոք չէ...
EC: - Եվ մենք «բաժանված ուղեղ» չունենք։ Քանի որ յուրաքանչյուր ծրագիր գործարկվում է բազմամասթերի կողմից, մեզ համար կարևոր չէ, թե որ կենտրոնին է հասել հարցումը։ Մենք պատրաստ ենք այն փաստին, որ եթե մեր տվյալների կենտրոններից մեկը անջատվի (մենք դրա վրա ենք հույսը դնում) և անցնի երկրորդ տվյալների կենտրոն՝ օգտատիրոջ հարցման կեսին, մենք պատրաստ ենք կորցնել այս օգտատիրոջը, իհարկե, բայց դրանք շատ քիչ կլինեն, բացարձակապես քիչ։
IN: - Բարի երեկո։ Շնորհակալություն զեկույցի համար։ Դուք խոսեցիք ձեր վրիպազերծիչի մասին, որը որոշ փորձարկման գործարքներ է կատարում արտադրության մեջ։ Հիմա պատմեք մեզ փորձարկման գործարքների մասին։ Որքա՞ն խորն է այն ընդգրկում։
EC: - Այն անցնում է ամբողջ բաղադրիչի ամբողջական ցիկլով։ Բաղադրիչի համար թեստային և գործող գործարքների միջև տարբերություն չկա։ Եվ տրամաբանության տեսանկյունից, դա պարզապես առանձին նախագիծ է համակարգում, որի վրա կատարվում են միայն թեստային գործարքներ։
IN: - Որտեղի՞ց եք կտրում այն։ Core-ը ուղարկեց...
EC: – Մենք այս դեպքում «Կոր»-ի կողմնակից ենք փորձնական գործարքների համար... Մենք ունենք այնպիսի հասկացություն, ինչպիսին է ռաութինգը. «Կոր»-ը գիտի, թե որ վճարային համակարգին ուղարկել. մենք ուղարկում ենք կեղծ վճարային համակարգի, որը պարզապես տալիս է http-return և վերջ։
IN: – Ասացեք խնդրեմ, ձեր հավելվածը գրված է որպես մեկ հսկայական մոնոլիտ, թե՞ այն բաժանել եք որոշ ծառայությունների կամ նույնիսկ միկրոսերվիսների։
EC: - Մենք, իհարկե, մոնոլիտ չունենք, մենք ունենք ծառայությունների վրա հիմնված ծրագիր: Մենք կատակում ենք, որ ունենք մոնոլիտներից պատրաստված ծառայություն. դրանք իրականում բավականին մեծ են: Դժվար է դրանք միկրոսերվիսներ անվանել, բայց սրանք այն ծառայություններն են, որոնց շրջանակներում գործում են բաշխված մեքենայական աշխատողներ:
Եթե սերվերի վրա ծառայությունը վտանգված է…
IN: - Ապա ես ունեմ հաջորդ հարցը։ Նույնիսկ եթե դա մոնոլիտ լիներ, դուք միևնույն է ասացիք, որ ունեք այս ակնթարթային սերվերներից շատերը, դրանք բոլորը հիմնականում մշակում են տվյալներ, և հարցն այսպիսին է. «Անմիջական սերվերներից մեկի կամ որևէ ծրագրի, որևէ առանձին կապի կոտրման դեպքում, արդյո՞ք նրանք ունեն մուտքի որևէ վերահսկողություն։ Նրանցից ո՞րը կարող է անել ինչ-որ բան։ Ու՞մ դիմել, ի՞նչ տվյալների համար»։
EC: - Այո, անկասկած։ Անվտանգության պահանջները բավականին լուրջ են։ Նախ, մենք ունենք բաց տվյալների հոսքեր, և միայն այն միացքները, որոնց միջոցով մենք կանխատեսում ենք երթևեկության հոսք։ Եթե որևէ բաղադրիչ կապվում է տվյալների բազայի հետ (ասենք՝ Muskul-ի հետ) 5-4-3-2-ի միջոցով, միայն 5-4-3-2-ը կլինի բաց նրա համար, իսկ մյուս միացքները, երթևեկության հոսքի այլ ուղղությունները հասանելի չեն լինի։ Բացի այդ, մենք պետք է հասկանանք, որ մեր արտադրության մեջ կա մոտ 10 տարբեր անվտանգության կոնտուր։ Եվ նույնիսկ եթե ծրագիրը ինչ-որ կերպ վնասվել է, Աստված մի արասցե, հարձակվողը չի կարողանա մուտք գործել սերվերի կառավարման կոնսոլ, քանի որ սա ցանցային անվտանգության այլ գոտի է։IN: – Եվ այս համատեքստում ինձ ավելի շատ հետաքրքրում է այն փաստը, որ դուք ունեք որոշակի պայմանագրեր ծառայությունների հետ՝ ինչ կարող են անել, ինչ «գործողությունների» միջոցով կարող են կապ հաստատել միմյանց հետ... Եվ բնականոն հոսքի դեպքում որոշ կոնկրետ ծառայություններ պահանջում են որոշակի տող, «գործողությունների» ցանկ մեկ այլ տողի վրա: Նրանք նորմալ իրավիճակում չեն կապվում մյուսների հետ, և ունեն պատասխանատվության այլ ոլորտներ: Եթե նրանցից մեկը վարակված լինի, կկարողանա՞ այն իրականացնել այդ ծառայության «գործողությունները»:
EC: - Հասկանում եմ։ Եթե մեկ այլ սերվերի հետ նորմալ իրավիճակում կապը ընդհանրապես թույլատրվում էր, ապա այո։ SLA պայմանագրի համաձայն՝ մենք չենք վերահսկում, որ ձեզ թույլատրվեն միայն առաջին 3 «գործողությունները», իսկ 4 «գործողությունները» թույլատրված չեն։ Սա, հավանաբար, մեզ համար չափազանց է, քանի որ մենք արդեն սկզբունքորեն ունենք 4 մակարդակի պաշտպանության համակարգ կոնտուրների համար։ Մենք նախընտրում ենք պաշտպանվել կոնտուրներով, այլ ոչ թե ներքին մասերի մակարդակով։
Ինչպես են աշխատում Visa-ն, MasterCard-ը և Sberbank-ը
IN: - Ես ուզում եմ պարզաբանել օգտատիրոջը մեկ տվյալների կենտրոնից մյուսը տեղափոխելու հարցը: Ինչքան ես գիտեմ, Visa-ն և MasterCard-ը աշխատում են 8583 բինար սինխրոն արձանագրությամբ, այնտեղ կան խառնուրդներ: Եվ ես ուզում էի իմանալ, սա անցում է անմիջապես Visa-ի և MasterCard-ի միջև, թե՞ վճարային համակարգերից առաջ, մշակումից առաջ:
EC: - Սա միքսերից առաջ է։ Մեր միքսերը մեկ տվյալների կենտրոնում են։
IN: – Կոպիտ ասած, դուք մեկ միացման կետ ունե՞ք։
EC: - Visa և MasterCard - այո։ Պարզապես որովհետև Visa-ն և MasterCard-ը պահանջում են բավականին լուրջ ներդրումներ ենթակառուցվածքներում՝ առանձին պայմանագրեր կնքելու համար, օրինակ, երկրորդ զույգ միքս ստանալու համար։ Դրանք պահվում են մեկ տվյալների կենտրոնում, բայց եթե, Աստված մի արասցե, մեր տվյալների կենտրոնը, որտեղ գտնվում են Visa-ին և MasterCard-ին միանալու միքսերը, խափանվի, ապա մեր կապը Visa-ի և MasterCard-ի հետ կկորչի...
IN: - Ինչպե՞ս կարելի է դրանք ամրագրել։ Գիտեմ, որ Visa-ն սկզբունքորեն թույլ է տալիս պահպանել միայն մեկ կապ։
EC: - Նրանք իրենք են մատակարարում սարքավորումները։ Ամեն դեպքում, մենք ստացել ենք սարքավորումներ, որոնք լիովին ներքին պահուստավորված են։
IN: - Այսինքն՝ տաղավարը նրանց Connects Orange-ից է՞։
EC: - Այո:
IN: - Իսկ ի՞նչ կասեք այս դեպքում. եթե ձեր տվյալների կենտրոնը անհետանա, ինչպե՞ս եք շարունակելու օգտագործել այն։ Կամ պարզապես երթևեկությունը դադարո՞ւմ է։
EC: - Ոչ։ Այս դեպքում մենք պարզապես կտեղափոխենք տրաֆիկը մեկ այլ ալիքի, որը, բնականաբար, ավելի թանկ կլինի մեզ համար, ավելի թանկ կլինի հաճախորդների համար։ Բայց տրաֆիկը չի անցնի մեր Visa-ի, MasterCard-ի հետ ուղիղ միացմամբ, այլ պայմանական Sberbank-ի միջոցով (շատ չափազանցված)։
Խորապես ներողություն եմ խնդրում, եթե վիրավորել եմ «Սբերբանկի» աշխատակիցներին։ Բայց մեր վիճակագրության համաձայն՝ «Սբերբանկը» ռուսական բանկն է, որն ամենաշատն է ձախողվում։ Ոչ մի ամիս չի անցնում, որ «Սբերբանկում» ինչ-որ բան չընկնի։
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com
