Սցենարներից մեր սեփական հարթակին. Ինչպես ավտոմատացրեցինք զարգացումը ЦИАН-ում

RIT 2019-ին մեր գործընկեր Ալեքսանդր Քորոտկովը ներկայացրեց գրականություն ЦИАН-ում ծրագրի զարգացման ավտոմատացման մասին. Հեշտացնելու համար, մենք օգտագործում ենք մեր սեփական Integro հարթակը: Դա հետևում է խնդիրների կյանքի ձևին, ազատում է ծրագրավորողներին պարբերական գործողություններից և զգալիորեն նվազեցնում է production-ում հայտնված սխալների քանակը: Այս հրապարակմամբ մենք լրացրել ենք Ալեքսանդրի զեկույցը և կպատմենք, թե ինչպես ենք անցել պարզ սցենարներից դեպի open source արտադրանքների միացում մեր սեփական հարթակի միջոցով և՝ ինչով է զբաղված առանձին ավտոմատացման թիմը:
 

Զրոյական մակարդակ

«Զրոյական մակարդակ չի լինում, ես նման բան չեմ ճանաչում»
Մայստեր Շիֆու «Կունգ-ֆու պանդա» մուլտիվ ից

ЦИАН-ում ավտոմատացումը սկսվեց 14 տարի անց՝ ընկերության հիմնադրման: Այդ ժամանակ ուսումնական թիմում 35 մարդ էր: Հոգնեցուցիչ է հավատալ, էյ? Հ当然, որ մեկ կերպ ավտոմատացումը արդեն գոյություն ուներ, բայց շարունակական ինտեգրացման և կոդի մատակարարում տեխնոլոգիայով առանձին ուղղություն սկսեց ձևավորվել միայն 2015 թվականին: 

Այդ պահին մենք ունեինք ահռելի միահամույթ Python, C# և PHP—ի վրա՝ տեղադրված Linux/Windows սերվերներում: Այս հսկան տեղադրման համար ունեինք ձեռքով ընթացագիր, որը գործարկում էինք: Ինքնակարգավորումն ևս խնդիր էր, որը բերում էր ցավ ու տառապանքների՝ ճյուղերի միավորման ընդմիջումներից, նվազեցման սխալներից և «մյուս խնդիրների հավաքածուի» վերակազմավորումից: Սահմանափակորեն գործընթացը այսպես էր բխում.

Սա մեզ չէին բավարարում, և մենք ցանկանում էինք ստեղծել կրկնվող, ավտոմատացված և կառավարվող գործընթացի հավաքում ու տեղադրում: Այս համար մեզ պետք էր CI/CD համակարգ, և մենք ընտրում էինք Teamcity-ի ազատ տարբերակն ու ազատ Jenkins-ը, քանի որ մենք աշխատում էինք դրանց հետ, և երկուսն էլ մեզ հարմար էին ֆունկցիոնալության հավաքածուով: Ընտրեցինք Teamcity-ը, որպես ավելի նոր արտադրանք: Այդ ժամանակ մենք դեռ չէինք օգտագործում միկրոservices ճարտարապետություն և չէինք սպասում շատ հարցերի ու նախագծերի:

Կանգնում ենք մեր սեփական համակարգի գաղափարի մոտ

Teamcity-ի ներդրումը միայն մասնակի կերպով վերացրեց ձեռնարկային աշխատանքը՝ դեռ մնալով Pull Request-ների ստեղծումը, Jira-ում հարցերի առաջընթացը և թողարկման հարցերի ընտրությունը։ Teamcity-ն արդեն չէր կարողանում հաղթահարել այս խնդիրները։ Մնացել էր հետագա մեխանիզացման ճանապարհ ընտրելու հարցը։ Մենք դիտարկում էինք Teamcity-ում սցենարներով աշխատելու տարբերակները կամ անցնել երրորդ կողմի մեխանիզացման համակարգեր։ Սակայն, ի վերջո, որոշեցինք, որ մեզ հարկավոր է առավելագույն ճկունություն, որը կարող էր ապահովել միայն մեր սեփական լուծումը։ Այնպես հայտնվեց՝ ներքին մեխանիզացման համակարգի առաջին տարբերակը՝ Integro։

