Në ditët e sotme, shërbimi "Bitrix24" nuk ka qindra gigabit trafik dhe as një park të madh serverash (edhe pse, natyrisht, ka sërish mjaft). Megjithatë, për shumë klientë, ai është mjeti kryesor për punën në kompani; është një aplikacion që ka rëndësi kritike për biznesin. Prandaj, nuk ka mënyrë që të dështojë. E çfarë ndodh nëse ndodhi një rënie, por shërbimi u rikthye aq shpejt sa askush nuk e vuri re? Dhe si realizohet ndarja në rast rënies pa humbur cilësinë e punës dhe numrin e klientëve? Aleksandër Demidov, drejtori i degës së shërbimeve në cloud të "Bitrix24", rrëfeu për blogun tonë se si është evolucionuar sistemi i rezervave gjatë 7 vjetëve të ekzistencës së produktit.
Si shërbim SaaS, ne lançuam "Bitrix24" 7 vjet më parë. Sfidat kryesore ndoshta ishin këto: para lançimit në publik si SaaS, ky produkt ekzistonte thjesht në formatin e një zgjidhjeje me kutinë. Klientët e blinin prej nesh, e instalonin në serverët e tyre, krijonin një portal korporativ — një zgjidhje e përbashkët për komunikimin e punonjësve, ruajtjen e skedarëve, menaxhimin e detyrave, CRM, dhe kështu me radhë. Dhe deri në vitin 2012 vendosëm që dëshironim ta lançojmë këtë si SaaS, me menaxhimin e vet, duke siguruar qëndrueshmëri dhe besueshmëri. Përvoja e fituam në proces, sepse deri atëherë ne thjesht nuk e kishim — ishim vetëm prodhues të softuerit, jo ofrues shërbimesh.
Kur filluam shërbimin, e kuptonim se më e rëndësishme është të sigurojmë që shërbimi të jetë i disponueshëm, i besueshëm dhe konstant, sepse nëse keni një faqe të zakonshme, një dyqan, për shembull, dhe ajo bie për një orë, vuani vetëm ju, humbni porositë, humbni klientët, por për vetë klientin tuaj — për të nuk është shumë kritike. Sigurisht, ai mërzitet, por shkon dhe blen në një faqe tjetër. Por nëse është një aplikacion, në të cilin është e varur e gjithë puna brenda kompanisë, komunikimet, vendimet, atëherë çelësi është të fitoni besimin e përdoruesve, domethënë të mos i lini ata në baltë dhe të mos dështoni. Sepse e gjithë puna mund të ndalojë nëse diçka brenda nuk funksionon.
Bitrix.24 si SaaS
Prototipi i parë e kemi ndërtuar një vit para lançimit publik, në vitin 2011. E përfunduam për rreth një javë, e shikuam, e kthyem - madje ishte funksional. Pra, mund të shkoje në formë, të shkruaje emrin e portalit, dhe krijohej një portal i ri, duke u krijuar një bazë përdoruesish. E shikuam, e vlerësuam në thelb produktin, e mbyllëm dhe kaluam një vit tjetër për ta qëndruar përpara. Sepse kishim një detyrë të madhe: nuk donim të bënim dy baza të ndryshme kodesh, nuk donim të mbështesim produkte të ndryshme, veçmas, zgjidhje cloud - ne donim ta bënim gjithë këtë brenda një kode.
Një aplikacion web tipik në atë kohë ishte një server, ku filmonte ndonjë kod php, baza mysql, skedarët ngarkoheshin, dokumentet, imazhet vendoseshin në dosjen upload - dhe gjithçka funksiononte. Për fat të keq, nuk është e mundur të nisni një shërbim web kritikisht të qëndrueshëm në këtë mënyrë. Nuk mbështetet caching i shpërndarë, nuk mbështetet replikimi i bazave të të dhënave.
Ne kemi formuluar kërkesat: kjo është aftësia për t'u vendosur në vende të ndryshme, për të mbështetur replikimin, idealisht të vendoset në qendra të të dhënave geografi të shpërndara. Të ndajmë logjikën e produktit dhe, në thelb, ruajtjen e të dhënave. Të jemi në gjendje të shpërndajmë dinamikisht ngarkesat, duke nxjerrë jashtë statikën. Nga këto konsiderata janë formuar, në thelb, kërkesat për produktin, të cilin ne e kemi përmirësuar për një vit. Gjatë këtij kohë, ne krijuam një platformë të unifikuar — për zgjidhje kutish, për shërbimin tonë vetjak — ku kemi bërë mbështetje për ato gjëra që na ishin të nevojshme. Mbështetje për replikimin MySQL në nivelin e vetë produktit: pra, programuesi, i cili shkruan kod, nuk mendon se si do të shpërndahen kërkesat e tij, ai përdor API-n tonë, dhe ne dimë të shpërndajmë saktë kërkesat për shkrim dhe për lexim midis Master-ave dhe Slave-ave.
Ne kemi implementuar mbështetje për nivele të ndryshme produktesh të magazinave objektive cloud: Google Storage, Amazon S3, dhe gjithashtu mbështetje për Open Stack Swift. Kështu që kjo ishte e përshtatshme si për ne si shërbim, ashtu dhe për zhvilluesit që punojnë me zgjidhje të paketuara: nëse ata përdorin vetëm API-në tonë, ata nuk mendojnë se ku do të ruhet përfundimisht skedari, në sisteme lokale të skedarëve apo do të shkonte në një magazinë objektive skedarësh.
Në përfundim, ne menjëherë vendosëm që do të rezervojmë në nivelin e një qendre të tërë të të dhënave. Në vitin 2012, ne u nisëm plotësisht në Amazon AWS, sepse tashmë kishim përvojë me këtë platformë - faqja jonë e internetit ishte vendosur aty. Na tërhiqte se në çdo rajon në Amazon ka disa zona disponueshmërie - në thelb, (në terminologjinë e tyre) disa qendra të të dhënave, të cilat janë më pak ose më shumë të pavarura nga njëra-tjetra dhe na lejojnë të rezervojmë në nivelin e një qendre të tërë të të dhënave: nëse ndonjëherë dështon, bazat replikohen master-master, serverët e aplikacioneve të uebit janë të rezervuar, dhe statika ka kaluar në magazinën objektive s3. Ngarkesa balancohet - në atë kohë me elb të Amazon-it, por pak më vonë erdhëm te balancuesit tanë, sepse na nevojitej një logjikë më e komplikuar.
Çfarë dëshiruam - atë edhe morëm...
Të gjitha gjërat bazike që donim të siguronim - qëndrueshmëria e vet serverëve, aplikacioneve të uebit, bazave të të dhënave - të gjitha funksiononin mirë. Scenari më i thjeshtë: nëse ndonjë aplikacion uebi dështon, atëherë këtu është e thjeshtë - ato fikën nga balancimi.
Makinat e balansimit që kanë dalë nga funksioni (atëherë ishte elb nga Amazon) vetë i shënonte si të pamundur, duke ndaluar shpërndarjen e ngarkesës tek ato. Funksiononte automatikisht skelimi i Amazon: kur ngarkesa rritej, shtoheshin makina të reja në grupin e skelimit, ngarkesa shpërndaxehej te makinat e reja - gjithçka ishte mirë. Logjika jonë e balansuesve është përafërsisht e njëjtë: nëse ndodh diçka me serverin e aplikacioneve, ne heqim kërkesat nga ai, e largojmë atë makinë, fillojmë makina të reja dhe vazhdojmë të punojmë. Plani ka ndryshuar pak gjatë këtyre viteve, por vazhdon të funksionojë: është i thjeshtë, i qartë, dhe nuk ka asnjë sfidë me të.
Ne punojmë në të gjithë botën, piket e ngarkesës së klientëve janë plotësisht të ndryshme, dhe, për të qënë të sinqertë, ne duhet të kemi mundësinë të kryejmë punime shërbimi me çdo komponent të sistemit tonë në çdo kohë - pa u vënë re nga klientët. Prandaj kemi mundësi të fikim bazën e të dhënave, duke ripjeshkatuar ngarkesën në qendrën e dytë të të dhënave.
Si si funksionon gjithçka? — Ne kalojmë trafikun në qendër të të dhënave që punon — nëse ka një fatkeqësi në qendrën e të dhënave, atëherë krejtësisht, nëse janë punë të planifikuara në ndonjë bazë të dhënash, atëherë ne kalojmë një pjesë të trafikut që shërben për këta klientë në qendrën e dytë të të dhënave, dhe ndalim replikimin. Nëse kërkohen makina të reja për aplikacione web, pasi është rritur ngarkesa në qendrën e dytë të të dhënave, ato startojnë automatikisht. Puna përfundon, replikimi rikthehet, dhe ne kthejmë të gjithë ngarkesën prapa. Nëse na nevojitet të bëjmë punë të ngjashme në qendrën e dytë të të dhënave, për shembull, për të instaluar përditësime sistemore ose për të ndryshuar cilësimet në bazën e dytë të dhënash, ne, në përgjithësi, përsërisim të njëjtën gjë, vetëm në drejtim të lartë. Por nëse ka një fatkeqësi, atëherë ne bëjmë gjithçka thjesht: në sistemin e monitorimit përdorim mekanizmin e menaxherëve të ngjarjeve. Nëse disa kontrolle aktivizohen dhe statusi kalon në kritike, atëherë aktivizohet ky menaxher, që mund të realizojë logjikën e caktuar. Për çdo bazë të dhënash kemi rregulluar se cili server është failover për të dhe ku duhet të kalojmë trafikun në rast se ajo bëhet e pamundur. Ne — për shkak të historisë — përdorim në një farë mënyre nagios ose ndonjë nga nënformat e tij. Në principe, mekanizma të tillë ka në praktikisht çdo sistem monitorimi, por ne për momentin nuk përdorim diçka më të komplikuar, megjithatë ndoshta do të fillojmë ndonjëherë. Tani monitorimi aktivizohet në rastin e pamundësisë dhe ka mundësinë të kalojë diçka.
A është rezervuar gjithçka prej nesh?
Ne kemi shumë klientë nga SHBA, shumë klientë nga Europa, shumë klientë që janë më afër Lindjes — Japonia, Singapori dhe kështu me radhë. Natyrisht, një pjesë e madhe e klientëve janë në Rusi. Pra, puna jonë shtrihet në shumë rajone të ndryshme. Përdoruesit duan një reagim të shpejtë, ka kërkesa për përputhjen me ligjet lokale të ndryshme, dhe brenda çdo rajoni ne rezervojmë dy qendra të dhënash, plus ka disa shërbime shtesë, që gjithashtu është e përshtatshme t’i vendosim brenda një rajoni — për klientët që punojnë në atë rajon. Trajnerët REST, serverët e autorizimit, nuk janë aq kritikë për funksionimin e klientit në përgjithësi, për to mund të kalojmë me një vonesë të pranuar, por nuk duam të shpikim biçikleta, si t’i monitorojmë dhe çfarë të bëjmë me to. Kështu që në maksimum ne mundohemi të përdorim zgjidhje ekzistuese, dhe jo të zhvillojmë ndonjë kompetencë për produkte shtesë në vetveten tonë. Diku ne thjesht përdorim kalimin në nivelin dns, ndërsa aktiviteti i shërbimit përcaktohet nga të njëjtin dns. Në Amazon ka shërbimin Route 53, por ajo nuk është thjesht dns, në të cilin mund të regjistrojmë një rekord dhe të gjitha — është shumë më fleksibël dhe e përshtatshme. Nëpërmjet saj mund të ndërtojmë shërbime të shpërndara gjeo me gjeolokacione, kur me ndihmën e saj përcaktoni nga erdhi klienti, dhe i jepni atij regjistrat përkatës — me ndihmën e saj mund të ndërtoni arkitektura failover. Kontrollimet e shëndetit gjithashtu mund të konfigurohen në Route 53, ju caktoni endpointet që monitorohen, caktoni metrike, përcaktoni se me cilat protokolle të përcaktoni "aktivitetin" e shërbimit — tcp, http, https; caktoni periodicitetin e kontrollimeve që përcaktojnë nëse shërbimi është aktiv apo jo. Dhe në dns vetë përcaktoni cila do të jetë primary, cila do të jetë secondary, ku do të kaloni, nëse kontrolli i shëndetit në brendësi të route 53 ndodh. Të gjithë këto mund të bëhen me mundësi të tjera veglash, por ajo çfarë është e përshtatshme — një herë e konfigurove dhe pastaj nuk mendojmë fare për si bëhen kontrollimet, si bëhet kalimi: gjithçka funksionon vetë.
E para, por çfarë duhet të rezervojmë vërtet route 53? E kush e di, ndoshta ndodh ndonjë gjë me të? Fatmirësisht, ne kurrë nuk kemi përjetuar këtë, por përsëri, do të ndaj një tregim se pse menduam se duhet ta rezervonim. Këtu po e mbrojmë veten paraprakisht. Disa herë në ditë, bëjmë një eksport të plotë të të gjitha zonave që kemi regjistruar në route 53. API i Amazon na lejon t'i shërbejmë ato në JSON pa ndonjë problem, dhe kemi ngritur disa serverë rezervë ku e konvertojmë këtë, e eksportojmë si konfiguracione dhe kemi, në thelb, një konfigurim rezervë. Në rast se ndodh ndonjë gjë, mund ta rindërtojmë shpejt manualisht, pa humbur të dhënat e konfigurimeve DNS.E dyta
Por e dyta: çfarë nuk është e rezervuar ende në këtë imazh? Balancuesi i vet! Ne kemi bërë ndarjen e klientëve sipas rajoneve shumë të thjeshtë. Ne kemi domenet bitrix24.ru, bitrix24.com, .de — tani kemi rreth 13 të ndryshme, të cilat punojnë në zona të ndryshme. Arritëm në përfundimin se në çdo rajon duhet të kemi balancues të vetë. Kështu është më e lehtë të ndahet sipas rajoneve, në varësi të ngarkesës maksimale në rrjet. Nëse ka një dështim në nivelin e ndonjë balancuesi, ai thjesht nxirret nga përdorimi dhe hiqet nga DNS. Nëse ndodh ndonjë problem me grupin e balancuesve, ata rezervohen në platforma të tjera, dhe kalimi midis tyre bëhet me anë të route53, sepse me një TTL të shkurtër kalimi ndodh maksimumi brenda 2, 3, 5 minutash.
Treta "po": çfarë tjetër nuk është rezervuar? S3, e saktë. Ne, duke ruajtur skedarët që kemi tek përdoruesit në s3, besonim sinqerisht se ishte i paprekshëm dhe nuk duhej të reservonim asgjë aty. Por historia tregon se ndodhin gjëra të tjera. Në fakt, Amazon e përshkruan S3 si një shërbim themelor, sepse vetë Amazon e përdor S3 për të ruajtur imazhe makinerish, konfigurimesh, imazhe AMI, snapshot-e… Dhe nëse bie s3, si ndodhi një herë gjatë këtyre 7 viteve që po përdorim bitrix24, ai rrëmben pas tij shumë të tjera — papërshkrueshmëri në nisjen e virtualëve, dështim në funksionimin e api-ve dhe kështu me radhë.
Edhe S3 mund të dështojë — kështu ndodhi një herë. Prandaj arritëm në skemën e mëposhtme: disa vite më parë nuk kishte depozita objektive publike serioze në Rusi, dhe ne po shqyrtonim mundësinë për të bërë diçka tonën… Për fat, ne nuk e filluam këtë, sepse do të kishim mbetur të humbur në atë ekspertizë që ne nuk e kemi, dhe ndoshta do të kishim bërë gabime. Tani depozitat e përputhshme me s3 janë nga Mail.ru, nga Yandex, dhe nga disa ofrues të tjerë. Në fund erdhëm në përfundimin se duam të kemi, së pari, rezervim, dhe së dyti, mundësinë për të punuar me kopje lokale. Për rajonin konkret rus ne përdorim shërbimin Mail.ru Hotbox, i cili është i përputhshëm me api-në s3. Nuk na nevojiteshin ndonjë përmirësim serioz në kodin brenda aplikacionit, dhe ne krijuam mekanizmin e mëposhtëm: në s3 ka trigger-a që veprojnë në krijimin dhe fshirjen e objekteve, dhe Amazon ka një shërbim të tillë si Lambda — kjo është një shërbim serverless për ekzekutimin e kodit, i cili do të realizohet pikërisht kur aktivizohen këto trigger-a.
Kemi bërë shumë thjeshtë: nëse aktivizohet një trigger, ne ekzekutojmë kodin që kopjon objektin në ngjarjen Mail.ru. Për të filluar plotësisht punën me kopjet lokale të të dhënave, na nevojitet edhe një sinkronizim i kundërt, në mënyrë që klientët që janë në segmentin rus të mund të punojnë me një arkiv që është më afër tyre. Mail është gati të përfundojë triggerat në arkiv — do të jetë e mundur tashmë në nivelin e infrastrukturës të ekzekutojmë sinkronizimin e kundërt, për momentin ne e bëjmë këtë në nivelin e kodit tonë. Nëse shohim që klienti ka vendosur një skedar, ne vendosim një ngjarje në radhë në kodin tonë, e përpunojmë atë dhe bëjmë replikimin e kundërt. Çfarë është e keqe në këtë: nëse ndodh ndonjë punë me objektet tona jashtë produktit tonë, pra me mjete të jashtme, ne nuk do ta kemi parasysh. Prandaj presim deri sa të mbarojnë triggerat në nivelin e arkivave, në mënyrë që, pavarësisht se nga ku ekzekutojmë kodin, objekti që erdhi te ne të kopjohet në anën tjetër.
Në nivelin e kodit, ne regjistrojmë dy ruajtje për çdo klient: një që konsiderohet si kryesore dhe tjetra si backup. Nëse gjithçka shkon mirë, punojmë me ruajtjen që është më pranë nesh: klientët tanë që janë në Amazon punojnë me S3, ndërsa ata që operojnë në Rusi punojnë me Hotbox. Nëse ndonjëherë aktivizohet një sinjal, ne duhet të aktivizojmë failover dhe të kalojmë klientët në një ruajtje tjetër. Ne mund ta aktivizojmë këtë sinjal pavarësisht nga rajonet dhe t'i kalojmë disa herë. Në praktikë nuk e kemi përdorur ende, por e kemi parashikuar këtë mekanizëm dhe mendojmë se ndonjëherë do na nevojitet kalimi. Një herë ka ndodhur tashmë.
O, dhe Amazon ju iku...
Ky prill — përvjetori i nisjes së bllokimeve të Telegramit në Rusi. Prodhuesi më i prekur nga kjo ishte Amazon. Dhe, fatkeqësisht, kompanitë ruse që punonin për të gjithë botën e patën më keq.
Nëse një kompani është globale dhe Rusia është një segment shumë i vogël për të, 3-5% — po, sidoqoftë, mund të sakrifikohen.
Nëse kjo është një kompani që vepron ekskluzivisht në Rusi, jam i sigurt se duhet të vendoset lokal – do të ishte thjesht më e përshtatshme dhe më e rehatshme për përdoruesit, dhe do të ketë më pak rreziqe.
Por nëse kjo është një kompani që vepron globalisht dhe ka klientë të barabartë nga Rusia dhe nga vende të tjera? Rëndësia e lidhshmërisë midis segmenteve është e madhe, dhe ata duhet të punojnë së bashku në një farë mënyre.
Në fund të marsit 2018, Roskomnadzor dërgoi një letër operatorëve më të mëdhenj, duke informuar se planifikonin të bllokonin disa miliona IP nga Amazon për të bllokuar… aplikacionin e mesazheve Zello. Falë këtyre ofruesve, ata e shpërndanë letrën me sukses, dhe u kuptua se lidhshmëria me Amazon mund të prishej. Ishte një të premte; ne vrapuam në panik tek kolegët tanë nga servers.ru, me fjalët: «Shokë, na nevojiten disa serverë që të vendosen jashtë Rusisë, jo në Amazon, por, për shembull, diku në Amsterdam», për të pasur mundësi ashtu si të pakuptuar të vendosnim atje të paktën diçka. vpn dhe proxy për disa endpoint’e, për të cilët nuk mund të ndikojmë në asnjë mënyrë, për shembull endpoint’e të S3 — nuk mund të përpiqemi të ngremë një shërbim të ri dhe të marrim një IP tjetër, na duhen gjithsesi për të arritur atje. Brenda disa ditësh i konfiguruam këto servera, i ngritëm, dhe përgjithësisht, deri në momentin e fillimit të bllokimeve u përgatitëm. Është interesante se RKN, duke parë sherrin dhe panikun e ngritur, tha: "Jo, ne tani nuk do të bllokojmë asgjë". (Por kjo është pikërisht deri në atë moment kur filluan të bllokojnë Telegramin.) Pas konfigurimit të mundësive të anashkalimit dhe duke kuptuar se nuk u vendos bllokimi, megjithatë, ne nuk e shpërndamë këtë situatë. Pra, për çdo rast.
Dhe ja, në vitin 2019, ne jetojmë nën kushtet e bllokimeve. Dëgjova natën e kaluar: rreth një milion IP vazhdojnë të bllokohen. Në të vërtetë, Amazon është shumica e rikthyer, dhe arritëm deri në 20 milion adresash në kulm... Në përgjithësi, realiteti është se lidhshmëria, lidhshmëria e mirë — ndonjëherë nuk mund të ekzistojë. Papritur. Mund të mungojë për arsye teknike — zjarre, ekskavatorë, dhe të tjera të ngjashme. Ose, siç pamë, jo gjithmonë për arsye teknike. Prandaj dikush i madh dhe i rëndësishëm, me AS-të e tij, ndoshta mund ta menaxhojë këtë me rrugë të tjera, — direkt lidhje dhe gjëra të tjera në nivelin l2. Por në një version të thjeshtë, si ne ose më të vegjlit, është mirë të keni një rezervim në nivel serverash, të ngritur diku tjetër, me VPN, proxy të konfigurura paraprakisht, me mundësinë për të ndërruar shpejt konfigurimin në ato segmente që janë kritike për ju në lidhshmëri. Kjo na ka ndihmuar shumë herë, kur filluan bllokimet e Amazon, ne kalonim trafikun e S3 në rastin më të keq, por gradualisht gjithçka u rregullua.
Si të rezervosh... një tërësi ofruesi?
Aktualisht nuk kemi një skenar për rastet e dështimit të plotë të Amazon. Por, kemi një skenar të ngjashëm për Rusinë. Në Rusi, ne ishim të akomoduar në një ofrues, nga i cili zgjodhëm të kishim disa platforma. Para një viti përballëm një problem: pavarësisht se ishin dy qendra të të dhënash, në nivelin e konfigurimit të rrjetit të ofruesit mund të ishin problemet që ndikonin edhe të dy qendrat. Kështu, mund të përjetonim mungesë aksesit në të dy platforma. Natyrisht, kështu ndodhi. Në fund, ne rishikuan arkitekturën tonë të brendshme. Ajo nuk u ndryshua shumë ndjeshëm, por për Rusinë tani kemi dy platforma, të cilat nuk janë në një ofrues, por në dy të ndryshëm. Nëse njëra shkatërrohet, ne mund të kalojmë te tjetra.
Hipotetikisht, për Amazon po shqyrtojmë mundësinë e rezervimit në nivelin e një ofruesi tjetër; ndoshta Google, ndoshta dikush tjetër... Por deri tani kemi vëzhguar në praktikë se nëse ndodhin aksidente në një zonë të caktuar të disponueshmërisë në Amazon, aksidentet në nivelin e të gjithë rajonit janë të mjaft të rralla. Prandaj, teoriisht, kemi një ide se ndoshta do të bëjmë rezervimet "Amazon - jo Amazon", por në praktikë, kjo ende nuk ka ndodhur.
Një fjalë për automatizimin
A ka nevojë gjithmonë për automatizim? Këtu është e përshtatshme të kujtojmë efektin Dunning-Kruger. Në boshtin "x" janë njohuritë dhe përvoja që ne fitojmë, ndërsa në boshtin "y" është besimi në veprimet tona. Fillimisht nuk dimë asgjë dhe nuk jemi aspak të sigurt. Pastaj dimë pak dhe bëhemi mega të sigurt - ky është "pika e marrëzisë", e cila ilustrohet mirë në imazhin "nëse nuk je i mençur, ke guxim". Pastaj ne kemi mësuar pak dhe jemi gati të shkojmë në luftë. Më pas shkelim mbi disa gafa të rënda, bien në luginën e dëshpërimit, kur duket se dimë diçka, por në të vërtetë nuk dimë shumë. Pastaj, me kalimin e kohës, bëhemi më të sigurt.
Logjika jonë për ndërrimet e ndryshme automatikisht për aksidente të caktuara është shumë mirë e përshkruar nga ky grafik. Ne e filluam - nuk dinim asgjë, pothuajse të gjitha punët bëheshin manualisht. Më pas kuptuam se mund të vendosnim automatik për gjithçka dhe të flinim qetë. Papritmas, humbasim kontrollin dhe ndodhim në një situatë problematike: ndodhin false positive dhe ne përçojmë trafikun për andej këndej, kur, në fakt, nuk duhej ta bënim këtë. Kjo do të thotë se ndodhin prishje të replikimit ose ndonjë gjë tjetër - kjo është ajo luginë e dëshpërimit. Pastaj arrijmë në kuptimin se çdo gjë duhet ta shohim me mend. Kështu që ka kuptim të mbështetemi në automatikë, duke parashikuar mundësinë e aktivizimit të gabuar. Por! nëse pasojat mund të jenë shkatërruese, është më mirë ta lëmë këtë në duar të ekipit në turn, inxhinierëve të zyrës, të cilët do të sigurohen dhe do të kontrollojnë nëse është vërtet një emergjencë dhe do të realizojnë veprimet e nevojshme manualisht...
Përfundimi
Në 7 vjet, kemi kaluar nga panika totale kur ndodhte ndonjë rënie, në kuptimin se nuk ka probleme, por vetëm detyra që duhet dhe mund të zgjidhen. Kur ndiheni duke ndërtuar një shërbim, shikoni atë nga lart, vlerësoni të gjitha rreziqet që mund të ndodhin. Nëse i shihni menjëherë, parashikoni rezervimin dhe mundësinë për të ndërtuar një infrastrukturë që nuk dështoon, sepse çdo pikë që mund të dështojë dhe të çojë në mosfunksionimin e shërbimit, do ta bëjë patjetër. Dhe edhe nëse mendoni se disa elementë të infrastrukturës, si p.sh. s3, nuk do të dështojnë, duhet të keni parasysh se ata gjithashtu mund të ndodhin. Të paktën teorikisht, duhet të keni një ide se çfarë do të bëni me ta nëse ndodh diçka. Keni një plan për menaxhimin e rreziqeve. Kur mendoni të bëni gjithçka me automatizim ose manualisht, vlerësoni rreziqet: çfarë do ndodhe nëse automatizimi fillon të ndryshojë gjithçka — a do të çojë kjo në një skenë për keq në krahasim me një katastrofë? Ndoshta, diku është e nevojshme të përdoret një kompromis i arsyeshëm mes përdorimit të automatizimit dhe reagimit të inxhinierit në detyrë, i cili do të vlerësojë situatën reale dhe do të kuptojë nëse është e nevojshme të ndryshohet menjëherë apo "po, por jo tani".
Një kompromis i arsyeshëm midis përsosmërisë dhe kapacitetit real, kohës, parave që mund të shpenzoni për skemën që do të keni në fund.
Ky tekst është një version i zgjeruar dhe i pasuruar i raportit të Aleksandër Demidov në konferencë. .
Burimi: habr.com
