Այսօր Bitrix24 ծառայությունը չունի հարյուրավոր գիգաբիթ տրաֆիկ, ինչպես նաև չունի սերվերների հսկայական պաշար (չնայած, իհարկե, գոյություն ունեցողները բավականին քիչ են): Բայց շատ հաճախորդների համար դա ընկերությունում աշխատելու հիմնական գործիքն է, այն իրական բիզնեսի համար կարևոր հավելված է: Հետեւաբար, ընկնելու ճանապարհ չկա: Իսկ եթե վթարն իսկապես տեղի ունենար, բայց ծառայությունն այնքան արագ «վերականգնվեր», որ ոչ ոք ոչինչ չնկատե՞ց: Իսկ ինչպե՞ս է հնարավոր իրականացնել failover՝ չկորցնելով աշխատանքի որակը և հաճախորդների թիվը։ Bitrix24-ի ամպային ծառայությունների տնօրեն Ալեքսանդր Դեմիդովը մեր բլոգի համար խոսեց այն մասին, թե ինչպես է զարգացել ամրագրման համակարգը ապրանքի գոյության 7 տարիների ընթացքում:
«Մենք Bitrix24-ը գործարկեցինք որպես SaaS 7 տարի առաջ: Հիմնական դժվարությունը, հավանաբար, հետևյալն էր. նախքան այն հրապարակայնորեն գործարկվել որպես SaaS, այս արտադրանքը պարզապես գոյություն ուներ տուփային լուծման ձևաչափով: Հաճախորդները այն գնել են մեզանից, հյուրընկալել են իրենց սերվերներում, ստեղծել կորպորատիվ պորտալ՝ ընդհանուր լուծում աշխատակիցների հաղորդակցության, ֆայլերի պահպանման, առաջադրանքների կառավարման, CRM-ի համար, այս ամենը: Եվ մինչև 2012 թվականը մենք որոշեցինք, որ ցանկանում ենք այն գործարկել որպես SaaS՝ ինքներս կառավարելով այն՝ ապահովելով սխալների հանդուրժողականություն և հուսալիություն: Մենք փորձ ձեռք բերեցինք ճանապարհին, քանի որ մինչ այդ մենք պարզապես չունեինք դա՝ մենք միայն ծրագրային ապահովման արտադրողներ էինք, ոչ թե ծառայություններ մատուցողներ:
Ծառայությունը գործարկելիս մենք հասկացանք, որ ամենակարևորը անսարքության հանդուրժողականություն, հուսալիություն և ծառայության մշտական հասանելիություն ապահովելն է, քանի որ եթե ունես սովորական սովորական կայք, օրինակ՝ խանութ, և այն ընկնում է քեզ վրա և նստում այնտեղ։ մեկ ժամ, միայն դու տուժում ես, պատվերներ ես կորցնում, հաճախորդներ ես կորցնում, բայց հենց քո հաճախորդի համար դա այնքան էլ կարևոր չէ նրա համար: Նա, իհարկե, նեղսրտել էր, բայց գնաց ու գնեց այլ կայքից։ Իսկ եթե սա հավելված է, որի վրա կապված է ընկերության ներսում կատարվող ողջ աշխատանքը, հաղորդակցությունները, որոշումները, ապա ամենակարևորը օգտատերերի վստահությունը շահելն է, այսինքն՝ նրանց չընկնելն ու չընկնելը։ Քանի որ բոլոր աշխատանքները կարող են դադարեցվել, եթե ներսում ինչ-որ բան չաշխատի:
Bitrix.24 որպես SaaS
Մենք առաջին նախատիպը հավաքել ենք հանրային մեկնարկից մեկ տարի առաջ՝ 2011թ. Մենք այն հավաքեցինք մոտ մեկ շաբաթվա ընթացքում, նայեցինք, պտտեցինք, նույնիսկ աշխատում էր: Այսինքն՝ կարող էիր մտնել ձևաթուղթ, այնտեղ մուտքագրել պորտալի անունը, նոր պորտալ բացվեր և օգտատերերի բազա կստեղծվեր։ Մենք նայեցինք այն, սկզբունքորեն գնահատեցինք ապրանքը, ջարդոն արեցինք և շարունակեցինք զտել մի ամբողջ տարի։ Քանի որ մենք մեծ խնդիր ունեինք. մենք չէինք ցանկանում ստեղծել երկու տարբեր կոդերի հիմքեր, մենք չէինք ցանկանում աջակցել առանձին փաթեթավորված արտադրանքին, առանձին ամպային լուծումներին. մենք ուզում էինք ամեն ինչ անել մեկ կոդի շրջանակներում:
Տիպիկ վեբ հավելվածն այն ժամանակ մեկ սերվեր էր, որի վրա աշխատում է որոշ PHP կոդ, mysql տվյալների բազա, ֆայլերը վերբեռնվում են, փաստաթղթերը, նկարները տեղադրվում են վերբեռնման թղթապանակում. լավ, ամեն ինչ աշխատում է: Ավաղ, անհնար է գործարկել խիստ կայուն վեբ ծառայություն՝ օգտագործելով սա: Այնտեղ բաշխված քեշը չի աջակցվում, տվյալների բազայի կրկնօրինակումը չի ապահովվում:
Մենք ձևակերպել ենք պահանջները. սա տարբեր վայրերում տեղակայվելու, կրկնօրինակման աջակցման և տարբեր աշխարհագրական բաշխված տվյալների կենտրոններում տեղակայվելու հնարավորությունն է: Առանձնացրեք արտադրանքի տրամաբանությունը և, փաստորեն, տվյալների պահպանումը: Կարողանալ դինամիկ մասշտաբել ըստ բեռի և ամբողջությամբ հանդուրժել ստատիկությունը: Այս նկատառումներից, ըստ էության, առաջացան ապրանքին ներկայացվող պահանջները, որոնք մենք տարվա ընթացքում կատարելագործեցինք։ Այս ընթացքում հարթակում, որը պարզվեց, որ միասնական է՝ տուփային լուծումների, մեր սեփական ծառայության համար, մենք աջակցություն ենք ցուցաբերել այն բաների համար, որոնք մեզ անհրաժեշտ են։ Mysql-ի կրկնօրինակման աջակցություն հենց արտադրանքի մակարդակով. այսինքն՝ մշակողը, ով գրում է կոդը, չի մտածում, թե ինչպես են բաշխվելու իր հարցումները, նա օգտագործում է մեր api-ն, և մենք գիտենք, թե ինչպես ճիշտ բաշխել գրելու և կարդալու հարցումները վարպետների միջև։ և ստրուկներ.
Մենք աջակցություն ենք ցուցաբերել արտադրանքի մակարդակով տարբեր ամպային օբյեկտների պահեստավորման համար՝ google storage, amazon s3, գումարած աջակցություն open stack swift-ի համար: Հետևաբար, սա հարմար էր և՛ մեզ՝ որպես ծառայության, և՛ մշակողների համար, ովքեր աշխատում են փաթեթավորված լուծումներով. եթե նրանք պարզապես օգտագործում են մեր API-ն աշխատանքի համար, նրանք չեն մտածում, թե որտեղ կպահվի ֆայլը, ի վերջո, ֆայլային համակարգում, թե՞ օբյեկտի ֆայլի պահեստում:
Արդյունքում մենք անմիջապես որոշեցինք, որ կպահենք տվյալների ամբողջ կենտրոնի մակարդակով։ 2012 թվականին մենք ամբողջությամբ գործարկեցինք Amazon AWS-ում, քանի որ արդեն ունեինք փորձ այս հարթակի հետ. մեր սեփական կայքը տեղակայվել էր այնտեղ: Մեզ գրավեց այն փաստը, որ յուրաքանչյուր տարածաշրջանում Amazon-ն ունի մի քանի հասանելիության գոտիներ. իրականում (իրենց տերմինաբանությամբ) մի քանի տվյալների կենտրոններ, որոնք քիչ թե շատ անկախ են միմյանցից և թույլ են տալիս մեզ վերապահել տվյալների մի ամբողջ կենտրոնի մակարդակով. եթե այն հանկարծակի ձախողվի, տվյալների բազաները կրկնօրինակվում են master-master, վեբ հավելվածի սերվերները կրկնօրինակվում են, և ստատիկ տվյալները տեղափոխվում են s3 օբյեկտների պահեստ: Բեռը հավասարակշռված է. այն ժամանակ Amazon elb-ով, բայց մի փոքր ուշ մենք հասանք մեր սեփական բեռի հավասարակշռողներին, քանի որ մեզ ավելի բարդ տրամաբանություն էր պետք։
Այն, ինչ նրանք ուզում էին, այն էր, ինչ նրանք ստացան...
Բոլոր հիմնական բաները, որոնք մենք ուզում էինք ապահովել՝ սերվերների սխալ հանդուրժողականություն, վեբ հավելվածներ, տվյալների բազաներ, ամեն ինչ լավ էր աշխատում: Ամենապարզ սցենարը. եթե մեր վեբ հավելվածներից մեկը ձախողվի, ապա ամեն ինչ պարզ է՝ դրանք անջատված են հավասարակշռությունից:
Հավասարակշռողը (այն ժամանակ դա Amazon-ի էլբն էր) անսարք մեքենաները նշել է որպես անառողջ և անջատել բեռի բաշխումը դրանց վրա։ Amazon autoscaling-ը աշխատեց. երբ ծանրաբեռնվածությունը մեծացավ, նոր մեքենաներ ավելացվեցին ավտոմաշտաբային խմբում, բեռը բաշխվեց նոր մեքենաների վրա. ամեն ինչ լավ էր: Մեր բալանսավորողների մոտ տրամաբանությունը մոտավորապես նույնն է. եթե հավելվածի սերվերի հետ ինչ-որ բան պատահի, մենք հեռացնում ենք հարցումները, դուրս ենք նետում այդ մեքենաները, սկսում ենք նորերը և շարունակում ենք աշխատել: Տարիների ընթացքում սխեման մի փոքր փոխվել է, բայց շարունակում է գործել. այն պարզ է, հասկանալի, և դրա հետ կապված դժվարություններ չկան:
Մենք աշխատում ենք ամբողջ աշխարհում, հաճախորդների ծանրաբեռնվածության գագաթնակետերը բոլորովին տարբեր են, և, բարեկամաբար, մենք պետք է կարողանանք ցանկացած պահի կատարել որոշակի սպասարկման աշխատանքներ մեր համակարգի ցանկացած բաղադրիչի վրա՝ աննկատ հաճախորդների կողմից: Հետևաբար, մենք հնարավորություն ունենք անջատել տվյալների բազան շահագործումից՝ վերաբաշխելով բեռը երկրորդ տվյալների կենտրոնին։
Ինչպե՞ս է այդ ամենը աշխատում: — Մենք տեղափոխում ենք երթևեկությունը աշխատանքային տվյալների կենտրոնի. եթե տվյալների կենտրոնում վթար է տեղի ունենում, ապա ամբողջությամբ, եթե սա մեր պլանավորված աշխատանքն է մեկ տվյալների բազայի հետ, ապա մենք փոխում ենք այս հաճախորդներին սպասարկող տրաֆիկի մի մասը երկրորդ տվյալների կենտրոն՝ կասեցնելով։ այն կրկնօրինակում է: Եթե նոր մեքենաներ են անհրաժեշտ վեբ հավելվածների համար, քանի որ երկրորդ տվյալների կենտրոնի բեռը մեծացել է, դրանք ավտոմատ կերպով կսկսվեն: Մենք ավարտում ենք աշխատանքը, վերարտադրումը վերականգնվում է և ամբողջ բեռը հետ ենք վերադարձնում: Եթե մենք պետք է երկրորդ DC-ում որոշ աշխատանք արտացոլենք, օրինակ, տեղադրենք համակարգի թարմացումները կամ փոխենք կարգավորումները երկրորդ տվյալների բազայում, ապա, ընդհանուր առմամբ, մենք կրկնում ենք նույնը, պարզապես մյուս ուղղությամբ: Իսկ եթե սա դժբախտ պատահար է, ապա մենք ամեն ինչ անլուրջ ենք անում. մոնիտորինգի համակարգում օգտագործում ենք իրադարձությունների մշակման մեխանիզմը։ Եթե մի քանի ստուգումներ են գործարկվում, և կարգավիճակը դառնում է կրիտիկական, ապա մենք գործարկում ենք այս մշակիչը՝ մշակող, որը կարող է կատարել այս կամ այն տրամաբանությունը: Յուրաքանչյուր տվյալների բազայի համար մենք նշում ենք, թե որ սերվերն է դրա ձախողումը, և որտեղ պետք է փոխարկվի երթևեկությունը, եթե այն անհասանելի է: Պատմականորեն մենք օգտագործում ենք նագիոսը կամ դրա պատառաքաղները այս կամ այն ձևով: Սկզբունքորեն, նմանատիպ մեխանիզմներ կան գրեթե ցանկացած մոնիտորինգի համակարգում, մենք դեռ ավելի բարդ բան չենք օգտագործում, բայց միգուցե մի օր կկիրառենք։ Այժմ մոնիտորինգն առաջանում է անհասանելիության պատճառով և ունի ինչ-որ բան փոխելու հնարավորություն:
Արդյո՞ք մենք ամեն ինչ վերապահել ենք:
Մենք ունենք բազմաթիվ հաճախորդներ ԱՄՆ-ից, շատ հաճախորդներ Եվրոպայից, շատ հաճախորդներ, ովքեր ավելի մոտ են Արևելքին՝ Ճապոնիա, Սինգապուր և այլն: Իհարկե, հաճախորդների մեծ մասը Ռուսաստանում է։ Այսինքն՝ աշխատանքը մեկ մարզում չէ։ Օգտատերերը ցանկանում են արագ արձագանքել, կան պահանջներ՝ համապատասխանելու տարբեր տեղական օրենքներին, և յուրաքանչյուր տարածաշրջանում մենք վերապահում ենք երկու տվյալների կենտրոն, գումարած կան մի քանի լրացուցիչ ծառայություններ, որոնք կրկին հարմար են տեղադրել մեկ տարածաշրջանում՝ հաճախորդների համար, ովքեր գտնվում են այս տարածաշրջանն աշխատում է: REST կարգավորիչներ, թույլտվության սերվերներ, դրանք ավելի քիչ կարևոր են հաճախորդի աշխատանքի համար, որպես ամբողջություն, դուք կարող եք անցնել դրանց միջոցով մի փոքր ընդունելի ուշացումով, բայց դուք չեք ցանկանում նորից հորինել անիվը, թե ինչպես վերահսկել դրանք և ինչ անել: նրանց հետ. Հետևաբար, մենք փորձում ենք առավելագույնս օգտագործել առկա լուծումները, այլ ոչ թե զարգացնել որևէ իրավասություն լրացուցիչ արտադրանքներում: Եվ ինչ-որ տեղ մենք աննշանորեն օգտագործում ենք փոխարկումը DNS մակարդակում, և ծառայության աշխույժությունը որոշում ենք նույն DNS-ով։ Amazon-ն ունի Route 53 ծառայություն, բայց դա պարզապես DNS չէ, որտեղ դուք կարող եք մուտքագրումներ կատարել, և վերջ, այն շատ ավելի ճկուն և հարմար է: Դրա միջոցով դուք կարող եք կառուցել աշխարհաբաշխված ծառայություններ գեոլոկացիաներով, երբ այն օգտագործում եք՝ որոշելու, թե որտեղից է հաճախորդը և տալիս նրան որոշակի գրառումներ. դրա օգնությամբ դուք կարող եք կառուցել failover ճարտարապետներ: Նույն առողջապահական ստուգումները կազմաձևված են հենց 53-րդ երթուղում, դուք սահմանում եք վերջնակետերը, որոնք վերահսկվում են, սահմանում եք չափումներ, սահմանում եք, թե որ արձանագրություններն են որոշելու ծառայության «կենսունակությունը»՝ tcp, http, https; սահմանել ստուգումների հաճախականությունը, որոնք որոշում են ծառայությունը կենդանի է, թե ոչ: Իսկ բուն DNS-ում դուք նշում եք, թե որն է լինելու առաջնային, ինչը՝ երկրորդական, որտեղ անցնել, եթե առողջության ստուգումը գործարկվի 53 երթուղու ներսում: Այս ամենը կարելի է անել որոշ այլ գործիքներով, բայց ինչու է դա հարմար. մեկ անգամ և հետո ընդհանրապես մի մտածիր այդ մասին, թե ինչպես ենք մենք ստուգումներ անում, ինչպես ենք փոխում. ամեն ինչ ինքն իրեն է աշխատում:
Առաջին «բայց»Ինչպե՞ս և ինչով ամրագրել 53 երթուղին ինքնին: Ո՞վ գիտի, իսկ եթե նրան ինչ-որ բան պատահի։ Բարեբախտաբար, մենք երբեք չենք ոտք դրել այս փոցխի վրա, բայց դարձյալ, ես դեռ մի պատմություն կունենամ առջևում, թե ինչու մտածեցինք, որ դեռ պետք է վերապահում անենք: Այստեղ մենք նախապես ծղոտներ ենք դրել մեզ համար։ Օրական մի քանի անգամ մենք կատարում ենք 53 երթուղու մեր ունեցած բոլոր գոտիների ամբողջական բեռնաթափումը։ Amazon-ի API-ն թույլ է տալիս հեշտությամբ ուղարկել դրանք JSON-ով, և մենք ունենք մի քանի պահուստային սերվերներ, որտեղ այն փոխակերպում ենք, վերբեռնում կոնֆիգուրացիաների տեսքով և, կոպիտ ասած, պահուստային կոնֆիգուրացիա ունենք: Եթե ինչ-որ բան պատահի, մենք կարող ենք արագ տեղակայել այն ձեռքով, առանց DNS-ի կարգավորումների տվյալները կորցնելու:
Երկրորդ «բայց»Ի՞նչը այս նկարում դեռ վերապահված չէ: Հավասարակշռողն ինքը! Մեր հաճախորդների բաշխումն ըստ տարածաշրջանի շատ պարզ է: Մենք ունենք bitrix24.ru, bitrix24.com, .de տիրույթները - այժմ կան 13 տարբեր, որոնք գործում են տարբեր գոտիներում: Մենք եկանք հետևյալին. յուրաքանչյուր մարզ ունի իր հավասարակշռողները։ Սա ավելի հարմար է դարձնում տարածումը տարբեր տարածաշրջաններում՝ կախված նրանից, թե որտեղ է գտնվում ցանցի գագաթնակետային բեռը: Եթե սա մեկ բալանսավորողի մակարդակով ձախողում է, ապա այն պարզապես հանվում է ծառայությունից և հանվում է dns-ից։ Եթե որևէ խնդիր կա հավասարակշռողների խմբի հետ, ապա դրանք կրկնօրինակվում են այլ կայքերում, և դրանց միջև անցումը կատարվում է նույն երթուղու միջոցով53, քանի որ կարճ TTL-ի պատճառով անցումը տեղի է ունենում առավելագույնը 2, 3, 5 րոպեի ընթացքում: .
Երրորդ «բայց»Ի՞նչը դեռ վերապահված չէ: S3, ճիշտ է: Երբ մենք տեղադրեցինք ֆայլերը, որոնք մենք պահում ենք օգտատերերի համար s3-ում, մենք անկեղծորեն հավատում էինք, որ այն զրահապատ է և կարիք չկա այնտեղ որևէ բան վերապահել։ Սակայն պատմությունը ցույց է տալիս, որ ամեն ինչ այլ կերպ է տեղի ունենում: Ընդհանրապես, Amazon-ը նկարագրում է S3-ը որպես հիմնարար ծառայություն, քանի որ Amazon-ն ինքն է օգտագործում S3-ը՝ մեքենայի պատկերները, կոնֆիգուրացիաները, AMI պատկերները, snapshot-ները պահելու համար... Իսկ եթե s3-ը խափանվի, ինչպես եղել է մեկ անգամ այս 7 տարվա ընթացքում, քանի դեռ մենք օգտագործում ենք: bitrix24, այն հետևում է երկրպագուի պես: Կան մի շարք բաներ, որոնք ի հայտ են գալիս՝ վիրտուալ մեքենաներ գործարկելու անկարողություն, API-ի ձախողում և այլն:
Իսկ S3-ը կարող է ընկնել, դա եղել է մեկ անգամ: Հետևաբար, մենք եկանք հետևյալ սխեմային. մի քանի տարի առաջ Ռուսաստանում չկային լուրջ հանրային օբյեկտների պահեստավորման օբյեկտներ, և մենք դիտարկում էինք մեր սեփական ինչ-որ բան անելու տարբերակը... Բարեբախտաբար, մենք չսկսեցինք դա անել, քանի որ կ փորել ենք այն փորձաքննությունը, որը մենք չունենք, ունենք, և հավանաբար կխառնվենք: Այժմ Mail.ru-ն ունի s3-ի հետ համատեղելի պահեստ, ունի այն Yandex-ը և մի շարք այլ պրովայդերներ: Վերջիվերջո մենք եկանք այն մտքին, որ ուզում ենք ունենալ, առաջին հերթին, կրկնօրինակում, և երկրորդ՝ տեղական պատճենների հետ աշխատելու կարողություն։ Հատկապես Ռուսաստանի տարածաշրջանի համար մենք օգտագործում ենք Mail.ru Hotbox ծառայությունը, որը համատեղելի է API-ի հետ s3-ի հետ: Մենք կարիք չունեինք հավելվածի ներսում կոդի որևէ լուրջ փոփոխության, և մենք ստեղծեցինք հետևյալ մեխանիզմը. s3-ում կան գործարկիչներ, որոնք հրահրում են օբյեկտների ստեղծում/ջնջում, Amazon-ն ունի ծառայություն, որը կոչվում է Lambda. սա կոդերի առանց սերվերի գործարկում է: որը կկատարվի հենց այն ժամանակ, երբ գործարկվեն որոշակի ձգաններ:
Մենք դա արեցինք շատ պարզ. եթե մեր գործարկիչը գործարկվի, մենք գործարկում ենք կոդ, որը պատճենելու է օբյեկտը Mail.ru-ի պահեստում: Տվյալների տեղական պատճենների հետ աշխատանքն ամբողջությամբ սկսելու համար մեզ անհրաժեշտ է նաև հակադարձ համաժամացում, որպեսզի ռուսաստանյան հատվածում գտնվող հաճախորդները կարողանան աշխատել իրենց ավելի մոտ գտնվող պահեստով: Փոստը պատրաստվում է լրացնել գործարկիչները իր պահեստում. հնարավոր կլինի հակադարձ համաժամացում կատարել ենթակառուցվածքի մակարդակով, բայց առայժմ մենք դա անում ենք մեր սեփական կոդի մակարդակով: Եթե մենք տեսնում ենք, որ հաճախորդը տեղադրել է ֆայլ, ապա կոդի մակարդակում մենք իրադարձությունը տեղադրում ենք հերթում, մշակում և կատարում հակադարձ կրկնօրինակում։ Ինչու է դա վատ. եթե մենք ինչ-որ աշխատանք անենք մեր առարկաների հետ մեր արտադրանքից դուրս, այսինքն՝ ինչ-որ արտաքին միջոցներով, մենք դա հաշվի չենք առնի: Հետևաբար, մենք սպասում ենք մինչև վերջ, երբ պահեստավորման մակարդակում հայտնվեն գործարկիչները, որպեսզի անկախ նրանից, թե որտեղից ենք մենք կատարում կոդը, մեզ հասած օբյեկտը պատճենվում է մյուս ուղղությամբ։
Կոդի մակարդակով մենք գրանցում ենք երկու պահեստները յուրաքանչյուր հաճախորդի համար՝ մեկը համարվում է հիմնական, մյուսը՝ պահեստային: Եթե ամեն ինչ լավ է, մենք աշխատում ենք մեզ ավելի մոտ գտնվող պահեստի հետ, այսինքն՝ մեր հաճախորդները, ովքեր Amazon-ում են, նրանք աշխատում են S3-ով, իսկ նրանք, ովքեր աշխատում են Ռուսաստանում, աշխատում են Hotbox-ով։ Եթե դրոշակը գործարկվում է, ապա պետք է միացվի failover-ը, և մենք կլիենտները տեղափոխում ենք մեկ այլ պահեստ: Մենք կարող ենք ստուգել այս վանդակը անկախ տարածաշրջանից և կարող ենք դրանք հետ ու առաջ փոխարկել: Մենք դա դեռ գործնականում չենք օգտագործել, բայց նախատեսել ենք այս մեխանիզմը և կարծում ենք, որ մի օր մեզ հենց այս անջատիչը պետք կգա և հարմար կլինի։ Սա արդեն մեկ անգամ եղել է.
Օ, և Amazon-ը փախավ...
Այս ապրիլին լրանում է Ռուսաստանում Telegram-ի արգելափակման սկզբի տարեդարձը։ Ամենաշատ տուժած մատակարարը, որն ընկել է դրա տակ, Amazon-ն է: Եվ, ցավոք, ավելի շատ տուժեցին ռուսական ընկերությունները, որոնք աշխատում էին ամբողջ աշխարհի համար։
Եթե ընկերությունը գլոբալ է, իսկ Ռուսաստանը նրա համար շատ փոքր սեգմենտ է, 3-5 տոկոս, լավ, այսպես թե այնպես, կարող ես նրանց զոհաբերել։
Եթե սա զուտ ռուսական ընկերություն է, ես վստահ եմ, որ այն պետք է տեղակայվի տեղում, ապա դա պարզապես հարմար կլինի հենց իրենց օգտագործողների համար, հարմարավետ, և ավելի քիչ ռիսկեր կլինեն:
Իսկ եթե սա մի ընկերություն է, որը գործում է գլոբալ և ունի մոտավորապես հավասար թվով հաճախորդներ Ռուսաստանից և աշխարհի տարբեր ծայրերից: Սեգմենտների կապը կարևոր է, և դրանք պետք է այսպես թե այնպես աշխատեն միմյանց հետ։
2018 թվականի մարտի վերջին Ռոսկոմնադզորը նամակ է ուղարկել խոշորագույն օպերատորներին, որում ասվում է, որ նրանք նախատեսում են արգելափակել Amazon-ի մի քանի միլիոն IP-ներ՝ արգելափակելու... Zello մեսենջերը։ Այս նույն պրովայդերների շնորհիվ՝ նրանք հաջողությամբ արտահոսեցին նամակը բոլորին, և հասկացավ, որ Amazon-ի հետ կապը կարող է փլուզվել: Ուրբաթ էր, մենք խուճապի մատնվեցինք servers.ru-ի մեր գործընկերների մոտ՝ ասելով. «Ընկերնե՛ր, մեզ պետք են մի քանի սերվերներ, որոնք տեղակայված կլինեն ոչ թե Ռուսաստանում, ոչ Ամազոնում, այլ, օրինակ, ինչ-որ տեղ Ամստերդամում»: որպեսզի կարողանանք գոնե ինչ-որ կերպ այնտեղ տեղադրել մեր սեփական VPN-ը և պրոքսին որոշ վերջնակետերի համար, որոնց վրա մենք չենք կարող որևէ կերպ ազդել, օրինակ՝ նույն s3-ի վերջնակետերը, մենք չենք կարող փորձել բարձրացնել նոր ծառայություն և ստանալ այլ ip, մենք դեռ պետք է այնտեղ հասնեք: Ընդամենը մի քանի օրվա ընթացքում մենք ստեղծեցինք այս սերվերները, գործարկեցինք դրանք և, ընդհանուր առմամբ, պատրաստվեցինք արգելափակման սկսվելու պահին: Հետաքրքիր է, որ RKN-ն, նայելով աղմուկին և խուճապին, ասաց. «Ոչ, մենք հիմա ոչինչ չենք արգելափակի»: (Բայց սա հենց այն պահն է, երբ Telegram-ը սկսեց արգելափակվել:) Սահմանելով շրջանցման հնարավորությունները և հասկանալով, որ արգելափակումը չի ներդրվել, մենք, այնուամենայնիվ, չսկսեցինք կարգավորել ամբողջ հարցը: Այո, ամեն դեպքում:
Իսկ հիմա 2019 թվականին մենք դեռ ապրում ենք արգելափակման պայմաններում։ Երեկ երեկոյան նայեցի՝ շուրջ մեկ միլիոն IP-ներ շարունակում են արգելափակվել։ Ճիշտ է, Amazon-ը գրեթե ամբողջությամբ ապաշրջափակվեց, իր գագաթնակետին հասավ 20 միլիոն հասցեի... Ընդհանրապես, իրականությունն այն է, որ կարող է չլինի համահունչ, լավ համահունչ։ Հանկարծակի. Դա կարող է գոյություն չունենալ տեխնիկական պատճառներով՝ հրդեհներ, էքսկավատորներ, այդ ամենը։ Կամ, ինչպես տեսանք, ոչ ամբողջովին տեխնիկական: Հետևաբար, ինչ-որ մեկը մեծ ու մեծ, իր սեփական AS-ներով, հավանաբար կարող է դա կառավարել այլ կերպ՝ ուղիղ միացում և այլ բաներ արդեն l2 մակարդակի վրա են։ Բայց պարզ տարբերակում, ինչպիսին մերն է կամ նույնիսկ ավելի փոքր, կարող եք, ամեն դեպքում, ունենալ ավելորդություն այլ տեղ բարձրացված սերվերների մակարդակով, նախապես կազմաձևված vpn, պրոքսի, այդ հատվածներում կոնֆիգուրացիան դրանց արագ անցնելու ունակությամբ: որոնք կարևոր են ձեր կապի համար: Սա մեզ համար մեկ անգամ չէ, որ ձեռնտու էր, երբ սկսվեց Amazon-ի արգելափակումը, վատագույն դեպքում մենք միայն թույլ տվեցինք S3 երթևեկությունը դրանց միջոցով, բայց աստիճանաբար այս ամենը լուծվեց:
Ինչպե՞ս վերապահել... մի ամբողջ մատակարար:
Այս պահին մենք սցենար չունենք, եթե ամբողջ Ամազոնն ընկնի: Մենք նման սցենար ունենք Ռուսաստանի համար. Ռուսաստանում մեզ հյուրընկալել էր մեկ պրովայդեր, որից որոշեցինք ունենալ մի քանի կայքեր։ Եվ մեկ տարի առաջ մենք բախվեցինք խնդրի հետ. չնայած դրանք երկու տվյալների կենտրոններ են, կարող են խնդիրներ լինել արդեն պրովայդերի ցանցի կոնֆիգուրացիայի մակարդակում, որոնք դեռ կազդեն երկու տվյալների կենտրոնների վրա: Եվ մենք կարող ենք անհասանելի լինել երկու կայքերում: Իհարկե, այդպես էլ եղավ։ Մենք ի վերջո վերանայեցինք ներսի ճարտարապետությունը: Այն շատ չի փոխվել, բայց Ռուսաստանի համար մենք այժմ ունենք երկու կայք, որոնք ոչ թե նույն մատակարարից են, այլ երկու տարբեր կայքերից: Եթե մեկը ձախողվի, կարող ենք անցնել մյուսին:
Հիպոթետիկորեն Amazon-ի համար մենք դիտարկում ենք մեկ այլ մատակարարի մակարդակով ամրագրման հնարավորությունը. գուցե Google-ը, գուցե մեկ ուրիշը... Բայց մինչ այժմ մենք գործնականում նկատում ենք, որ մինչ Amazon-ը վթարներ է ունենում հասանելիության մեկ գոտու մակարդակով, դժբախտ պատահարները մի ամբողջ տարածաշրջանի մակարդակով բավականին հազվադեպ են: Հետևաբար, մենք տեսականորեն ունենք այն գաղափարը, որ կարող ենք կատարել «Amazon-ը Amazon չէ» վերապահումը, բայց գործնականում դա դեռ այդպես չէ:
Մի քանի խոսք ավտոմատացման մասին
Արդյո՞ք ավտոմատացումը միշտ անհրաժեշտ է: Այստեղ տեղին է հիշել Դանինգ-Կրյուգերի էֆեկտը։ «x» առանցքի վրա մեր ձեռք բերած գիտելիքներն ու փորձն է, իսկ «y» առանցքի վրա՝ վստահությունը մեր գործողությունների նկատմամբ: Սկզբում մենք ոչինչ չգիտենք և բոլորովին վստահ չենք։ Այնուհետև մենք մի քիչ գիտենք և դառնում ենք մեգավստահ. սա այսպես կոչված «հիմարության գագաթնակետն է», որը լավ պատկերված է «դեմենցիա և քաջություն» նկարով: Հետո մենք մի քիչ սովորել ենք և պատրաստ ենք մարտի գնալ։ Հետո մենք ոտք ենք դնում մեգալուրջ սխալների վրա և հայտնվում ենք հուսահատության հովտում, երբ թվում է, թե ինչ-որ բան գիտենք, բայց իրականում շատ բան չգիտենք։ Հետո փորձ ձեռք բերելով՝ ավելի ինքնավստահ ենք դառնում։
Որոշ վթարների տարբեր ավտոմատ անջատիչների վերաբերյալ մեր տրամաբանությունը շատ լավ նկարագրված է այս գրաֆիկով: Մենք սկսեցինք, մենք չգիտեինք, թե ինչպես անել, գրեթե ամբողջ աշխատանքը ձեռքով էր արվել: Հետո հասկացանք, որ կարող ենք ավտոմատացում կցել ամեն ինչին և, ինչպես, հանգիստ քնել: Եվ հանկարծ մենք ոտք ենք դնում մեգա-ռեյկի վրա. կեղծ դրական արդյունք է տեղի ունենում, և մենք փոխում ենք երթևեկությունը ետ ու առաջ, երբ, լավ իմաստով, մենք չպետք է դա անեինք: Հետևաբար, կրկնօրինակումը փչանում է կամ այլ բան. սա հենց հուսահատության հովիտն է: Եվ հետո մենք գալիս ենք այն ըմբռնմանը, որ ամեն ինչին պետք է խելամիտ մոտենալ։ Այսինքն՝ իմաստ ունի ապավինել ավտոմատացմանը՝ նախատեսելով կեղծ ահազանգերի հնարավորություն։ Բայց! եթե հետեւանքները կարող են կործանարար լինել, ապա ավելի լավ է դա թողնել հերթափոխին, հերթապահ ինժեներներին, ովքեր կհամոզվեն ու կհետևեն, որ իսկապես վթար կա, և ձեռքով կիրականացնեն անհրաժեշտ գործողությունները...
Ամփոփում
7 տարվա ընթացքում մենք գնացինք այն բանից, որ երբ ինչ-որ բան ընկնում էր, խուճապ-խուճապ էր, այն հասկացողությանը, որ խնդիրներ չկան, կան միայն առաջադրանքներ, դրանք պետք է և կարելի է լուծել։ Երբ դուք կառուցում եք ծառայություն, նայեք դրան վերևից, գնահատեք բոլոր ռիսկերը, որոնք կարող են լինել։ Եթե դրանք անմիջապես տեսնեք, ապա նախապես ապահովեք ավելորդություն և անսարքության հանդուրժող ենթակառուցվածք կառուցելու հնարավորություն, քանի որ ցանկացած կետ, որը կարող է ձախողվել և հանգեցնել ծառայության անգործունակության, անպայման դա կանի։ Եվ նույնիսկ եթե ձեզ թվում է, որ ենթակառուցվածքի որոշ տարրեր հաստատ չեն ձախողվի, օրինակ՝ s3-ը, այնուամենայնիվ հիշեք, որ դրանք կարող են: Եվ գոնե տեսականորեն, պատկերացրեք, թե ինչ եք անելու նրանց հետ, եթե ինչ-որ բան պատահի: Ունեցեք ռիսկերի կառավարման պլան: Երբ մտածում եք ամեն ինչ ինքնաբերաբար կամ ձեռքով անելու մասին, գնահատեք ռիսկերը. ի՞նչ կլինի, եթե ավտոմատացումը սկսի փոխել ամեն ինչ, դա չի՞ հանգեցնի ավելի վատ իրավիճակի, քան դժբախտ պատահարը: Թերևս ինչ-որ տեղ անհրաժեշտ է օգտագործել խելամիտ փոխզիջում ավտոմատացման կիրառման և հերթապահ ինժեների արձագանքի միջև, ով կգնահատի իրական պատկերը և կհասկանա՝ ինչ-որ բան պետք է տեղում միացնել, թե՞ «այո, բայց ոչ հիմա»:
Խելամիտ փոխզիջում կատարելության և իրական ջանքերի, ժամանակի, փողի միջև, որը դուք կարող եք ծախսել այն սխեմայի վրա, որն ի վերջո կունենաք:
Այս տեքստը համագումարում Ալեքսանդր Դեմիդովի զեկույցի թարմացված և ընդլայնված տարբերակն է .
Source: www.habr.com