Failover: fullkomnunarárátta og... leti eru að rústa okkur

Á sumrin minnka jafnan bæði innkaupavirkni og styrkleiki breytinga á innviðum vefverkefna, segir Captain Obvious okkur. Einfaldlega vegna þess að jafnvel upplýsingatæknisérfræðingar fara stundum í frí. Og CTO líka. Það er þeim mun erfiðara fyrir þá sem sitja áfram, en það er ekki málið núna: kannski er sumarið besti tíminn til að hugsa hægt um núverandi fyrirvarakerfi og gera áætlun til að bæta það. Og reynslu Yegor Andreev frá Admin Division, sem hann talaði um á ráðstefnunni Spennudagur.

Það eru nokkrir gildrur sem þú getur fallið í þegar þú byggir öryggisafrit. Og það er algjörlega ómögulegt að festast í þeim. Og það sem eyðileggur okkur í þessu öllu saman eins og mörgu öðru er fullkomnunarárátta og... leti. Við erum að reyna að gera allt, allt, allt fullkomlega, en við þurfum ekki að gera það fullkomlega! Þú þarft aðeins að gera ákveðna hluti, en gera þá rétt, klára þá svo þeir virki rétt.

Failover er ekki einhvers konar skemmtilegur, skemmtilegur hlutur; þetta er hlutur sem ætti að gera nákvæmlega eitt - draga úr niður í miðbæ þannig að þjónustan, fyrirtækið, tapi minna fé. Og í öllum bókunaraðferðum legg ég til að hugsa í eftirfarandi samhengi: hvar eru peningarnir?

Fyrsta gildran: Þegar við byggjum upp stór, áreiðanleg kerfi og tökum þátt í offramboði fækkum við slysum. Þetta er hræðilegur misskilningur. Þegar við tökum þátt í uppsögnum er líklegt að slysum fjölgi. Og ef við gerum allt rétt, þá munum við sameiginlega draga úr stöðvunartíma. Slysin verða fleiri en þau verða með lægri kostnaði. Hvað er fyrirvari? - þetta er flækja kerfisins. Allir flækjur eru slæmar: við höfum fleiri tannhjól, fleiri gír, í einu orði, fleiri þætti - og þar af leiðandi meiri líkur á bilun. Og þeir munu virkilega brotna. Og þeir munu brotna oftar. Einfalt dæmi: segjum að við höfum vefsíðu með PHP og MySQL. Og það þarf brýn að taka frá.

Shtosh (c) Við tökum seinni síðuna, byggjum eins kerfi... Flækjustigið verður tvöfalt meira - við höfum tvær einingar. Við útfærum líka ákveðna rökfræði til að flytja gögn frá einni síðu til annarrar - það er að afrita gögn, afrita kyrrstæð gögn og svo framvegis. Svo, afritunarrökfræðin er venjulega mjög flókin og því getur heildarflækjustig kerfisins ekki verið 2, heldur 3, 5, 10 sinnum meiri.

Önnur gildra: Þegar við byggjum mjög stór flókin kerfi, fantasera við um hvað við viljum fá á endanum. Voila: við viljum fá ofuráreiðanlegt kerfi sem virkar án þess að vera í biðtíma, skiptir yfir á hálfri sekúndu (eða betra, samstundis) og við byrjum að láta drauma rætast. En það er líka blæbrigði hér: því styttri sem æskilegur skiptitími er, því flóknari verður kerfisrökfræðin. Því flóknari sem við þurfum að gera þessa rökfræði, því oftar mun kerfið bila. Og þú getur lent í mjög óþægilegum aðstæðum: við erum að reyna af öllu afli að draga úr stöðvunartíma en í raun gerum við allt flóknara og þegar eitthvað fer úrskeiðis mun tíminn á endanum lengri. Hér lendir maður oft í því að hugsa: jæja... það væri betra að panta ekki. Það væri betra ef það virkaði eitt og sér og með skiljanlegum niðritíma.