Teamcity-ն զբաղվում է մեխանիզացման երևույթով, ինչը վերաբերում է կառուցման և տեղադրման գործընթացների մեկնարկին, իսկ Integro-ն կենտրոնանալով ծրագրավորման գործընթացների վերին մակարդակի մեխանիզացման վրա։ Հետադրված աշխատանքը պետք է միավորեր Jira-ում գտնվող հարցերը՝ Bitbucket-ում չափազանց համապատասխան աղբյուրային կոդի մշակումը։ Այս փուլում Integro-ում սկսեցին հայտնվել իրենց հոսքագրերը տարբեր տեսակի հարցերի հետ աշխատելու համար։ 

Մեխանիզացիայի մեծացման պատճառով բիզնես-փորձառություններում ավելացավ Teamcity-ում նախագծերի և գործողությունների թիվը։ Այսպիսով, առաջ եկավ նոր խնդիր. մեկ անվճար Teamcity-instance-ը քիչ էր (3 գործակալ և 100 նախագիծ), մենք ավելացրեցինք ևս մեկ instance (մյուս 3 գործակալ և 100 նախագիծ)։ Բոլոր դեպքերում, մենք ստացանք մի քանի կլաստերներից բաղկացած համակարգ, որը դժվար էր կառավարել։

Երբ քննարկվում էր 4-րդ instance-ի հարցը, մենք հասկացանք, որ այսպես շարունակել չենք կարող, քանի որ 4 instance-ի աջակցման համախառն ծախսերը արդեն դուրս էին գալիս ցանկացած շրջանակներից։ Որոշվեց կանչել վճարովի Teamcity կամ ընտրել անվճար Jenkins-ի օգտին։ Մենք հաշվում էինք instance-ների և մեխանիզացման ծրագրերի շուրջ և կարիք շատ կար, որ մենք տեղափոխվենք Jenkins-ի։ Մի քանի շաբաթ հետո մենք անցանք Jenkins-ին և ազատեցինք մեզ մի մասը գլխացավանքից, որը կապված էր մի քանի Teamcity-instance-ների աջակցման հետ։ Ուստի կարողացանք կենտրոնանալ Integro-ի մշակմանը և Jenkins-ը բարելավելու հարցում։

Բազային ավտոմատացման աճի (ջղայնացված Pull Request-ների ավտոմատ ստեղծումն, Code coverage-ի հավաքումը և հրապարակումը, ինչպես նաև այլ ստուգումներ) հետ սկսվեց հաստատակամ ցանկություն ամբողջությամբ հրաժարվել ձեռքով թողարկումներից և այս աշխատանքը հանձնել ռոբոտներին: Բացի դրանից, ընկերությունում սկզբնավորվեց միկրոըառումների անցում, որոնք պահանջում էին հաճախակի թողարկումներ, և առավել ևս յուրաքանչյուրն առանձին: Այդպես մենք աստիճանաբար հասնում ենք մեր միկրոըառումների ավտոմատ թողարկումներին (մոնոլիտը դեռ ձեռքով ենք թողարկում, մեծացած գործընթացի պատճառով): Սակայն, ինչպես սովորաբար լինում է, առաջացավ նոր բարդություն. 

Ավտոմատizando թեստավորումը

Թողարկումների ավտոմատացման շնորհիվ զարգացման գործընթացները արագացան, մասամբ՝ որոշ թեստավորման փուլերը բաց թողնելու հաշվին: Դա առաջացրեց ժամանակավոր որակի կորուստ: Հարցը թվում է ակնհայտ, բայց թողարկումների արագացման հետ միասին անհրաժեշտ էր փոփոխել նաև արտադրանքի զարգացման methodology-ն: Պետք էր մտածել թեստավորման ավտոմատացման, անձնական պատասխանատվության (այստեղ խոսքը վերաբերում է «միտքին ընդունելուն», այլ ոչ թե ֆինանսական տուգանքներին) նկատմամբ մշակողների համար թողարկված կոդի և դրա վրայով բգերերի, ինչպես նաև թողարկման/չթողարկման որոշման մասին՝ ավտոմատ տեղադրումների միջոցով. 

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

