Ինչպե՞ս կզգայիք ձեզ, եթե մի գեղեցիկ ամառային օր ձեր սարքավորումներով տվյալների կենտրոնը այսպիսի տեսք ունենար։
Բարև բոլորին։ Իմ անունը Դմիտրի Սամսոնով է, ես աշխատում եմ որպես առաջատար համակարգային ադմինիստրատոր ընկերությունում։Լուսանկարում պատկերված է չորս տվյալների կենտրոններից մեկը, որտեղ տեղադրված է մեր նախագիծը սպասարկող սարքավորումները։ Այս պատերի հետևում գտնվում են մոտ 4 հազար միավոր սարքավորումներ՝ սերվերներ, տվյալների պահպանման համակարգեր, ցանցային սարքավորումներ և այլն՝ մեր բոլոր սարքավորումների գրեթե ⅓-ը։
Սերվերների մեծ մասը LinuxԿան նաև մի քանի տասնյակ սերվերներ Windows (MS SQL)-ը մեր ժառանգությունն է, որը մենք համակարգված կերպով լքել ենք տարիներ շարունակ։
Այսպիսով, 5 թվականի հունիսի 2019-ին, ժամը 14:35-ին, մեր տվյալների կենտրոններից մեկի ինժեներները հայտնեցին հրդեհային տագնապի մասին։
Հրաժարում
14:45։ Տվյալների կենտրոններում ծխի աննշան դեպքերը տեղի են ունենում ավելի հաճախ, քան կարող եք պատկերացնել։ Դահլիճների ներսում ցուցիչները նորմալ էին, ուստի մեր առաջին արձագանքը համեմատաբար հանգիստ էր. մենք արգելք դրեցինք արտադրական աշխատանքների վրա, այսինքն՝ ցանկացած կոնֆիգուրացիայի փոփոխության, նոր տարբերակների թողարկման և այլնի վրա, բացառությամբ որևէ բանի վերանորոգման հետ կապված աշխատանքների։
Զայրույթ
Դուք երբևէ փորձե՞լ եք հրշեջներից պարզել, թե տանիքի որ հատվածում է հրդեհը, կամ ինքներդ բարձրանալ այրվող տանիք՝ իրավիճակը գնահատելու համար: Որքանո՞վ կվստահեիք հինգ մարդուց ստացված տեղեկատվությանը:
14- ը `50: Տեղեկություն է ստացվել, որ կրակը մոտենում է սառեցման համակարգին։Բայց կհասնի՞ այն այնտեղ։ Հերթապահ համակարգի ադմինիստրատորը հեռացնում է արտաքին երթևեկությունը այս տվյալների կենտրոնի ճակատային մասից։
Այս պահին մեր բոլոր ծառայությունների ճակատները կրկնօրինակված են երեք տվյալների կենտրոններում, հավասարակշռումը կիրառվում է DNS մակարդակում, ինչը թույլ է տալիս հեռացնել մեկ տվյալների կենտրոնի հասցեները DNS-ից, այդպիսով պաշտպանելով օգտատերերին ծառայություններին մուտք գործելու հնարավոր խնդիրներից: Եթե տվյալների կենտրոնում արդեն խնդիրներ են առաջացել, այն ավտոմատ կերպով դուրս է գալիս ռոտացիայից: Ավելին կարող եք կարդալ այստեղ՝
Հրդեհը մեզ վրա որևէ ազդեցություն չի ունեցել դեռևս. ո՛չ օգտատերերը, ո՛չ էլ սարքավորումները չեն տուժել: Սա վթար է՞: «Վթարի դեպքում գործողությունների ծրագիր» փաստաթղթի առաջին բաժնում սահմանվում է «Վթար» հասկացությունը և այն ավարտվում է հետևյալ կերպ.
«Եթե կա որևէ կասկած՝ դա պատահականություն է, թե ոչ, ապա դա պատահականություն է։»
14:53. Նշանակվում է արտակարգ իրավիճակների համակարգող։
Համակարգողը այն անձն է, որը վերահսկում է բոլոր մասնակիցների միջև հաղորդակցությունը, գնահատում է վթարի մասշտաբները, օգտագործում է «Վթարի դեպքում գործողությունների ծրագիրը», ներգրավում է անհրաժեշտ անձնակազմ, վերահսկում է վերանորոգման աշխատանքների ավարտը և, ամենակարևորը, պատվիրակում է ցանկացած առաջադրանք: Այլ կերպ ասած, սա այն անձն է, որը կառավարում է վթարի վերացման ամբողջ գործընթացը:
Գնորդը
15:01. Մենք սկսում ենք անջատել այն սերվերները, որոնք կապված չեն արտադրության հետ։
15:03. Բոլոր ամրագրված ծառայությունները ճիշտ են անջատվում։
Սա ներառում է ոչ միայն ճակատային մասերը (որոնք այս պահին օգտատերերը այլևս չեն այցելում) և դրանց օժանդակ ծառայությունները (բիզնես տրամաբանություն, քեշեր և այլն), այլև տարբեր տվյալների բազաներ՝ 2 կամ ավելի կրկնօրինակման գործակցով (, , , և այլն):
15- ը `06: Տեղեկություն է ստացվել, որ հրդեհ է սպառնում տվյալների կենտրոնի դահլիճներից մեկին։ Մենք այս դահլիճում սարքավորումներ չունենք, բայց այն փաստը, որ կրակը կարող է տանիքից տարածվել դեպի դահլիճներ, մեծապես փոխում է կատարվողի պատկերը։
(Հետագայում պարզվեց, որ դահլիճի համար ֆիզիկական սպառնալիք չկար, քանի որ այն հերմետիկորեն փակված էր տանիքից։ Սպառնալիքը միայն դահլիճի սառեցման համակարգին էր վերաբերում):
15:07. Թույլատրվում է սերվերների վրա հրամանների կատարումը արագացված ռեժիմով՝ առանց լրացուցիչ ստուգումների ().
15:08. Դահլիճներում ջերմաստիճանը նորմայի սահմաններում է։
15- ը `12: Սրահներում ջերմաստիճանի բարձրացում է գրանցվել։
15:13. Տվյալների կենտրոնի սերվերների կեսից ավելին անջատված են։ Եկեք շարունակենք։
15:16. Որոշում է կայացվել անջատել բոլոր սարքավորումները։
15:21. Մենք սկսում ենք անջատել անպետք սերվերների սնուցումը՝ առանց պատշաճ կերպով անջատելու ծրագիրը և օպերացիոն համակարգը։
15:23. MS SQL-ի համար պատասխանատու մարդկանց խումբ է հատկացվում (նրանցից քչերը կան, ծառայությունները շատ կախված չեն նրանցից, բայց ֆունկցիոնալությունը վերականգնելու ընթացակարգն ավելի շատ ժամանակ է պահանջում և ավելի բարդ է, քան, օրինակ, Cassandra-ի դեպքում):
Դեպրեսիա
15- ը `25: Տեղեկություններ են ստացվել 16 դահլիճներից չորսում (թիվ 6, 7, 8, 9) էլեկտրաէներգիայի անջատումների մասին։ Մեր սարքավորումները գտնվում են 7-րդ և 8-րդ դահլիճներում: Մեր մյուս երկու դահլիճների (համար 1 և 3) մասին տեղեկություններ չկան:
Սովորաբար, հրդեհի ժամանակ էլեկտրամատակարարումը անմիջապես անջատվում է, սակայն այս դեպքում, հրշեջների և տվյալների կենտրոնի տեխնիկական անձնակազմի համակարգված աշխատանքի շնորհիվ, այն ամենուրեք չի անջատվել և ոչ թե անմիջապես, այլ անհրաժեշտության դեպքում։
(Հետագայում պարզվեց, որ 8-րդ և 9-րդ դահլիճներում էլեկտրաէներգիան չէր անջատվել):
15:28. Մենք սկսում ենք MS SQL տվյալների բազաները տեղակայել այլ տվյալների կենտրոնների պահուստային պատճեններից։
Որքա՞ն ժամանակ կտևի դա։ Արդյո՞ք ցանցի հզորությունը բավարար կլինի ամբողջ երթուղու համար։
15- ը `37: Հաղորդվել է, որ ցանցի որոշ հատվածներ դուրս են եկել շահագործումից։
Կառավարման և արտադրական ցանցերը ֆիզիկապես մեկուսացված են միմյանցից։ Եթե արտադրական ցանցը հասանելի է, կարող եք մուտք գործել սերվեր, դադարեցնել ծրագիրը և անջատել օպերացիոն համակարգը։ Եթե այն հասանելի չէ, կարող եք մուտք գործել IPMI-ի միջոցով, դադարեցնել ծրագիրը և անջատել օպերացիոն համակարգը։ Եթե ոչ մի ցանց հասանելի չէ, ոչինչ չեք կարող անել։ «Շնորհակալություն, կապիտան», - կարող եք մտածել։
«Եվ ընդհանուր առմամբ, շատ աղմուկ է բարձրանում», կարող եք նաև մտածել։
Բանն այն է, որ սերվերները նույնիսկ առանց կրակի հսկայական քանակությամբ ջերմություն են արտադրում: Ավելի ճիշտ, երբ սառեցում կա, դրանք ջերմություն են արտադրում, իսկ երբ սառեցում չկա, ստեղծում են դժոխային դժոխք, որը լավագույն դեպքում կհալեցնի սարքավորումների մի մասը և կանջատի մյուս մասերը, իսկ վատագույն դեպքում... սենյակի ներսում հրդեհ կառաջացնի, որը գրեթե երաշխավորված է, որ ամեն ինչ կոչնչացնի:
15:39. Կոնֆ բազայի հետ կապված խնդիրների լուծում։
Conf բազան համանուն ծառայության backend-ն է, որն օգտագործվում է բոլոր արտադրական ծրագրերի կողմից՝ կարգավորումները արագ փոխելու համար: Առանց այս բազայի մենք չենք կարող կառավարել պորտալի աշխատանքը, բայց պորտալն ինքը կարող է դեռ աշխատել:
15:41։ Հիմնական ցանցային սարքավորումների ջերմաստիճանի սենսորները գրանցում են թույլատրելի առավելագույնին մոտ ջերմաստիճանի ցուցմունքներ։ Սա մի տուփ է, որը զբաղեցնում է ամբողջ դարակը և ապահովում է տվյալների կենտրոնի ներսում գտնվող բոլոր ցանցերի աշխատանքը։
15:42։ Խնդիրների հետևորդը և վիքին անհասանելի են, անցնում են սպասման ռեժիմի։
Սա արտադրություն չէ, բայց վթարի դեպքում ցանկացած գիտելիքների բազայի առկայությունը կարող է կարևոր լինել։
15:50. Մոնիթորինգի համակարգերից մեկը անջատվել է։
Դրանցից մի քանիսը կան, և դրանք պատասխանատու են ծառայությունների տարբեր ասպեկտների համար: Դրանցից մի քանիսը կարգավորված են յուրաքանչյուր տվյալների կենտրոնում ինքնուրույն աշխատելու համար (այսինքն՝ վերահսկում են միայն իրենց սեփական տվյալների կենտրոնը), մյուսները բաղկացած են բաշխված բաղադրիչներից, որոնք թափանցիկորեն գոյատևում են ցանկացած տվյալների կենտրոնի կորստից հետո:
Այս դեպքում այն դադարեց աշխատել , որը գործում է գլխավոր սպասման ռեժիմում: Անցված է սպասման ռեժիմի:
Որդեգրում
15:51։ Բոլոր սերվերները, բացառությամբ MS SQL-ի, անջատվել են IPMI-ի միջոցով՝ առանց պատշաճ անջատման։
Պատրա՞ստ եք անհրաժեշտության դեպքում IPMI-ի միջոցով զանգվածային սերվերի կառավարմանը։
Հենց այն պահը, երբ տվյալների կենտրոնում գտնվող սարքավորումների փրկարարական աշխատանքները այս փուլում ավարտված են։ Ամեն ինչ, ինչ հնարավոր էր անել, արդեն արված է։ Որոշ գործընկերներ կարող են հանգստանալ։
16- ը `13: Տեղեկություն է ստացվել, որ տանիքի վրա գտնվող օդորակիչների ֆրեոնային խողովակները պայթել են. դա կհետաձգի տվյալների կենտրոնի գործարկումը հրդեհի մարումից հետո։
16:19. Տվյալների կենտրոնի տեխնիկական անձնակազմից ստացված տվյալների համաձայն՝ դահլիճներում ջերմաստիճանի բարձրացումը դադարել է։
17:10. conf տվյալների բազան վերականգնվել է։ Հիմա մենք կարող ենք փոխել ծրագրի կարգավորումները։
Ինչո՞ւ է սա այդքան կարևոր, եթե ամեն ինչ խափանումների նկատմամբ դիմացկուն է և աշխատում է նույնիսկ առանց մեկ տվյալների կենտրոնի։
Նախ, ամեն ինչ չէ, որ խափանումների նկատմամբ դիմացկուն է: Կան տարբեր երկրորդական ծառայություններ, որոնք բավարար չափով չեն դիմանում տվյալների կենտրոնի խափանումներին, և կան տվյալների բազաներ, որոնք գտնվում են գլխավոր սպասման ռեժիմում: Կարգավորումները կառավարելու հնարավորությունը թույլ է տալիս անել ամեն ինչ, որպեսզի նվազագույնի հասցվի վթարի ազդեցությունը օգտատերերի վրա նույնիսկ դժվար պայմաններում:
Երկրորդ, պարզ դարձավ, որ տվյալների կենտրոնը լիովին չի վերականգնվի առաջիկա ժամերի ընթացքում, ուստի անհրաժեշտ էր միջոցներ ձեռնարկել՝ ապահովելու համար, որ կրկնօրինակների երկարաժամկետ անհասանելիությունը չհանգեցնի լրացուցիչ խնդիրների, ինչպիսիք են սկավառակի գերբեռնվածությունը մնացած տվյալների կենտրոններում։
17:29. Պիցցայի ժամանակն է։ Մենք աշխատանքի ենք վերցնում մարդկանց, ոչ թե ռոբոտների։
Վերականգնում
18:02։ Ջերմաստիճանը կայունացել է #8 (մեր), 9, 10 և 11 դահլիճներում։ Անջատվածներից մեկում (#7) մեր սարքավորումներն են, և այնտեղ ջերմաստիճանը շարունակում է բարձրանալ։
18:31։ Թույլտվություն է տրվել 1-ին և 3-րդ դահլիճներում սարքավորումները գործարկելու համար. այդ դահլիճները հրդեհից չեն տուժել։
Այս պահին սերվերները գործարկվում են #1, 3, 8 սրահներում՝ սկսած ամենակարևորներից։ Ստուգվում է բոլոր գործարկված ծառայությունների ճիշտ աշխատանքը։ 7-րդ սրահի հետ դեռևս խնդիրներ կան։
18:44. Տվյալների կենտրոնի տեխնիկական անձնակազմը հայտնաբերեց, որ #7 սրահում (որտեղ գտնվում են միայն մեր սարքավորումները) շատ սերվերներ անջատված չեն։ Մեր տվյալներով՝ այնտեղ մնում է 26 սերվեր։ Երկրորդ ստուգումից հետո մենք գտնում ենք 58 սերվեր։
20:18: Տվյալների կենտրոնի տեխնիկները միջանցքներում տեղադրված շարժական օդային խողովակների միջոցով օդ են փչում օդորակիչ չունեցող սենյակ:
23:08։ Առաջին ադմինիստրատորին տուն ուղարկեցին։ Մեկը պետք է այսօր գիշեր քնի, որպեսզի վաղը շարունակի աշխատանքը։ Հետո մենք ևս մի քանի ադմինիստրատորների և ծրագրավորողների կուղարկենք։
02:56. Մենք գործարկեցինք այն ամենը, ինչ հնարավոր էր գործարկել: Մենք իրականացնում ենք բոլոր ծառայությունների լայնածավալ ստուգում՝ ավտոմատ թեստերի միջոցով:
03:02. Վերջին, 7-րդ դահլիճի օդորակիչը վերականգնվել է։
03:36. Տվյալների կենտրոնի ճակատային մասերը DNS-ում ռոտացիայի են ենթարկվել։ Այս պահից սկսած՝ օգտատերերի երթևեկությունը սկսում է հոսել։
Մենք վարչական թիմի մեծ մասին տուն ենք ուղարկում։ Բայց մի քանիսին էլ թողնում ենք։
Փոքրիկ Հաճախակի տրվող հարցեր.
Հարց. Ի՞նչ է տեղի ունեցել 18:31-ից մինչև 02:56-ը։
Ա. «Արտակարգ գործողությունների պլանին» հետևելով՝ մենք գործարկում ենք բոլոր ծառայությունները, սկսած ամենակարևորներից: Միաժամանակ, չաթում համակարգողը ծառայությունը տրամադրում է անվճար ադմինիստրատորին, որը ստուգում է, թե արդյոք օպերացիոն համակարգը և հավելվածը գործարկվել են, արդյոք կան սխալներ, արդյոք ցուցանիշները նորմալ են: Գործարկման ավարտից հետո նա չաթում հայտնում է, որ ազատ է, և համակարգողից ստանում է նոր ծառայություն:
Գործընթացը լրացուցիչ դանդաղում է սարքավորումների խափանումների պատճառով: Նույնիսկ եթե օպերացիոն համակարգի և սերվերի անջատումը ճիշտ է եղել, որոշ սերվերներ չեն վերադառնում սկավառակների, հիշողության և շասսիի հանկարծակի խափանման պատճառով: Երբ էլեկտրաէներգիան անջատվում է, խափանումների տոկոսը մեծանում է:
Հարց. Ինչո՞ւ չենք կարող ամեն ինչ միանգամից գործարկել, ապա շտկել մոնիթորինգի ընթացքում ի հայտ եկածը։
Ա. Ամեն ինչ պետք է արվի աստիճանաբար, քանի որ ծառայությունների միջև կան կախվածություններ: Եվ ամեն ինչ պետք է ստուգվի անմիջապես՝ առանց մոնիթորինգի սպասելու, քանի որ ավելի լավ է անմիջապես լուծել խնդիրները, քան սպասել դրանց վատթարացմանը:
7:40։ Վերջին ադմինիստրատորը (կոորդինատորը) գնաց քնելու։ Առաջին օրվա աշխատանքն ավարտված է։
Ժամը 8:09-ին Առաջին մշակողները, տվյալների կենտրոնի ինժեներները և ադմինիստրատորները (ներառյալ նոր համակարգողը) սկսել են վերականգնման աշխատանքները։
09:37. Մենք սկսել ենք բարձրացնել 7-րդ դահլիճը (վերջինը):
Զուգահեռաբար, մենք շարունակում ենք վերականգնել այն, ինչը չէր վերանորոգվել մյուս սենյակներում՝ փոխարինելով սկավառակները/հիշողությունը/սերվերները, շտկելով մոնիտորինգի ժամանակ «այրվող» ամեն ինչ, դերերի վերադարձը master-standby սխեմաներում և այլ մանրուքներ, որոնք, այնուամենայնիվ, բավականին շատ են։
17:08. Մենք թույլատրում ենք արտադրական բոլոր կանոնավոր աշխատանքները։
21։45։ Երկրորդ օրվա աշխատանքն ավարտված է։
09:45. Այսօր ուրբաթ է։ Մոնիթորինգի հետ կապված դեռ կան մի քանի մանր խնդիրներ։ Շաբաթավերջը մոտենում է, բոլորը ուզում են հանգստանալ։ Մենք շարունակում ենք մասսայաբար շտկել այն ամենը, ինչ կարող ենք։ Հետաձգվել են կանոնավոր վարչական առաջադրանքները, որոնք կարող էին հետաձգվել։ Կա նոր համակարգող։
15:40։ ՄԵԿ ԱՅԼ տվյալների կենտրոնում Core Network սարքավորումների կեսը հանկարծակի վերագործարկվեց։ Ռիսկերը նվազագույնի հասցնելու համար առջևի մասերը հանվեցին ռոտացիայից։ Օգտատերերի վրա ազդեցություն չի եղել։ Հետագայում պարզվել է, որ խնդիրը շասսիի անսարքությունն է եղել։ Համակարգողը աշխատում է միաժամանակ երկու վթարը շտկելու ուղղությամբ։
17:17. Մեկ այլ տվյալների կենտրոնում ցանցի աշխատանքը վերականգնվել է, ամեն ինչ ստուգվել է։ Տվյալների կենտրոնը դրվել է ռոտացիայի։
18։29։ Երրորդ օրվա աշխատանքները և, ընդհանուր առմամբ, վթարից հետո վերականգնումն ավարտված են։
Հետո
04.04.2013 գ., , «Դասընկերներ» —երեք օր պորտալը լիովին կամ մասնակիորեն անհասանելի էր։ Այս ամբողջ ընթացքում տարբեր քաղաքներից, տարբեր ընկերություններից (կրկին շնորհակալություն!) ավելի քան 100 մարդ, հեռակա և անմիջապես տվյալների կենտրոններում, ձեռքով և ավտոմատ կերպով վերանորոգել է հազարավոր սերվերներ։
Մենք եզրակացություններ ենք արել։ Նման բանի կրկնությունը կանխելու համար մենք մինչ օրս իրականացրել և շարունակում ենք իրականացնել լայնածավալ աշխատանք։
Որո՞նք են ներկայիս վթարի և 404-ի միջև հիմնական տարբերությունները։
- Մենք ունենք «Աղետի գործողությունների ծրագիր»։ Եռամսյակը մեկ անգամ մենք անցկացնում ենք վարժանք՝ խաղում ենք արտակարգ իրավիճակ, որը ադմինիստրատորների խումբը (բոլորը հերթով) պետք է լուծի «Աղետի գործողությունների ծրագրի» միջոցով։ Առաջատար համակարգի ադմինիստրատորները հերթով կատարում են համակարգողի դերը։
- Յուրաքանչյուր եռամսյակ, փորձնական ռեժիմով, մենք մեկուսացնում ենք տվյալների կենտրոնները (բոլորը հերթով) LAN և WAN ցանցերի միջոցով, ինչը թույլ է տալիս մեզ ժամանակին հայտնաբերել խոչընդոտները։
- Ավելի քիչ կոտրված սկավառակներ, քանի որ մենք խստացրել ենք չափանիշները՝ ավելի քիչ աշխատանքային ժամեր, SMART-ի համար ավելի խիստ շեմային արժեքներ,
- Մենք ամբողջությամբ հրաժարվեցինք BerkeleyDB-ից, որը հին և անկայուն տվյալների բազա էր, որը սերվերի վերագործարկումից հետո երկար ժամանակ էր պահանջում վերականգնվելու համար։
- Նվազեցվեց MS SQL-ով սերվերների քանակը և նվազեցվեց կախվածությունը մնացածներից։
- Մենք ունենք մեր սեփականը , որտեղ մենք արդեն երկու տարի ակտիվորեն տեղափոխում ենք բոլոր ծառայությունները։ Ամպային տեխնոլոգիաները զգալիորեն պարզեցնում են հավելվածի հետ աշխատանքի ամբողջ ցիկլը, իսկ վթարի դեպքում այն տրամադրում է այնպիսի եզակի գործիքներ, ինչպիսիք են՝
- բոլոր ծրագրերի ճիշտ դադարեցումը մեկ սեղմումով;
- ծրագրերի հեշտ տեղափոխում անսարք սերվերներից;
- Ամբողջ տվյալների կենտրոնի ավտոմատ, դասակարգված (ծառայության առաջնահերթության կարգով) մեկնարկը։
Այս հոդվածում նկարագրված վթարը ամենամեծն էր 404-րդ օրվանից ի վեր։ Իհարկե, ամեն ինչ հարթ չէր ընթացել։ Օրինակ, մինչ հրդեհի հետևանքով վնասված տվյալների կենտրոնը անհասանելի էր, մեկ այլ տվյալների կենտրոնի սերվերներից մեկի վրա սկավառակը խափանվեց, ինչը նշանակում էր, որ Cassandra կլաստերի երեք կրկնօրինակներից միայն մեկը մնաց հասանելի, այդ իսկ պատճառով բջջային հավելվածների օգտատերերի 4,2%-ը չկարողացավ մուտք գործել։ Միևնույն ժամանակ, արդեն միացված օգտատերերը շարունակեցին աշխատել։ Ընդհանուր առմամբ, վթարի հետևանքով հայտնաբերվել է ավելի քան 30 խնդիր՝ սկսած սովորական սխալներից մինչև ծառայության ճարտարապետության թերություններ։
Սակայն ներկայիս և 404-րդ վթարի միջև հիմնական տարբերությունն այն է, որ մինչ մենք վերացնում էինք հրդեհի հետևանքները, օգտատերերը շարունակում էին հաղորդագրություններ ուղարկել և տեսազանգեր կատարել։ , խաղեր խաղացին, երաժշտություն լսեցին, միմյանց նվերներ տվեցին, տեսանյութեր, հեռուստասերիալներ և հեռուստաալիքներ դիտեցին , և նաև հեռարձակվել է .
Ինչպե՞ս են անցնում ձեր վթարները։
Source: www.habr.com
