«Bitrix24»: «Kiiresti tõstetud ei loeta kukkunud»

Tänaseks pole teenusel «Bitrix24» sadu gigabite liiklust, pole tohutut serverite parki (kuigi olemasolevaid on muidugi päris palju). Kuid paljudele klientidele on see ettevõtte töö peamine vahend, tõeline business-critical rakendus. Seetõttu ei tohi see absoluutselt kokku kukkuda. Aga mis siis, kui kukkumine siiski juhtus, aga teenus «tõusis» nii kiiresti, et keegi ei märkagi? Ja kuidas õnnestub sellega samal ajal rakendada failoveri ilma kvaliteedi kadumiseta ja klientide arvu vähenemiseta? Alexander Demidov, «Bitrix24» pilveteenuste suuna direktor, rääkis meie blogis, kuidas on 7 aasta jooksul toote olemasolust arenenuud varundamissüsteemi.

„SaaS“ vormis käivitasime „Bitrix24“ 7 aastat tagasi. Peamine väljakutse oli tõenäoliselt see, et enne avalikku käivitamist „SaaS“ vormis eksisteeris see toode lihtsalt kastilahendusena. Kliendid ostsid selle meilt, paigaldasid selle oma serveritesse, lõid ettevõtteportaali — ühise lahenduse töötajate suhtlemiseks, failide hoidmiseks, ülesannete korraldamiseks, CRM-iks, kõigeks selleks. Ja 2012. aastaks otsustasime, et soovime selle käivitada kui „SaaS“, hallates seda ise ja tagades töökindluse ja usaldusväärsuse. Kogemusi kogusime protsessi käigus, kuna enne seda polnud meil seda lihtsalt olnud — olime vaid tarkvaratootjad, mitte teenusepakkujad.

Teenuse käivitamisel mõistsime, et kõige olulisem on tagada teenuse töökindlus, usaldusväärsus ja pidev kättesaadavus. Kui teil on lihtsalt tavaline veebisait, näiteks pood, ja see on maas tund aega — kannatate ainult teie, kaotate tellimusi ja kliente, kuid teie klient ei pea seda eriti kriitiliseks. Ta muidugi tunneb end halvasti, kuid läheb ja ostab mujalt. Kuid kui see on rakendus, millel põhineb kogu töö firmasisesteks suheteks ja lahenduste leidmiseks, siis on kõige olulisem kasutajate usalduse võitmine — mitte neid alt vedada ja mitte alla kukkuda. Sest kogu töö võib peatuda, kui miski seest ei tööta.

Bitrix24 nagu SaaS

Esimese prototüübi lõime aasta enne avalikku käivitamist, 2011. aastal. Kogusime selle umbes nädala jooksul, vaatasime, keerasime – see töötas isegi. St, sai minna vormi, sisestada portaalinimi ja käivitada uus portaal, luua kasutajabaas. Vaatasime seda, hindasime põhimõtteliselt toodet, sulgesime ja töötasime aasta edasi. Selle tõttu, et meil oli suur eesmärk: me ei soovinud teha kahte erinevat koodibaasi, ei soovinud toetada eraldi loodud toodet ja eraldi pilve lahendusi, — me soovisime teha kõike ühtse koodi raames.

Tüüpiline veebirakendus sel ajal oli üks server, kus jooksis mingisugune php kood, mysql andmebaas, failid laaditi üles, dokumendid, pildid pandi upload kausta – no ja kõik see töötas. Kahjuks ei ole võimalik sellistel alustel käivitada kriitiliselt usaldusväärset veebiteenust. Seal ei toetata jaotatud vahemälu ega andmebaaside replikeerimist.

Oleme määratlenud nõuded: see hõlmab võimalust paikneda erinevates asukohtades, toetada replikatsiooni ning ideaaljuhul paikneda geograafiliselt jaotatud andmekeskustes. Toote loogika ja andmete salvestamise eraldamine. Dünaamiline skaleerimine koormuse järgi, staatika väljastamine. Nendest kaalutlustest tulenesid nõuded tootele, mida oleme aasta jooksul täiustanud. Selle aja jooksul on meie saadud platvorm, mis on muutunud ühtseks — nii kastilahenduste kui ka meie teenuse jaoks — saanud toetuse nendele elementidele, mis olid meile vajalikud. Mysql-replikatsiooni tugi toote tasemel: see tähendab, et arendaja, kes kirjutab koodi, ei pea mõtlema, kuidas tema päringud jaotuvad, vaid kasutab meie API-d, samas kui meie suudame õigesti jaotada kirjutamise ja lugemise päringud masterite ja slave'ide vahel.