Hvernig geturðu barist við þetta? Við þurfum að hætta að ljúga að okkur sjálfum, hætta að smjaðra um að við ætlum að byggja geimskip hér núna, en skilja nægilega hversu lengi verkefnið getur legið. Og fyrir þennan hámarkstíma munum við velja hvaða aðferðir við munum nota til að auka áreiðanleika kerfisins okkar.

Það er kominn tími á "sögur frá w"... úr lífinu, auðvitað.

Dæmi númer eitt

Ímyndaðu þér nafnspjaldavef fyrir Pipe Rolling Plant No. 1 í borginni N. Þar stendur með stórum stöfum - Pipe Rolling Plant No. Rétt fyrir neðan er slagorðið: „Pípurnar okkar eru kringlóttustu rörin í N.“ Og hér að neðan er símanúmer forstjórans og nafn hans. Við skiljum að þú þarft að panta - þetta er mjög mikilvægt! Við skulum byrja að reikna út hvað það samanstendur af. Html-statics - það er að segja nokkrar myndir þar sem framkvæmdastjórinn er í raun að ræða einhvers konar næsta samning við borðið í baðstofunni við félaga sinn. Við byrjum að hugsa um niðurtíma. Það kemur upp í hugann: þú þarft að liggja þarna í fimm mínútur, ekki meira. Og þá vaknar spurningin: hversu miklar sölur voru almennt séð frá þessari síðu okkar? Hversu mikið - hversu mikið? Hvað þýðir "núll"? Og það þýðir: vegna þess að hershöfðinginn gerði öll fjögur viðskiptin á síðasta ári við sama borð, með sama fólkinu og þeir fara í baðstofuna og setjast við borðið. Og við skiljum að jafnvel þó að síðan standi í einn dag mun ekkert hræðilegt gerast.

Byggt á kynningarupplýsingunum er dagur til að vekja athygli á þessari sögu. Við skulum byrja að hugsa um uppsagnarkerfi. Og við veljum besta uppsagnarkerfið fyrir þetta dæmi: við notum ekki offramboð. Þetta allt getur hvaða stjórnandi sem er hægt að hækka á hálftíma með reykhléum. Settu upp vefþjón, bættu við skrám - það er það. Það mun virka. Þú þarft ekki að fylgjast með neinu, þú þarft ekki að fylgjast sérstaklega með neinu. Það er að segja, niðurstaðan úr dæmi númer eitt er alveg augljós: þjónustu sem ekki þarf að panta þarf ekki að panta.

Dæmi númer tvö

Fyrirtækjablogg: þar skrifar sérþjálfað fólk fréttir, við tókum þátt í svona og svona sýningu en gáfum út aðra nýja vöru o.s.frv. Segjum að þetta sé staðlað PHP með WordPress, litlum gagnagrunni og smá kyrrstöðu. Auðvitað dettur mér aftur í hug að þú ættir ekki undir neinum kringumstæðum að leggjast niður - "ekki meira en fimm mínútur!" Það er allt og sumt. En hugsum lengra. Hvað gerir þetta blogg? Fólk kemur þangað frá Yandex, frá Google byggt á nokkrum fyrirspurnum, lífrænt. Frábært. Hefur sala eitthvað með það að gera? Skírdagur: ekki í raun. Auglýsingaumferð fer á aðalsíðuna, sem er á annarri vél. Við skulum byrja að hugsa um bókunarkerfi. Á góðan hátt þarf að hækka hann á nokkrum klukkutímum og það væri gaman að undirbúa þetta. Eðlilegt væri að taka vél úr annarri gagnaver, rúlla umhverfinu inn á hana, það er vefþjón, PHP, WordPress, MySQL og skilja hana eftir. Í augnablikinu þegar við skiljum að allt er bilað, þurfum við að gera tvennt - rúlla út mysql dumpið 50 metra, það mun fljúga þangað eftir eina mínútu og rúlla út ákveðinn fjölda mynda úr öryggisafritinu þar. Þetta er heldur ekki til staðar þar sem guð má vita hversu lengi. Þannig hækkar allt á hálftíma. Engin endurtekning, eða Guð fyrirgefi mér, sjálfvirk bilun. Ályktun: það sem við getum fljótt rúllað út úr öryggisafriti þarf ekki að taka öryggisafrit.

