{"id":35092,"date":"2019-10-31T22:02:18","date_gmt":"2019-10-31T19:02:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim\/"},"modified":"2019-10-31T22:02:18","modified_gmt":"2019-10-31T19:02:18","slug":"bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","title":{"rendered":"\u00abBitrix24\u00bb: \u00abKiiresti t\u00f5stetud ei loeta kukkunud\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

T\u00e4naseks pole teenusel \u00abBitrix24\u00bb sadu gigabite liiklust, pole tohutut serverite parki (kuigi olemasolevaid on muidugi p\u00e4ris palju). Kuid paljudele klientidele on see ettev\u00f5tte t\u00f6\u00f6 peamine vahend, t\u00f5eline business-critical rakendus. Seet\u00f5ttu ei tohi see absoluutselt kokku kukkuda. Aga mis siis, kui kukkumine siiski juhtus, aga teenus \u00abt\u00f5usis\u00bb nii kiiresti, et keegi ei m\u00e4rkagi? Ja kuidas \u00f5nnestub sellega samal ajal rakendada failoveri ilma kvaliteedi kadumiseta ja klientide arvu v\u00e4henemiseta? Alexander Demidov, \u00abBitrix24\u00bb pilveteenuste suuna direktor, r\u00e4\u00e4kis meie blogis, kuidas on 7 aasta jooksul toote olemasolust arenenuud varundamiss\u00fcsteemi.<\/p>\n

\"\u00abBitrix24\u00bb:
\n<\/a><\/noindex>
\n\u201eSaaS\u201c vormis k\u00e4ivitasime \u201eBitrix24\u201c 7 aastat tagasi. Peamine v\u00e4ljakutse oli t\u00f5en\u00e4oliselt see, et enne avalikku k\u00e4ivitamist \u201eSaaS\u201c vormis eksisteeris see toode lihtsalt kastilahendusena. Kliendid ostsid selle meilt, paigaldasid selle oma serveritesse, l\u00f5id ettev\u00f5tteportaali \u2014 \u00fchise lahenduse t\u00f6\u00f6tajate suhtlemiseks, failide hoidmiseks, \u00fclesannete korraldamiseks, CRM-iks, k\u00f5igeks selleks. Ja 2012. aastaks otsustasime, et soovime selle k\u00e4ivitada kui \u201eSaaS\u201c, hallates seda ise ja tagades t\u00f6\u00f6kindluse ja usaldusv\u00e4\u00e4rsuse. Kogemusi kogusime protsessi k\u00e4igus, kuna enne seda polnud meil seda lihtsalt olnud \u2014 olime vaid tarkvaratootjad, mitte teenusepakkujad. <\/p>\n

Teenuse k\u00e4ivitamisel m\u00f5istsime, et k\u00f5ige olulisem on tagada teenuse t\u00f6\u00f6kindlus, usaldusv\u00e4\u00e4rsus ja pidev k\u00e4ttesaadavus. Kui teil on lihtsalt tavaline veebisait, n\u00e4iteks pood, ja see on maas tund aega \u2014 kannatate ainult teie, kaotate tellimusi ja kliente, kuid teie klient ei pea seda eriti kriitiliseks. Ta muidugi tunneb end halvasti, kuid l\u00e4heb ja ostab mujalt. Kuid kui see on rakendus, millel p\u00f5hineb kogu t\u00f6\u00f6 firmasisesteks suheteks ja lahenduste leidmiseks, siis on k\u00f5ige olulisem kasutajate usalduse v\u00f5itmine \u2014 mitte neid alt vedada ja mitte alla kukkuda. Sest kogu t\u00f6\u00f6 v\u00f5ib peatuda, kui miski seest ei t\u00f6\u00f6ta.<\/p>\n

Bitrix24 nagu SaaS<\/h4>\n

\nEsimese protot\u00fc\u00fcbi l\u00f5ime aasta enne avalikku k\u00e4ivitamist, 2011. aastal. Kogusime selle umbes n\u00e4dala jooksul, vaatasime, keerasime \u2013 see t\u00f6\u00f6tas isegi. St, sai minna vormi, sisestada portaalinimi ja k\u00e4ivitada uus portaal, luua kasutajabaas. Vaatasime seda, hindasime p\u00f5him\u00f5tteliselt toodet, sulgesime ja t\u00f6\u00f6tasime aasta edasi. Selle t\u00f5ttu, et meil oli suur eesm\u00e4rk: me ei soovinud teha kahte erinevat koodibaasi, ei soovinud toetada eraldi loodud toodet ja eraldi pilve lahendusi, \u2014 me soovisime teha k\u00f5ike \u00fchtse koodi raames. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nT\u00fc\u00fcpiline veebirakendus sel ajal oli \u00fcks server, kus jooksis mingisugune php kood, mysql andmebaas, failid laaditi \u00fcles, dokumendid, pildid pandi upload kausta \u2013 no ja k\u00f5ik see t\u00f6\u00f6tas. Kahjuks ei ole v\u00f5imalik sellistel alustel k\u00e4ivitada kriitiliselt usaldusv\u00e4\u00e4rset veebiteenust. Seal ei toetata jaotatud vahem\u00e4lu ega andmebaaside replikeerimist. <\/p>\n

Oleme m\u00e4\u00e4ratlenud n\u00f5uded: see h\u00f5lmab v\u00f5imalust paikneda erinevates asukohtades, toetada replikatsiooni ning ideaaljuhul paikneda geograafiliselt jaotatud andmekeskustes. Toote loogika ja andmete salvestamise eraldamine. D\u00fcnaamiline skaleerimine koormuse j\u00e4rgi, staatika v\u00e4ljastamine. Nendest kaalutlustest tulenesid n\u00f5uded tootele, mida oleme aasta jooksul t\u00e4iustanud. Selle aja jooksul on meie saadud platvorm, mis on muutunud \u00fchtseks \u2014 nii kastilahenduste kui ka meie teenuse jaoks \u2014 saanud toetuse nendele elementidele, mis olid meile vajalikud. Mysql-replikatsiooni tugi toote tasemel: see t\u00e4hendab, et arendaja, kes kirjutab koodi, ei pea m\u00f5tlema, kuidas tema p\u00e4ringud jaotuvad, vaid kasutab meie API-d, samas kui meie suudame \u00f5igesti jaotada kirjutamise ja lugemise p\u00e4ringud masterite ja slave'ide vahel. <\/p>\n

Oleme t\u00f5stnud toetaseme mitmete pilvep\u00f5histe objektide salvestusteenuste, nagu Google Storage, Amazon S3, \u2014 lisaks ka OpenStack Swifti, toetamiseks. Seet\u00f5ttu on see olnud mugav nii meie teenuse kui ka arendajate jaoks, kes t\u00f6\u00f6tavad valmislahendusega: kui nad kasutavad lihtsalt meie API-t, siis ei pea nad muretsema, kus fail l\u00f5puks salvestatakse, kas kohalikule failis\u00fcsteemile v\u00f5i objektide salvestusteenusele.<\/p>\n

L\u00f5puks otsustasime kohe, et seame end \u00fcles kogu andmekeskuse tasemel. 2012. aastal k\u00e4ivitasime end t\u00e4ielikult Amazon AWS-is, kuna meil oli juba see platvormiga kogemus \u2014 meie enda sait oli seal majutatud. Meie jaoks oli oluline, et igas regioonis on Amazonis mitu k\u00e4ttesaadavustsooni \u2014 p\u00f5him\u00f5tteliselt (nende terminoloogias) mitu andmekeskust, mis on teineteisest enam-v\u00e4hem iseseisvad ja v\u00f5imaldavad meil rikka andmekeskuse tasemel: kui see peaks t\u00f6\u00f6lt v\u00e4lja kukkuma, replitseeritakse andmebaasid master-master, veebirakenduste serverid on reserveeritud ja staatika on paigutatud objektide salvestusesse s3. Koormus jaotatakse \u2014 sel hetkel Amazon\u2019i elb\u2019ga, kuid hiljem j\u00f5udsime oma load balancer\u2019ite juurde, kuna vajasime keerukamat loogikat. <\/p>\n

Saime just seda, mida soovisime...<\/h4>\n

\nK\u00f5ik p\u00f5hilised asjad, mida soovisime tagada \u2014 serverite, veebirakenduste ja andmebaaside talitlush\u00e4ired \u2014 t\u00f6\u00f6tasid h\u00e4sti. Lihtsaim stsenaarium: kui m\u00f5ni meie veebirakendus eba\u00f5nnestub, siis on k\u00f5ik lihtne \u2014 nad eemaldatakse tasakaalustamisest. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nV\u00e4lja surnud tasakaalustajad (tol hetkel oli see Amazoni ELB) m\u00e4rkisid ise endid ebatervislikeks, l\u00f5petades nendele koormuse jaotamise. Amazoni automaatne skaleerimine t\u00f6\u00f6tas: kui koormus suurenes, lisandus automaatse skaleerimise r\u00fchma uusi masinaid, koormus jaotati uutele masinatele - k\u00f5ik toimis h\u00e4sti. Meie tasakaalustajatel on loogika enam-v\u00e4hem sama: kui serveriga juhtub midagi, eemaldame sellele p\u00e4ringud, eemaldame need masinad, k\u00e4ivitame uued ja j\u00e4tkame t\u00f6\u00f6d. Skeem on aastate jooksul veidi muutunud, kuid see t\u00f6\u00f6tab endiselt: see on lihtne, arusaadav ja sellega ei ole mingeid keerukusi. <\/p>\n

Me t\u00f6\u00f6tame \u00fcle kogu maailma, klientide koormuse tipud on t\u00e4iesti erinevad ja, \u00f5igupoolest, peaksime olema v\u00f5imelised l\u00e4bi viima teenindust\u00f6id meie s\u00fcsteemi \u00fcksk\u00f5ik milliste komponentidega igal ajal \u2013 klientidele m\u00e4rkamatult. Seet\u00f5ttu on meil v\u00f5imalus h\u00e4\u00e4lestada andmebaas v\u00e4lja, jagades koormust teise andmekeskuse vahel. <\/p>\n

Kuidas see k\u00f5ik t\u00f6\u00f6tab? \u2014 Me suuname liikluse t\u00f6\u00f6tavale andmekeskusele \u2014 kui tegemist on andmekeskuse rikkega, siis t\u00e4ielikult, kui teeme plaanilisi t\u00f6id m\u00f5nes 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\u00e4ivitatakse need automaatselt. Kui t\u00f6\u00f6d on l\u00f5petatud, taastatakse replikeerimine ja suuname kogu koormuse tagasi. Kui peame teises andmekeskuses j\u00e4relevalve t\u00f6id tegema, n\u00e4iteks installima s\u00fcsteemiv\u00e4rskendusi v\u00f5i muutma seadeid teises andmebaasis, siis, p\u00f5him\u00f5tteliselt, kordame k\u00f5ik samu samme, lihtsalt vastupidises suunas. Ja kui see on rike, siis teeme k\u00f5ik lihtsalt: j\u00e4lgimiss\u00fcsteemis kasutame event-handler'ite mehhanismi. Kui meil t\u00f6\u00f6tab mitu kontrolli ja olek muutub kriitiliseks, k\u00e4ivitame selle handleri, t\u00f6\u00f6tleja, mis suudab t\u00e4ita teatud loogikat. Meil on iga andmebaasi jaoks kirjas, milline server on selle failover ja kuhu liiklus suunata, kui see pole saadaval. Meie s\u00fcsteemides, ajalooliselt, kasutame me nagios'e v\u00f5i midagi, mis on selle fork. P\u00f5him\u00f5tteliselt on taolised mehhanismid praktiliselt igas j\u00e4lgimiss\u00fcsteemis olemas, praegu me midagi keerulisemat ei kasuta, kuid v\u00f5ibolla kunagi kasutame. Praegu reageerib j\u00e4lgimine mitteeelarvataolekule ja tal on v\u00f5imalus midagi suunata.<\/p>\n

Kas oleme k\u00f5ik broneerinud?<\/h4>\n

\nMeil on palju kliente Ameerikas, rohkelt kliente Euroopas, samuti kliente, kes asuvad l\u00e4hemal Idas \u2014 Jaapanis, Singapuris ja nii edasi. Loomulikult on suur osa kliente Venemaal. See t\u00e4hendab, et meie tegevus ei piirdu vaid \u00fche piirkonnaga. Kasutajad soovivad kiiret vastust, on kohustus j\u00e4rgida erinevaid kohalikke seadusi, ning igas piirkonnas reservime kaks andmekeskust. Lisaks on olemas m\u00f5ned t\u00e4iendavad teenused, mille paigutamine \u00fchte piirkonda on mugavam \u2014 klientidele, kes seal t\u00f6\u00f6tavad. REST-handlers ja autoriseerimiserverid ei ole kliendi t\u00f6\u00f6 jaoks nii kriitilised, neid saab vahetada m\u00f5ningase vastuv\u00f5etava viivitusega, kuid me ei taha uuesti jalgratast leiutada, kuidas neid j\u00e4lgida ja mida nendega teha. Seet\u00f5ttu p\u00fc\u00fcame maksimaalselt kasutada juba olemasolevaid lahendusi, mitte arendada oma kompetentsi t\u00e4iendavate toodete osas. M\u00f5nes kohas kasutame lihtsalt DNS-i tasemel \u00fcmberl\u00fclitamist, m\u00e4\u00e4rates teenuse aktiivsuse samasuguse DNS-i abil. Amazonis on teenus Route 53, kuid see pole lihtsalt DNS, kuhu saab kirjeid sisse kirjutada ja k\u00f5ik \u2014 see on palju paindlikum ja mugavam. Selle abil on v\u00f5imalik \u00fcles ehitada geojaotatud teenuseid geolokatsioonidega, millega saate m\u00e4\u00e4rata, kust klient tuli, ja pakkuda talle vastavaid kirjeid \u2014 selle abil on v\u00f5imalik luua ka failover-architektuure. Samad tervisekontrollid seadistatakse Route 53-s, kus m\u00e4\u00e4rate endpoint-id, mida j\u00e4lgitakse, m\u00e4\u00e4rate m\u00f5\u00f5dikud, mille j\u00e4rgi m\u00e4\u00e4rata teenuse \u201eeluj\u00f5ud\u201c \u2014 TCP, HTTP, HTTPS; m\u00e4\u00e4rate kontrollide sageduse, et kindlaks teha, kas teenus on eluj\u00f5uline v\u00f5i mitte. Ja oma DNS-is registreerite, mis on primaarne, mis sekundaarne, kuhu \u00fcmber l\u00fclituda, kui Route 53-s sissel\u00fclitamistuvastus aktiveerub. K\u00f5ike seda saab teha ka teiste t\u00f6\u00f6riistade abil, kuid mugavus seisneb selles, et seadistate selle \u00fcks kord ja ei pea enam \u00fcldse m\u00f5tlema, kuidas meie kontrollid toimuvad, kuidas \u00fcmberl\u00fclitused k\u00e4ivad: k\u00f5ik t\u00f6\u00f6tab iseseisvalt.<\/p>\n

Esimene \"aga\"<\/b>: kuidas ja millega broneerida Route 53? \u00dcksk\u00f5ik, mis juhtub, kui midagi peaks juhtuma? Me oleme \u00f5nneks seda probleemi kunagi kogenud, aga siiski, mul on ees jutustus, miks me arvasime, et broneerimine on vajalik. Siin me valmistame ennast ette. Mitu korda p\u00e4evas teeme t\u00e4ieliku v\u00e4ljundi k\u00f5igist tsoonidest, mis meil Route 53-s on. Amazoni API v\u00f5imaldab neid mugavalt edastada JSON-vormingus ja meil on \u00fcles seatud mitu varundusserverit, kuhu me selle konverteerime, eksportime konfigureerimisfailidena ja omame sisuliselt varukoopia konfiguratsiooni. Kui midagi juhtub, saame selle kiiresti k\u00e4sitsi taastada, kaotamata DNS-i seadistuste andmeid.<\/p>\n

Teine \"aga\"<\/b>: mida ei ole sellel pildil veel reserveeritud? Just tasakaalustaja! Meie klientide jaotus piirkondade kaupa on v\u00e4ga lihtne. Meil on domeenid bitrix24.ru, bitrix24.com, .de \u2014 praegu on neid 13 erinevat, mis t\u00f6\u00f6tavad erinevates piirkondades. Oleme j\u00f5udnud j\u00e4rgmisele j\u00e4reldusele: igas piirkonnas on oma tasakaalustajad. See muudab piirkondade vahel jaotamise mugavamaks, s\u00f5ltuvalt sellest, kus on v\u00f5rgukoormuse tipud. Kui tekib rike \u00fche tasakaalustaja tasemel, l\u00fclitatakse see lihtsalt v\u00e4lja ja eemaldatakse DNS-ist. Kui tekib probleem tasakaalustajate grupiga, reserveeritakse need teistel platsidel ning vahetus nende vahel toimub sama route53 abil, kuna l\u00fchikese ttl t\u00f5ttu toimub vahetus maksimaalselt 2, 3, 5 minuti jooksul. <\/p>\n

Kolmas \"aga\"<\/b>: 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\u00e4itab, et asjad k\u00e4ivad teisiti. \u00dcldiselt kirjeldab Amazon S3-d kui p\u00f5hiteenust, kuna Amazon ise kasutab S3-d masinate piltide, konfiguratsioonide, AMI-piltide, snapshotide jne salvestamiseks... Ja kui S3 kukub, nagu see on juhtunud \u00fche korra 7 aasta jooksul, mil oleme bitrix24-t kasutanud, siis t\u00f5mbab see kaasa palju teisi probleeme \u2014 virtuaalsete masinate k\u00e4ivitamise h\u00e4ired, API rike ja nii edasi. <\/p>\n

Ja S3 v\u00f5ib kukkuda \u2014 see on kunagi juhtunud. Seet\u00f5ttu j\u00f5udsime j\u00e4rgmise skeemini: m\u00f5ned aastad tagasi ei olnud Venemaal t\u00f5siseltv\u00f5etavaid objekti avalikke ladustamisi ja m\u00f5tlesime, et teeme midagi oma\u2026 \u00d5nneks me seda ei alustanud, sest oleksime s\u00fcvenenud sellesse ekspertisu, mida meil ei olnud, ja kindlasti oleksime vea teinud. Praegu on s3 \u00fchilduvaid ladustamisi Mail.ru, Yandexil ja veel mitmel teenusepakkujal. L\u00f5puks j\u00f5udsime j\u00e4reldusele, et soovime, esiteks, varundamist ja teiseks, v\u00f5imalust t\u00f6\u00f6tada kohalike koopiatega. Konkreetselt Venemaa regioonis kasutame Mail.ru Hotboxi teenust, mis on API kaudu \u00fchilduv s3-ga. Me ei vajanud rakenduse sisese koodi osas t\u00f5siseid muudatusi ja tegime j\u00e4rgmise mehhanismi: s3-s on k\u00e4ivitajad, mis aktiveeruvad objektide loomise\/eealimise korral, Amazonil on selline teenus nagu Lambda \u2014 see on serverless koodi k\u00e4ivitamine, mis toimub just nendel korral, kui k\u00e4ivitavad teatud trigged.<\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nMeie oleme selle lihtsaks teinud: kui meil aktiveerub k\u00e4ivitus, t\u00e4idame koodi, mis kopeerib objekti Mail.ru salvestusse. Et alustada kohalike andmekoopia t\u00f6\u00f6tlemist, vajame veel tagasis\u00fcnkroniseerimist, et kliendid, kes asuvad Venemaa segmendis, saaksid t\u00f6\u00f6tada salvestusega, mis on neile l\u00e4hemal. Mail on peagi valmis k\u00e4ivitama k\u00e4ivitusi oma salvestuses \u2014 infrastruktuuri tasemel saab rakendada tagasik\u00f5nku, seni teeme seda meie enda koodil. Kui me n\u00e4eme, et klient on \u00fcles laadinud mingi faili, paneme meie kooditasemel s\u00fcndmuse j\u00e4rjekorda, t\u00f6\u00f6tleme seda ja teeme tagasikohandamise. Miks see on halb: kui meie toodet v\u00e4liste vahenditega tehakse, ei arvestata seda. Seet\u00f5ttu ootame l\u00f5puni, kuni salvestuses aktiveeritakse k\u00e4ivitused, et s\u00f5ltumata sellest, kust koodi t\u00e4idame, kopeeritakse objekt, mis meieni j\u00f5uab, teisele poole. <\/p>\n

Iga kliendi jaoks on meie kooditasemel m\u00e4\u00e4ratud kaks salvestusruumi: \u00fcks peamine ja teine varundamiseks. Kui k\u00f5ik on korras, t\u00f6\u00f6tame selle salvestusruumiga, mis on meile l\u00e4hemal: 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\u00f5ltumatult regioonide kaupa ja saame neid vajadusel vahetada. Praktikas ei ole me sellega veel kasutanud, kuid me oleme selle mehhanismi ette n\u00e4inud ja usume, et \u00fchel hetkel vajame seda vahetust. See on juba \u00fcks kord juhtunud. <\/p>\n

Oi, kas teie Amazon on kadunud...<\/h4>\n

\nSel aprillil m\u00f6\u00f6dub aastap\u00e4ev Telegrami blokeerimise algusest Venemaal. K\u00f5ige rohkem kannatasid selle t\u00f5ttu Amazon, mis oli k\u00f5ige kahjustatum teenusepakkuja. Kahjuks said rohkem kannatada ka maailma t\u00f6\u00f6tavad vene ettev\u00f5tted. <\/p>\n

Kui ettev\u00f5te on globaalne ja Venemaa on selle jaoks vaid v\u00e4ike segment, 3-5% \u2014 siis mingil moel v\u00f5ib neid ohverdada. <\/p>\n

Kui tegemist on puhtalt Venemaa ettev\u00f5ttega, siis olen kindel, et tuleb paikneda kohapeal \u2014 lihtsalt kasutajatele endile on see mugavam, riskid on v\u00e4iksemad. <\/p>\n

Ent kui tegemist on ettev\u00f5ttega, mis tegutseb globaalselt ja millel on umbes sama palju kliente Venemaalt kui mujal maailmas? Segmentide vahelise \u00fchenduse olemasolu on oluline ning nad peavad omavahel mingil moel kokku t\u00f6\u00f6tama. <\/p>\n

Juba 2018. aasta m\u00e4rtsi l\u00f5pus saatis Roskomnadzor suurimatele operaatoritele kirja, kus teatas, et nad kavatsevad blokeerida mitu miljonit Amazon'i IP-aadressi, et blokeerida\u2026 messengeri Zello. Ait\u00e4h nendele teenusepakkujatele \u2014 nad leaksid kirja edukalt ja tekkis arusaam, et Amazon'i \u00fchendus v\u00f5ib katkeeda. Oli reede, ja me paanitsesime ning l\u00e4ksime servers.ru kolleegide juurde, \u00f6eldes: \u201eS\u00f5brad, meil on vaja mitmeid servereid, mis ei asu Venemaal, mitte Amazon'is, vaid n\u00e4iteks kuskil Amsterdamis\u201c, et oleks v\u00e4hemalt mingisugune v\u00f5imalus seal oma\u2026 vpn<\/a> ja proxy m\u00f5nedele endpoint'idele, millele me kuidagi ei saa m\u00f5ju avaldada, n\u00e4iteks s3 endpoint'id \u2014 ei saa p\u00fc\u00fcda t\u00f5sta uut teenust ja saada teist ip, peame ikka sinna kohale j\u00f5udma. M\u00f5ne p\u00e4evaga h\u00e4\u00e4lestasime need serverid ja \u00fcldiselt olime blokaatide alguseks valmis. Uvitav, et RKN, n\u00e4hes segadust ja t\u00f5stetud paanikat, \u00fctles: \"Ei, me hetkel ei blokeeri midagi.\" (Kuni hetkeni, mil nad hakkasid Telegrami blokeerima.) H\u00e4\u00e4lestades ringk\u00e4igu v\u00f5imalusi ja aru saades, et blokaat ei ole sisse viidud, ei hakanud me siiski k\u00f5ike seda seadistama. Nii, igaks juhuks. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nJa, ja 2019. aastal elame me t\u00f5epoolest blokeeringute tingimustes. Eile \u00f6\u00f6sel vaatasin: umbes miljon IP-aadressi j\u00e4tkab blokeerimist. T\u00f5si, Amazoni on peaaegu t\u00e4ielikult blokeerimisest vabastatud, tipphetkel oli see 20 miljoni aadressi juurde\u2026 \u00dches\u00f5naga, reaalsus on selline, et sideteenuseid, head sideteenuseid \u2014 ei pruugi olla. \u00dcht\u00e4kki. Seda v\u00f5ib mitte olla tehniliste p\u00f5hjuste t\u00f5ttu \u2014 tulekahjud, ekskavaatorid, sellised asjad. V\u00f5i nagu me oleme n\u00e4inud, mitte t\u00e4iesti tehnilistel p\u00f5hjustel. Seega, keegi suur ja v\u00f5imas, kellel on enda AS-id, v\u00f5ib t\u00f5en\u00e4oliselt seda muude meetoditega juhtida, \u2014 direct connect ja muud asjad juba l2 tasemel. Aga lihtsas variandis, nagu meie v\u00f5i veel v\u00e4iksemad, on m\u00f5istlik igaks juhuks omada varukoopiaid serverite tasemel, mis on kuskil mujal \u00fcles seatud, eelnevalt seadistatud VPN, proxy, v\u00f5imalusega kiiresti nendele konfigureerimisega \u00fcle l\u00fclitada 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\u00e4rk-j\u00e4rgult lahenes k\u00f5ik.<\/p>\n

Aga kuidas reserveerida\u2026 tervet teenusepakkujat?<\/h4>\n

\nPraegu puudub meil stsenaarium, mis k\u00e4sitleks kogu Amazoni t\u00f5rget. Meil on sarnane stsenaarium Venemaa jaoks. Venemaal olime \u00fches teenuseosutajas, kelle juures valisime, et oleksid mitmed platvormid. Ja aasta tagasi seisime silmitsi probleemiga: isegi kui tegemist on kahe andmekeskusega, v\u00f5ivad teenuseosutaja v\u00f5rgu konfiguratsiooni tasemel esineda probleemid, mis m\u00f5jutavad ikkagi m\u00f5lemat andmekeskust. Seega v\u00f5ime saada ligip\u00e4\u00e4smatuks m\u00f5lemal platvormil. Loomulikult juhtuski nii. L\u00f5puks \u00fcle vaatasime meie arhitektuuri seestpoolt. See ei muutunud kuigi palju, kuid Venemaa jaoks on meil n\u00fc\u00fcd kaks platvormi, mis ei asu \u00fches teenuseosutajas, vaid kahes erinevas. Kui \u00fches midagi t\u00f5rkub, saame \u00fcle minna teisele.<\/p>\n

H\u00fcpotetiseerides kaalume Amazonile teise teenusepakkuja tasemel broneerimist; v\u00f5ib-olla Google, v\u00f5ib-olla veel keegi... Kuid seni oleme praktikas m\u00e4rganud, et kui Amazonil tekivad rikkeid \u00fches availability zone'is, siis kogu piirkonna rikkeid esineb suhteliselt harva. Seet\u00f5ttu on meil teoreetiline arusaam, et v\u00f5ime broneerida \"Amazon \u2014 mitte Amazon\", kuid praktikas seda seni ei ole. <\/p>\n

M\u00f5ned s\u00f5nad automatiseerimise kohta<\/h4>\n

\nKas 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 \u00fcldse kindlad. Seej\u00e4rel me teame natuke ja muutume \u00fclihinnatud \u2013 see on nn \"rumaluse tipptase\", mida illustreerib h\u00e4sti pilt \"rumalus ja julgustunne\". Edasi, me oleme juba natuke \u00f5ppinud ja valmis lahingusse minema. Siis astume m\u00f5ne t\u00f5sise takistuse otsa, satume meeleheite orgu, kus tundub, et me teame midagi, kuid tegelikult ei tea me paljusid asju. Seej\u00e4rel, kogemuste kogumisega, muutume taas kindlamaks.<\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nMeie l\u00e4henemine erinevatele l\u00fclitustele automaatselt teatud t\u00f5rgetele \u2014 seda on v\u00e4ga h\u00e4sti kirjeldatud selle graafiku abil. Alustasime \u2014 me ei osanud midagi, praktiliselt k\u00f5ik t\u00f6\u00f6d tehti k\u00e4sitsi. Siis m\u00f5istsime, et k\u00f5iki asju v\u00f5ib automatiseerida ja nagu, magada rahulikult. Ja \u00e4kki satume mega-\u00e4ppesse: meil tekib valeh\u00e4ire ja l\u00fclitame liiklust siia-sinna, kui tegelikult poleks seda pidanud tegema. Seega, replikatsioon katke v\u00f5i midagi muud \u2014 see ongi meeleheite oru hetk. Ja edasi j\u00f5uame arusaamisele, et k\u00f5igesse tuleb suhtuda arukalt. Ehk siis on m\u00f5istlik tugineda automaatikatele, arvestades valeh\u00e4ire v\u00f5imalusega. Kuid! Kui tagaj\u00e4rjed v\u00f5ivad olla katastroofilised, siis on parem lasta sel enda \u00fcle dürgnabil, vahetuses olevatel inseneridel, kes veenduvad, kontrollivad, et t\u00f5epoolest on h\u00e4ire, ja vajalikud toimingud teostatakse k\u00e4sitsi...<\/p>\n

Kokkuv\u00f5te<\/h4>\n

\nSeitsme aastaga oleme l\u00e4inud olukorrast, kus k\u00f5ik kukkus kokku ja toimus paanika, arusaamisele, et probleeme ei ole, on ainult \u00fclesanded, mida tuleb lahendada \u2014 ja see on v\u00f5imalik. Kui loote teenust, vaadake sellele \u00fclaltpoolt, hinnake k\u00f5iki riske, mis v\u00f5ivad tekkida. Kui n\u00e4ete neid kohe \u2014 kavandage ette reserveerimine ja v\u00f5imalus rajada t\u00f5rketaluv infrastruktuur, sest iga punkt, mis v\u00f5ib eba\u00f5nnestuda ja teenuse t\u00f6\u00f6katkestuse p\u00f5hjustada, teeb seda kindlasti. Ja isegi kui teil on tunne, et m\u00f5ni infrastruktuuri element ei tohi eba\u00f5nnestuda \u2014 nagu n\u00e4iteks s3, pidage ikkagi meeles, et need v\u00f5ivad. Ja v\u00e4hemalt teoreetiliselt olge valmis m\u00f5tlema, mida te nendega teete, kui midagi juhtub. Olge valmis riskide maandamise plaaniga. Kui kaalute, kas teha k\u00f5ik automaatikaga v\u00f5i k\u00e4sitsi \u2014 hinnake riske: mis juhtub, kui automaatika hakkab k\u00f5ike \u00fcmber l\u00fclitama \u2014 kas see ei too kaasa halvenenud olukorra v\u00f5rreldes avariiga? V\u00f5ib-olla on m\u00f5nes kohas m\u00f5istlik leida tasakaal automaatika kasutamise ja valves oleva inseneri reageerimise vahel, kes hindab tegelikku olukorda ja m\u00f5istab, kas on vaja midagi kohe l\u00fclitada v\u00f5i \"jah, aga mitte praegu.\"<\/p>\n

M\u00f5istlik kompromiss perfektsionismi ja tegelike ressursside, aja ning rahaga, mida saate oma l\u00f5ppprojekti jaoks kasutada.<\/p>\n

See tekst on t\u00e4iendatud ja laiendatud versioon Aleksandr Demidovi ettekandest konverentsil. S\u00fcsteemi t\u00f6\u00f6aeg, p\u00e4ev 4<\/a><\/noindex>.<\/i>
\n
Allikas: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35092","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u201eBitrix24\u201d: \u201eKiirelt \u00fcles t\u00f5stetud ei loetu kukkunuks\u201d | ProHoster","description":"Praegu ei ole teenusel \u201eBitrix24\u201d sadu gigabite liiklust ega tohutut serveriparki (kuigi neid on kindlasti mitmeid). Kuid paljudele klientidele on see nende ettev\u00f5tte p\u00f5hivahend, t\u00f5eline business-critical rakendus. Seet\u00f5ttu ei tohi see kunagi kukkuda. Ja mis siis, kui kukkumine ikkagi toimub, aga teenus t\u00f5useb nii kiiresti, et keegi ei m\u00e4rkagi.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb: \u00ab\u0411\u044b\u0441\u0442\u0440\u043e \u043f\u043e\u0434\u043d\u044f\u0442\u043e\u0435 \u043d\u0435 \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u0443\u043f\u0430\u0432\u0448\u0438\u043c\u00bb | ProHoster","og:description":"\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:02:18+00:00","article:modified_time":"2019-10-31T19:02:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35092","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-04 14:51:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:10:27","updated":"2026-02-04 14:51:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35092","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=35092"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35092\/revisions"}],"predecessor-version":[{"id":156668,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35092\/revisions\/156668"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/26389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=35092"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=35092"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=35092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}