Oleme tõstnud toetaseme mitmete pilvepõhiste objektide salvestusteenuste, nagu Google Storage, Amazon S3, — lisaks ka OpenStack Swifti, toetamiseks. Seetõttu on see olnud mugav nii meie teenuse kui ka arendajate jaoks, kes töötavad valmislahendusega: kui nad kasutavad lihtsalt meie API-t, siis ei pea nad muretsema, kus fail lõpuks salvestatakse, kas kohalikule failisüsteemile või objektide salvestusteenusele.

Lõpuks otsustasime kohe, et seame end üles kogu andmekeskuse tasemel. 2012. aastal käivitasime end täielikult Amazon AWS-is, kuna meil oli juba see platvormiga kogemus — meie enda sait oli seal majutatud. Meie jaoks oli oluline, et igas regioonis on Amazonis mitu kättesaadavustsooni — põhimõtteliselt (nende terminoloogias) mitu andmekeskust, mis on teineteisest enam-vähem iseseisvad ja võimaldavad meil rikka andmekeskuse tasemel: kui see peaks töölt välja kukkuma, replitseeritakse andmebaasid master-master, veebirakenduste serverid on reserveeritud ja staatika on paigutatud objektide salvestusesse s3. Koormus jaotatakse — sel hetkel Amazon’i elb’ga, kuid hiljem jõudsime oma load balancer’ite juurde, kuna vajasime keerukamat loogikat.

Saime just seda, mida soovisime...

Kõik põhilised asjad, mida soovisime tagada — serverite, veebirakenduste ja andmebaaside talitlushäired — töötasid hästi. Lihtsaim stsenaarium: kui mõni meie veebirakendus ebaõnnestub, siis on kõik lihtne — nad eemaldatakse tasakaalustamisest.

Välja surnud tasakaalustajad (tol hetkel oli see Amazoni ELB) märkisid ise endid ebatervislikeks, lõpetades nendele koormuse jaotamise. Amazoni automaatne skaleerimine töötas: kui koormus suurenes, lisandus automaatse skaleerimise rühma uusi masinaid, koormus jaotati uutele masinatele - kõik toimis hästi. Meie tasakaalustajatel on loogika enam-vähem sama: kui serveriga juhtub midagi, eemaldame sellele päringud, eemaldame need masinad, käivitame uued ja jätkame tööd. Skeem on aastate jooksul veidi muutunud, kuid see töötab endiselt: see on lihtne, arusaadav ja sellega ei ole mingeid keerukusi.

Me töötame üle kogu maailma, klientide koormuse tipud on täiesti erinevad ja, õigupoolest, peaksime olema võimelised läbi viima teenindustöid meie süsteemi ükskõik milliste komponentidega igal ajal – klientidele märkamatult. Seetõttu on meil võimalus häälestada andmebaas välja, jagades koormust teise andmekeskuse vahel.

Kuidas see kõik töötab? — Me suuname liikluse töötavale andmekeskusele — kui tegemist on andmekeskuse rikkega, siis täielikult, kui teeme plaanilisi töid mõnes kindlas andmebaasis, siis suuname osa liiklust, mis teenindab neid kliente, teise andmekeskusse, replikeerimine peatatakse. Kui vajame uusi masinaid veebirakendustele, kuna koormus teises andmekeskuses on suurenenud, käivitatakse need automaatselt. Kui tööd on lõpetatud, taastatakse replikeerimine ja suuname kogu koormuse tagasi. Kui peame teises andmekeskuses järelevalve töid tegema, näiteks installima süsteemivärskendusi või muutma seadeid teises andmebaasis, siis, põhimõtteliselt, kordame kõik samu samme, lihtsalt vastupidises suunas. Ja kui see on rike, siis teeme kõik lihtsalt: jälgimissüsteemis kasutame event-handler'ite mehhanismi. Kui meil töötab mitu kontrolli ja olek muutub kriitiliseks, käivitame selle handleri, töötleja, mis suudab täita teatud loogikat. Meil on iga andmebaasi jaoks kirjas, milline server on selle failover ja kuhu liiklus suunata, kui see pole saadaval. Meie süsteemides, ajalooliselt, kasutame me nagios'e või midagi, mis on selle fork. Põhimõtteliselt on taolised mehhanismid praktiliselt igas jälgimissüsteemis olemas, praegu me midagi keerulisemat ei kasuta, kuid võibolla kunagi kasutame. Praegu reageerib jälgimine mitteeelarvataolekule ja tal on võimalus midagi suunata.