Dæmi númer þrjú, flóknara

Net verslun. PhP með opnu hjarta er svolítið fínstillt, mysql með traustum grunni. Frekar mikið af static (enda er netverslunin með fallegar HD myndir og allt það), Redis fyrir sessuna og Elasticsearch fyrir leit. Við byrjum að hugsa um niðurtíma. Og hér er auðvitað augljóst að netverslun getur ekki legið sársaukalaust í einn dag. Eftir allt saman, því lengur sem það liggur, því meiri peninga tapum við. Það er þess virði að flýta sér. Hversu mikið? Ég held að ef við leggjumst niður í klukkutíma þá verði enginn brjálaður. Já, við munum missa eitthvað, en ef við förum að leggja hart að okkur þá verður það bara verra. Við skilgreinum kerfi um leyfilegan niðurtíma á klukkustund.

Hvernig er hægt að áskilja allt þetta? Þú þarft bíl í öllum tilvikum: klukkutími er frekar lítill. Mysql: hér þurfum við nú þegar afritun, lifandi afritun, því eftir klukkutíma verður 100 GB líklegast ekki bætt við sorphauginn. Tölfræði, myndir: aftur, eftir klukkutíma gæti 500 GB ekki tíma til að bæta við. Þess vegna er betra að afrita myndirnar strax. Redis: þetta er þar sem hlutirnir verða áhugaverðir. Í Redis eru lotur geymdar - við getum ekki bara tekið það og grafið það. Vegna þess að þetta verður ekki mjög gott: allir notendur verða skráðir út, körfurnar þeirra verða tæmdar o.s.frv. Fólk mun neyðast til að slá inn notandanafn og lykilorð aftur og margir geta brotið af sér og ekki gengið frá kaupunum. Aftur munu viðskipti lækka. Á hinn bóginn er Redis beinlínis uppfærð, þar sem sennilega er ekki þörf á síðustu innskráðum notendum heldur. Og góð málamiðlun er að taka Redis og endurheimta það úr öryggisafriti frá því í gær, eða, ef þú gerir það á klukkutíma fresti, fyrir klukkutíma síðan. Sem betur fer þýðir það að endurheimta það úr öryggisafriti að afrita eina skrá. Og áhugaverðasta sagan er Elasticsearch. Hver hefur einhvern tíma tekið upp MySQL afritun? Hver hefur einhvern tíma tekið upp Elasticsearch afritun? Og fyrir hvern virkaði það venjulega eftir? Það sem ég á við er að við sjáum ákveðna heild í kerfinu okkar. Það virðist vera gagnlegt - en það er flókið.
Flókið í þeim skilningi að samverkfræðingar okkar hafa enga reynslu af því að vinna með það. Eða það er neikvæð reynsla. Eða við skiljum að þetta er enn frekar ný tækni með blæbrigðum eða hráleika. Við hugsum... Fjandinn, teygja er líka holl, það tekur líka langan tíma að endurheimta það úr öryggisafriti, hvað á ég að gera? Okkur skilst að teygja í okkar tilfelli er notuð við leit. Hvernig selur netverslun okkar? Við förum til markaðsfólks og spyrjum hvaðan fólk komi. Þeir svara: "90% frá Yandex Market koma beint á vörukortið." Og annað hvort kaupa þeir það eða ekki. Þess vegna þurfa 10% notenda að leita. Og að halda teygjanlegri afritun, sérstaklega á milli mismunandi gagnavera á mismunandi svæðum, hefur í raun fullt af blæbrigðum. Hvaða útgangur? Við tökum teygju af frátekinni síðu og gerum ekkert með hana. Ef málið dregst á langinn munum við væntanlega taka það upp einhvern tímann, en það er ekki víst. Reyndar er niðurstaðan sú sama, plús eða mínus: við, aftur, pantum ekki þjónustu sem hefur ekki áhrif á peninga. Til að gera skýringarmyndina einfaldari.

