Në verë, si aktiviteti blerës, ashtu edhe intensiteti i ndryshimeve në infrastrukturën e projekteve në ueb tradicionalisht ulen, na thotë kapiteni Obvious. Thjesht sepse edhe specialistët e IT ndonjëherë shkojnë me pushime. Dhe CTO gjithashtu. Është edhe më e vështirë për ata që mbeten në detyrë, por kjo nuk është çështja tani: ndoshta kjo është arsyeja pse vera është periudha më e mirë për të menduar ngadalë për skemën ekzistuese të rezervimeve dhe për të hartuar një plan për ta përmirësuar atë. Dhe përvoja e Yegor Andreev nga , për të cilën foli në konferencë .
Ka disa gracka në të cilat mund të bini kur ndërtoni faqe rezervë. Dhe është absolutisht e pamundur të kapesh në to. Dhe ajo që na prish në gjithë këtë, si në shumë gjëra të tjera, është perfeksionizmi dhe... dembelizmi. Ne po përpiqemi të bëjmë gjithçka, gjithçka, gjithçka në mënyrë perfekte, por nuk kemi nevojë ta bëjmë atë në mënyrë perfekte! Ju duhet vetëm të bëni disa gjëra, por t'i bëni ato në mënyrë korrekte, t'i plotësoni në mënyrë që të funksionojnë siç duhet.
Failover nuk është një lloj argëtimi, gjëje argëtuese; kjo është një gjë që duhet të bëjë pikërisht një gjë - të zvogëlojë kohën e ndërprerjes në mënyrë që shërbimi, kompania, të humbasë më pak para. Dhe në të gjitha metodat e rezervimit, unë sugjeroj të mendoni në kontekstin e mëposhtëm: ku janë paratë?
Kurthi i parë: kur ndërtojmë sisteme të mëdha, të besueshme dhe përfshihemi në tepricë, ne zvogëlojmë numrin e aksidenteve. Ky është një keqkuptim i tmerrshëm. Kur përfshihemi në tepricë, ka të ngjarë të rrisim numrin e aksidenteve. Dhe nëse bëjmë gjithçka siç duhet, atëherë kolektivisht do të reduktojmë kohën e joproduktive. Do të ketë më shumë aksidente, por ato do të ndodhin me kosto më të ulët. Çfarë është një rezervim? - ky është një ndërlikim i sistemit. Çdo ndërlikim është i keq: ne kemi më shumë dhëmbëza, më shumë ingranazhe, me një fjalë, më shumë elementë - dhe, për rrjedhojë, një shans më të lartë për prishje. Dhe ata me të vërtetë do të thyhen. Dhe ata do të thyhen më shpesh. Një shembull i thjeshtë: le të themi se kemi një faqe interneti me PHP dhe MySQL. Dhe urgjentisht duhet të rezervohet.
Shtosh (c) Marrim vendin e dytë, ndërtojmë një sistem identik... Kompleksiteti bëhet dy herë më i madh - kemi dy entitete. Ne gjithashtu hapim një logjikë të caktuar për transferimin e të dhënave nga një faqe në tjetrën - domethënë, riprodhimi i të dhënave, kopjimi i të dhënave statike, etj. Pra, logjika e riprodhimit është zakonisht shumë komplekse, dhe për këtë arsye, kompleksiteti i përgjithshëm i sistemit mund të jetë jo 2, por 3, 5, 10 herë më i madh.
Kurthi i dytë: kur ndërtojmë sisteme komplekse vërtet të mëdha, ne fantazojmë për atë që duam të marrim në fund. Voila: ne duam të marrim një sistem super të besueshëm që funksionon pa asnjë ndërprerje, kalon në gjysmë sekonde (ose më mirë akoma, në çast) dhe fillojmë t'i bëjmë ëndrrat realitet. Por këtu ka edhe një nuancë: sa më e shkurtër të jetë koha e dëshiruar e ndërrimit, aq më komplekse bëhet logjika e sistemit. Sa më komplekse duhet ta bëjmë këtë logjikë, aq më shpesh sistemi do të prishet. Dhe ju mund të përfundoni në një situatë shumë të pakëndshme: ne po përpiqemi me të gjitha forcat të reduktojmë kohën e joproduktive, por në fakt po e komplikojmë gjithçka dhe kur diçka nuk shkon mirë, koha e joproduktive do të përfundojë të jetë më e gjatë. Këtu shpesh e kapni veten duke menduar: mirë... do të ishte më mirë të mos bëni një rezervim. Do të ishte më mirë nëse do të funksiononte vetëm dhe me kohë joproduktive të kuptueshme.
Si mund ta luftosh këtë? Ne duhet të ndalojmë së gënjyeri veten, të ndalojmë së lajkuari se do të ndërtojmë një anije kozmike këtu tani, por të kuptojmë në mënyrë adekuate se sa mund të zgjasë projekti. Dhe për këtë kohë maksimale, ne do të zgjedhim se cilat metoda do të përdorim në të vërtetë për të rritur besueshmërinë e sistemit tonë.
Është koha për “histori nga w”... nga jeta, sigurisht.
Shembulli numër një
Imagjinoni një faqe interneti për kartëvizitë për Uzinën e Rrotullimit të Tubave nr. 1 në qytetin e N. Aty thuhet me shkronja të mëdha - Uzina e rrokullisjes së tubave nr. 1. Pak më poshtë është slogani: "Tubacionet tona janë tubat më të rrumbullakosura në veri". Dhe më poshtë është numri i telefonit të CEO dhe emri i tij. Ne e kuptojmë që ju duhet të bëni një rezervim - kjo është një gjë shumë e rëndësishme! Le të fillojmë të kuptojmë se nga çfarë përbëhet. Html-statics - domethënë disa foto ku menaxheri i përgjithshëm, në fakt, po diskuton një lloj marrëveshjeje tjetër në tryezë në banjë me partnerin e tij. Ne fillojmë të mendojmë për kohën e pushimit. Të vjen në mendje: duhet të shtrihesh atje për pesë minuta, jo më shumë. Dhe pastaj lind pyetja: sa shitje ka pasur nga kjo faqe jonë në përgjithësi? Sa - sa? Çfarë do të thotë "zero"? Dhe kjo do të thotë: sepse gjenerali ka bërë të katër transaksionet vitin e kaluar në të njëjtën tavolinë, me të njëjtët njerëz me të cilët shkojnë në banjë dhe ulen në tavolinë. Dhe ne e kuptojmë që edhe nëse faqja ulet për një ditë, asgjë e tmerrshme nuk do të ndodhë.
Bazuar në informacionin hyrës, ka një ditë për të ngritur këtë histori. Le të fillojmë të mendojmë për një skemë tepricë. Dhe ne zgjedhim skemën më ideale të tepricës për këtë shembull: ne nuk përdorim tepricën. E gjithë kjo mund të ngrihet nga çdo administrator në gjysmë ore me pushime tymi. Instaloni një server në internet, shtoni skedarë - kjo është ajo. Do të funksionojë. Ju nuk keni nevojë të mbani një sy mbi asgjë, nuk keni nevojë t'i kushtoni vëmendje të veçantë asgjëje. Kjo do të thotë, përfundimi nga shembulli numër një është mjaft i qartë: shërbimet që nuk kanë nevojë të rezervohen nuk kanë nevojë të rezervohen.
Shembulli numër dy
Blogu i kompanisë: njerëz të trajnuar posaçërisht shkruajnë lajme atje, ne morëm pjesë në një ekspozitë të tillë, por ne lëshuam një produkt tjetër të ri, e kështu me radhë. Le të themi se kjo është PHP standarde me WordPress, një bazë të dhënash të vogël dhe pak statike. Natyrisht, përsëri vjen në mendje që në asnjë rrethanë nuk duhet të shtriheni - "jo më shumë se pesë minuta!" Kjo është e gjitha. Por le të mendojmë më tej. Çfarë bën ky blog? Njerëzit vijnë atje nga Yandex, nga Google bazuar në disa pyetje, në mënyrë organike. E madhe. A kanë lidhje shitjet me të? Epifania: jo me të vërtetë. Trafiku i reklamave shkon në faqen kryesore, e cila është në një makinë tjetër. Le të fillojmë të mendojmë për një skemë rezervimi. Në një mënyrë të mirë, ajo duhet të ngrihet në disa orë, dhe do të ishte mirë të përgatitesh për këtë. Do të ishte e arsyeshme të merrje një makinë nga një qendër tjetër të dhënash, të rrotullosh mjedisin në të, domethënë një server në internet, PHP, WordPress, MySQL dhe ta linte atje. Në momentin kur kuptojmë se gjithçka është prishur, duhet të bëjmë dy gjëra - të hapim deponinë mysql 50 metra, ai do të fluturojë atje brenda një minutë dhe të nxjerrim një numër të caktuar fotografish nga rezervimi atje. Kjo gjithashtu nuk është aty për një kohë të gjatë që një Zot e di. Kështu, në gjysmë ore e gjithë gjëja ngrihet. Asnjë përsëritje, ose Zoti më fal, dështim automatik. Përfundim: ajo që mund të nxjerrim shpejt nga një kopje rezervë nuk ka nevojë të rezervohet.
Shembulli numër tre, më i ndërlikuar
Dyqan online. PhP me zemër të hapur është pak i modifikuar, mysql me një bazë solide. Shumë statike (në fund të fundit, dyqani online ka imazhe të bukura HD dhe të gjitha ato gjëra), Redis për seancën dhe Elasticsearch për kërkim. Ne fillojmë të mendojmë për kohën e pushimit. Dhe këtu, natyrisht, është e qartë se një dyqan në internet nuk mund të qëndrojë pa dhimbje për një ditë. Në fund të fundit, sa më gjatë të qëndrojë, aq më shumë para humbasim. Ia vlen të përshpejtohet. Sa shumë? Unë mendoj se nëse shtrihemi për një orë, askush nuk do të çmendet. Po, do të humbasim diçka, por nëse fillojmë të punojmë shumë, do të përkeqësohet. Ne përcaktojmë një skemë të pushimit të lejuar në orë.
Si mund të rezervohet e gjithë kjo? Ju duhet një makinë në çdo rast: një orë kohë është mjaft pak. Mysql: këtu ne kemi nevojë tashmë për riprodhim, riprodhim të drejtpërdrejtë, sepse në një orë 100 GB me shumë mundësi nuk do të shtohen në hale. Statika, foto: përsëri, në një orë 500 GB mund të mos kenë kohë për t'u shtuar. Prandaj, është më mirë të kopjoni fotot menjëherë. Redis: këtu gjërat bëhen interesante. Në Redis, seancat ruhen - ne nuk mund ta marrim thjesht dhe ta varrosim. Sepse kjo nuk do të jetë shumë e mirë: të gjithë përdoruesit do të dalin jashtë, shportat e tyre do të zbrazen, etj. Njerëzit do të detyrohen të rifusin emrin e përdoruesit dhe fjalëkalimin e tyre dhe shumë njerëz mund të shkëputen dhe të mos e përfundojnë blerjen. Përsëri, konvertimet do të bien. Nga ana tjetër, Redis është drejtpërdrejt i azhurnuar, me përdoruesit e fundit të regjistruar ndoshta nuk nevojiten as. Dhe një kompromis i mirë është të marrësh Redis dhe ta rivendosësh atë nga një kopje rezervë e djeshme, ose, nëse e bën çdo orë, nga një orë më parë. Për fat të mirë, rikthimi i tij nga një kopje rezervë nënkupton kopjimin e një skedari. Dhe historia më interesante është Elasticsearch. Kush e ka marrë ndonjëherë përsëritjen e MySQL? Kush e ka zgjedhur ndonjëherë përsëritjen e Elasticsearch? Dhe për kë funksionoi normalisht më pas? Ajo që dua të them është se ne shohim një entitet të caktuar në sistemin tonë. Duket se është e dobishme - por është komplekse.
Kompleks në kuptimin që kolegët tanë inxhinierë nuk kanë përvojë pune me të. Ose ka një përvojë negative. Ose e kuptojmë se kjo është ende një teknologji mjaft e re me nuanca ose vrazhdësi. Ne mendojmë... Dreq, llastiku është gjithashtu i shëndetshëm, gjithashtu kërkon shumë kohë për ta restauruar nga një rezervë, çfarë duhet të bëj? Ne e kuptojmë se elastiku në rastin tonë përdoret për kërkim. Si shitet dyqani ynë online? Shkojmë te tregtarët dhe pyesim se nga vijnë njerëzit. Ata përgjigjen: "90% nga Yandex Market vijnë direkt në kartën e produktit." Dhe ose ata e blejnë atë ose nuk e bëjnë. Prandaj, kërkimi është i nevojshëm nga 10% e përdoruesve. Dhe duke ruajtur përsëritjen elastike, veçanërisht midis qendrave të ndryshme të të dhënave në zona të ndryshme, ka vërtet shumë nuanca. Cila dalje? Ne marrim elastik nga një faqe e rezervuar dhe nuk bëjmë asgjë me të. Nëse çështja zvarritet, ndoshta do ta ngremë një ditë, por kjo nuk është e sigurt. Në fakt, përfundimi është i njëjtë, plus ose minus: ne, përsëri, nuk rezervojmë shërbime që nuk ndikojnë në para. Për ta mbajtur diagramin më të thjeshtë.
Shembulli numër katër, edhe më i vështirë
Integrator: shitja e luleve, thirrja e një taksie, shitja e mallrave, në përgjithësi, çdo gjë. Një gjë serioze që funksionon 24/7 për një numër të madh përdoruesish. Me një pirg interesant të plotë, ku ka baza interesante, zgjidhje, ngarkesë të lartë dhe më e rëndësishmja, dhemb të shtrihesh për më shumë se 5 minuta. Jo vetëm dhe jo aq shumë sepse njerëzit nuk do të blejnë, por sepse njerëzit do të shohin që kjo gjë nuk funksionon, ata do të mërziten dhe mund të mos kthehen fare.
NE RREGULL. Pesë minuta. Çfarë do të bëjmë për këtë? Në këtë rast, ne, si të rriturit, i përdorim të gjitha paratë për të ndërtuar një faqe të vërtetë rezervë, me përsëritje të gjithçkaje, dhe ndoshta edhe për të automatizuar kalimin në këtë faqe sa më shumë që të jetë e mundur. Dhe përveç kësaj, duhet të mbani mend të bëni një gjë të rëndësishme: në fakt, shkruani rregulloret e ndërrimit. Rregulloret, edhe nëse keni gjithçka të automatizuar, mund të jenë shumë të thjeshta. Nga seria "ekzekutoni një skenar të tillë dhe të tillë", "kliko një kuti kontrolli në rrugën 53" dhe kështu me radhë - por kjo duhet të jetë një lloj liste e saktë veprimesh.
Dhe gjithçka duket e qartë. Ndërrimi i replikimit është një detyrë e parëndësishme, ose do të ndërrohet vetë. Rishkrimi i një emri domaini në DNS është nga e njëjta seri. Problemi është se kur një projekt i tillë dështon, fillon paniku, madje edhe administratorët më të fortë dhe mjekërr mund të jenë të ndjeshëm ndaj tij. Pa udhëzime të qarta "hap terminalin, eja këtu, adresa e serverit tonë është ende e tillë", është e vështirë të përmbushësh kufirin kohor 5-minutësh të caktuar për ringjalljen. Epo, plus, kur përdorim këto rregullore, është e lehtë të regjistrojmë disa ndryshime në infrastrukturë, për shembull, dhe të ndryshojmë rregulloret në përputhje me rrethanat.
Epo, nëse sistemi i rezervimit është shumë kompleks dhe në një moment kemi bërë një gabim, atëherë mund të shkatërrojmë faqen tonë rezervë, dhe përveç kësaj t'i kthejmë të dhënat në një kungull në të dy faqet - kjo do të jetë plotësisht e trishtueshme.
Shembulli numër pesë, komplet hardcore
Një shërbim ndërkombëtar me qindra miliona përdorues në mbarë botën. Të gjitha zonat kohore që ekzistojnë, ngarkesë e lartë me shpejtësi maksimale, nuk mund të shtrihesh fare. Një minutë - dhe do të jetë e trishtuar. Çfarë duhet bërë? Rezervoni sërish sipas programit të plotë. Ne bëmë gjithçka për të cilën fola në shembullin e mëparshëm, dhe pak më shumë. Një botë ideale dhe infrastruktura jonë është sipas të gjitha koncepteve të IaaC. Kjo do të thotë, gjithçka është në gjendje, dhe ju thjesht shtypni butonin.
Çfarë mungon? Një - ushtrime. Është e pamundur pa to. Duket se gjithçka është perfekte me ne, ne përgjithësisht gjithçka e kemi nën kontroll. Ne shtypim butonin, gjithçka ndodh. Edhe nëse është kështu - dhe ne e kuptojmë se nuk ndodh kështu - sistemi ynë ndërvepron me disa sisteme të tjera. Për shembull, kjo është dns nga rruga 53, ruajtja s3, integrimi me disa api. Ne nuk do të jemi në gjendje të parashikojmë gjithçka në këtë eksperiment spekulativ. Dhe derisa të tërheqim çelësin, nuk do ta dimë nëse do të funksionojë apo jo.
Kjo është ndoshta e gjitha. Mos u bëni dembel ose mos e teproni. Dhe kohëzgjatja mund të jetë me ju!
Burimi: www.habr.com