Kas oleme kõik broneerinud?

Meil on palju kliente Ameerikas, rohkelt kliente Euroopas, samuti kliente, kes asuvad lähemal Idas — Jaapanis, Singapuris ja nii edasi. Loomulikult on suur osa kliente Venemaal. See tähendab, et meie tegevus ei piirdu vaid ühe piirkonnaga. Kasutajad soovivad kiiret vastust, on kohustus järgida erinevaid kohalikke seadusi, ning igas piirkonnas reservime kaks andmekeskust. Lisaks on olemas mõned täiendavad teenused, mille paigutamine ühte piirkonda on mugavam — klientidele, kes seal töötavad. REST-handlers ja autoriseerimiserverid ei ole kliendi töö jaoks nii kriitilised, neid saab vahetada mõningase vastuvõetava viivitusega, kuid me ei taha uuesti jalgratast leiutada, kuidas neid jälgida ja mida nendega teha. Seetõttu püüame maksimaalselt kasutada juba olemasolevaid lahendusi, mitte arendada oma kompetentsi täiendavate toodete osas. Mõnes kohas kasutame lihtsalt DNS-i tasemel ümberlülitamist, määrates teenuse aktiivsuse samasuguse DNS-i abil. Amazonis on teenus Route 53, kuid see pole lihtsalt DNS, kuhu saab kirjeid sisse kirjutada ja kõik — see on palju paindlikum ja mugavam. Selle abil on võimalik üles ehitada geojaotatud teenuseid geolokatsioonidega, millega saate määrata, kust klient tuli, ja pakkuda talle vastavaid kirjeid — selle abil on võimalik luua ka failover-architektuure. Samad tervisekontrollid seadistatakse Route 53-s, kus määrate endpoint-id, mida jälgitakse, määrate mõõdikud, mille järgi määrata teenuse „elujõud“ — TCP, HTTP, HTTPS; määrate kontrollide sageduse, et kindlaks teha, kas teenus on elujõuline või mitte. Ja oma DNS-is registreerite, mis on primaarne, mis sekundaarne, kuhu ümber lülituda, kui Route 53-s sisselülitamistuvastus aktiveerub. Kõike seda saab teha ka teiste tööriistade abil, kuid mugavus seisneb selles, et seadistate selle üks kord ja ei pea enam üldse mõtlema, kuidas meie kontrollid toimuvad, kuidas ümberlülitused käivad: kõik töötab iseseisvalt.

Esimene "aga": aga kuidas ja millega reserveerida ise Route 53? Isegi, kui juhtub midagi? Meil on õnneks kunagi sellist olukorda olnud, aga siiski, mul on eesolev jutt, miks me arutasime, et reserveerimine on vajalik. Siin me paneme endale ettevaatlikult õlgedest peenraha. Korraga mitu korda päevas teeme täieliku andmeekstraktsiooni kõikidest tsoonidest, mis meil Route 53-s on. Amazoni API võimaldab neid mugavalt JSON-formaadis edastada ja meil on üles seatud mitu varuserverit, kuhu me selle konverteerime, laadime välja konfiguratsioonid ja meil on, ütleme nii, varukoopia konfiguratsioon. Hädaolukorra korral saame selle kiiresti käsitsi taastada, kaotamata DNS-i seadistuste andmeid.

Teine "aga": mida ei ole sellel pildil veel reserveeritud? Just tasakaalustaja! Meie klientide jaotus piirkondade kaupa on väga lihtne. Meil on domeenid bitrix24.ru, bitrix24.com, .de — praegu on neid 13 erinevat, mis töötavad erinevates piirkondades. Oleme jõudnud järgmisele järeldusele: igas piirkonnas on oma tasakaalustajad. See muudab piirkondade vahel jaotamise mugavamaks, sõltuvalt sellest, kus on võrgukoormuse tipud. Kui tekib rike ühe tasakaalustaja tasemel, lülitatakse see lihtsalt välja ja eemaldatakse DNS-ist. Kui tekib probleem tasakaalustajate grupiga, reserveeritakse need teistel platsidel ning vahetus nende vahel toimub sama route53 abil, kuna lühikese ttl tõttu toimub vahetus maksimaalselt 2, 3, 5 minuti jooksul.