Ավտոմատացման թիմ

Այժմ մեզ մոտ աշխատում են 130 ծրագրավորողներ, և մենք շարունակում ենք ճանապարհները. Անհրաժեշտության տեսլականն ու ԴևՕպս ծրագրերի անդորրը (ցանկացած դեպքում— Deploy and Integration թիմ) բաղկացած է 7 մարդուց և աշխատում է 2 ուղղություններով՝ Integro ավտոմատացման հայտնի պլատֆորմի զարգացման եւ DevOps-ի. 

DevOps պատասխանատու է CIAN-ի Dev/Beta միջավայրերի, Integro-ի միջավայրերի համար, օգնում է ծրագրավորողներին խնդիրները լուծելու մեջ և նոր մոտեցումներ մշակելու տեսանկյունից միջավայրերի ընդլայնման։ Integro-ի զարգացման ուղղությունը զբաղվում է ինչպես Integro-ով, այնպես էլ հարակից ծառայություններով, օրինակ՝ Jenkins, Jira, Confluence պլագիններով, ինչպես որ զարգացնում է լրացուցիչ գործիքներ և ծրագրեր ծրագրավորող թիմերի համար։ 

DI թիմը աշխատում է համատեղ Պլատֆորմայի թիմի հետ, որը զբաղվում է ընկերության ներսում ճարտարապետության, գրադարանների և զարգացման մոտեցումների մշակմամբ։ Բացի դրանից, ցանկացած ծրագրավորող CIAN-ի ներսում կարող է մասնակցել ավտոմատացման աշխատանքներին, օրինակ՝ կատարել միկրոավտոմատացում թիմի կարիքների համար կամ կիսվել լավ գաղափարով, թե ինչպես դարձնել ավտոմատացումը ավելի լավ։

CIAN-ում ավտոմատացման շերտավոր կարկանդակ

Ավտոմատացման մեջ ներգրավված բոլոր համակարգերը կարելի է բաժանել մի քանի շերտերի.

1. Արտաքին համակարգեր (Jira, Bitbucket և այլն). Դրանց հետ աշխատում են ծրագրավորման թիմերը.
2. Integro պլատֆորմա. Դրանց հետ որպես կանոն ծրագրավորողները չեն աշխատում ուղղակիորեն, բայց հենց այդ պլատֆորման ապահովում է ամբողջ ավտոմատացման աշխատանքը.
3. Ներդրման, օրկեստրացման և հայտնաբերման ծառայություններ (օրինակ՝ Jenkins, Consul, Nomad). Դրանց միջոցով մենք կոդը ներդնում ենք սերվերներում և ապահովում ենք ծառայությունների բաշխումը միմյանց հետ.
4. Ֆիզիկական մակարդակ (սերվերներ, ՕՀ, հարակից ծրագրակազմ). Այս մակարդակում աշխատում է մեր կոդը: Սա կարող է լինել թե՛ ֆիզիկական սերվեր, թե՛ վիրտուալ (LXC, KVM, Docker).

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

Integro

Հանդիպենք Integro-ի վրա և սկսենք տեխնոլոգիական стекից.

• CentOs 7
• Docker + Nomad + Consul + Vault
• Java 11 (հին Integro մոնոլիտը կմնա Java 8-ի վրա)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• RabbitMQ 
• Apache Ignite
• Camunda (embedded)
• Grafana + Graphite + Prometheus + Jaeger + ELK
• Web UI: React (CSR) + MobX
• SSO: Keycloak

Մեր ուժգնությունը միկրո ծառայությունների զարգացման սկզբունքին է, մինչդեռ մեզ մոտ կա նաև նախկինի ինտեգրացիան՝ հին Integro մոնոլիտի տեսքով: Յուրաքանչյուր միկրո ծառայություն գործարկվում է իր docker կոնտեյնում, ծառայությունները հաղորդակցվում են HTTP հարցումների և RabbitMQ հաղորդագրությունների միջոցով: Միկրո ծառայությունները գտնում են միմյանց միջոցով Consul և կատարում են հարցումներ, անցնելով SSO (Keycloak, OAuth 2/OpenID Connect) միջոցով:

