In die somer neem beide aankoopaktiwiteite en die intensiteit van veranderinge in die infrastruktuur van webprojekte tradisioneel af, vertel Captain Evidence vir ons. Net omdat selfs IT-mense soms met vakansie gaan. En CTO ook. Hoe moeiliker is dit vir diegene wat in die amp bly, maar dit gaan nie nou daaroor nie: miskien is dit hoekom die somer die beste tyd is om jou tyd te neem om die bestaande besprekingskema te oorweeg en 'n plan te maak om dit te verbeter. En hierin sal jy baat vind by die ervaring van Yegor Andreev waaroor hy op die konferensie gepraat het .
Wanneer jy reservaatpersele bou, wanneer jy bespreek, is daar verskeie strikke waarin jy kan trap. En jy kan hulle nie regtig slaan nie. En ruïneer ons in dit alles, soos in baie ander dinge, perfeksionisme en ... luiheid. Ons probeer alles-alles-alles perfek maak, maar jy hoef dit nie perfek te doen nie! Jy moet net sekere dinge doen, maar doen dit reg, bring hulle tot die einde sodat hulle normaal werk.
Failover is nie een of ander pret, prettige "laat dit wees" ding nie; dit is 'n ding wat presies een ding moet doen - verminder stilstand sodat die diens, die maatskappy, minder geld verloor. En in alle besprekingsmetodes stel ek voor om in die volgende konteks te dink: waar is die geld?
Eerste lokval: wanneer ons groot betroubare stelsels bou en oortolligheid doen, verminder ons die aantal ongelukke. Dit is 'n verskriklike dwaling. Wanneer ons oortolligheid doen, sal ons waarskynlik die aantal ongelukke verhoog. En as ons alles reg doen, sal ons stilstandtyd gesamentlik verminder. Daar sal meer ongelukke wees, maar dit sal teen 'n laer koste plaasvind. Wat is immers 'n bespreking? is 'n komplikasie van die stelsel. Enige komplikasie is sleg: ons het meer skroewe, meer ratte, in 'n woord, meer elemente - en dus 'n groter kans op breek. En hulle breek regtig. En hulle sal meer dikwels breek. 'n Eenvoudige voorbeeld: kom ons sê ons het 'n webwerf, met PHP, MySQL. En dit moet dringend gereserveer word.
Shtosh (c) Ons neem die tweede terrein, bou 'n identiese stelsel ... Die kompleksiteit word twee keer so groot - ons het twee entiteite. En ons rol ook oor 'n sekere logika vir die oordrag van data van een webwerf na 'n ander van bo af - dit wil sê, data replikasie, kopiëring van statika, ensovoorts. Dus, die logika van replikasie is gewoonlik baie kompleks, en daarom kan die totale kompleksiteit van die stelsel nie 2, maar 3, 5, 10 keer meer wees nie.
Tweede lokval: wanneer ons werklik groot komplekse stelsels bou, fantaseer ons wat ons op die ou end wil kry. Voila: ons wil 'n superbetroubare stelsel hê wat sonder enige stilstand werk, binne 'n halwe sekonde (of beter, onmiddellik) oorskakel en drome begin bewaarheid. Maar ook hier is daar 'n nuanse: hoe korter die verlangde skakeltyd, hoe meer kompleks word die stelsellogika. Hoe moeiliker ons het om hierdie logika te maak, hoe meer dikwels sal die stelsel breek. En jy kan in 'n baie onaangename situasie beland: ons probeer ons bes om stilstand te verminder, maar in werklikheid kompliseer ons alles, en wanneer iets verkeerd loop, sal die stilstand uiteindelik langer wees. Hier betrap jy jouself dikwels dat jy dink: hier ... dit sal beter wees om nie te bespreek nie. Dit sal beter wees as dit alleen werk en met 'n duidelike stilstand.
Hoe kan jy dit beveg? Ons moet ophou om vir onsself te lieg, ophou om onsself te vlei dat ons nou 'n ruimteskip gaan bou, maar voldoende verstaan hoe lank die projek kan lê. En onder hierdie maksimum tyd sal ons kies watter metodes ons die betroubaarheid van ons stelsel sal verhoog.
Dis tyd vir “stories van f” ... uit die lewe, natuurlik.
Voorbeeld nommer een
Stel jou 'n besigheidskaartjie-webwerf van die pyprolleraanleg nr. 1 van die stad N voor. Daar staan in groot letters - PYP-ROLLENDE Aanleg nr. 1. 'n Bietjie laer is die slagspreuk: "Ons pype is die rondste pype in N." En onderaan is die HUB se telefoonnommer en sy naam. Ons verstaan dat jy moet bespreek - dit is 'n baie belangrike ding! Kom ons begin om te verstaan waaruit dit bestaan. Html-statika - dit wil sê 'n paar foto's waar die generaal eintlik aan tafel in die badhuis saam met sy maat 'n volgende transaksie bespreek. Ons begin dink aan stilstand. Dit kom by my op: jy moet vyf minute lank daar lê, nie meer nie. En dan is die vraag: hoeveel verkope vanaf hierdie webwerf van ons was daar oor die algemeen? Hoeveel? Wat beteken "nul"? En dit beteken: want al vier transaksies die afgelope jaar het die generaal aan dieselfde tafel gedoen, met dieselfde mense saam met wie hulle na die badhuis gaan sit aan tafel. En ons verstaan dat selfs as die werf vir 'n dag lê, daar niks verskriklik sal wees nie.
Op grond van die insette is daar 'n dag om hierdie storie te opper. Ons begin dink aan die afdankingskema. En ons kies die mees ideale skema vir oortolligheid vir hierdie voorbeeld: ons gebruik nie oortolligheid nie. Hierdie hele ding word deur enige admin in 'n halfuur geopper met rookpouses. Stel 'n webbediener op, plaas lêers - dit is dit. Dit sal werk. Daar is niks om na te kyk nie, niks om spesiale aandag aan te gee nie. Dit wil sê, die gevolgtrekking uit voorbeeld nommer een is redelik voor die hand liggend: dienste wat nie gerugsteun hoef te word nie, hoef nie gerugsteun te word nie.
Voorbeeld nommer twee
Maatskappyblog: spesiaal opgeleide mense skryf nuus daar, so ons het aan so en so 'n uitstalling deelgeneem, maar ons het nog 'n nuwe produk vrygestel, ens. Kom ons sê dit is standaard PHP met WordPress, 'n klein databasis en 'n bietjie staties. Natuurlik kom dit weer by jou op dat jy in geen geval moet gaan lê nie - "nie meer as vyf minute nie!", Dis al. Maar kom ons dink verder. Wat doen hierdie blog? Hulle kom daar van Yandex, van Google vir sommige versoeke, vir organiese produkte. Groot. Het dit iets met verkope te doen? Insig: nie regtig nie. Advertensieverkeer gaan na die hoofwerf, wat op 'n ander masjien is. Kom ons begin dink aan die blog se besprekingskema. Op 'n goeie manier moet dit binne 'n paar uur grootgemaak word, en dit sal lekker wees om hiervoor voor te berei. Dit sal redelik wees om 'n masjien in 'n ander datasentrum te neem, die omgewing daarop te rol, dit wil sê 'n webbediener, PHP, WordPress, MySQL, en dit gedemp te laat. Op die oomblik wanneer ons verstaan dat alles stukkend is, moet ons twee dinge doen - rol die mysql-storting uit na 50 meter, dit sal binne 'n minuut soontoe vlieg, en 'n sekere aantal foto's van die rugsteun daar uitrol. Dis ook daar nie God weet hoeveel nie. So oor 'n halfuur rys die hele ding. Enige herhalings, of God vergewe, outomatiese failover'a. Gevolgtrekking: wat ons vinnig uit 'n rugsteun kan uitrol, is nie nodig om te bespreek nie.
Voorbeeld nommer drie, moeiliker
Aanlyn winkel. PhP met oop hart is effens geliasseer, mysql met 'n soliede basis. Nogal baie staties (die aanlyn winkel het immers pragtige HD-prente en dit alles), Redis vir die sessie en Elasticsearch vir soek. Ons begin dink aan stilstand. En hier is dit natuurlik duidelik dat 'n aanlyn winkel nie vir 'n dag pynloos kan lieg nie. Hoe langer dit lê, hoe meer geld verloor ons immers. Dit is die moeite werd om te versnel. Hoeveel? Ek dink as ons vir 'n uur lê, sal niemand mal word nie. Ja, ons sal iets verloor, maar as ons ywerig begin raak, sal dit net erger word. Ons bepaal die skema van ledige tyd wat per uur toegelaat word.
Hoe kan dit bespreek word? 'n Motor is in elk geval nodig: 'n uur se tyd is nogal 'n bietjie. Mysql: replikasie is reeds hier nodig, lewendige replikasie, want oor 'n uur sal 100 GB heel waarskynlik nie by die storting ingesluit word nie. Statika, prente: weer, oor 'n uur het 500 GB dalk nie tyd om aan te sluit nie. Daarom is dit beter om die prente dadelik te kopieer. Redis: dit is waar dinge interessant raak. Sessies lê in Redis - ons kan dit nie net vat en begrawe nie. Want dit sal nie baie goed wees nie: alle gebruikers sal afgemeld word, die mandjies sal leeggemaak word, ensovoorts. Mense sal gedwing word om hul gebruikersnaam en wagwoord weer in te voer, en baie mense kan wegbreek en nie die aankoop voltooi nie. Weereens sal die omskakeling daal. Aan die ander kant is Redis op datum, met die laaste aangemelde gebruikers wat waarskynlik ook nie nodig is nie. En 'n goeie kompromie is om Redis te neem en dit van 'n rugsteun te herstel, gister, of, as jy dit elke uur doen, 'n uur gelede. Gelukkig is om dit vanaf 'n rugsteun te herstel, om een lêer te kopieer. En die interessantste storie is Elasticsearch. Wie het ooit MySQL-replikasie ter sprake gebring? Het iemand al ooit Elasticsearch-replikasie opgetel? En vir wie het sy normaal gewerk? Wat ek bedoel: ons sien 'n sekere entiteit in ons stelsel. Dit is nogal nuttig, maar dit is ingewikkeld.
Moeilik in die sin dat ons mede-ingenieurs geen ondervinding daarmee het nie. Of het 'n slegte ervaring. Of ons verstaan dit terwyl dit 'n redelik nuwe tegnologie met nuanses of vogtigheid is. Ons dink ... Damn, rek is ook gesond, dit neem ook lank om dit van rugsteun af te herstel, wat moet ek doen? Ons verstaan dat rek in ons geval gebruik word vir soektog. Hoe verkoop ons aanlynwinkel? Ons gaan na bemarkers en vra waar mense vandaan kom. Hulle antwoord: "90% van Yandex Market kom direk na die produkkaart." En of hulle dit koop of nie. Daarom het 10% van gebruikers soektog nodig. En om elastic'a replikasie te hou, veral tussen verskillende datasentrums in verskillende sones, is daar regtig baie nuanses. Watter uitgang? Ons neem rek op 'n gereserveerde werf en doen niks daarmee nie. As die saak sloer, kan ons dit dalk een of ander tyd later opper, maar dit is nie seker nie. Eintlik is die gevolgtrekking plus of minus dieselfde: dienste wat nie geld raak nie, reserveer ons weer nie. Om die stroombaan eenvoudig te hou.
Voorbeeld nommer vier, selfs moeiliker
Integreerder: blomme verkoop, 'n taxi bel, goedere verkoop, in die algemeen, enigiets. 'n Ernstige ding wat 24/7 werk vir 'n groot aantal gebruikers. Met 'n volwaardige interessante stapel, waar daar interessante basisse is, maak oplossings, hoë werklading, en die belangrikste, lê vir meer as 5 minute hom seer. Nie net en nie soseer omdat mense nie sal koop nie, maar omdat mense sal sien dat hierdie ding nie werk nie, sal hulle ontsteld wees en dalk glad nie 'n tweede keer kom nie.
OK. Vyf minute. Wat gaan ons hiermee doen? In hierdie geval, op 'n volwasse manier, bou ons 'n regte rugsteunwerf met al die geld, met replikasie van alles en alles, en miskien selfs outomatiseer die maksimum oorskakeling na hierdie webwerf. En bykomend tot hierdie, moet jy onthou om een belangrike ding te doen: om die waarheid te sê, skryf die skakelregulasies. Die regulasie, selfs al is alles en alles vir jou geoutomatiseer, kan baie eenvoudig wees. Van die reeks "hardloop so en so 'n moontlike script", "druk so en so 'n merkblokkie in roete 53", ensovoorts - maar dit moet 'n soort presiese lys van aksies wees.
En alles blyk duidelik te wees. Om te skakel na replikasie is 'n onbenullige taak, of dit sal self verander. Herskryf die domeinnaam in dns - uit dieselfde reeks. Die probleem is dat wanneer so 'n projek val, paniek intree, en selfs die sterkste, bebaarde admins kan daaraan onderwerp word. Sonder 'n duidelike instruksie "maak die terminale oop, kom hier, die adres van ons bediener is steeds so" is die tydperk van 5 minute wat vir resussitasie toegeken is moeilik om te verduur. Wel, plus, wanneer ons hierdie regulasie gebruik, is dit maklik om byvoorbeeld 'n paar veranderinge in die infrastruktuur reg te stel en die regulasie dienooreenkomstig te verander.
Wel, as die besprekingstelsel baie ingewikkeld is en ons het op 'n stadium 'n fout gemaak, dan kan ons ons rugsteunwerf neerlê, en boonop die data op beide werwe in 'n pampoen verander - dit sal baie hartseer wees.
Voorbeeld nommer vyf volle hardcore
'n Internasionale diens met honderde miljoene gebruikers wêreldwyd. Al die tydsones wat bestaan, hoë las teen maksimum spoed, jy kan glad nie gaan lê nie. ’n Minuut – en dit sal hartseer wees. Wat om te doen? Bespreek weer ten volle. Ons het alles gedoen wat in die vorige voorbeeld genoem is, en 'n bietjie meer. 'n Ideale wêreld, en ons infrastruktuur is, volgens al die konsepte van IaaC devops. Dit wil sê, alles is oor die algemeen in git, en druk net die knoppie.
Wat ontbreek? Een is onderrig. Jy kan nie sonder hulle nie. Alles blyk perfek te wees, ons het alles onder beheer. Ons druk die knoppie, alles gebeur. Selfs al is dit waar - en ons verstaan dat dit nie die geval is nie - is ons stelsel in wisselwerking met sommige ander stelsels. Byvoorbeeld, dit is dns vanaf roete 53, s3-berging, integrasie met 'n paar API. Ons kan nie alles in hierdie spekulatiewe eksperiment voorsien nie. En totdat ons regtig die skakelaar trek, sal ons nie weet of dit sal werk of nie.
Dis seker al. Moenie lui wees nie en moenie dit oordoen nie. En mag optyd met jou wees!
Bron: will.com