Kolmas "aga": mida veel ei ole reserveeritud? S3, eks ole. Me uskusime, et S3, kuhu salvestame kasutajate faile, on kuulikindel ja seal ei pea midagi reserveerima. Kuid ajalugu näitab, et asjad käivad teisiti. Üldiselt kirjeldab Amazon S3-d kui põhiteenust, kuna Amazon ise kasutab S3-d masinate piltide, konfiguratsioonide, AMI-piltide, snapshotide jne salvestamiseks... Ja kui S3 kukub, nagu see on juhtunud ühe korra 7 aasta jooksul, mil oleme bitrix24-t kasutanud, siis tõmbab see kaasa palju teisi probleeme — virtuaalsete masinate käivitamise häired, API rike ja nii edasi.

Ja S3 võib kukkuda — see on kunagi juhtunud. Seetõttu jõudsime järgmise skeemini: mõned aastad tagasi ei olnud Venemaal tõsiseltvõetavaid objekti avalikke ladustamisi ja mõtlesime, et teeme midagi oma… Õnneks me seda ei alustanud, sest oleksime süvenenud sellesse ekspertisu, mida meil ei olnud, ja kindlasti oleksime vea teinud. Praegu on s3 ühilduvaid ladustamisi Mail.ru, Yandexil ja veel mitmel teenusepakkujal. Lõpuks jõudsime järeldusele, et soovime, esiteks, varundamist ja teiseks, võimalust töötada kohalike koopiatega. Konkreetselt Venemaa regioonis kasutame Mail.ru Hotboxi teenust, mis on API kaudu ühilduv s3-ga. Me ei vajanud rakenduse sisese koodi osas tõsiseid muudatusi ja tegime järgmise mehhanismi: s3-s on käivitajad, mis aktiveeruvad objektide loomise/eealimise korral, Amazonil on selline teenus nagu Lambda — see on serverless koodi käivitamine, mis toimub just nendel korral, kui käivitavad teatud trigged.

Meie oleme selle lihtsaks teinud: kui meil aktiveerub käivitus, täidame koodi, mis kopeerib objekti Mail.ru salvestusse. Et alustada kohalike andmekoopia töötlemist, vajame veel tagasisünkroniseerimist, et kliendid, kes asuvad Venemaa segmendis, saaksid töötada salvestusega, mis on neile lähemal. Mail on peagi valmis käivitama käivitusi oma salvestuses — infrastruktuuri tasemel saab rakendada tagasikõnku, seni teeme seda meie enda koodil. Kui me näeme, et klient on üles laadinud mingi faili, paneme meie kooditasemel sündmuse järjekorda, töötleme seda ja teeme tagasikohandamise. Miks see on halb: kui meie toodet väliste vahenditega tehakse, ei arvestata seda. Seetõttu ootame lõpuni, kuni salvestuses aktiveeritakse käivitused, et sõltumata sellest, kust koodi täidame, kopeeritakse objekt, mis meieni jõuab, teisele poole.

Iga kliendi jaoks on meie kooditasemel määratud kaks salvestusruumi: üks peamine ja teine varundamiseks. Kui kõik on korras, töötame selle salvestusruumiga, mis on meile lähemal: sealhulgas meie kliendid, kes asuvad Amazonis, kasutavad S3, samas kui need, kes tegutsevad Venemaal, kasutavad Hotboxi. Kui lipp aktiveeritakse, peab meil olema failover-funktsioon, et saaksime kliente suunata teise salvestusruumi. Saame seda lippu panna sõltumatult regioonide kaupa ja saame neid vajadusel vahetada. Praktikas ei ole me sellega veel kasutanud, kuid me oleme selle mehhanismi ette näinud ja usume, et ühel hetkel vajame seda vahetust. See on juba üks kord juhtunud.

Oi, kas teie Amazon on kadunud...

Sel aprillil möödub aastapäev Telegrami blokeerimise algusest Venemaal. Kõige rohkem kannatasid selle tõttu Amazon, mis oli kõige kahjustatum teenusepakkuja. Kahjuks said rohkem kannatada ka maailma töötavad vene ettevõtted.