Ավելի իրական օրինակով դիտենք Jenkins-ով փոխգործակցություն, որը բաղկացած է հետևյալ քայլերից:

1. Workflow-ի կառավարիչ միկրո ծառայությունը (հաջորդիվ Flow-միկրո ծառայություն) ցանկանում է սկսել հավաքումը Jenkins-ում: Այս նպատակով նա միջոցով Consul գտնում է IP:PORT Jenkins-֊ի ինտեգրացիայի միկրո ծառայության (հաջորդակա Jenkins-միկրո ծառայություն) և ուղարկում է նրան ասինխրոն հարցում Jenkins-֊ում հավաքումը սկսելու համար:
2. Jenkins-միկրո ծառայությունը, ստանալով հարցումը, ձևավորում և վերադարձնում է պատասխան Job ID, որով գոյություն կունենա վերջին արդյունքը հաստատելու համար: Դրա հետ միասին նա Jenkins-֊ում սկսում է հավաքումը REST API-֊ի միջոցով:
3. Jenkins-֊ը կատարում է հավաքումը, և ավարտելուց հետո նա ուղարկում է webhook արդյունքներով Jenkins-միկրո ծառայությանը:
4. Jenkins-միկրո ծառայությունը, ստանալով webhook-ը, ձևավորում է հարցման ավարտի հազնվորը և կապում նրան ավարտին ձեռք են բերված արդյունքները: Հայտնի հաղորդագրությունը ուղարկվում է RabbitMQ հերթին:
5. RabbitMQ-֊ի միջոցով հրապարակված հաղորդագրությունը հասնում է Flow-միկրո ծառայությանը, որը տեղեկանում է իր խնդրի մշակման արդյունքի մասին, համեմատելով հարցման Job ID-֊ն և ստացված հաղորդագրության Job ID-ը:

Այս պահին մենք ունենք մոտ 30 միկրո ծառայություններ, որոնք կարելի է բաժանել մի քանի խմբերի:

1. Կոնֆիգուրացիաների կառավարում:
2. Օգտվողներին տեղեկացնելը և փոխգործակցությունը (մեսենջերներ, ուսումնական միջոցներ):
3. Տեսակացի կոդի հետ աշխատելը:
4. Վերակումային գործիքների (jenkins, nomad, consul և այլն) ինտեգրացիա:
5. Մոնիթորինգ (հրապարակումների, սխալների և այլն):
6. Web ժամանցային գործիքներ (UI թեստային միջավայրերի կառավարման համար, վիճակագրություն հավաքելու և այլն):
7. Տասք-տրեկերների և նման համակարգերի ինտեգրացիա:
8. Աշխատանքի ռազմավարություն տարբեր խնդիրների համար:

Ֆլոու խնդիրների

Integro-֊ն ավտոմատացնում է խնդիրների կյանքի ցիկլի հետ կապված գործողությունները: Հայեցակարգով խնդիրների կյանքի ցիկլի տակ մենք հասկանում ենք Jira-֊ում խնդիրների workflow-ն: Մեր մշակման գործընթացում կախված նախագծից, խնդիրների տեսակներից և հատուկ ընտրանքներից, գոյություն ունի մի քանի տարբերակների workflow: 

Դիտենք workflow, որը մենք հաճախ օգտագործում ենք:

Նկարագիրը ցույց է տալիս, որ անցումը ավտոմատ կերպով սկսվում է Integro-ի կողմից, մինչդեռ մարդու նկարը նշանակում է, որ անցումը սկսվում է մարդու կողմից: Рассмотрим несколько путей, по которым задача может пройти в этом workflow.

Լրիվորեն ձեռքով իրականացվող փորձարկում DEV+BETA-ին առանց կանաչ լույսի փորձարկումների (ամբողջականը սովորաբար թողարկվում է մոնոլիտ):

