Banki.ru atariko Eragiketa zuzendari Andrey Nikolsky hitz egin zuen iazko hitzaldian umezurtz zerbitzuei buruz: nola identifikatu umezurtz bat azpiegituran, zergatik diren txarrak umezurtz zerbitzuak, zer egin haiekin eta zer egin ezerk laguntzen ez badu.
Ebakiaren azpian txostenaren testu bertsio bat dago.
Kaixo lankideok! Nire izena Andrey da, Banki.ru-n operazioen buru naiz.
Zerbitzu handiak ditugu, halako zerbitzu monolitikoak dira, badaude zerbitzuak zentzu klasikoagoan, eta oso txikiak. Nire langile-nekazari terminologian esaten dut zerbitzu bat sinplea eta txikia bada, mikroa dela, eta oso sinplea eta txikia ez bada, zerbitzu bat besterik ez dela.
Zerbitzuen abantailak
Azkar azalduko ditut zerbitzuen abantailak.
Lehenengoa eskalatzea da. Zerbitzuan zerbait azkar egin dezakezu eta ekoizpena has dezakezu. Trafikoa jaso duzu, zerbitzua klonatu duzu. Trafiko gehiago duzu, klonatu duzu eta horrekin bizi zara. Hau bonus ona da, eta, printzipioz, hasi ginenean, guretzat garrantzitsuena zen, zergatik egiten ari garen hau guztia.
Bigarrenik, garapen isolatua, hainbat garapen talde dituzunean, hainbat garatzaile ezberdin talde bakoitzean, eta talde bakoitzak bere zerbitzua garatzen duenean.
Taldeekin Γ±abardura bat dago. Garatzaileak desberdinak dira. Eta badira, adibidez, . Maxim Dorofeev-ekin ikusi nuen lehen aldiz. Batzuetan elur maluta jendea talde batzuetan egoten da eta besteetan ez. Horrek konpainian erabiltzen diren zerbitzu desberdinak pixka bat irregularrak bihurtzen ditu.
Begira argazkia: hau garatzaile ona da, esku handiak ditu, asko egin dezake. Arazo nagusia esku hauek nondik datozen da.
Zerbitzuek zeregin ezberdinetarako egokiagoak diren programazio-lengoaia desberdinak erabiltzea ahalbidetzen dute. Zerbitzu batzuk Go-n daude, beste batzuk Erlang-en, beste batzuk Ruby-n, zerbait PHP-n, zerbait Python-en. Oro har, oso zabal dezakezu. Hemen ere Γ±abardurak daude.
Zerbitzuetara bideratutako arkitektura devopei buruzkoa da batez ere. Hau da, automatizaziorik ez baduzu, ez dago inplementazio prozesurik, eskuz konfiguratzen baduzu, zure konfigurazioak zerbitzu-instantzia batetik bestera alda daitezke, eta hara joan behar duzu zerbait egiteko, orduan infernuan zaude.
Adibidez, 20 zerbitzu dituzu eta eskuz zabaldu behar duzu, 20 kontsola dituzu eta aldi berean "sartu" sakatzen duzu ninja bat bezala. Ez da oso ona.
Probatu ondoren zerbitzuren bat baduzu (probak badaude, noski), eta oraindik fitxategi batekin amaitu behar baduzu produkzioan funtziona dezan, albiste txarrak ere baditut zuretzat.
Amazon zerbitzu zehatzetan oinarritzen bazara eta Errusian lan egiten baduzu, duela bi hilabete ere izan zenuen "Inguruan dena sutan dago, ondo nago, dena polita da".
Ansible erabiltzen dugu hedapena automatizatzeko, Puppet konbergentziarako, Bamboo hedapena automatizatzeko eta Confluence nolabait deskribatzeko.
Ez naiz horretan zehatz-mehatz luzatuko, txostena interakzio praktikei buruzkoa baita, eta ez ezarpen teknikoari buruzkoa.
Adibidez, arazoak izan ditugu Puppet zerbitzarian Ruby 2-rekin lan egiten duen tokian, baina aplikazio batzuk Ruby 1.8rako idatzita daude eta ez dute elkarrekin funtzionatzen. Zerbait gaizki doa hor. Eta Rubyren hainbat bertsio exekutatu behar dituzunean makina batean, normalean arazoak izaten hasten zara.
Esaterako, garatzaile bakoitzari plataforma bat ematen diogu, gutxi gorabehera daukagun guztia dagoen, garatu daitezkeen zerbitzu guztiak, ingurune isolatu bat izan dezan, hautsi eta nahi duen moduan eraiki dezan.
Gertatzen da bereziki konpilatutako paketeren bat behar duzula bertan zerbaitetarako laguntzarekin. Nahiko gogorra da. Docker irudiak 45 GB pisatzen dituen erreportaje bat entzun nuen. Linux-en, noski, sinpleagoa da, han dena txikiagoa da, baina hala ere, ez da leku nahikorik egongo.
Beno, mendekotasun gatazkatsuak daude, proiektuaren zati bat bertsio bateko liburutegi baten menpe dagoenean, proiektuaren beste zati bat beste bertsio baten araberakoa denean, eta liburutegiak ez dira batere batera instalatzen.
PHP 5.6-n webguneak eta zerbitzuak ditugu, lotsatzen gaituzte, baina zer egin dezakegu? Hau da gure gune bakarra. PHP 7-n guneak eta zerbitzuak daude, gehiago daude, ez gara lotsatzen. Eta garatzaile bakoitzak bere oinarria dauka, non pozik ikusten duen.
Enpresa batean hizkuntza batean idazten baduzu, garatzaile bakoitzeko hiru makina birtualek normala dirudi. Programazio-lengoaia desberdinak badituzu, egoerak okerrera egiten du.
Honi buruzko guneak eta zerbitzuak dituzu, honetan, gero Go-rako beste gune bat, Ruby-rentzat eta beste Redis batzuk alboan. Ondorioz, hori guztia laguntza eremu handi batean bihurtzen da, eta denbora guztian horietako batzuk hautsi daitezke.
Hori dela eta, programazio-lengoaiaren onurak esparru ezberdinen erabilerarekin ordezkatu ditugu, PHP esparruak nahiko desberdinak direnez, gaitasun desberdinak, komunitate desberdinak eta euskarri desberdinak dituzte. Eta zerbitzu bat idatz dezakezu dagoeneko horretarako zerbait prest izan dezazun.
Zerbitzu bakoitzak bere taldea du
Gure abantaila nagusia, hainbat urtetan kristalizatu dena, zerbitzu bakoitzak bere taldea duela da. Hau erosoa da proiektu handi baterako, denbora aurreztu dezakezu dokumentazioan, kudeatzaileek ondo ezagutzen dute euren proiektua.
Laguntzatik erraz bidal ditzakezu zereginak. Adibidez, aseguru zerbitzua matxuratu zen. Eta segituan aseguruak jorratzen dituen taldea konpontzera joaten da.
Ezaugarri berriak azkar sortzen ari dira, zeren zerbitzu atomiko bat duzunean, azkar zerbait sartu dezakezu.
Eta zure zerbitzua apurtzen duzunean, eta hori ezinbestean gertatzen denean, ez zenuen beste pertsonen zerbitzuetan eraginik izan, eta beste taldeetako zatiak dituzten garatzaileak ez dira zuregana etortzen eta esaten: "Oh, ez egin hori".
Beti bezala, Γ±abardurak daude. Talde egonkorrak ditugu, zuzendariak taldean iltzatuta daude. Dokumentu argiak daude, kudeatzaileek dena gertutik kontrolatzen dute. Zuzendari bat duen talde bakoitzak hainbat zerbitzu ditu, eta konpetentzia puntu zehatz bat dago.
Taldeak flotatzen ari badira (batzuetan hau ere erabiltzen dugu), badago metodo on bat "izar mapa" izenekoa.
Zerbitzuen eta pertsonen zerrenda duzu. Izar batek esan nahi du pertsona zerbitzu honetan aditua dela, liburu batek esan nahi du pertsona hori zerbitzu hau ikasten ari dela. Pertsonaren zeregina liburuxka izartxo batengatik aldatzea da. Eta zerbitzuaren aurrean ezer idazten ez bada, arazoak hasten dira, eta horri buruz gehiago hitz egingo dut.
Nola agertzen dira umezurtz zerbitzuak?
Lehenengo arazoa, zure azpiegituran zerbitzu umezurtz bat lortzeko lehen modua jendea kaleratzea da. Inork izan al du enpresa batek bete beharreko epeak betetzea zereginak ebaluatu aurretik? Batzuetan gertatzen da epeak estuak direla eta dokumentaziorako denbora nahikorik ez dagoela. "Zerbitzua ekoizpenaren esku utzi behar dugu, gero gehituko dugu".
Taldea txikia bada, gertatzen da garatzaile bat dagoela dena idazten duena, gainerakoak hegaletan daude. "Oinarrizko arkitektura idatzi nuen, gehi ditzagun interfazeak". Orduan, noizbait zuzendariak, adibidez, alde egiten du. Eta tarte horretan, kudeatzailea utzi eta oraindik berri bat izendatu ez denean, garatzaileek eurek erabakitzen dute zerbitzua nora doan eta zer gertatzen den bertan. Eta dakigunez (itzul ditzagun diapositiba batzuk), talde batzuetan elur-maluta jendea dago, batzuetan elur-maluta taldeburua. Orduan utzi egiten du, eta umezurtz zerbitzu bat lortzen dugu.
Aldi berean, laguntza- eta negozio-zereginak ez dira desagertzen; atzerapenean amaitzen dira. Zerbitzuaren garapenean akats arkitektonikoren bat egon bada, atzerapenarekin ere amaitzen da. Zerbitzua pixkanaka hondatzen ari da.
Nola identifikatu umezurtz bat?
Zerrenda honek ondo deskribatzen du egoera. Nork ikasi zuen beren azpiegiturei buruz?
Dokumentatutako konponbideei buruz: zerbitzu bat dago eta, orokorrean, funtzionatzen du, bi orrialdeko eskuliburua dauka nola lan egin jakiteko, baina inork ez daki nola funtzionatzen duen barruan.
Edo, adibidez, badago lotura laburtzaile moduko bat. Adibidez, gaur egun hiru esteka laburtzaile ditugu zerbitzu ezberdinetan helburu ezberdinetarako erabiltzen. Ondorioak besterik ez dira.
Orain begi-bistakoaren kapitaina izango naiz. Zer egin behar da? Lehenik eta behin, zerbitzua beste kudeatzaile bati, beste talde bati, transferitu behar diogu. Zure taldeko buruak oraindik utzi ez badu, beste talde honetan, zerbitzua umezurtz bat bezalakoa dela ulertzen duzunean, horri buruz gutxienez zerbait ulertzen duen norbait sartu behar duzu.
Gauza nagusia: transferentzia-prozedurak odolez idatzita eduki behar dituzu. Gure kasuan, normalean hau kontrolatzen dut, dena behar dudalako funtzionatzeko. Kudeatzaileek azkar entregatu behar dute, eta geroago gertatzen dena ez da hain garrantzitsua haientzat.
Umezurtz bat egiteko hurrengo modua da: "Kontratatuta egingo dugu, azkarragoa izango da, eta gero taldeari emango diogu". Argi dago denek plan batzuk dituztela taldean, txanda. Askotan enpresa-bezero batek uste du azpikontratatzaileak enpresak duen sail teknikoaren gauza bera egingo duela. Haien motibatzaileak desberdinak diren arren. Irtenbide teknologiko bitxiak eta irtenbide algoritmiko bitxiak daude azpikontratazioan.
Esaterako, ustekabeko hainbat lekutan Sphinx zuen zerbitzu bat genuen. Gero esango dizut zer egin behar nuen.
Kontratatzaileek norberak idatzitako esparruak dituzte. Hau PHP hutsa da aurreko proiektu bateko kopiatu-itsatsiarekin, non era guztietako gauza aurki ditzakezun. Inplementazio-scriptak eragozpen handia dira Bash-eko script konplexu batzuk erabili behar dituzunean fitxategi batzuetan hainbat lerro aldatzeko, eta inplementazio-script hauei hirugarren script batek deitzen die. Ondorioz, inplementazio-sistema aldatzen duzu, beste zerbait aukeratu, hop, baina zure zerbitzuak ez du funtzionatzen. Bertan karpeta ezberdinen artean 8 esteka gehiago jarri behar zirelako. Edo gertatzen da mila disko funtzionatzen dutela, baina ehun mila jada ez.
Kapitain izaten jarraituko dut. Kontratatutako zerbitzu bat onartzea nahitaezko prozedura da. Inori izan al da inoiz azpikontratatutako zerbitzurik iritsi eta inon onartu ez izan? Hau ez da, noski, umezurtz zerbitzu bat bezain ezaguna, baina hala ere.
Zerbitzua egiaztatu behar da, zerbitzua berrikusi, pasahitzak aldatu. Zerbitzu bat eman zigutenean kasu bat izan genuen, administrazio-panel bat dago "saioa == 'admin' && pasahitza == 'admin'...", kodean bertan idatzita dago. Esertzen gara eta pentsatzen dugu, eta jendeak hau idazten du 2018an?
Biltegiratze ahalmena probatzea ere beharrezkoa da. Ehun mila diskotan zer gertatuko den begiratu behar duzu, zerbitzu hau nonbait produkzioan jarri aurretik ere.
Ez da lotsarik izan behar zerbitzu bat hobetzera bidaltzeko. Zuk esaten duzunean: "Ez dugu zerbitzu hau onartuko, 20 zeregin ditugu, egin, gero onartuko dugu", hau normala da. Zure kontzientzia ez da kaltetu behar kudeatzaile bat sortzen ari zarela edo negozioa dirua xahutzen ari delako. Gero, negozioak gehiago gastatuko du.
Kasu bat izan genuen proiektu pilotu bat azpikontratatzea erabaki genuenean.
Garaiz entregatu zen, eta hori izan zen kalitate irizpide bakarra. Horregatik, beste proiektu pilotu bat egin genuen, benetan pilotua ere ez zena. Zerbitzu hauek onartu ziren, eta administrazio-bideen bidez esan zuten, hona hemen zure kodea, hona hemen taldea, hona hemen zure kudeatzailea. Zerbitzuak dagoeneko hasi dira irabaziak lortzen. Aldi berean, hain zuzen ere, umezurtzak dira oraindik, inork ez du ulertzen nola funtzionatzen duten, eta arduradunek ahal duten guztia egiten dute euren zereginak uko egiteko.
Bada beste kontzeptu handi bat: gerrillaren garapena. Sail batzuk, normalean marketin-sailak, hipotesi bat probatu nahi duenean eta zerbitzu osoa azpikontratatuta agintzen duenean. Trafikoa sartzen hasten da, dokumentuak itxi, kontratistarekin dokumentuak sinatzen dituzte, martxan jartzen dira eta esaten dute: βAdiskideok, hemen zerbitzua dugu, dagoeneko trafikoa dauka, dirua ekartzen digu, onar dezagunβ. Esan genuen: "Oppa, nola izan daiteke hori".
Eta zerbitzu umezurtz bat lortzeko beste modu bat: talderen bat bat-batean kargatuta aurkitzen denean, zuzendaritzak hauxe dio: "Laga diezaiogun talde honen zerbitzua beste talde bati, karga txikiagoa du". Eta gero hirugarren talde batera transferituko dugu eta managerra aldatuko dugu. Eta azkenean umezurtz bat dugu berriro.
Zein da umezurtzekin arazoa?
Nork ez daki, hau da Suedian altxatutako Wasa gudu-ontzia, itsasoratu eta 5 minutura hondoratu izanagatik famatua. Eta Suediako erregeak, bide batez, ez zuen inor exekutatu horretarako. Horrelako ontziak eraikitzen jakin ez zuten bi ingeniari belaunaldiek eraiki zuten. Efektu naturala.
Ontzia hondoratu zitekeen, bide batez, askoz modu okerragoan, adibidez, erregea jada nonbait ekaitz batean gainean zihoala. Eta horrela, berehala ito zen, Agileren arabera ona da goiz huts egitea.
Goiz huts egiten badugu, normalean ez dago arazorik. Esaterako, onarpenean berrikusteko bidali zen. Baina dagoeneko ekoizpenean huts egiten badugu, dirua inbertitzen denean, arazoak egon daitezke. Ondorioak, negozioetan deitzen zaien bezala.
Zergatik umezurtz zerbitzuak arriskutsuak dira:
- Zerbitzua bat-batean hautsi daiteke.
- Zerbitzuak denbora asko behar du konpontzen edo ez da batere konpontzen.
- Segurtasun arazoak.
- Hobekuntzarekin eta eguneraketekin arazoak.
- Zerbitzu garrantzitsu bat apurtzen bada, konpainiaren ospeak kalte egiten du.
Zer egin umezurtz zerbitzuekin?
Berriro errepikatuko dut zer egin. Lehenik eta behin, dokumentazioa egon behar da. Banki.ru-n 7 urtez irakatsi zidaten probatzaileek ez dutela garatzaileen hitza hartu behar, eta operazioek ez dutela guztion hitza hartu behar. Egiaztatu behar dugu.
Bigarrenik, elkarrekintza-diagramak idaztea beharrezkoa da, gertatzen baita oso harrera ez diren zerbitzuek inork esan ez dituen menpekotasunak dituztela. Adibidez, garatzaileek zerbitzua Yandex.Maps edo Dadata batzuen gakoan instalatu zuten. Doako mugarik gabe geratu zara, dena hautsita dago eta ez dakizu zer gertatu den. Halako arrasto guztiak deskribatu behar dira: zerbitzuak Dadata, SMS, beste zerbait erabiltzen ditu.
Hirugarrenik, zor teknikoarekin lan egitea. Nolabaiteko makuluak egin edo zerbitzu bat onartu eta zerbait egin behar dela esaten duzunean, egin dela ziurtatu behar duzu. Orduan gerta daitekeelako zulo txikia ez dela hain txikia, eta bertatik eroriko zara.
Arkitektura zereginekin, Esfingeri buruzko istorio bat genuen. Zerbitzuetako batek Sphinx erabiltzen zuen zerrendetan sartzeko. Orridun zerrenda bat besterik ez, baina gauero berriro indexatzen zen. Bi indizetatik muntatzen zen: handi bat gauero indexatzen zen, eta aurkibide txiki bat ere izorratuta zegoen. Egunero, bonbardaketa egiteko edo ez %50eko probabilitatearekin, indizeak huts egin zuen kalkuluan zehar, eta gure albisteak orrialde nagusian eguneratzeari utzi zion. Hasieran 5 minutu behar izan ziren indizea berriro indexatzeko, gero indizea hazi egin zen, eta noizbait 40 minutu behar izaten hasi zen berriro indexatzeko. Hau moztu genuenean, arnasa hartu genuen, argi baitzegoen denbora pixka bat gehiago pasatuko zela eta gure indizea berriro indexatuko zela denbora osoan. Gure atariaren hutsegite bat izango da, zortzi orduz ez dago albisterik; hori da, negozioa gelditu da.
Umezurtz zerbitzu batekin lan egiteko plana
Izan ere, hori egitea oso zaila da, devops-a komunikazioa delako. Zure lankideekin harreman onak izan nahi dituzu, eta zure lankide eta kudeatzaileei araudiekin burutik jotzen dituzunean, sentimendu kontrajarriak izan ditzakete hori egiten duten pertsonekiko.
Puntu guzti horiez gain, beste gauza garrantzitsu bat ere badago: pertsona zehatzak izan behar dira zerbitzu zehatz bakoitzaren arduradunak, hedapen prozeduraren atal zehatz bakoitzeko. Jenderik ez dagoenean eta gai hau guztia aztertzeko beste pertsona batzuk erakarri behar dituzunean, zaila egiten da.
Horrek guztiak lagundu ez badu eta zure umezurtz zerbitzua oraindik umezurtz bada, inork ez du hartu nahi, dokumentazioa ez dago idatzita, zerbitzu honetara deitu zen taldeak ezer egiteari uko egiten dio, modu erraz bat dago: berregin. dena .
Hau da, zerbitzuaren baldintzak berriro hartu eta zerbitzu berri bat idazten duzu, hobeto, plataforma hobe batean, irtenbide teknologiko arrarorik gabe. Eta bertara migratzen zara guduan.
Egoera bat izan genuen Yii 1-en zerbitzu bat hartu genuenean eta konturatu ginen ezin genuela gehiago garatu, Yii 1-en ondo idatz zezaketen garatzailerik gabe geratu ginelako. Garatzaile guztiek ondo idazten dute Symfony XNUMX-n. Zer egin? Denbora esleitu genuen, talde bat esleitu, kudeatzaile bat esleitu, proiektua berridatzi eta trafikoa leunki aldatu genuen.
Horren ondoren, zerbitzu zaharra ezabatu daiteke. Hau da nire prozedurarik gogokoena, konfigurazio-kudeaketako sistematik zerbitzu batzuk hartu eta garbitu behar dituzunean eta, ondoren, produkzioan dauden auto guztiak desgaituta daudela ikustean, garatzaileek aztarnarik utzi ez dezaten. Biltegia Git-en geratzen da.
Honetaz hitz egin nahi nuen guztia, eztabaidatzeko prest nago, gaia holivar da, askok igeri egin dute.
Diapositibak hizkuntzak bateratu dituzula esaten zuen. Adibide bat irudien tamaina aldatzea izan zen. Beharrezkoa al da benetan hizkuntza batera mugatzea? PHPn irudiaren tamaina aldatzea, bai, Golang-en egin liteke.
Izan ere, hautazkoa da, praktika guztiak bezala. Agian, kasu batzuetan, desiragarria ere bada. Baina ulertu behar duzu 50 laguneko enpresa batean sail tekniko bat baduzu, horietako 45 PHP espezialistak direla, beste 3 Python, Ansible, Puppet eta horrelako zerbait ezagutzen dituzten devopeak direla, eta horietako batek bakarrik idazten duela batzuetan. hizkuntza mota. Go irudien tamaina aldatzeko zerbitzu batzuk, gero irteten denean, espezializazioa berekin doa. Eta, aldi berean, hizkuntza hau ezagutzen duen merkatuko garatzaile espezifiko bat bilatu beharko duzu, batez ere arraroa bada. Hau da, antolakuntzaren ikuspuntutik, hori problematikoa da. Devops-en ikuspuntutik, ez dituzu soilik zerbitzuak zabaltzeko erabiltzen dituzun prestatutako liburu-liburu batzuk klonatu beharko, baizik eta berriro idatzi beharko dituzu.
Une honetan zerbitzu bat eraikitzen ari gara Node.js-en, eta hau garatzaile bakoitzarentzako gertuko plataforma bat izango da hizkuntza bereizia duena. Baina eseri eta jolasak kandela merezi zuela pentsatu genuen. Hau da, hau eseri eta pentsatzeko galdera bat da.
Nola kontrolatzen dituzu zure zerbitzuak? Nola biltzen eta kontrolatzen dituzu erregistroak?
Elasticsearch-en erregistroak biltzen ditugu eta Kibanan jartzen ditugu, eta ekoizpen- edo proba-inguruneak diren kontuan hartuta, biltzaile desberdinak erabiltzen dira bertan. Nonbait Lumberjack, beste nonbait beste zerbait, ez naiz gogoratzen. Eta oraindik ere badaude zenbait zerbitzutan Telegraf instalatzen dugun eta beste nonbait bereizita filmatzen dugun.
Nola bizi Puppet eta Ansiblerekin ingurune berean?
Izan ere, gaur egun bi ingurune ditugu, bata Puppet da, bestea Ansible. Horiek hibridatzeko lanean ari gara. Ansible hasierako konfiguraziorako marko ona da, Puppet hasierako konfiguraziorako esparru txarra da plataforman zuzenean lan praktikoa behar duelako eta Puppet-ek konfigurazio-konbergentzia bermatzen du. Horrek esan nahi du plataformak eguneratutako egoeran mantentzen duela, eta ansibilizatutako makina eguneratuta egon dadin, jolas-liburuak exekutatu behar dituzula denbora guztian maiztasun batekin. Hori da aldea.
Nola mantentzen duzu bateragarritasuna? Ansible eta Puppet-en konfiguraziorik al duzu?
Hau da gure min handia, gure eskuekin bateragarritasuna mantentzen dugu eta hau guztia nonbait nola pasatu pentsatzen dugu orain. Ematen du Puppet-ek paketeak zabaltzen dituela eta esteka batzuk mantentzen dituela bertan, eta Ansiblek, adibidez, kodea zabaldu eta azken aplikazioen konfigurazioak doitzen ditu bertan.
Aurkezpena Rubyren bertsio ezberdinei buruzkoa izan zen. Zein irtenbide?
Leku bakarrean topatu dugu hau, eta denbora guztian buruan gorde behar dugu. Aplikazioekin bateraezina zen Ruby-n exekutatzen zen zatia itzali genuen eta bereizita mantendu genuen.
Aurtengo jardunaldia abenduaren 7an izango da Technopolisen. Azaroaren 11ra arte txostenak egiteko eskaerak onartzen ditugu. iezaguzu hitz egin nahi baduzu.
Parte hartzaileentzako izen-ematea zabalik dago, bat egin gurekin!
Iturria: www.habr.com