Kui ettevõte on globaalne ja Venemaa on selle jaoks vaid väike segment, 3-5% — siis mingil moel võib neid ohverdada.

Kui tegemist on puhtalt Venemaa ettevõttega, siis olen kindel, et tuleb paikneda kohapeal — lihtsalt kasutajatele endile on see mugavam, riskid on väiksemad.

Ent kui tegemist on ettevõttega, mis tegutseb globaalselt ja millel on umbes sama palju kliente Venemaalt kui mujal maailmas? Segmentide vahelise ühenduse olemasolu on oluline ning nad peavad omavahel mingil moel kokku töötama.

Juba 2018. aasta märtsi lõpus saatis Roskomnadzor suurimatele operaatoritele kirja, kus teatas, et nad kavatsevad blokeerida mitu miljonit Amazon'i IP-aadressi, et blokeerida… messengeri Zello. Aitäh nendele teenusepakkujatele — nad leaksid kirja edukalt ja tekkis arusaam, et Amazon'i ühendus võib katkeeda. Oli reede, ja me paanitsesime ning läksime servers.ru kolleegide juurde, öeldes: „Sõbrad, meil on vaja mitmeid servereid, mis ei asu Venemaal, mitte Amazon'is, vaid näiteks kuskil Amsterdamis“, et oleks vähemalt mingisugune võimalus seal oma… vpn ja proxy mõnele endpoint’ile, millele me ei saa mingil moel mõjuda, näiteks sama s3 endpoint’id — ei saa proovida tõsta uut teenust ja saada teist ip-d, meil on ikkagi vaja sinna jõuda. Mõne päeva jooksul seadistasime need serverid, tõstsime üles ja üldiselt olime blokeeringute alguseks valmis. Kõige huvitavam on see, et RKN, vaadates segadust ja tekitatud paanikat, ütles: „Ei, me ei kavatse midagi blokeerida.” (Aga see kestis täpselt kuni hetkeni, mil hakati blokkeerima Telegrammi.) Seades sisse ümbersõiduvõimalused ja mõistes, et blokeeringut ei olnud sisse viidud, ei hakanud me sellega siiski tegelema. Nii, igaks juhuks.

Ja, ja 2019. aastal elame me tõepoolest blokeeringute tingimustes. Eile öösel vaatasin: umbes miljon IP-aadressi jätkab blokeerimist. Tõsi, Amazoni on peaaegu täielikult blokeerimisest vabastatud, tipphetkel oli see 20 miljoni aadressi juurde… Ühesõnaga, reaalsus on selline, et sideteenuseid, head sideteenuseid — ei pruugi olla. Ühtäkki. Seda võib mitte olla tehniliste põhjuste tõttu — tulekahjud, ekskavaatorid, sellised asjad. Või nagu me oleme näinud, mitte täiesti tehnilistel põhjustel. Seega, keegi suur ja võimas, kellel on enda AS-id, võib tõenäoliselt seda muude meetoditega juhtida, — direct connect ja muud asjad juba l2 tasemel. Aga lihtsas variandis, nagu meie või veel väiksemad, on mõistlik igaks juhuks omada varukoopiaid serverite tasemel, mis on kuskil mujal üles seatud, eelnevalt seadistatud VPN, proxy, võimalusega kiiresti nendele konfigureerimisega üle lülitada neis segmentides, mis on teie jaoks sideteenustes kriitilised. See on meile korduvalt kasuks tulnud, kui Amazoni blokeeringud algasid, suunamine toimus halvimal juhul S3 kaudu, kuid järk-järgult lahenes kõik.

Aga kuidas reserveerida… tervet teenusepakkujat?

Praegu puudub meil stsenaarium, mis käsitleks kogu Amazoni tõrget. Meil on sarnane stsenaarium Venemaa jaoks. Venemaal olime ühes teenuseosutajas, kelle juures valisime, et oleksid mitmed platvormid. Ja aasta tagasi seisime silmitsi probleemiga: isegi kui tegemist on kahe andmekeskusega, võivad teenuseosutaja võrgu konfiguratsiooni tasemel esineda probleemid, mis mõjutavad ikkagi mõlemat andmekeskust. Seega võime saada ligipääsmatuks mõlemal platvormil. Loomulikult juhtuski nii. Lõpuks üle vaatasime meie arhitektuuri seestpoolt. See ei muutunud kuigi palju, kuid Venemaa jaoks on meil nüüd kaks platvormi, mis ei asu ühes teenuseosutajas, vaid kahes erinevas. Kui ühes midagi tõrkub, saame üle minna teisele.

