Habr mundua aldatzen ari da. Urtebete baino gehiago daramagu blogean. Duela sei hilabete inguru, Khabrovites-en iritzi guztiz logikoa jaso genuen: Β«Dodo, nonahi esaten duzu zure sistema propioa duzula. Eta zein da sistema hau? Eta zergatik behar du pizza-kate batek?
Eseri, pentsatu eta arrazoia duzula konturatu gara. Behatzetan dena azaltzen saiatzen gara, baina puskatan ateratzen da eta inon ez dago sistemaren deskribapen osoa. Horrela, informazio bilketa, egileak bilatzeko eta Dodo ISri buruzko artikulu sorta bat idazteko ibilbide luzea hasi zen. Goazen!
Eskerrak: Eskerrik asko zure iritzia gurekin partekatzeagatik. Berari esker, azkenean sistema deskribatu dugu, radar tekniko bat osatu eta laster gure prozesuen deskribapen handi bat zabalduko dugu. Zuek gabe, beste 5 urtez egongo ginateke bertan eserita.
Artikulu sorta "Zer da Dodo IS?" buruz kontatzen du:
- Dodo IS-en lehen monolitoa (2011-2015). (Abian...)
- Back office bidea: oinarri bereiziak eta autobusa. (hemen zaude)
- Bezeroaren alboko bidea: oinarriaren gaineko fatxada (2016-2017). (Abian...)
- Egiazko mikrozerbitzuen historia. (2018-2019). (Abian...)
- Monolitoaren zerraketa amaitu eta arkitektura egonkortzea. (Abian...)
Beste zerbait jakin nahi baduzu - idatzi iruzkinetan.
Egilearen deskribapen kronologikoari buruzko iritzia
Aldizka, langile berrientzako bilera bat egiten dut "Sistemaren arkitektura" gaiari buruz. "Dodo IS Arkitekturaren Sarrera" deitzen diogu eta garatzaile berrien barne-prozesuaren parte da. Era batean edo bestean gure arkitekturaz, bere ezaugarriez kontatuaz, deskribapenaren ikuspegi historiko jakin bat sortu dut.
Tradizionalki, sistema osagai multzo bat bezala ikusten dugu (teknikoak edo goi-mailakoak), helbururen bat lortzeko elkarren artean elkarreragiten duten negozio-modulu gisa. Eta ikuspegi hori diseinurako justifikatuta badago, ez da nahiko egokia deskribatzeko eta ulertzeko. Hainbat arrazoi daude hemen:
- Errealitatea paperean dagoenaren ezberdina da. Dena ez da aurreikusi bezala ateratzen. Eta benetan nola izan den eta nola funtzionatzen duen interesatzen zaigu.
- Informazioaren aurkezpen koherentea. Izan ere, hasieratik gaur egungo egoerara kronologikoki joan zaitezke.
- Sinpletik konplexura. Ez unibertsalki, baina gure kasuan hala da. Arkitektura ikuspegi sinpleagoetatik konplexuagoetara pasa zen. Askotan, konplikazioaren bidez, ezarpen-abiadura eta egonkortasun arazoak konpondu ziren, baita funtzio ez-funtziodunen zerrendako beste hamaika propietate ere ( ondo kontatua konplexutasuna beste eskakizun batzuekin kontrasteaz).
2011n, Dodo IS arkitekturak itxura hau zuen:
2020rako, pixka bat zailagoa bihurtu da eta honela geratu da:
Nola gertatu zen bilakaera hori? Zergatik behar dira sistemaren zati desberdinak? Zein erabaki arkitektoniko hartu ziren eta zergatik? Jakin dezagun artikulu sorta honetan.
2016ko lehen arazoak: zergatik utzi behar dute zerbitzuek monolitoa
Zikloko lehen artikuluak monolitotik bereizten lehenak izan ziren zerbitzuei buruzkoak izango dira. Testuinguruan jartzeko, 2016. urtearen hasieran sisteman zer arazo izan genituen esango dizut, zerbitzuen bereizketari aurre egin behar geniola.
MySql datu-base bakarra, non garai hartan Dodo IS-en zeuden aplikazio guztiek beren erregistroak idatzi zituzten. Ondorioak hauek izan ziren:
- Zama astuna (eskaeren %85 irakurketarekin).
- Oinarria hazi egin da. Horregatik, bere kostua eta laguntza arazo bihurtu ziren.
- Porrot puntu bakarra. Datu-basean idazten ari den aplikazio bat bat-batean modu aktiboagoan egiten hasten bazen, beste aplikazio batzuek euren kabuz sentitzen zuten.
- Eraginkortasunik eza biltegiratzeko eta kontsultak egiteko. Sarritan datuak agertoki batzuetarako egokiak ziren baina beste batzuetarako egokiak ez ziren egitura batzuetan gordetzen ziren. Indizeek eragiketa batzuk bizkortzen dituzte, baina beste batzuk moteldu ditzakete.
- Arazoetako batzuk azkar eginiko cacheak eta oinarrien irakurketa-erreplikek kendu zituzten (artikulu bereizia izango da), baina denbora irabazten bakarrik utzi zieten eta ez zuten funtsean arazoa konpondu.
Arazoa monolitoaren beraren presentzia zen. Ondorioak hauek izan ziren:
- Argitalpen bakarrak eta arraroak.
- Pertsona kopuru handi baten garapen bateratua izateko zailtasuna.
- Teknologia berriak, esparru eta liburutegi berriak ekartzeko ezintasuna.
Oinarriarekin eta monolitoarekin izandako arazoak askotan deskribatu dira, adibidez, 2018 hasieran izandako istripuen testuinguruan (, ΠΈ ), beraz, ez naiz gehiegi luzatuko. Esan dezadan zerbitzuak garatzerakoan malgutasun handiagoa eman nahi genuela. Lehenik eta behin, sistema osoan kargatu eta erro gehien zeudenei dagokie - Auth eta Tracker.
Bulegoko bidea: Oinarri bereiziak eta autobusa
Kapituluen nabigazioa
Monolito eskema 2016
Hona hemen Dodo IS 2016 monolitoaren bloke nagusiak, eta azpian haien zeregin nagusien transkripzioa dago.
Kutxazain entrega. Mezularitzak kontabilizatzea, mezulariei aginduak ematea.
Harremanetarako zentroa. Aginduak operadorearen bidez onartzea.
Web. Gure webguneak (dodopizza.ru, dodopizza.co.uk, dodopizza.by, etab.).
auth. Back officerako baimen eta autentifikazio zerbitzua.
tracker. Eskaeraren jarraipena sukaldean. Eskaera prestatzerakoan prest egoerak markatzeko zerbitzua.
Jatetxeko kutxazaina. Jatetxe batean eskaerak hartzea, kutxazain interfazeak.
Esportatu. Txostenak 1C-n igotzea kontabilitaterako.
Jakinarazpenak eta fakturak. Ahots-aginduak sukaldean (adibidez, "Pizza berria iritsi da") + mezularientzako faktura inprimatzea.
Txandako zuzendaria. Txandako zuzendariaren lanerako interfazeak: eskaeren zerrenda, errendimendu grafikoak, langileak txandara eramatea.
Bulegoko zuzendaria. Frankiziadunaren eta gerentearen lanerako interfazeak: langileen harrera, pizzeriaren lanari buruzko txostenak.
Jatetxearen markagailua. Menua erakustea pizzerietako telebistetan.
admin. Pizzeria zehatz bateko ezarpenak: menua, prezioak, kontabilitatea, promozio kodeak, promozioak, webguneko banner-ak, etab.
Langilearen kontu pertsonala. Langileen lan ordutegiak, langileei buruzko informazioa.
Sukaldeko Motibazio Mahaia. Sukaldean zintzilik dagoen eta pizza-egileen abiadura erakusten duen pantaila bereizia.
komunikazioa. Sms eta mezu elektronikoak bidaltzea.
Fitxategien biltegiratzea. Fitxategi estatikoak jaso eta igortzeko zerbitzu propioa.
Arazoak konpontzeko lehen saiakerek lagundu ziguten, baina behin-behineko atsedena baino ez ziren izan. Ez ziren sistema konponbide bihurtu, beraz, argi zegoen oinarriekin zerbait egin behar zela. Adibidez, datu-base orokorra hainbat espezializatuagotan banatzea.
Monolitoa deskargatzen hastea: Auth eta Tracker bereiztea
Datu-basetik besteek baino gehiago erregistratu eta irakurtzen zituzten zerbitzu nagusiak:
- Autent. Back officerako baimen eta autentifikazio zerbitzua.
- Jarraitzailea. Eskaeraren jarraipena sukaldean. Eskaera prestatzerakoan prest egoerak markatzeko zerbitzua.
Zer egiten du Auth-ek?
Auth zerbitzu bat da, zeinaren bidez erabiltzaileak atzeko bulegoan hasten dira saioa (bezeroaren aldean sarrera independente bat dago). Halaber, eskaeran eskatzen da beharrezkoak diren sarbide-eskubideak daudela eta azken saioa hasi zenetik eskubide horiek aldatu ez direla ziurtatzeko. Haren bitartez, gailuak pizzerian sartzen dira.
Adibidez, pantaila bat ireki nahi dugu aretoan zintzilik dagoen telebistan amaitutako eskaeren egoerarekin. Ondoren, auth.dodopizza.ru irekiko dugu, hautatu "Hasi saioa gailu gisa", txanda-kudeatzailearen ordenagailuan orri berezi batean sar daitekeen kode bat agertzen da, gailu (gailu) mota adieraziz. Telebista bera bere pizzeriaren nahi den interfazera aldatuko da eta bertan eskaerak prest dituzten bezeroen izenak bistaratzen hasiko da.
Nondik datoz zamak?
Back office-n saioa hasitako erabiltzaile bakoitza datu-basera doa, eskaera bakoitzerako erabiltzaile-taulara, erabiltzailea ateratzen du sql kontsulta baten bidez eta orrialde honetarako beharrezko sarbidea eta eskubideak dituen egiaztatzen du.
Gailu bakoitzak gauza bera egiten du gailuen taularekin bakarrik, bere rola eta sarbidea egiaztatuz. Datu-base nagusiari egindako eskaerak kopuru handi batek bere karga eta eragiketa hauetarako datu-base komunaren baliabideak xahutzea dakar.
Autentifikazioa deskargatzen
Auth-ek domeinu isolatua du, hau da, erabiltzaileei, saio-saioei edo gailuei buruzko datuak zerbitzuan sartzen dira (momentuz) eta bertan geratzen dira. Norbaitek behar baditu, zerbitzu honetara joango da datu bila.
ZEN. Jatorrizko lan-eskema honako hau zen:
Nola funtzionatu zuen pixka bat azaldu nahiko nuke:
- Kanpoko eskaera bat backend-era dator (Asp.Net MVC dago), saioko cookie bat dakar, Redis(1) saioko datuak lortzeko erabiltzen dena. Sarbideei buruzko informazioa dauka, eta gero kontrolagailurako sarbidea irekita dago (3,4) edo ez.
- Sarbiderik ez badago, baimen-prozedura igaro behar duzu. Hemen, sinpletasunerako, atributu bereko bidearen zati gisa erakusten da, nahiz eta saioa hasteko orrirako trantsizioa den. Eszenatoki positibo baten kasuan, behar bezala osatutako saio bat lortuko dugu eta Backoffice Controllerera joango gara.
- Datuak badaude, erabiltzaileen oinarrian duten garrantzia egiaztatu behar duzu. Aldatu al da bere rola, ez zaio orain orrialdean sartu behar? Kasu honetan, saioa jaso ondoren (1), zuzenean datu-basera joan eta erabiltzailearen sarbidea egiaztatu behar duzu autentifikazio-geruza logikoa erabiliz (2). Ondoren, saioa hasteko orrira edo joan kontrolagailura. Hain sistema sinplea, baina ez nahiko estandarra.
- Prozedura guztiak gainditzen badira, kontrolagailu eta metodoetan logika gehiago saltatzen dugu.
Erabiltzaileen datuak beste datu guztietatik bereizten dira, aparteko kideen taula batean gordetzen dira, AuthService geruza logikoko funtzioak api metodo bihur daitezke. Domeinuen mugak nahiko argi definitzen dira: erabiltzaileak, haien rolak, sarbide-datuak, sarbidea ematea eta baliogabetzea. Dena ematen du zerbitzu bereizi batean atera ahal izateko.
IZAN. Hala egin zuten:
Ikuspegi honek arazo ugari ditu. Adibidez, prozesu baten barruan metodo bati deitzea ez da kanpoko zerbitzu bati http bidez deitzea. Latentzia, fidagarritasuna, mantentze-gaitasuna, funtzionamenduaren gardentasuna guztiz desberdinak dira. Andrey Morevskiyk halako arazoei buruz zehatzago hitz egin zuen bere txostenean. .
Autentifikazio-zerbitzua eta, horrekin batera, gailu-zerbitzua back officerako erabiltzen dira, hau da, ekoizpenean erabiltzen diren zerbitzu eta interfazeetarako. Bezero-zerbitzuetarako autentifikazioa (adibidez, webgune bat edo mugikorretarako aplikazio bat) bereizita egiten da Auth erabili gabe. Banaketak urtebete inguru iraun zuen, eta orain berriro gai hau jorratzen ari gara, sistema autentifikazio zerbitzu berrietara (protokolo estandarrekin) transferituz.
Zergatik iraun zuen hainbeste denbora bereizketak?
Bidean moteldu gintuzten arazo asko izan ziren:
- Herrialde espezifikoko datu-baseetatik erabiltzaile, gailu eta autentifikazio-datuak batera eraman nahi genituen. Horretarako, taula eta erabilera guztiak int identifikatzailetik UUId identifikatzaile globalera itzuli behar izan ditugu (berriki kode hau berritu da. eta kode irekiko proiektua ). Erabiltzaileen datuak biltegiratzeak (informazio pertsonala denez) bere mugak ditu eta herrialde batzuetarako beharrezkoa da bereizita gordetzea. Baina erabiltzailearen id globalak izan behar du.
- Datu-baseko taula askok auditoretza-informazioa dute eragiketa egin duen erabiltzaileari buruz. Horrek koherentziarako mekanismo gehigarri bat behar zuen.
- Api-zerbitzuak sortu ondoren, beste sistema baterako trantsizio epe luze eta pixkanaka egon zen. Erabiltzaileentzat aldatzea ezin hobea izan behar zen eta eskuzko lana behar zuen.
Gailua erregistratzeko eskema pizzeria batean:
Auth eta Devices zerbitzua atera ondoren arkitektura orokorra:
Kontuan izan. 2020rako, Auth-en bertsio berri bat lantzen ari gara, OAuth 2.0 baimen estandarrean oinarritzen dena. Estandar hau nahiko konplexua da, baina baliagarria da pass-through autentifikazio-zerbitzu bat garatzeko. artikuluan "Β» Gu Alexey Chernyaev estandarra ahalik eta modu errazen eta argien kontatzen saiatu ginen, hura aztertzen denbora aurrezteko.
Zer egiten du Tracker-ek?
Orain kargatutako zerbitzuetako bigarrenari buruz. Jarraitzaileak eginkizun bikoitza betetzen du:
- Batetik, bere zeregina sukaldeko langileei erakustea da gaur egun zer enkargu lanean dauden, orain zer produktu prestatu behar diren.
- Bestetik, sukaldeko prozesu guztiak digitalizatzea.
Eskaera batean produktu berri bat agertzen denean (adibidez, pizza), Rolling out tracker geltokira doa. Geltoki honetan, pizza-egile bat dago behar den tamainako opil bat hartu eta jaurtitzen duena, eta, ondoren, jarraipenaren tabletan bere zeregina amaitu duela ohartzen du eta ijetzitako ore-oinarria hurrengo geltokira transferitzen du - "Hasiera" .
Bertan, hurrengo pizza-egileak pizza betetzen du, ondoren bere zeregina bete duela eta pizza labean sartzen du tabletan (taulan adierazi behar den geltoki bereizia da hau ere). Halako sistema bat hasiera-hasieratik izan zen Dodo-n eta Dodo IS-en existentziaren hasiera-hasieratik. Transakzio guztiak guztiz jarraitzeko eta digitalizatzeko aukera ematen du. Horrez gain, jarraitzaileak produktu jakin bat nola prestatu iradokitzen du, produktu mota bakoitza bere fabrikazio-eskemaren arabera gidatzen du, produktuaren egosketa denbora optimoa gordetzen du eta produktuaren eragiketa guztien jarraipena egiten du.
Horrelakoa da tabletaren pantaila "Raskatka" jarraitzailearen geltokian
Nondik datoz zamak?
Pizzeria bakoitzak bost tablet inguru ditu jarraitzaile batekin. 2016an, 100 pizzeria baino gehiago genituen (eta orain 600 baino gehiago). Tabletetako bakoitzak eskaera bat egiten dio backend-ari 10 segundoro behin eta eskaera-taularen (bezeroarekin eta helbidearen konexioa), eskaeraren osaera (produktuarekin konexioa eta kantitatearen adierazpidea), motibazio-kontabilitate-taularen datuak ateratzen ditu ( sakatzearen denboraren jarraipena egiten da bertan). Pizza-egile batek jarraitzaileko produktu batean klik egiten duenean, taula horietako guztietako sarrerak eguneratzen dira. Eskaera-taula orokorra da, eskaera bat onartzerakoan txertaketak, sistemaren beste atal batzuetako eguneraketak eta irakurketa ugari ere baditu, adibidez, pizzeria batean zintzilik dagoen eta bezeroei egindako eskaerak erakusten dizkien telebista batean.
Kargekin borroka garaian, dena eta dena cachean gorde eta oinarriaren erreplika asinkronora transferitu zirenean, jarraitzailearekin egindako eragiketa hauek oinarri nagusira joaten jarraitu zuten. Ez luke atzerapenik egon behar, datuak eguneratuta egon behar dira, sinkronizazioa desegokia da onartezina.
Era berean, taula eta indize propiorik ez egoteak ez zuen baimendu haien erabilerarako egokitutako kontsulta zehatzagoak idazteko. Esate baterako, eraginkorra izan liteke jarraitzaile batek eskaera-taulan pizzeria baten indize bat izatea. Beti kentzen ditugu pizzerien eskaerak jarraitzaileen datu-basetik. Aldi berean, eskaera bat jasotzeko, ez da hain garrantzitsua zein pizzerian erortzen den, garrantzitsuagoa da zein bezerok egin duen eskaera hori. Eta esan nahi du hor bezeroaren indizea beharrezkoa dela. Era berean, ez da beharrezkoa jarraitzaileak eskaerarekin lotutako inprimatutako ordainagiriaren edo bonus-sustapenen IDa gordetzea eskaera-taulan. Informazio hau ez da interesgarria gure jarraitzaile-zerbitzuarentzat. Datu-base monolitiko komun batean, taulak erabiltzaile guztien arteko konpromisoa soilik izan litezke. Hau izan zen jatorrizko arazoetako bat.
ZEN. Jatorrizko arkitektura hau izan zen:
Prozesu bereizietan banatuta ere, kode-oinarri gehiena ohikoa izaten jarraitzen zuen zerbitzu desberdinetarako. Kontrolagailuen azpian dagoen guztia bakarra zen eta biltegi berean bizi zen. Zerbitzuen metodo komunak erabili genituen, biltegiak, oinarri komun bat, zeinetan mahai komunak zeuden.
Tracker deskargatzen
Tracker-aren arazo nagusia datu-base ezberdinen artean sinkronizatu behar dela da. Hau da, halaber, Auth zerbitzuaren bereizketarekin duen desberdintasun nagusia, ordena eta bere egoera alda daitezke eta zerbitzu ezberdinetan bistaratu behar dira.
Jatetxeko Kutxan eskaera bat onartzen dugu (zerbitzu bat da), datu-basean gordetzen da "Onartuta" egoeran. Horren ostean, jarraitzailera iritsi beharko luke, non bere egoera beste hainbat aldiz aldatuko duen: "Sukaldea"tik "Paketatuta". Aldi berean, Kutxazainaren edo Shift Manager interfazearen kanpoko eragin batzuk gerta daitezke eskaerarekin. Eskaeraren egoerak taulan haien deskribapenarekin emango ditut:
Eskaeraren egoerak aldatzeko eskemak hauxe du:
Sistema ezberdinen artean egoerak aldatzen dira. Eta hemen jarraitzailea ez da datuak ixten diren azken sistema bat. Horrelako kasuetan zatitzeko hainbat hurbilketa posible ikusi ditugu:
- Eskaera ekintza guztiak zerbitzu bakarrean biltzen ditugu. Gure kasuan, aukera honek zerbitzu gehiegi eskatzen du eskaerarekin lan egiteko. Bertan geldituko bagina, bigarren monolitoa lortuko genuke. Ez genuke arazoa konponduko.
- Sistema batek beste bati dei egiten dio. Bigarren aukera dagoeneko interesgarriagoa da. Baina horrekin batera, dei-kateak posible dira (), osagaien konektibitatea handiagoa da, zailagoa da kudeatzea.
- Ekitaldiak antolatzen ditugu, eta zerbitzu bakoitza beste batekin komunikatzen da ekitaldi horien bidez. Ondorioz, hirugarren aukera izan zen aukeratutakoa, eta horren arabera zerbitzu guztiak elkarren artean ekitaldiak trukatzen hasten dira.
Hirugarren aukera aukeratzeak esan nahi zuen tracker-ak bere datu-basea izango zuela, eta eskaeraren aldaketa bakoitzeko, honi buruzko ekitaldi bat bidaliko zuen, zein beste zerbitzutara harpidetzen den eta zein, besteak beste, masterrean sartzen den. datu-basea. Horretarako, zerbitzuen arteko mezuak bidaltzea bermatuko zuen zerbitzuren bat behar genuen.
Ordurako, RabbitMQ geneukan pilan, horregatik mezuen bitartekari gisa erabiltzeko azken erabakia hartu genuen. Diagramak Jatetxe Kutxazainetik Tracker bidez egindako eskaera baten trantsizioa erakusten du, non bere egoera eta Kudeatzailearen Eskaerak interfazean bistaratzen dituen. BIHURTU:
Agindu bidea urratsez urrats
Eskaera-bidea eskaera-iturburuko zerbitzuetako batean hasten da. Hona hemen jatetxeko kutxazaina:
- Ordaintzean, eskaera guztiz prest dago, eta jarraitzailera bidaltzeko garaia da. Jarraitzailea harpidetuta dagoen gertaera botatzen da.
- Jarraitzaileak, eskaera bat beretzat onartuz, bere datu-basean gordetzen du, "Order Accepted by Tracker" gertaera eginez eta RMQra bidaliz.
- Dagoeneko hainbat kudeatzaile daude ekitaldien autobusera harpidetuta eskaera bakoitzeko. Guretzat, oinarri monolitiko batekin sinkronizazioa egiten duena garrantzitsua da.
- Kudeatzaileak gertaera bat jasotzen du, bertatik esanguratsuak diren datuak hautatzen ditu: gure kasuan, hau da " Tracker-ek onartutako " eskaeraren egoera eta bere eskaera-entitatea datu-base nagusian eguneratzen du.
Norbaitek mahai monolitikoen aginduetatik agindu bat behar badu, hortik ere irakur dezakezu. Adibidez, Shift Manager-eko Eskaerak interfazeak hau behar du:
Gainerako zerbitzu guztiak ere harpidetu daitezke jarraitzailetik gertaerak eskatzeko, beraiek erabiltzeko.
Pixka bat igaro ondoren, eskaera lanean jartzen bada, bere egoera lehenik bere datu-basean aldatzen da (Tracker datu-basean), eta gero "OrderIn Progress" gertaera berehala sortzen da. RMQ-n ere sartzen da, eta bertatik datu-base monolitiko batean sinkronizatu eta beste zerbitzu batzuetara entregatzen da. Bidean hainbat arazo egon daitezke, horiei buruzko xehetasun gehiago Zhenya Peshkov-en txostenean aurki daitezke .
Azken arkitektura Auth eta Tracker-en aldaketen ondoren
Tarteko emaitza laburbilduz: Hasieran, Dodo IS sistemaren bederatzi urteko historia artikulu batean biltzeko ideia izan nuen. Azkar eta erraz hitz egin nahi nuen eboluzioaren faseei buruz. Hala ere, materialaren bila eserita, dena dirudiena baino askoz korapilatsuagoa eta interesgarriagoa dela konturatu nintzen.
Material horren onurez (edo horren gabeziaz) hausnartuz, ondorioztatu nuen etengabeko garapena ezinezkoa dela gertaeren analitiko osorik gabe, atzera begirako zehatzak eta nire iraganeko erabakien azterketarik gabe.
Espero dut erabilgarria eta interesgarria izan izana gure bidea ezagutzea. Orain hurrengo artikuluan Dodo IS sistemaren zein atal deskribatu behar den aukera baten aurrean nago: iruzkinetan idatzi edo bozkatu.
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
Dodo ISren zein atal jakin nahiko zenuke hurrengo artikuluan?
-
24,1%Dodo IS-en lehen monolitoa (2011-2015)14
-
24,1%Lehen arazoak eta haien konponbideak (2015-2016)14
-
20,7%Bezeroaren aldeko bidea: fatxada oinarriaren gainean (2016-2017)12
-
36,2%Egiazko mikrozerbitzuen historia (2018-2019)21
-
44,8%Monolitoaren zerra osoa eta arkitektura egonkortzea26
-
29,3%Sistema garatzeko plan gehiagori buruz17
-
19,0%Ez dut ezer jakin nahi Dodo IS11-i buruz
58 erabiltzailek eman dute botoa. 6 erabiltzaile abstenitu ziren.
Iturria: www.habr.com