Portāla Banki.ru operāciju direktors Andrejs Nikoļskis uzstājās pagājušā gada konferencē par bāreņu pakalpojumiem: kā identificēt bāreņu pakalpojumu infrastruktūrā, kāpēc bāreņu pakalpojumi ir slikti, ko ar tiem darīt un ko darīt, ja nekas nepalīdz.
Zem griezuma ir pārskata teksta versija.
Sveiki kolēģi! Mani sauc Andrejs, es vadu Banki.ru operācijas.
Mums ir lieli pakalpojumi, tie ir tādi monolīti pakalpojumi, ir pakalpojumi klasiskākā izpratnē, un ir ļoti mazi. Savā strādnieku-zemnieku terminoloģijā es saku, ja pakalpojums ir vienkāršs un mazs, tad tas ir mikro, un, ja tas nav ļoti vienkāršs un mazs, tad tas ir tikai pakalpojums.
Pakalpojumu plusi
Es ātri apskatīšu pakalpojumu priekšrocības.
Pirmais ir mērogošana. Jūs varat ātri kaut ko darīt pakalpojumā un sākt ražošanu. Jūs esat saņēmis trafiku, esat klonējis pakalpojumu. Jums ir lielāka trafika, esat to klonējis un dzīvo ar to. Tas ir labs bonuss, un principā, kad mēs sākām, mums tas tika uzskatīts par vissvarīgāko, kāpēc mēs to visu darām.
Otrkārt, izolēta izstrāde, kad tev ir vairākas izstrādes komandas, katrā komandā vairāki dažādi izstrādātāji un katra komanda izstrādā savu servisu.
Ar komandām ir nianse. Izstrādātāji ir dažādi. Un ir, piemēram, . Pirmo reizi es to redzēju kopā ar Maksimu Dorofejevu. Dažreiz sniegpārsliņu cilvēki ir vienās komandās, bet citās ne. Tas padara dažādus pakalpojumus, kas tiek izmantoti visā uzņēmumā, nedaudz nevienmērīgi.
Paskaties uz attēlu: šis ir labs izstrādātājs, viņam ir lielas rokas, viņš var daudz. Galvenā problēma ir tā, no kurienes nāk šīs rokas.
Pakalpojumi ļauj izmantot dažādas programmēšanas valodas, kas ir piemērotākas dažādiem uzdevumiem. Kāds pakalpojums ir Go, daži ir Erlang, daži ir Ruby, kaut kas ir PHP, kaut kas ir Python. Kopumā jūs varat paplašināties ļoti plaši. Šeit ir arī nianses.
Uz pakalpojumiem orientēta arhitektūra galvenokārt ir saistīta ar devops. Tas ir, ja jums nav automatizācijas, nav izvietošanas procesa, ja to konfigurējat manuāli, jūsu konfigurācijas var mainīties atkarībā no pakalpojuma gadījuma un jums ir jāiet tur, lai kaut ko darītu, tad jūs esat ellē.
Piemēram, jums ir 20 pakalpojumi, kas ir jāizvieto ar roku, jums ir 20 konsoles, un jūs kā nindzja vienlaikus nospiediet taustiņu “Enter”. Tas nav ļoti labi.
Ja jums ir pakalpojums pēc testēšanas (ja, protams, ir testēšana), un jums tas joprojām ir jāpabeidz ar failu, lai tas darbotos ražošanā, man ir arī sliktas ziņas.
Ja paļaujaties uz konkrētiem Amazon pakalpojumiem un strādājat Krievijā, tad pirms diviem mēnešiem arī jums bija "Viss apkārt deg, man ir labi, viss ir forši."
Mēs izmantojam Ansible, lai automatizētu izvietošanu, Puppet konverģencei, Bamboo, lai automatizētu izvietošanu, un Confluence, lai kaut kā to visu aprakstītu.
Sīkāk par to nekavēšos, jo pārskats vairāk ir par mijiedarbības praksi, nevis par tehnisko ieviešanu.
Piemēram, mums ir bijušas problēmas, kad Puppet serverī darbojas ar Ruby 2, bet dažas lietojumprogrammas ir rakstītas Ruby 1.8, un tās nedarbojas kopā. Tur kaut kas noiet greizi. Un, kad vienā datorā ir jāpalaiž vairākas Ruby versijas, parasti rodas problēmas.
Piemēram, mēs katram izstrādātājam iedodam platformu, uz kuras ir aptuveni viss, kas mums ir, visi servisi, kurus var izstrādāt, lai viņam būtu izolēta vide, viņš to varētu uzlauzt un uzbūvēt, kā vēlas.
Gadās, ka vajag kādu speciāli sastādītu paketi ar kaut ko tur atbalstu. Tas ir diezgan grūts. Es noklausījos ziņojumu, kur Docker attēls sver 45 GB. Linux, protams, tas ir vienkāršāk, tur viss ir mazāks, bet tomēr vietas nepietiks.
Nu, ir pretrunīgas atkarības, kad viena projekta daļa ir atkarīga no vienas versijas bibliotēkas, cita projekta daļa ir atkarīga no citas versijas, un bibliotēkas vispār netiek instalētas kopā.
Mums ir vietnes un pakalpojumi PHP 5.6 versijā, mums ir kauns par tiem, bet ko mēs varam darīt? Šī ir mūsu viena vietne. PHP 7 ir vietnes un pakalpojumi, to ir vairāk, mēs par tiem nekaunāmies. Un katram izstrādātājam ir sava bāze, kur viņš ar prieku zāģē.
Ja uzņēmumā rakstāt vienā valodā, tad trīs virtuālās mašīnas vienam izstrādātājam izklausās normāli. Ja jums ir dažādas programmēšanas valodas, situācija pasliktinās.
Jums ir vietnes un pakalpojumi par šo, šajā, pēc tam vēl viena vietne pakalpojumam Go, viena vietne Ruby un dažas citas Redis. Rezultātā tas viss pārvēršas par lielu atbalsta lauku, un visu laiku kāds no tā var salūzt.
Tāpēc mēs aizstājām programmēšanas valodas priekšrocības ar dažādu ietvaru izmantošanu, jo PHP ietvari ir diezgan atšķirīgi, tiem ir dažādas iespējas, dažādas kopienas un atšķirīgs atbalsts. Un jūs varat uzrakstīt pakalpojumu, lai jums jau būtu kaut kas tam gatavs.
Katram pakalpojumam ir sava komanda
Mūsu galvenā priekšrocība, kas ir izkristalizējusies vairāku gadu laikā, ir tā, ka katram dienestam ir sava komanda. Tas ir ērti lielam projektam, jūs varat ietaupīt laiku uz dokumentāciju, vadītāji labi pārzina savu projektu.
Jūs varat viegli iesniegt uzdevumus no atbalsta. Piemēram, sabojājās apdrošināšanas pakalpojums. Un nekavējoties komanda, kas nodarbojas ar apdrošināšanu, dodas to salabot.
Ātri tiek radītas jaunas iespējas, jo, kad tev ir viens atomserviss, tajā var ātri kaut ko ieskrūvēt.
Un, kad jūs pārtraucat savu pakalpojumu, un tas neizbēgami notiek, jūs neietekmējāt citu cilvēku pakalpojumus, un izstrādātāji no citām komandām neskrien pie jums ar sīkumiem un nesaka: "Ak, nedariet to."
Kā vienmēr, ir nianses. Mums ir stabilas komandas, menedžeri ir pienagloti komandai. Ir skaidri dokumenti, vadītāji rūpīgi visu uzrauga. Katrai komandai ar vadītāju ir vairāki pakalpojumi, un ir noteikts kompetences punkts.
Ja komandas ir peldošas (mēs arī dažreiz to izmantojam), ir laba metode, ko sauc par “zvaigžņu karti”.
Jums ir pakalpojumu un cilvēku saraksts. Zvaigznīte nozīmē, ka persona ir šī pakalpojuma eksperts, grāmata nozīmē, ka persona apgūst šo pakalpojumu. Personas uzdevums ir nomainīt bukletu pret zvaigznīti. Un, ja dienesta priekšā nekas nav rakstīts, tad sākas problēmas, par kurām es runāšu tālāk.
Kā parādās bāreņu pakalpojumi?
Pirmā problēma, pirmais veids, kā iegūt bāreņu pakalpojumu savā infrastruktūrā, ir cilvēku atlaišana. Vai kāds kādreiz ir ievērojis uzņēmuma darbības termiņus pirms uzdevumu novērtēšanas? Dažkārt gadās, ka termiņi ir saspringti un dokumentācijai vienkārši nepietiek laika. "Mums ir jānodod pakalpojums ražošanai, tad mēs to pievienosim."
Ja komanda ir maza, gadās, ka ir viens izstrādātājs, kurš visu raksta, pārējie ir spārnos. "Es uzrakstīju pamata arhitektūru, pievienosim saskarnes." Tad kādā brīdī vadītājs, piemēram, aiziet. Un šajā periodā, kad vadītājs ir aizgājis un jauns vēl nav iecelts, izstrādātāji paši izlemj, kurp pakalpojums virzās un kas tur notiek. Un, kā mēs zinām (atgriezīsimies dažus slaidus), dažās komandās ir sniegpārsliņu cilvēki, dažreiz sniegpārsliņu komandas vadītājs. Tad viņš pamet, un mēs saņemam bāreņu pakalpojumu.
Tajā pašā laikā atbalsta un biznesa uzdevumi nepazūd, tie nonāk atpalikšanā. Ja pakalpojuma izstrādes gaitā radās kādas arhitektūras kļūdas, tās arī nonāk atpalikšanā. Pakalpojums lēnām pasliktinās.
Kā atpazīt bāreni?
Šis saraksts labi raksturo situāciju. Kurš kaut ko uzzināja par savu infrastruktūru?
Par dokumentētiem risinājumiem: ir serviss, un kopumā tas darbojas, ir divu lappušu rokasgrāmata, kā ar to strādāt, bet neviens nezina, kā tas darbojas iekšā.
Vai, piemēram, ir kāds saišu saīsinātājs. Piemēram, mums pašlaik ir trīs saišu saīsinātāji, kas tiek izmantoti dažādiem mērķiem dažādos pakalpojumos. Tās ir tikai sekas.
Tagad es būšu acīmredzamā kapteinis. Kas būtu jādara? Pirmkārt, mums ir jānodod pakalpojums citam menedžerim, citai komandai. Ja jūsu komandas vadītājs vēl nav izstājies, tad šajā citā komandā, kad saprotat, ka pakalpojums ir kā bārenis, jums jāiekļauj kāds, kurš vismaz kaut ko no tā saprot.
Galvenais: pārsūtīšanas procedūrām jābūt rakstītām ar asinīm. Mūsu gadījumā es parasti to uzraugu, jo man tas viss ir nepieciešams, lai tas darbotos. Vadītājiem to vajag ātri piegādāt, un tas, kas ar to notiek vēlāk, viņiem vairs nav tik svarīgi.
Nākamais veids, kā padarīt bāreni, ir “Mēs to darīsim ārpakalpojumā, tas būs ātrāk, un tad mēs to nodosim komandai”. Skaidrs, ka katram ir kādi plāni komandā, pavērsiens. Bieži vien biznesa klients domā, ka ārpakalpojumu sniedzējs darīs to pašu, ko uzņēmuma tehniskais departaments. Lai gan viņu motivētāji ir dažādi. Ārpakalpojumos ir dīvaini tehnoloģiskie risinājumi un dīvaini algoritmiskie risinājumi.
Piemēram, mums bija pakalpojums, kurā Sfinksa bija dažādās neparedzētās vietās. Es jums pastāstīšu vēlāk, kas man bija jādara.
Ārpakalpojumu sniedzējiem ir pašizrakstīti ietvari. Tas ir tikai tukšs PHP ar copy-paste no iepriekšējā projekta, kur var atrast visādas lietas. Izvietošanas skripti ir liels trūkums, ja jums ir jāizmanto daži sarežģīti Bash skripti, lai mainītu vairākas rindiņas kādā failā, un šos izvietošanas skriptus izsauc kāds trešais skripts. Rezultātā jūs maināt izvietošanas sistēmu, izvēlaties kaut ko citu, lēkāt, bet jūsu pakalpojums nedarbojas. Jo tur vajadzēja ielikt vēl 8 saites starp dažādām mapēm. Vai arī gadās, ka tūkstotis ierakstu strādā, bet simts tūkstoši vairs nedarbojas.
Es turpināšu pildīt kapteiņa pienākumus. Ārpakalpojuma pieņemšana ir obligāta procedūra. Vai kādam kādreiz ir atnācis ārpakalpojums un nekur nav pieņemts? Tas, protams, nav tik populārs kā bāreņu pakalpojums, bet tomēr.
Jāpārbauda serviss, jāpārskata serviss, jāmaina paroles. Mums bija gadījums, kad viņi mums sniedza pakalpojumu, ir administratora panelis "if login == 'admin' && password == 'admin'...", tas ir rakstīts tieši kodā. Mēs sēžam un domājam, un cilvēki to raksta 2018. gadā?
Nepieciešama ir arī atmiņas ietilpības pārbaude. Jāskatās, kas notiks ar simts tūkstošiem ierakstu, pat pirms kaut kur laist šo pakalpojumu ražošanā.
Nav kauns nosūtīt pakalpojumu uzlabošanai. Kad jūs sakāt: "Mēs nepieņemsim šo pakalpojumu, mums ir 20 uzdevumi, izpildiet tos, tad mēs pieņemsim," tas ir normāli. Jūsu sirdsapziņa nedrīkst sāpēt par to, ka veidojat vadītāju vai bizness lieki izšķiež naudu. Pēc tam uzņēmums tērēs vairāk.
Mums bija gadījums, kad mēs nolēmām pilotprojektam uzticēt ārpakalpojumus.
Tas tika piegādāts laikā, un tas bija vienīgais kvalitātes kritērijs. Tāpēc mēs izveidojām vēl vienu pilotprojektu, kas pat vairs nebija izmēģinājuma projekts. Šie pakalpojumi tika pieņemti, un ar administratīviem līdzekļiem viņi teica: šeit ir jūsu kods, šeit ir komanda, šeit ir jūsu menedžeris. Pakalpojumi faktiski jau ir sākuši nest peļņu. Tajā pašā laikā patiesībā viņi joprojām ir bāreņi, neviens nesaprot, kā viņi strādā, un vadītāji dara visu iespējamo, lai atteiktos no saviem uzdevumiem.
Ir vēl viena lieliska koncepcija - partizānu attīstība. Kad kāda nodaļa, parasti mārketinga nodaļa, vēlas pārbaudīt hipotēzi un pasūta visu pakalpojumu ārpakalpojumu sniedzējam. Sāk ieplūst satiksme, aizver dokumentus, paraksta dokumentus ar darbuzņēmēju, ķeras klāt un saka: "Vīri, mums te ir serviss, tur jau ir satiksme, atnes mums naudu, pieņemsim." Mēs atbildējām: "Oppa, kā tas var būt."
Un vēl viens veids, kā iegūt bāreņu pakalpojumu: kad kāda komanda pēkšņi ir noslogota, vadība saka: "Nodosim šīs komandas pakalpojumu citai komandai, tai ir mazāka slodze." Un tad mēs to nodosim trešajai komandai un mainīsim vadītāju. Un galu galā mums atkal ir bārenis.
Kāda problēma ar bāreņiem?
Kas nezina, šis ir Zviedrijā celtais līnijkuģis Wasa, kas slavens ar to, ka nogrima 5 minūtes pēc palaišanas. Un Zviedrijas karalis, starp citu, nevienam par to neizpildīja nāvessodu. To uzbūvēja divas inženieru paaudzes, kuras nezināja, kā būvēt šādus kuģus. Dabisks efekts.
Kuģis varēja nogrimt, starp citu, daudz sliktākā veidā, piemēram, kad karalis jau kaut kur vētrā brauca uz tā. Un tā viņš uzreiz noslīka, pēc Agile domām, ir labi, ja agri neizdodas.
Ja mums neizdodas agri, parasti problēmu nav. Piemēram, pieņemšanas laikā tas tika nosūtīts pārskatīšanai. Bet, ja mums neizdodas jau ražošanā, kad tiek ieguldīta nauda, tad var rasties problēmas. Sekas, kā tās sauc biznesā.
Kāpēc bāreņu pakalpojumi ir bīstami:
- Pakalpojums var pēkšņi pārtraukt.
- Servisa remonts prasa ilgu laiku vai netiek remontēts vispār.
- Drošības problēmas.
- Problēmas ar uzlabojumiem un atjauninājumiem.
- Ja kāds svarīgs pakalpojums sabojājas, cieš uzņēmuma reputācija.
Ko darīt ar bāreņu pakalpojumiem?
Es vēlreiz atkārtošu, ko darīt. Pirmkārt, jābūt dokumentācijai. 7 gadi darbā Banki.ru man iemācīja, ka testētājiem nevajadzētu pieņemt izstrādātāju vārdus un operācijām nevajadzētu pieņemt ikviena vārdu. Mums ir jāpārbauda.
Otrkārt, ir jāraksta mijiedarbības diagrammas, jo gadās, ka ne pārāk labi uztverti pakalpojumi satur atkarības, par kurām neviens nav teicis. Piemēram, izstrādātāji instalēja pakalpojumu savā atslēgā uz kādu Yandex.Maps vai Dadata. Jums ir beidzies brīvais limits, viss ir bojāts, un jūs vispār nezināt, kas noticis. Visi tādi grābekļi jāapraksta: serviss izmanto Dadata, SMS, vēl kaut ko.
Treškārt, darbs ar tehnisko parādu. Kad tu izdari kaut kādus kruķus vai pieņem kādu pakalpojumu un saki, ka kaut kas ir jādara, tev ir jāpārliecinās, ka tas ir izdarīts. Jo tad var izrādīties, ka mazā bedre nemaz nav tik maza, un tu tai izkritīsi.
Ar arhitektūras uzdevumiem mums bija stāsts par Sfinksu. Viens no pakalpojumiem izmantoja Sfinksu, lai ievadītu sarakstus. Tikai lappušu saraksts, bet katru vakaru tas tika indeksēts no jauna. Tas tika salikts no diviem indeksiem: katru vakaru tika indeksēts viens liels, un tam bija arī mazs indekss, kas tam tika pieskrūvēts. Katru dienu ar 50% iespējamību, ka tiks spridzināts vai nē, indekss aprēķina laikā avarēja, un mūsu ziņas tika pārtrauktas galvenajā lapā. Sākumā indeksa pārindeksācijai bija nepieciešamas 5 minūtes, pēc tam indekss pieauga, un kādā brīdī pārindeksēšana sāka aizņemt 40 minūtes. Kad šo izgriezām, atviegloti uzelpojām, jo bija skaidrs, ka paies vēl nedaudz laika un mūsu indekss tiks pārindeksēts uz pilnu slodzi. Mūsu portālam tā būs neveiksme, astoņas stundas nav ziņu - lūk, bizness ir apstājies.
Plānojiet darbu ar bāreņu pakalpojumu
Patiesībā to ir ļoti grūti izdarīt, jo devops ir saistīts ar saziņu. Jūs vēlaties būt labās attiecībās ar saviem kolēģiem, un, kad jūs saviem kolēģiem un vadītājiem sitat pa galvu ar noteikumiem, viņiem var rasties pretrunīgas jūtas pret cilvēkiem, kas to dara.
Papildus visiem šiem punktiem ir vēl viena svarīga lieta: konkrētiem cilvēkiem ir jāatbild par katru konkrēto pakalpojumu, par katru konkrēto izvietošanas procedūras sadaļu. Kad nav cilvēku un ir jāpiesaista daži citi cilvēki, lai izpētītu visu šo lietu, kļūst grūti.
Ja tas viss nepalīdzēja un jūsu bāreņu pakalpojums joprojām ir bāreņa statuss, neviens to nevēlas uzņemties, dokumentācija nav uzrakstīta, komanda, kas tika izsaukta šajā dienestā, atsakās neko darīt, ir vienkāršs veids - pārtaisīt viss .
Respektīvi, tu ņem no jauna prasības pakalpojumam un raksti jaunu pakalpojumu, labāku, uz labākas platformas, bez dīvainiem tehnoloģiskiem risinājumiem. Un jūs migrējat uz to kaujā.
Mums bija situācija, kad paņēmām pakalpojumu uz Yii 1 un sapratām, ka nevaram to tālāk attīstīt, jo mums pietrūka izstrādātāju, kas varētu labi rakstīt uz Yii 1. Visi izstrādātāji labi raksta uz Symfony XNUMX. Ko darīt? Mēs piešķīrām laiku, piešķīrām komandu, piešķīrām vadītāju, pārrakstījām projektu un raiti pārslēdzām uz to trafiku.
Pēc tam veco pakalpojumu var dzēst. Tā ir mana mīļākā procedūra, kad no konfigurācijas pārvaldības sistēmas jāizņem un jāiztīra kāds serviss un tad jāiziet cauri un jāskatās, ka visas ražotās mašīnas ir atslēgtas, lai izstrādātājiem nepaliek pēdas. Repozitorijs paliek Git.
Tas ir viss, par ko es gribēju runāt, esmu gatavs apspriest, tēma ir holivar, daudzi tajā ir peldējušies.
Slaidos bija teikts, ka jūs vienojat valodas. Piemērs bija attēlu izmēru maiņa. Vai tiešām tas ir stingri jāierobežo tikai ar vienu valodu? Tā kā attēla izmēru maiņu PHP valodā faktiski var veikt Golangā.
Faktiski tā nav obligāta, tāpat kā visas prakses. Iespējams, dažos gadījumos tas ir pat nevēlami. Bet jums ir jāsaprot, ka, ja jums ir tehniskā nodaļa uzņēmumā ar 50 cilvēkiem, 45 no tiem ir PHP speciālisti, vēl 3 ir devopi, kas zina Python, Ansible, Puppet un kaut ko tamlīdzīgu, un tikai viens no viņiem raksta sava veida valoda. kāds Go attēla izmēru maiņas pakalpojums, tad, kad tas aiziet, zināšanas tiek pievienotas. Un tajā pašā laikā jums būs jāmeklē tirgū specifisks izstrādātājs, kurš zina šo valodu, it īpaši, ja tā ir reti sastopama. Tas ir, no organizatoriskā viedokļa tas ir problemātiski. No devops viedokļa jums nevajadzēs tikai klonēt kādu gatavu rokasgrāmatu kopu, ko izmantojat pakalpojumu izvietošanai, bet jums tās būs jāraksta no jauna.
Pašlaik mēs veidojam pakalpojumu vietnē Node.js, un tā būs tikai blakus esoša platforma katram izstrādātājam ar atsevišķu valodu. Bet mēs sēdējām un domājām, ka spēle bija sveces vērta. Tas ir, šis ir jautājums, kas jums jāapsēž un jādomā.
Kā jūs uzraugāt savus pakalpojumus? Kā jūs apkopojat un uzraugāt žurnālus?
Mēs savācam baļķus Elasticsearch un ievietojam Kibanā, un atkarībā no tā, vai tā ir ražošanas vai testa vide, tur tiek izmantoti dažādi savācēji. Kaut kur mežstrādnieks, kaut kur citur, es neatceros. Un vēl ir dažas vietas atsevišķos servisos, kur mēs uzstādām Telegraf un filmējam kaut kur citur atsevišķi.
Kā sadzīvot ar Puppet un Ansible vienā vidē?
Patiesībā mums tagad ir divas vides, viena ir Puppet, otra ir Ansible. Mēs strādājam, lai tos hibridizētu. Ansible ir labs ietvars sākotnējai iestatīšanai, Puppet ir slikta sākotnējās iestatīšanas sistēma, jo tas prasa praktisku darbu tieši platformā, un Puppet nodrošina konfigurācijas konverģenci. Tas nozīmē, ka platforma uztur sevi atjauninātā stāvoklī, un, lai pielāgotā iekārta būtu atjaunināta, tajā visu laiku ar noteiktu biežumu ir jāpalaiž rokasgrāmatas. Tāda ir atšķirība.
Kā jūs saglabājat saderību? Vai jums ir konfigurācijas gan Ansible, gan Puppet?
Tā ir mūsu lielā sāpe, mēs saglabājam saderību ar rokām un domājam, kā tagad kaut kur no tā visa virzīties tālāk. Izrādās, ka Puppet izlaiž pakotnes un tur uztur dažas saites, bet Ansible, piemēram, izrullē kodu un pielāgo tur jaunākās lietojumprogrammu konfigurācijas.
Prezentācija bija par dažādām Ruby versijām. Kāds risinājums?
Mēs ar to saskārāmies vienuviet, un mums tas visu laiku jāpatur prātā. Mēs vienkārši izslēdzām to daļu, kas darbojās Ruby un kas nebija saderīga ar lietojumprogrammām, un turējām to atsevišķi.
Šī gada konference 7. decembrī notiks Technopolē. Pieteikumus atskaitēm pieņemam līdz 11. novembrim. mums, ja vēlaties runāt.
Dalībnieku reģistrācija ir atvērta, pievienojies!
Avots: www.habr.com