Hüpotetiseerides kaalume Amazonile teise teenusepakkuja tasemel broneerimist; võib-olla Google, võib-olla veel keegi... Kuid seni oleme praktikas märganud, et kui Amazonil tekivad rikkeid ühes availability zone'is, siis kogu piirkonna rikkeid esineb suhteliselt harva. Seetõttu on meil teoreetiline arusaam, et võime broneerida "Amazon — mitte Amazon", kuid praktikas seda seni ei ole.

Mõned sõnad automatiseerimise kohta

Kas automaatika on alati vajalik? Siin on paslik meenutada Dunningi-Krugeri efekti. X teljel on meie teadmised ja kogemused, mida me omandame, ja Y teljel on meie enesekindlus oma tegevustes. Alguses me ei tea midagi ja ei ole üldse kindlad. Seejärel me teame natuke ja muutume ülihinnatud – see on nn "rumaluse tipptase", mida illustreerib hästi pilt "rumalus ja julgustunne". Edasi, me oleme juba natuke õppinud ja valmis lahingusse minema. Siis astume mõne tõsise takistuse otsa, satume meeleheite orgu, kus tundub, et me teame midagi, kuid tegelikult ei tea me paljusid asju. Seejärel, kogemuste kogumisega, muutume taas kindlamaks.

Meie lähenemine erinevatele lülitustele automaatselt teatud tõrgetele — seda on väga hästi kirjeldatud selle graafiku abil. Alustasime — me ei osanud midagi, praktiliselt kõik tööd tehti käsitsi. Siis mõistsime, et kõiki asju võib automatiseerida ja nagu, magada rahulikult. Ja äkki satume mega-äppesse: meil tekib valehäire ja lülitame liiklust siia-sinna, kui tegelikult poleks seda pidanud tegema. Seega, replikatsioon katke või midagi muud — see ongi meeleheite oru hetk. Ja edasi jõuame arusaamisele, et kõigesse tuleb suhtuda arukalt. Ehk siis on mõistlik tugineda automaatikatele, arvestades valehäire võimalusega. Kuid! Kui tagajärjed võivad olla katastroofilised, siis on parem lasta sel enda üle dürgnabil, vahetuses olevatel inseneridel, kes veenduvad, kontrollivad, et tõepoolest on häire, ja vajalikud toimingud teostatakse käsitsi...

Kokkuvõte

Seitsme aastaga oleme läinud olukorrast, kus kõik kukkus kokku ja toimus paanika, arusaamisele, et probleeme ei ole, on ainult ülesanded, mida tuleb lahendada — ja see on võimalik. Kui loote teenust, vaadake sellele ülaltpoolt, hinnake kõiki riske, mis võivad tekkida. Kui näete neid kohe — kavandage ette reserveerimine ja võimalus rajada tõrketaluv infrastruktuur, sest iga punkt, mis võib ebaõnnestuda ja teenuse töökatkestuse põhjustada, teeb seda kindlasti. Ja isegi kui teil on tunne, et mõni infrastruktuuri element ei tohi ebaõnnestuda — nagu näiteks s3, pidage ikkagi meeles, et need võivad. Ja vähemalt teoreetiliselt olge valmis mõtlema, mida te nendega teete, kui midagi juhtub. Olge valmis riskide maandamise plaaniga. Kui kaalute, kas teha kõik automaatikaga või käsitsi — hinnake riske: mis juhtub, kui automaatika hakkab kõike ümber lülitama — kas see ei too kaasa halvenenud olukorra võrreldes avariiga? Võib-olla on mõnes kohas mõistlik leida tasakaal automaatika kasutamise ja valves oleva inseneri reageerimise vahel, kes hindab tegelikku olukorda ja mõistab, kas on vaja midagi kohe lülitada või "jah, aga mitte praegu."

Mõistlik kompromiss perfektsionismi ja tegelike ressursside, aja ning rahaga, mida saate oma lõppprojekti jaoks kasutada.

See tekst on täiendatud ja laiendatud versioon Aleksandr Demidovi ettekandest konverentsil. Süsteemi tööaeg, päev 4.

Allikas: habr.com