Dæmi númer fjögur, enn erfiðara

Samþættari: selja blóm, hringja í leigubíl, selja vörur, almennt, hvað sem er. Alvarlegur hlutur sem virkar 24/7 fyrir mikinn fjölda notenda. Með fullgildum áhugaverðum stafla, þar sem eru áhugaverðar undirstöður, lausnir, mikið álag, og síðast en ekki síst, það er sárt að leggjast niður í meira en 5 mínútur. Ekki aðeins og ekki svo mikið vegna þess að fólk kaupir ekki, heldur vegna þess að fólk mun sjá að þetta virkar ekki, það verður í uppnámi og kemur kannski ekki aftur.

Allt í lagi. Fimm mínútur. Hvað ætlum við að gera í þessu? Í þessu tilfelli notum við, eins og fullorðnir, allan peninginn til að byggja upp alvöru öryggisafrit, með afritun alls, og ef til vill gera sjálfvirk skiptingu á þessa síðu eins mikið og mögulegt er. Og til viðbótar við þetta þarftu að muna að gera eitt mikilvægt atriði: skrifa í raun og veru skiptareglurnar. Reglurnar, jafnvel þótt þú hafir allt sjálfvirkt, getur verið mjög einfalt. Úr seríunni "keyrðu svona og svo ansible script", "smelltu á svona og svona gátreit í leið 53" og svo framvegis - en þetta hlýtur að vera einhvers konar nákvæmur listi yfir aðgerðir.

Og allt virðist ljóst. Að skipta um afritun er léttvægt verkefni, eða það mun skipta um sjálft sig. Að endurskrifa lén í DNS er úr sömu röð. Vandamálið er að þegar slíkt verkefni mistekst byrjar læti og jafnvel sterkustu, skeggjaðir stjórnendur geta verið viðkvæmir fyrir því. Án skýrra leiðbeininga „opnaðu flugstöðina, komdu hingað, heimilisfang netþjónsins okkar er enn svona,“ er erfitt að uppfylla 5 mínútna tímamörkin sem úthlutað er fyrir endurlífgun. Jæja, auk þess, þegar við notum þessar reglugerðir, er auðvelt að skrá nokkrar breytingar á innviðum, til dæmis, og breyta reglugerðinni í samræmi við það.
Jæja, ef bókunarkerfið er mjög flókið og á einhverjum tímapunkti gerðum við mistök, þá getum við eyðilagt öryggisafritið okkar, og að auki breytt gögnunum í grasker á báðum stöðum - þetta verður algjörlega sorglegt.

Dæmi númer fimm, algjör harðkjarna

Alþjóðleg þjónusta með hundruð milljóna notenda um allan heim. Öll tímabeltin sem eru til staðar, mikið álag á hámarkshraða, þú getur alls ekki lagt þig. Ein mínúta - og það verður sorglegt. Hvað skal gera? Pantaðu aftur, samkvæmt fullri dagskrá. Við gerðum allt sem ég talaði um í fyrra dæminu og aðeins meira. Tilvalinn heimur, og innviðir okkar eru í samræmi við allar hugmyndir IaaC devops. Það er, allt er í git, og þú ýtir bara á takkann.

Hvað vantar? Einn - æfingar. Það er ómögulegt án þeirra. Það virðist sem allt sé fullkomið hjá okkur, við höfum almennt allt undir stjórn. Við ýtum á takkann, allt að gerast. Jafnvel þótt þetta sé svo - og við skiljum að það gerist ekki með þessum hætti - hefur kerfið okkar samskipti við önnur kerfi. Til dæmis er þetta dns frá leið 53, s3 geymslu, samþætting við eitthvað api. Við munum ekki geta séð allt fyrir í þessari spákaupmennsku. Og þar til við tökum í raun rofann, munum við ekki vita hvort það mun virka eða ekki.

Það er líklega allt. Ekki vera latur eða ofleika það. Og gæti spenntur verið með þér!

Heimild: www.habr.com