Կա նաև այլ անցումների համադրություններ: Որոշ ժամանակ, այդ ճանապարհը, որով առաջադրանքը կարող է անցնել, կարելի է ընտրել Jira-ի տարբերակների միջոցով:

Առաջադրանքի շարժում

Եկեք դիտարկենք հիմնական քայլերը, որոնք իրականացվում են, երբ առաջադրանքը շարժվում է «DEV փորձարկում + կանաչ լույսի փորձարկումներ» աշխատանքային հոսքում:

1. Զարգացուցիչը կամ PM-ն ստեղծում է առաջադրանքը:

2. Զարգացուցիչը վերցնում է առաջադրանքը աշխատանքի: Այն ավարտվելուց հետո փոխանցում է այն IN REVIEW վիճակին:

3. Jira-ն ուղարկում է Webhook դեպի Jira-мիկրոսերվիս (պատասխանատու է Jira-ի ինտեգրման համար):

4. Jira-мիկրոսերվիսը ուղարկում է հարցում Flow-сервисին (պատասխանատու է ներքին workflow-ների համար, որտեղ կատարվում է աշխատանքը) աշխատանքային հոսքի մեկնարկի համար:

5. Flow-сервисի ներսում:

• Ավարտելիքների նշվածի վերնագրություններ назначаются для задачи (Users-мիկրոսервիս, որը գիտի բոլոր օգտատերերի մասին + Jira-мիկրոսервիս):
• Source-мիկրոսервիսով (գիտի ռեպոզիտորների և ճյուղերի մասին, բայց չի աշխատում ինքն՝ կոդի հետ) իրականացվում է որոնում ռեպոզիտորների, որտեղ կա մեր առաջադրանքի ճյուղ (հեշտացնելու համար որոնումը ճյուղի անունը համընկնում է Jira-ի առաջադրանքի համարի հետ): Հաճախ առաջադրանքը ունի միայն մեկ ճյուղ մեկ ռեպոզիտորիայում, որը հեշտացնում է տեղադրումների հերթի կառավարումը և նվազեցնում միջև ռեպոզիտորների կապը:
• Ահա յուրաքանչյուր հայտնաբերված ճյուղի համար կատարվող գործողությունների հաջորդականությունը:

  i) Master ճյուղի միացման (Git-мիկրոսервիսի համար, որը աշխատում է կոդի հետ):
  ii) Ճյուղը փակվում է փոփոխություններից մշակողին (Bitbucket-мիկրոսервիս):
  iii) Այդ ճյուղի համար ստեղծվում է Pull Request (Bitbucket-мիկրոսервիս):
  iv) Նոր Pull Request-ի մասին հաղորդագրություն է ուղարկվում զարգացողների զրույցներին (Notify-мիկրոսервիս, որը աշխատում է ծանուցումների հետ):
  v) Կատարվում է հավաքում, փորձարկում և առաջադրանքի տեղադրում DEV-ի վրա (Jenkins-мիկրոսервիս, որը աշխատում է Jenkins-ի հետ):
  vi) Եթե բոլոր նախորդ կետերը հաջող ավարտվեցին, ապա Integro-ն իր Approve-ն տեղադրում է Pull Request-ում (Bitbucket-мիկրոսервիս):

• Integro-ն սպասում է Pull Request-ի մեջ նշանակված վերանայողների Approve-ին:
• Ինչպես միայն անհրաժեշտ Approve-ները ստացվեն (նաև դրական անցողիկ փորձարկումները), Integro-ն տեղափոխում է առաջադրանքը Test on Dev վիճակին (Jira-мիկրոսервիս):

6. Թեսթավորողները կատարում են առաջադրանքի թեսթավորում: Եթե խնդիրներ չկան, ապա անցնում են առաջադրանքն 'Ready For Build' կարգավիճակին:

7. Integro-ն 'տեսնում է', որ առաջադրանքը պատրաստ է թողարկման, և սկսում է նրան տեղադրել զույգ ռեժիմում (Jenkins միկրոսերվիս): Թողարկման պատրաստությունը որոշվում է կանոնների խմբով: Օրինակ, առաջադրանքը անհրաժեշտ կարգավիճակում է, այլ առաջադրանքների համար չկա արգելքներ, այժմ չկա այս միկրոսերվիսի դինամիկ արտադրման և այլն:

8. Առաջադրանքը անցնում է 'Canary' կարգավիճակին (Jira միկրոսերվիս):

9. Jenkins-ն սկսում է через Nomad-ով առաջադրանքի տեղադրման գործընթացը զույգ ռեժիմում (հաճախ 1-3 ինստանսים) և ծանուցում է թողարկման մոնիտորինգի ծառայությունն (DeployWatch միկրոսերվիս):

10. DeployWatch միկրոսերվիսը հավաքում է սխալների ֆոնը և արձագանքում է նրան, եթե դա անհրաժեշտ է: Եթե սխալների ֆոնը գերազանցում է գիծը (ֆոնի նորման հաշվարկվում է ավտոմատապես), ծրագրավորողներին ծանուցում է կատարվում Notify միկրոսերվիսի միջոցով: Եթե 5 րոպե ընթացքում ծրագրավորողը չի արձագանքել (մի կտտացնում է Revert կամ Stay), ապա սկսվում է ավտոմատ հետադարձ կապի գործարկում: Եթե ֆոնը չգերազանցվում է, ապա ծրագրավորողը պետք է ձեռքով տեղադրի առաջադրանքը Production-ում (UI-ում կոճակը կտտացնելով): Եթե 60 րոպե ընթացքում ծրագրավորողը չի գործարկել տեղադրումը Production-ում, ապա զույգ ինստանսներն անվտանգության նկատառումներով նույնպես կփակվեն:

11. Production-ում տեղադրումը սկսելուց հետո:

• Առաջադրանքը անցնում է 'Production' կարգավիճակին (Jira միկրոսերվիս):
• Jenkins միկրոսերվիսը սկսում է տեղադրման գործընթացը և ծանուցում է թողարկման DeployWatch միկրոսերվիսին:
• DeployWatch միկրոսերվիսը verifica հերթափոխն այնպես, որ Production-ում բոլոր կոնտեյները թարմացվել են (եղել են դեպքեր, երբ բոլորի թարմացումները չեղել են):
• Notify միկրոսերվիսի միջոցով ուղարկվում է տեղադրման արդյունքների ծանուցում Production-ում:

12. Ծրագրավորողներին 30 րոպե կտրվի, որպեսզի հետադարձ կապի առաջադրանքը սկսել Production-ից այն դեպքում, երբ միկրոսերվիսի անխուսափելի վարքագիծ հայտնաբերվի: Այս ժամանակից հետո առաջադրանքը ավտոմատ կերպով շրջանառվելու է master-ում (Git միկրոսերվիս):

13. Սմեղ վերջին merge-ի ընթացքում master-ում առաջադրանքի կարգավիճակը կփոխվի 'Closed' (Jira միկրոսերվիս):

Սքեման չի հավակնում ամբողջական մանրամասնության (իրականում քայլեր ավելի շատ են), բայց թույլ է տալիս գնահատել ինտեգրման աստիճանը գործընթացներում: Մենք չենք համարվում այս սխեման իդիալ, և բարելավում ենք թողարկումների և տեղադրման ավտոմատ կառավարումը.

Ի՞նչ է հաջորդը

Մենք մեծ ծրագրեր ունենք ավտոմատացման զարգացման համար, օրինակ՝ ձեռնարկությունների գործառույթների ավտոմատացում՝ մոնոլիտի թողարկման ժամանակ, ավտոմատ տեղաբաշխման ժամանակ մոնիտորինգի բարելավում, զարգացման թիմերի հետ փոխգործակցության բարելավում։

Բայց այս պահին կանգ առնենք։ Ավտոմատացման մասին մենք շատ թեմաներ ենք մակերեսորեն քննարկել, նախորդեցինք որոշներն ընդհանրապես, ուստի մենք ուրախ կլինենք պատասխանելու ձեր հարցերին։ Ապագայում սպասում ենք առաջարկներին, թե ինչի մասին ավելի մանրամասն խոսենք։ Գրեք մեկնաբանություններում։

Ընտանիք: habr.com