Å odien pakalpojumam Bitrix24 nav simtiem gigabitu trafika, kÄ arÄ« tam nav milzÄ«ga serveru parka (lai gan, protams, ir diezgan daudz esoÅ”o). TaÄu daudziem klientiem tas ir galvenais rÄ«ks darbam uzÅÄmumÄ, tÄ ir reÄla biznesam svarÄ«ga aplikÄcija. TÄpÄc krist nav iespÄjams. KÄ bÅ«tu, ja avÄrija tomÄr notiktu, bet pakalpojums āatkoptosā tik Ätri, ka neviens neko nepamanÄ«tu? Un kÄ ir iespÄjams Ä«stenot failover, nezaudÄjot darba kvalitÄti un klientu skaitu? Aleksandrs Demidovs, Bitrix24 mÄkoÅpakalpojumu direktors, mÅ«su emuÄram runÄja par rezervÄÅ”anas sistÄmas attÄ«stÄ«bu 7 produkta pastÄvÄÅ”anas gadu laikÄ.
āMÄs Bitrix24 izlaidÄm kÄ SaaS pirms 7 gadiem. GalvenÄs grÅ«tÄ«bas, iespÄjams, bija Å”Ädas: pirms tas tika publiski izlaists kÄ SaaS, Å”is produkts vienkÄrÅ”i pastÄvÄja iesaiÅota risinÄjuma formÄtÄ. Klienti to iegÄdÄjÄs no mums, mitinÄja savos serveros, izveidoja korporatÄ«vo portÄlu - vispÄrÄjs risinÄjums darbinieku saziÅai, failu glabÄÅ”anai, uzdevumu pÄrvaldÄ«bai, CRM, tas arÄ« viss. Un lÄ«dz 2012. gadam mÄs nolÄmÄm, ka vÄlamies to palaist kÄ SaaS, administrÄjot to paÅ”i, nodroÅ”inot kļūdu toleranci un uzticamÄ«bu. Pieredzi ieguvÄm pa ceļam, jo āālÄ«dz tam mums tÄs vienkÄrÅ”i nebija ā bijÄm tikai programmatÅ«ras ražotÄji, nevis pakalpojumu sniedzÄji.
UzsÄkot pakalpojumu, mÄs sapratÄm, ka vissvarÄ«gÄkais ir nodroÅ”inÄt kļūdu toleranci, uzticamÄ«bu un pastÄvÄ«gu pakalpojuma pieejamÄ«bu, jo, ja jums ir vienkÄrÅ”a parasta vietne, piemÄram, veikals, un tas jums uzkrÄ«t un tur sÄž. stundu, tikai jÅ«s cieÅ”at, jÅ«s zaudÄjat pasÅ«tÄ«jumus, jÅ«s zaudÄjat klientus, bet paÅ”am klientam tas viÅam nav Ä«paÅ”i svarÄ«gi. ViÅÅ”, protams, bija sarÅ«gtinÄts, bet aizgÄja un nopirka to citÄ vietnÄ. Un, ja Ŕī ir aplikÄcija, uz kuras ir piesaistÄ«ts viss darbs uzÅÄmuma iekÅ”ienÄ, komunikÄcija, lÄmumi, tad svarÄ«gÄkais ir iegÅ«t lietotÄju uzticÄ«bu, proti, nepievilt un nepakrist. Jo viss darbs var apstÄties, ja kaut kas iekÅ”Ä nedarbojas.
Bitrix.24 kÄ SaaS
Pirmo prototipu samontÄjÄm gadu pirms publiskÄs palaiÅ”anas, 2011. gadÄ. MÄs to samontÄjÄm apmÄram nedÄļas laikÄ, apskatÄ«jÄm, pagriezÄm - tas pat strÄdÄja. Tas ir, jÅ«s varÄtu ieiet formÄ, ievadÄ«t tur portÄla nosaukumu, tiktu atvÄrts jauns portÄls un izveidota lietotÄju bÄze. MÄs to apskatÄ«jÄm, principÄ novÄrtÄjÄm produktu, nodevÄm metÄllūžÅos un turpinÄjÄm to pilnveidot veselu gadu. TÄ kÄ mums bija liels uzdevums: mÄs negribÄjÄm izveidot divas dažÄdas kodu bÄzes, mÄs negribÄjÄm atbalstÄ«t atseviŔķu iepakotu produktu, atseviŔķus mÄkoÅa risinÄjumus - mÄs vÄlÄjÄmies to visu izdarÄ«t vienÄ kodÄ.
Tipiska tÄ«mekļa aplikÄcija tajÄ laikÄ bija viens serveris, uz kura darbojas kaut kÄds PHP kods, mysql datubÄze, tiek augÅ”upielÄdÄti faili, dokumenti, attÄli tiek ievietoti augÅ”upielÄdes mapÄ - labi, tas viss darbojas. DiemžÄl, izmantojot Å”o, nav iespÄjams palaist kritiski stabilu tÄ«mekļa pakalpojumu. Tur izplatÄ«tÄ keÅ”atmiÅa netiek atbalstÄ«ta, datu bÄzes replikÄcija netiek atbalstÄ«ta.
MÄs formulÄjÄm prasÄ«bas: tÄ ir iespÄja atrasties dažÄdÄs vietÄs, atbalstÄ«t replikÄciju un ideÄlÄ gadÄ«jumÄ atrasties dažÄdos Ä£eogrÄfiski sadalÄ«tos datu centros. Atdaliet produkta loÄ£iku un faktiski datu glabÄÅ”anu. SpÄt dinamiski mÄrogot atbilstoÅ”i slodzei un vispÄr izturÄt statiku. No Å”iem apsvÄrumiem faktiski radÄs prasÄ«bas produktam, kuras mÄs gada laikÄ precizÄjÄm. Å ajÄ laikÄ platformÄ, kas izrÄdÄ«jÄs vienota - kastÄ«tiem risinÄjumiem, mÅ«su paÅ”u servisam - veicÄm atbalstu tÄm lietÄm, kas mums bija vajadzÄ«gas. Mysql replikÄcijas atbalsts paÅ”a produkta lÄ«menÄ«: tas ir, izstrÄdÄtÄjs, kurÅ” raksta kodu, nedomÄ par to, kÄ tiks izplatÄ«ti viÅa pieprasÄ«jumi, viÅÅ” izmanto mÅ«su api, un mÄs zinÄm, kÄ pareizi izplatÄ«t rakstÄ«Å”anas un lasÄ«Å”anas pieprasÄ«jumus starp meistariem. un vergi.
MÄs esam nodroÅ”inÄjuÅ”i atbalstu produktu lÄ«menÄ« dažÄdÄm mÄkoÅa objektu krÄtuvÄm: Google krÄtuvei, amazon s3, kÄ arÄ« atbalstam atvÄrtÄ steka swift. TÄpÄc tas bija Ärti gan mums kÄ pakalpojumam, gan izstrÄdÄtÄjiem, kuri strÄdÄ ar iepakotu risinÄjumu: ja viÅi vienkÄrÅ”i izmanto mÅ«su API darbam, viÅi nedomÄ par to, kur fails galu galÄ tiks saglabÄts, lokÄli failu sistÄmÄ vai objektu failu krÄtuvÄ.
RezultÄtÄ uzreiz nolÄmÄm, ka rezervÄsim visa datu centra lÄ«menÄ«. 2012. gadÄ mÄs pilnÄ«bÄ izlaidÄm pakalpojumu Amazon AWS, jo mums jau bija pieredze ar Å”o platformu ā tur tika mitinÄta mÅ«su paÅ”u vietne. MÅ«s piesaistÄ«ja fakts, ka katrÄ reÄ£ionÄ Amazon ir vairÄkas pieejamÄ«bas zonas ā patiesÄ«bÄ (to terminoloÄ£ijÄ) vairÄki datu centri, kas ir vairÄk vai mazÄk neatkarÄ«gi viens no otra un ļauj rezervÄt vesela datu centra lÄ«menÄ«: ja tas pÄkÅ”Åi neizdodas, datu bÄzes tiek replicÄtas par galveno-masters, tÄ«mekļa lietojumprogrammu serveri tiek dublÄti un statiskie dati tiek pÄrvietoti uz s3 objektu krÄtuvi. Slodze ir sabalansÄta - toreiz pa Amazon elb, bet nedaudz vÄlÄk tikÄm pie saviem slodzes balansÄtÄjiem, jo āāvajadzÄja sarežģītÄku loÄ£iku.
Tas, ko viÅi gribÄja, ir tas, ko viÅi saÅÄma...
Visas pamata lietas, ko vÄlÄjÄmies nodroÅ”inÄt ā paÅ”u serveru kļūdu tolerance, tÄ«mekļa lietojumprogrammas, datu bÄzes ā viss darbojÄs labi. VienkÄrÅ”Äkais scenÄrijs: ja kÄda no mÅ«su tÄ«mekļa lietojumprogrammÄm neizdodas, tad viss ir vienkÄrÅ”i - tÄs tiek izslÄgtas no balansÄÅ”anas.
BalansÄtÄjs (tolaik tas bija Amazon elbs) nederÄ«gÄs maŔīnas atzÄ«mÄja un izslÄdza uz tÄm slodzes sadali. Amazon automÄtiskÄ mÄrogoÅ”ana darbojÄs: kad slodze pieauga, automÄtiskÄs mÄrogoÅ”anas grupai tika pievienotas jaunas iekÄrtas, slodze tika sadalÄ«ta jaunÄm maŔīnÄm - viss bija kÄrtÄ«bÄ. Ar mÅ«su balansieriem loÄ£ika ir aptuveni tÄda pati: ja kaut kas notiek ar lietojumprogrammu serveri, mÄs noÅemam no tÄ pieprasÄ«jumus, izmetam Ŕīs maŔīnas, iedarbinÄm jaunas un turpinÄm strÄdÄt. ShÄma gadu gaitÄ ir nedaudz mainÄ«jusies, bet turpina darboties: tÄ ir vienkÄrÅ”a, saprotama, un ar to nav nekÄdu grÅ«tÄ«bu.
MÄs strÄdÄjam visÄ pasaulÄ, klientu slodzes maksimumi ir pilnÄ«gi atŔķirÄ«gi, un draudzÄ«gÄ veidÄ mums vajadzÄtu bÅ«t iespÄjai jebkurÄ laikÄ - klientiem nepamanÄ«ti - veikt noteiktus servisa darbus jebkurai mÅ«su sistÄmas sastÄvdaļai. LÄ«dz ar to mums ir iespÄja atslÄgt datu bÄzi no darbÄ«bas, pÄrdalot slodzi uz otru datu centru.
KÄ tas viss darbojas? ā PÄrslÄdzam trafiku uz strÄdÄjoÅ”u datu centru - ja datu centrÄ notiek avÄrija, tad pilnÄ«bÄ, ja tas ir mÅ«su plÄnotais darbs ar vienu datu bÄzi, tad daļu trafika, kas apkalpo Å”os klientus, pÄrslÄdzam uz otru datu centru, apturot tÄ replikÄcija. Ja tÄ«mekļa lietojumprogrammÄm ir nepiecieÅ”amas jaunas maŔīnas, jo ir palielinÄjusies otrÄ datu centra slodze, tÄs tiks startÄtas automÄtiski. MÄs pabeidzam darbu, tiek atjaunota replikÄcija, un mÄs atgriežam visu slodzi. Ja mums ir jÄatspoguļo kÄds darbs otrajÄ DC, piemÄram, jÄinstalÄ sistÄmas atjauninÄjumi vai jÄmaina iestatÄ«jumi otrajÄ datu bÄzÄ, tad kopumÄ mÄs atkÄrtojam to paÅ”u, tikai otrÄ virzienÄ. Un, ja tas ir nelaimes gadÄ«jums, tad mÄs visu darÄm triviÄli: mÄs izmantojam notikumu apstrÄdÄtÄju mehÄnismu uzraudzÄ«bas sistÄmÄ. Ja tiek aktivizÄtas vairÄkas pÄrbaudes un statuss kļūst kritisks, mÄs palaižam Å”o apdarinÄtÄju, kas var veikt Å”o vai citu loÄ£iku. Katrai datu bÄzei mÄs norÄdÄm, kurÅ” serveris ir tÄs kļūmjpÄrlÄce un kur ir jÄpÄrslÄdz trafiks, ja tÄ nav pieejama. VÄsturiski mÄs vienÄ vai otrÄ veidÄ izmantojam nagios vai dažas tÄs dakÅ”iÅas. PrincipÄ lÄ«dzÄ«gi mehÄnismi pastÄv gandrÄ«z jebkurÄ monitoringa sistÄmÄ, neko sarežģītÄku pagaidÄm neizmantojam, bet varbÅ«t kÄdreiz izmantosim. Tagad uzraudzÄ«bu aktivizÄ nepieejamÄ«ba, un tai ir iespÄja kaut ko pÄrslÄgt.
Vai esam visu rezervÄjuÅ”i?
Mums ir daudz klientu no ASV, daudzi klienti no Eiropas, daudzi klienti, kas atrodas tuvÄk Austrumiem ā JapÄnai, SingapÅ«rai un tÄ tÄlÄk. Protams, milzÄ«ga klientu daļa ir KrievijÄ. Tas ir, darbs nav vienÄ reÄ£ionÄ. LietotÄji vÄlas Ätru atbildi, ir prasÄ«bas ievÄrot dažÄdus vietÄjos likumus, un katrÄ reÄ£ionÄ mÄs rezervÄjam divus datu centrus, kÄ arÄ« ir daži papildu pakalpojumi, kurus atkal ir Ärti izvietot viena reÄ£iona ietvaros - klientiem, kuri atrodas Å”is reÄ£ions strÄdÄ. REST apstrÄdÄtÄji, autorizÄcijas serveri, tie ir mazÄk kritiski klienta darbÄ«bai kopumÄ, jÅ«s varat pÄrslÄgties caur tiem ar nelielu pieÅemamu kavÄÅ”anos, bet jÅ«s nevÄlaties izgudrot riteni, kÄ tos uzraudzÄ«t un ko darÄ«t ar viÅiem. TÄpÄc mÄs cenÅ”amies maksimÄli izmantot esoÅ”os risinÄjumus, nevis attÄ«stÄ«t kaut kÄdu kompetenci papildu produktos. Un kaut kur mÄs triviÄli izmantojam pÄrslÄgÅ”anu DNS lÄ«menÄ«, un pakalpojuma dzÄ«vÄ«gumu mÄs nosakÄm ar to paÅ”u DNS. Amazon ir pakalpojums Route 53, taÄu tas nav tikai DNS, kurÄ varat veikt ierakstus, un viss ā tas ir daudz elastÄ«gÄks un ÄrtÄks. Izmantojot to, jÅ«s varat izveidot Ä£eogrÄfiski izplatÄ«tus pakalpojumus ar Ä£eogrÄfiskajÄm atraÅ”anÄs vietÄm, kad to izmantojat, lai noteiktu, no kurienes klients ir nÄcis, un sniegtu viÅam noteiktus ierakstus - ar tÄ palÄ«dzÄ«bu jÅ«s varat izveidot kļūmjpÄrlÄces arhitektÅ«ras. TÄdas paÅ”as veselÄ«bas pÄrbaudes ir konfigurÄtas paÅ”Ä marÅ”rutÄ 53, jÅ«s iestatÄt uzraugÄmos galapunktus, iestatÄt metriku, iestatÄt, ar kÄdiem protokoliem nosaka pakalpojuma ādzÄ«vÄ«buā - tcp, http, https; iestatiet pÄrbaužu biežumu, kas nosaka, vai pakalpojums ir vai nav. Un paÅ”Ä DNS jÅ«s norÄdÄt, kas bÅ«s primÄrais, kas sekundÄrais, kur pÄrslÄgties, ja tiek aktivizÄta veselÄ«bas pÄrbaude marÅ”rutÄ 53. To visu var izdarÄ«t ar dažiem citiem rÄ«kiem, bet kÄpÄc tas ir Ärti - mÄs to iestatÄm vienreiz augÅ”Ä un tad vispÄr nedomÄ, kÄ mÄs veicam pÄrbaudes, kÄ pÄrslÄdzamies: viss darbojas pats no sevis.
Pirmais "bet": kÄ un ar ko rezervÄt paÅ”u 53. marÅ”rutu? Kas zina, ja nu ar viÅu kaut kas notiks? Par laimi, mÄs nekad neuzkÄpÄm uz Ŕī grÄbekļa, bet man atkal bÅ«s stÄsts par to, kÄpÄc mums likÄs, ka mums tomÄr ir jÄveic rezervÄcija. Å eit mÄs iepriekÅ” izlikÄm sev salmiÅus. VairÄkas reizes dienÄ veicam visu zonu pilnÄ«gu izkrauÅ”anu, kas mums ir 53. marÅ”rutÄ. Amazon API ļauj Ärti nosÅ«tÄ«t tos JSON formÄtÄ, un mums ir vairÄki rezerves serveri, kur mÄs to konvertÄjam, augÅ”upielÄdÄjam konfigurÄciju veidÄ un, rupji runÄjot, ir rezerves konfigurÄcija. Ja kaut kas notiek, mÄs varam to Ätri izvietot manuÄli, nezaudÄjot DNS iestatÄ«jumu datus.
Otrais "bet": Kas Å”ajÄ attÄlÄ vÄl nav rezervÄts? Pats balansÄtÄjs! MÅ«su klientu sadalÄ«jums pa reÄ£ioniem ir ļoti vienkÄrÅ”s. Mums ir domÄni bitrix24.ru, bitrix24.com, .de - tagad ir 13 dažÄdi, kas darbojas dažÄdÄs zonÄs. NonÄcÄm pie tÄ: katram reÄ£ionam ir savi balansÄtÄji. Tas padara ÄrtÄku sadali pa reÄ£ioniem atkarÄ«bÄ no tÄ, kur ir tÄ«kla maksimÄlÄ slodze. Ja tÄ ir kļūme viena balansÄtÄja lÄ«menÄ«, tad tas vienkÄrÅ”i tiek izÅemts no ekspluatÄcijas un izÅemts no dns. Ja ir kÄdas problÄmas ar balansÄtÄju grupu, tad tie tiek dublÄti citÄs vietnÄs, un pÄrslÄgÅ”anÄs starp tÄm notiek, izmantojot to paÅ”u marÅ”rutu53, jo Ä«sÄ TTL dÄļ pÄrslÄgÅ”anÄs notiek maksimÄli 2, 3, 5 minÅ«Å”u laikÄ. .
TreÅ”ais "bet": Kas vÄl nav rezervÄts? S3, pareizi. Kad ievietojÄm failus, ko glabÄjam lietotÄjiem s3, mÄs patiesi ticÄjÄm, ka tas ir bruÅu caurdurÅ”anas veids, un tur nekas nav jÄrezervÄ. TaÄu vÄsture rÄda, ka lietas notiek savÄdÄk. KopumÄ Amazon raksturo S3 kÄ fundamentÄlu pakalpojumu, jo Amazon pati izmanto S3, lai saglabÄtu maŔīnu attÄlus, konfigurÄcijas, AMI attÄlus, momentuzÅÄmumus... Un, ja s3 avarÄ, kÄ tas notika vienu reizi pa Å”iem 7 gadiem, tik ilgi, cik mÄs esam lietojuÅ”i bitrix24, tas seko tam kÄ ventilators. Ir daudz lietu, kas rodas ā nespÄja startÄt virtuÄlÄs maŔīnas, api kļūme utt.
Un S3 var nokrist - tas notika vienreiz. LÄ«dz ar to nonÄcÄm pie Å”Ädas shÄmas: pirms dažiem gadiem KrievijÄ nebija nopietnu sabiedrisko objektu krÄtuves, un mÄs apsvÄrÄm variantu kaut ko darÄ«t paÅ”i... Par laimi, nesÄkÄm to darÄ«t, jo mÄs to darÄ«tu. esam iedziļinÄjuÅ”ies zinÄÅ”anÄm, kuru mums nav, un, iespÄjams, sajauktos. Tagad Mail.ru ir ar s3 saderÄ«ga krÄtuve, tÄ ir pieejama Yandex un daudziem citiem pakalpojumu sniedzÄjiem. Galu galÄ mÄs nonÄcÄm pie domas, ka vÄlamies, pirmkÄrt, iegÅ«t dublÄjumu un, otrkÄrt, iespÄju strÄdÄt ar vietÄjÄm kopijÄm. KonkrÄti Krievijas reÄ£ionÄ mÄs izmantojam pakalpojumu Mail.ru Hotbox, kas ir API saderÄ«gs ar s3. Mums nebija vajadzÄ«gas nekÄdas lielas lietojumprogrammas koda modifikÄcijas, un mÄs izveidojÄm Å”Ädu mehÄnismu: s3 ir trigeri, kas aktivizÄ objektu izveidi/dzÄÅ”anu, Amazon piedÄvÄ pakalpojumu ar nosaukumu Lambda ā Ŕī ir koda palaiÅ”ana bez servera. kas tiks izpildÄ«ts tieÅ”i tad, kad tiks aktivizÄti noteikti aktivizÄtÄji.
MÄs to izdarÄ«jÄm ļoti vienkÄrÅ”i: ja mÅ«su aktivizÄtÄjs iedarbojas, mÄs izpildÄm kodu, kas kopÄs objektu uz Mail.ru krÄtuvi. Lai pilnÄ«bÄ uzsÄktu darbu ar vietÄjÄm datu kopijÄm, mums ir nepiecieÅ”ama arÄ« reversÄ sinhronizÄcija, lai klienti, kas ir Krievijas segmentÄ, varÄtu strÄdÄt ar viÅiem tuvÄku krÄtuvi. Pasts gatavojas pabeigt trigerus savÄ krÄtuvÄ - bÅ«s iespÄjams veikt reverso sinhronizÄciju infrastruktÅ«ras lÄ«menÄ«, bet pagaidÄm mÄs to darÄm sava koda lÄ«menÄ«. Ja redzam, ka klients ir ievietojis failu, tad koda lÄ«menÄ« notikumu ievietojam rindÄ, apstrÄdÄjam un veicam reverso replikÄciju. KÄpÄc tas ir slikti: ja mÄs kÄdu darbu ar saviem objektiem veicam Ärpus mÅ«su produkta, tas ir, ar kÄdiem ÄrÄjiem lÄ«dzekļiem, mÄs to neÅemsim vÄrÄ. TÄpÄc mÄs gaidÄm lÄ«dz beigÄm, kad krÄtuves lÄ«menÄ« parÄdÄs trigeri, lai neatkarÄ«gi no tÄ, no kurienes mÄs izpildÄm kodu, objekts, kas nonÄca pie mums, tiek kopÄts otrÄ virzienÄ.
Koda lÄ«menÄ« mÄs katram klientam reÄ£istrÄjam abas krÄtuves: viena tiek uzskatÄ«ta par galveno, otra tiek uzskatÄ«ta par rezerves. Ja viss ir kÄrtÄ«bÄ, mÄs strÄdÄjam ar krÄtuvi, kas mums ir tuvÄka: tas ir, mÅ«su klienti, kas atrodas Amazon, viÅi strÄdÄ ar S3, un tie, kas strÄdÄ KrievijÄ, viÅi strÄdÄ ar Hotbox. Ja karodziÅÅ” tiek aktivizÄts, ir jÄpievieno kļūmjpÄrlÄce, un mÄs pÄrslÄdzam klientus uz citu krÄtuvi. MÄs varam atzÄ«mÄt Å”o izvÄles rÅ«tiÅu neatkarÄ«gi pÄc reÄ£iona un pÄrslÄgt tos uz priekÅ”u un atpakaļ. MÄs to vÄl neesam izmantojuÅ”i praksÄ, bet esam paredzÄjuÅ”i Å”o mehÄnismu un domÄjam, ka kÄdreiz mums bÅ«s vajadzÄ«gs un noderÄs tieÅ”i Å”is slÄdzis. Tas jau vienreiz ir noticis.
Ak, un Amazon aizbÄga...
Å Ä« gada aprÄ«lÄ« tiek atzÄ«mÄta gadadiena kopÅ” Telegram bloÄ·ÄÅ”anas sÄkuma KrievijÄ. VisvairÄk ietekmÄtais pakalpojumu sniedzÄjs, uz kuru tas attiecas, ir Amazon. Un diemžÄl vairÄk cieta Krievijas uzÅÄmumi, kas strÄdÄja visai pasaulei.
Ja uzÅÄmums ir globÄls un Krievija tam ir ļoti mazs segments, 3-5% - nu, tÄ vai tÄ, jÅ«s varat tos upurÄt.
Ja tas ir tÄ«ri Krievijas uzÅÄmums - esmu pÄrliecinÄts, ka tam ir jÄatrodas lokÄli -, labi, tas vienkÄrÅ”i bÅ«s Ärti paÅ”iem lietotÄjiem, Ärti un bÅ«s mazÄk risku.
Ko darÄ«t, ja tas ir uzÅÄmums, kas darbojas globÄli un kuram ir aptuveni vienÄds klientu skaits no Krievijas un kaut kur citur pasaulÄ? Segmentu savienojamÄ«ba ir svarÄ«ga, un tiem vienÄ vai otrÄ veidÄ ir jÄdarbojas vienam ar otru.
2018. gada marta beigÄs Roskomnadzor nosÅ«tÄ«ja vÄstuli lielÄkajiem operatoriem, ka plÄno bloÄ·Ät vairÄkus miljonus Amazon IP, lai bloÄ·Ätu... Zello messenger. Pateicoties Å”iem paÅ”iem pakalpojumu sniedzÄjiem - viÅi veiksmÄ«gi nopludinÄja vÄstuli visiem, un radÄs izpratne, ka saikne ar Amazon var izjukt. Bija piektdiena, mÄs panikÄ skrÄjÄm pie kolÄÄ£iem no servers.ru, sakot: āDraugi, mums ir vajadzÄ«gi vairÄki serveri, kas atradÄ«sies nevis KrievijÄ, nevis AmazonÄ, bet, piemÄram, kaut kur AmsterdamÄ,ā secÄ«bÄ. uz, lai varÄtu vismaz kaut kÄ instalÄt savu VPN un starpniekserveri dažiem galapunktiem, kurus mÄs nekÄdÄ veidÄ nevaram ietekmÄt, piemÄram, tÄ paÅ”a s3 galapunktiem - mÄs nevaram mÄÄ£inÄt izveidot jaunu pakalpojumu un iegÅ«t citu IP, mums vÄl ir jÄnokļūst tur. Tikai dažu dienu laikÄ mÄs uzstÄdÄ«jÄm Å”os serverus, palaidÄm tos un kopumÄ sagatavojÄmies brÄ«dim, kad sÄkÄs bloÄ·ÄÅ”ana. Interesanti, ka RKN, skatoties uz satraukumu un paniku, teica: "NÄ, mÄs tagad neko nebloÄ·Äsim." (Bet tas ir tieÅ”i lÄ«dz brÄ«dim, kad sÄka bloÄ·Ät Telegram.) IekÄrtojuÅ”i apvedceļa iespÄjas un sapratuÅ”i, ka bloÄ·ÄÅ”ana nav ieviesta, mÄs tomÄr nesÄkÄm visu lietu sakÄrtot. JÄ, katram gadÄ«jumam.
Un 2019. gadÄ mÄs joprojÄm dzÄ«vojam bloÄ·ÄÅ”anas apstÄkļos. Vakar vakarÄ paskatÄ«jos: aptuveni miljons IP joprojÄm tiek bloÄ·Äti. Tiesa, Amazon tika gandrÄ«z pilnÄ«bÄ atbloÄ·Äts, maksimumÄ tas sasniedza 20 miljonus adreÅ”u... KopumÄ realitÄte ir tÄda, ka var nebÅ«t saskaÅotÄ«bas, labas saskaÅotÄ«bas. PÄkÅ”Åi. TÄ var nebÅ«t tehnisku iemeslu dÄļ ā ugunsgrÄki, ekskavatori, tas viss. Vai arÄ«, kÄ mÄs redzÄjÄm, ne gluži tehniski. LÄ«dz ar to kÄds liels un liels, ar saviem AS, droÅ”i vien var Å”o to nokÄrtot citÄdi - tieÅ”ais savienojums un citas lietas jau ir l2 lÄ«menÄ«. Bet vienkÄrÅ”Ä versijÄ, piemÄram, mÅ«su vai pat mazÄkÄ versijÄ, katram gadÄ«jumam var bÅ«t dublÄÅ”ana kaut kur citur paceltu serveru lÄ«menÄ«, kas iepriekÅ” konfigurÄts vpn, starpniekserveris, ar iespÄju Ätri pÄrslÄgt konfigurÄciju uz tiem Å”ajos segmentos. kas ir bÅ«tiski savienojamÄ«bai. Tas mums noderÄja ne reizi vien, kad sÄkÄs Amazon bloÄ·ÄÅ”ana, sliktÄkajÄ gadÄ«jumÄ caur tiem ļÄvÄm tikai S3 trafiku, bet pamazÄm tas viss atrisinÄjÄs.
KÄ rezervÄt... visu pakalpojumu sniedzÄju?
PaÅ”laik mums nav scenÄrija, ja visa Amazon nokristu. Mums ir lÄ«dzÄ«gs scenÄrijs attiecÄ«bÄ uz Krieviju. KrievijÄ mÅ«s mitinÄja viens pakalpojumu sniedzÄjs, no kura izvÄlÄjÄmies vairÄkas vietnes. Un pirms gada mÄs saskÄrÄmies ar problÄmu: lai gan tie ir divi datu centri, problÄmas var rasties jau pakalpojumu sniedzÄja tÄ«kla konfigurÄcijas lÄ«menÄ«, kas joprojÄm ietekmÄs abus datu centrus. Un mÄs varam nebÅ«t pieejami abÄs vietnÄs. Protams, tÄ arÄ« notika. MÄs beidzÄm pÄrskatÄ«t arhitektÅ«ru iekÅ”pusÄ. Tas nav Ä«paÅ”i mainÄ«jies, taÄu Krievijai mums tagad ir divas vietnes, kas nav no viena un tÄ paÅ”a pakalpojumu sniedzÄja, bet gan no divÄm dažÄdÄm. Ja viens neizdodas, mÄs varam pÄrslÄgties uz otru.
HipotÄtiski Amazon mÄs apsveram iespÄju veikt rezervÄciju cita pakalpojumu sniedzÄja lÄ«menÄ«; varbÅ«t Google, varbÅ«t vÄl kÄds... Bet lÄ«dz Å”im praksÄ esam novÄrojuÅ”i, ka, kamÄr Amazon notiek avÄrijas vienas pieejamÄ«bas zonas lÄ«menÄ«, tikmÄr vesela reÄ£iona lÄ«menÄ« avÄrijas ir diezgan reti. TÄpÄc teorÄtiski mums ir doma, ka mÄs varÄtu veikt atrunu āAmazon nav Amazonā, taÄu praksÄ tas vÄl nenotiek.
Daži vÄrdi par automatizÄciju
Vai vienmÄr ir nepiecieÅ”ama automatizÄcija? Å eit ir lietderÄ«gi atgÄdinÄt Danninga-Kruger efektu. Uz āxā ass ir mÅ«su zinÄÅ”anas un pieredze, ko mÄs iegÅ«stam, un uz āyā ass ir pÄrliecÄ«ba par mÅ«su rÄ«cÄ«bu. SÄkumÄ mÄs neko nezinÄm un nemaz neesam pÄrliecinÄti. Tad mÄs nedaudz zinÄm un kļūstam ļoti pÄrliecinÄti - tÄ ir tÄ sauktÄ āstulbuma virsotneā, ko labi ilustrÄ attÄls āplÄnprÄtÄ«ba un drosmeā. Tad esam nedaudz mÄcÄ«juÅ”ies un esam gatavi doties kaujÄ. Tad mÄs uzkÄpjam uz dažÄm mega nopietnÄm kļūdÄm un nonÄkam izmisuma ielejÄ, kad it kÄ kaut ko zinÄm, bet patiesÄ«bÄ nezinÄm daudz. Tad, gÅ«stot pieredzi, kļūstam pÄrliecinÄtÄki.
MÅ«su loÄ£ika par dažÄdiem automÄtiskajiem pÄrslÄgÅ”anÄs gadÄ«jumiem uz noteiktiem negadÄ«jumiem ir ļoti labi aprakstÄ«ta Å”ajÄ grafikÄ. SÄkÄm - neko nezinÄjÄm, gandrÄ«z viss darbs tika darÄ«ts ar rokÄm. Tad mÄs sapratÄm, ka varam visam pievienot automatizÄciju un, piemÄram, mierÄ«gi gulÄt. Un pÄkÅ”Åi mÄs uzkÄpjam uz mega-grÄbekļa: tiek aktivizÄts kļūdains pozitÄ«vs rÄdÄ«tÄjs, un mÄs pÄrslÄdzam satiksmi uz priekÅ”u un atpakaļ, ja labÄ nozÄ«mÄ mums to nevajadzÄja darÄ«t. LÄ«dz ar to replikÄcija sabojÄjas vai kaut kas cits ā Ŕī ir pati izmisuma ieleja. Un tad mÄs nonÄkam pie izpratnes, ka mums visam jÄpieiet gudri. Tas ir, ir jÄga paļauties uz automatizÄciju, paredzot viltus trauksmes iespÄju. Bet! ja sekas var bÅ«t graujoÅ”as, tad labÄk to atstÄt dežūrmaiÅÄ, dežurÄjoÅ”ajiem inženieriem, kuri pÄrliecinÄsies un uzraudzÄ«s, vai tieÅ”Äm ir notikusi avÄrija, un vajadzÄ«gÄs darbÄ«bas veiks manuÄli...
SecinÄjums
7 gadu laikÄ mÄs nonÄcÄm no tÄ, ka kaut kas nokrita, bija panika-panika, lÄ«dz sapratnei, ka problÄmas neeksistÄ, ir tikai uzdevumi, tie ir - un var - atrisinÄt. Veidojot pakalpojumu, paskatieties uz to no augÅ”as, novÄrtÄjiet visus riskus, kas var rasties. Ja jÅ«s tos redzat uzreiz, tad iepriekÅ” paredziet atlaiÅ”anu un iespÄju izveidot defektu izturÄ«gu infrastruktÅ«ru, jo jebkurÅ” punkts, kas var neizdoties un novest pie servisa nedarboÅ”anÄs, to noteikti darÄ«s. Un pat ja jums Ŕķiet, ka daži infrastruktÅ«ras elementi noteikti neizdosies - piemÄram, tas pats s3, tomÄr paturiet prÄtÄ, ka viÅi var. Un vismaz teorÄtiski ir priekÅ”stats par to, ko jÅ«s ar viÅiem darÄ«sit, ja kaut kas notiks. Ir riska pÄrvaldÄ«bas plÄns. Kad domÄjat darÄ«t visu automÄtiski vai manuÄli, novÄrtÄjiet riskus: kas notiks, ja automatizÄcija sÄks visu pÄrslÄgt - vai tas neradÄ«s vÄl sliktÄku situÄciju salÄ«dzinÄjumÄ ar negadÄ«jumu? VarbÅ«t kaut kur ir jÄizmanto saprÄtÄ«gs kompromiss starp automatizÄcijas izmantoÅ”anu un dežurÄjoÅ”Ä inženiera reakciju, kurÅ” izvÄrtÄs reÄlo ainu un sapratÄ«s, vai kaut kas ir jÄpÄrslÄdz uz vietas vai "jÄ, bet ne tagad".
SaprÄtÄ«gs kompromiss starp perfekcionismu un reÄlÄm pÅ«lÄm, laiku, naudu, ko varat tÄrÄt shÄmai, kas jums galu galÄ bÅ«s.
Å is teksts ir atjauninÄta un paplaÅ”inÄta versija Aleksandra Demidova ziÅojumam konferencÄ .
Avots: www.habr.com