PÄ sommaren minskar traditionellt bÄde köpbeteendet och intensiteten i förÀndringar av infrastruktur för webbprojekt, sÀger Kapten Upplysning. För att Àven IT-proffs gÄr pÄ semester dÄ och dÄ. Och CTO:n ocksÄ. Det gör det svÄrare för dem som stannar kvar pÄ posten, men det Àr inte poÀngen nu: kanske Àr det just dÀrför sommaren Àr den bÀsta tiden för att i lugn och ro övervÀga den befintliga reservplanen och skapa en plan för dess förbÀttring. Och i detta kan erfarenheten frÄn Egor Andreev vara till nytta frÄn , som han berÀttade om pÄ konferensen .
NÀr vi bygger reservanlÀggningar och hanterar reservtagning finns det flera fÀllor som man kan hamna i. Att hamna i dem Àr helt oacceptabelt. Och det som förstör oss hÀr, liksom i mycket annat, Àr perfektionism och⊠lathet. Vi försöker göra allt perfekt, men vi behöver inte göra allt perfekt! Vi mÄste bara göra vissa saker pÄ rÀtt sÀtt, genomföra dem fullt ut sÄ att de fungerar ordentligt.
Failover Ă€r inte bara nĂ„got roligt som Ă€r bra att ha; det Ă€r en funktion som ska göra precis en sak â minska stillestĂ„ndstiden, sĂ„ att tjĂ€nsten, företaget, förlorar mindre pengar. Och i alla metoder för reservtĂ€ckning föreslĂ„r jag att tĂ€nka i följande kontext: var ligger pengarna?
Den första fĂ€llan: nĂ€r vi bygger stora pĂ„litliga system och hanterar reservtagning minskar vi antalet avbrott. Detta Ă€r en stor missuppfattning. NĂ€r vi hanterar reservtagning ökar vi sannolikt antalet avbrott. Och om vi gör allt rĂ€tt sĂ„ kommer vi sammanfattningsvis att minska stillestĂ„ndstiden. Det kommer att bli fler avbrott, men de kommer att ske med mindre kostnader. Vad Ă€r reservtagning? â det Ă€r en komplicering av systemet. All komplicering Ă€r dĂ„ligt: vi fĂ„r fler skruvar, fler kuggdrev, helt enkelt fler komponenter â och dĂ€rmed en högre chans för fel. Och de kommer faktiskt att gĂ„ sönder. Och de kommer att gĂ„ sönder oftare. Ett enkelt exempel: sĂ€g att vi har en viss webbplats, med PHP, MySQL. Och den mĂ„ste snabbt reserveras.
SĂ„, vi tar en andra plattform, bygger ett identiskt system... SvĂ„righetsgraden blir dubbelt sĂ„ stor â vi har tvĂ„ enheter. Och dessutom lĂ€gger vi pĂ„ en viss logik för att överföra data frĂ„n en plattform till en annanâdet vill sĂ€ga datarreplication, kopiering av statik och sĂ„ vidare. SĂ„, logiken för replikering Ă€r vanligtvis mycket komplex, och dĂ€rmed kan den totala svĂ„righetsgraden för systemet vara inte bara 2, utan 3, 5, 10 gĂ„nger större.
Den andra fÀllan: nÀr vi bygger verkligt stora komplexa system, fantiserar vi om vad vi vill uppnÄ i slutÀndan. Voilà : vi vill ha ett superpÄlitligt system som fungerar helt utan driftstopp, vÀxlar pÄ en halv sekund (eller helst omedelbart), och vi börjar förverkliga vÄra drömmar. Men hÀr finns ocksÄ en nyans: ju kortare den önskade omstÀllningstiden, desto mer komplex blir logiken i systemet. Ju svÄrare vi mÄste göra denna logik, desto oftare kommer systemet att gÄ sönder. Och man kan hamna i en mycket otrevlig situation: vi försöker med alla medel minska driftstoppets tid, men egentligen gör vi allt mer komplicerat, och nÀr nÄgot gÄr fel, kommer driftstoppet i slutÀndan bli lÀngre. Man fÄngar ofta sig sjÀlv med tanken: tja... det vore bÀttre att inte reservera. BÀttre att det fungerade ensam och med en tydlig driftstoppstid.
Hur kan man bekÀmpa detta? Man mÄste sluta ljuga för sig sjÀlv, sluta smickra sig sjÀlv med att vi hÀr ska bygga en rymdfarkost, utan istÀllet förstÄ hur lÀnge projektet kan ta. Och utifrÄn denna maximala tid vÀljer vi vilka metoder vi egentligen ska anvÀnda för att öka vÄrt systems pÄlitlighet.
Det Àr dags för 'historier frÄn livet'... frÄn livet, sÄklart.
Exempel nummer ett
FörestĂ€ll dig en visitkortsliknande webbplats för rörproduktionsföretag nr 1 i staden N. PĂ„ den stĂ„r med stora bokstĂ€ver â RĂRPRODUKTION â 1. Lite lĂ€ngre ner â en slogan: "VĂ„ra rör Ă€r de mest perfekta rören i N". Och lĂ€ngst ner finns telefonnumret till verkstĂ€llande direktören och hans namn. Vi förstĂ„r att det Ă€r viktigt att reservera â det Ă€r ju en vĂ€ldigt viktig grej! Vi börjar förstĂ„ vad det handlar om. Html-statik â alltsĂ„ ett par bilder dĂ€r chefen, faktiskt, sitter vid bordet i bastun med sin partner och diskuterar nĂ„got affĂ€rsavtal. Vi börjar tĂ€nka pĂ„ stillestĂ„ndstiden. Det slĂ„r oss: man behöver ligga dĂ€r i fem minuter, max. Och hĂ€r kommer frĂ„gan: hur mĂ„nga försĂ€ljningar har vi haft frĂ„n denna webbplats? Hur mĂ„nga? Vad betyder "noll"? Det betyder att alla fyra affĂ€rer frĂ„n förra Ă„ret blev avslutade vid samma bord, med samma personer, som de gĂ„r till bastun med och sitter vid bordet. Och vi förstĂ„r att Ă€ven om webbplatsen ligger nere en dag â sĂ„ Ă€r det inget som Ă€r sĂ€rskilt farligt.
Med dessa förutsĂ€ttningar finns det en dag för att lyfta denna historia. Vi börjar tĂ€nka pĂ„ reservschemat. Och vi vĂ€ljer det mest ideala schemat för reservering för detta exempel: vi anvĂ€nder ingen reservdelning. Den hĂ€r alltet kan lyftas av vilken administratör som helst pĂ„ en halvtimme med pauser. SĂ€tta upp webbservern, lĂ€gga filerna â klart. Det kommer att fungera. Inget att hĂ„lla koll pĂ„, inget att ge sĂ€rskild uppmĂ€rksamhet. SĂ„ slutsatsen frĂ„n exempel nummer ett Ă€r ganska uppenbar: tjĂ€nster som inte behöver reserveras â behöver inte reserveras.
Exempel nummer tvÄ
Företagsblogg: specialutbildade skriver nyheter dĂ€r, som att vi deltog i en viss mĂ€ssa, och hĂ€r slĂ€ppte vi ytterligare en ny produkt och sĂ„ vidare. LĂ„t oss sĂ€ga att det Ă€r standard PHP med WordPress, en liten databas och lite statisk information. SjĂ€lvklart dyker tanken upp igen, att vi absolut inte kan ligga stilla â "inte mer Ă€n fem minuter!", och allt det dĂ€r. Men lĂ„t oss tĂ€nka vidare. Vad gör denna blogg? Den fĂ„r besök frĂ„n Yandex och Google genom olika sökfrĂ„gor, organiskt. Bra. Men hur hĂ€nger försĂ€ljningen ihop med detta? Insikt: inte sĂ€rskilt mycket. Annonstrafik gĂ„r till huvudwebbplatsen, som ligger pĂ„ en annan server. Vi börjar tĂ€nka pĂ„ reservlösningen för bloggen. Idealiskt sett bör den lyftas inom ett par timmar, och det vore bra att vara förberedd för det. Det Ă€r rimligt att ta en annan maskin i ett annat datacenter, installera miljön pĂ„ den, det vill sĂ€ga webbserver, PHP, WordPress, MySQL, och lĂ„ta den ligga inaktiv. I det ögonblick vi inser att nĂ„got har gĂ„tt fel, behöver vi göra tvĂ„ saker â Ă„terstĂ€lla en MySQL-dump pĂ„ 50 megabyte, som gĂ„r pĂ„ en minut, och Ă„terstĂ€lla ett visst antal bilder frĂ„n sĂ€kerhetskopian. Detta tar inte heller mycket tid. PĂ„ sĂ„ sĂ€tt Ă€r hela denna lösning uppe pĂ„ en halvtimme. Inga replikationer, eller förlĂ„t, automatiska failover-processer. Slutsats: det som kan Ă„terstĂ€llas snabbt frĂ„n backup, behöver inte reserveras.
Exempel nummer tre, lite mer komplicerat
E-handelsbutik. PHP med en nÄgot modifierad Open Heart, MySQL med en solid databas. Ganska mycket statisk information (eftersom e-handelsbutiker har vackra HD-bilder och allt det dÀr), Redis för sessioner och Elasticsearch för sök. Vi börjar tÀnka pÄ stillestÄndstid. Och hÀr Àr det uppenbart att en dag utan problem kan e-handelsbutiken inte ligga nere. Ju lÀngre den Àr nere, desto mer pengar förlorar vi. Vi mÄste öka takten. Men hur mycket? Jag tror att om vi ligger nere i en timme, sÄ ger ingen sig till vansinne. Ja, vi kommer att förlora nÄgot, men om vi stressar, kommer det bara att bli sÀmre. Vi definierar schemat för det acceptabla stillestÄndet per timme.
Hur kan man boka allt detta? En maskin behövs i vilket fall som helst: en timme Ă€r ganska lite. Mysql: hĂ€r behövs det replikering, levande replikering, eftersom 100 GB inte kommer att rymmas pĂ„ en timme. Statisk information, bilder: Ă„nyo, 500 GB kanske inte hinner rymmas pĂ„ en timme. SĂ„ det Ă€r bĂ€st att kopiera bilderna direkt. Redis: hĂ€r blir det intressantare. I Redis ligger sessionerna â vi kan inte bara ta bort det. För det skulle inte vara bra: alla anvĂ€ndare skulle loggas ut, kundvagnarna skulle tömmas och sĂ„ vidare. Folk tvingas skriva in sina inloggningsuppgifter pĂ„ nytt, och mĂ„nga kanske tappar intresset och inte slutför köpet. Ă
terigen, konversionen skulle sjunka. Ă
andra sidan, Redis Ă€r rĂ€tt sĂ„ uppdaterad, med de senast inloggade anvĂ€ndarna, kanske det inte heller Ă€r nödvĂ€ndigt. En bra kompromiss Ă€r att ta Redis och Ă„terstĂ€lla det frĂ„n backupen, den frĂ„n igĂ„r eller, om den görs varje timme, den frĂ„n för en timme sedan. Bra att Ă„terstĂ€lla det frĂ„n en backup Ă€r att kopiera en fil. Och den mest intressanta historien Ă€r Elasticsearch. Vem har nĂ„gonsin satt upp MySQL-replikering? Vem har nĂ„gonsin satt upp Elasticsearch-replikering? Och vem har den fungerat bra för efterĂ„t? Jag menar: vi ser en viss enhet i vĂ„rt system. Det verkar vara anvĂ€ndbart â men det Ă€r komplicerat.
SvÄrigheterna ligger i att vÄra ingenjörskollegor saknar erfarenhet av det. Antingen finns det negativa erfarenheter. Eller sÄ förstÄr vi att detta fortfarande Àr en ganska ny teknik med sina nyanser och brister. Vi tÀnker⊠Tja, Elastic Àr ocksÄ stort, det tar lÄng tid att ÄterstÀlla frÄn backup, vad ska vi göra? Vi inser att Elastic i det hÀr fallet anvÀnds för sökning. Men hur sÀljer vÄr webbutik? Vi pratar med marknadsförarna och frÄgar varifrÄn kunderna kommer. De svarar: "90 % kommer direkt till produktkortet frÄn Yandex Market." Antingen köper de eller sÄ gör de inte det. DÀrför behövs sökning endast för 10 % av anvÀndarna. Att hÄlla en replikering av Elastic, sÀrskilt mellan olika datacenter i olika zoner, har verkligen mÄnga nyanser. Vad Àr lösningen? Vi tar Elastic pÄ en reserverad plattform och gör inget med det. Om det drar ut pÄ tiden, kan vi kanske starta det senare, men det Àr inte sÀkert. SÄ, slutsatsen Àr i stort sett densamma: tjÀnster som inte pÄverkar intÀkterna reserverar vi inte. För att hÄlla schemat enklare.
Exempel nummer fyra, Ànnu svÄrare.
Integratör: försÀljning av blommor, bestÀllning av taxi, försÀljning av produkter, kort sagt, vad som helst. En seriös lösning som arbetar 24/7 med ett stort antal anvÀndare. Med en helhetslösning som har intressanta databaser, lösningar, hög belastning, och framför allt, att ligga nere mer Àn 5 minuter Àr problematiskt. Inte bara för att mÀnniskor inte köper, utan för att de ser att denna tjÀnst inte fungerar, blir besvikna och kanske inte kommer tillbaka en andra gÄng.
Okej. Fem minuter. Vad ska vi göra Ă„t detta? I det hĂ€r fallet bygger vi en riktig reservlösning för alla pengar, med replikering av allt och alla, och kanske automatiserar vi Ă€ven övergĂ„ngen till denna plattform sĂ„ mycket som möjligt. Dessutom bör vi inte glömma att göra en viktig sak: faktiskt skriva en övergĂ„ngsprotokoll. Protokollet, Ă€ven om allt Ă€r automatiserat, kan vara mycket enkelt. I stil med "starta detta Ansible-scenario", "tryck pĂ„ denna kryssruta i Route 53" osv. â men det mĂ„ste vara en tydlig lista över Ă„tgĂ€rder.
Och allt verkar klart. Att vÀxla replikation Àr en trivial uppgift, antingen sker det automatiskt eller sÄ gör vi det manuellt. Att skriva om domÀnnamnet i DNS Àr en liknande uppgift. Problemet Àr att nÀr ett sÄdant projekt kraschar, uppstÄr panik, och Àven de mest erfarna administratörerna kan bli drabbade. Utan en tydlig instruktion som "öppna terminalen, gÄ hit, adressen till vÄr server Àr fortfarande sÄ hÀr" Àr det svÄrt att hantera en tidsram pÄ 5 minuter för Äterupplivning. Dessutom, nÀr vi följer detta regelverk, Àr det lÀtt att dokumentera förÀndringar i infrastrukturen och justera reglerna dÀrefter.
Men om reservsystemet Ă€r mycket komplext och vi gör ett misstag vid nĂ„got tillfĂ€lle, kan vi bĂ„de krossa och vĂ„r reservplats, och dessutom förvandla data till pumpor pĂ„ bĂ„da platserna â det skulle bli riktigt tragiskt.
Exempel nummer fem, ren hardcore
En internationell tjĂ€nst med hundratals miljoner anvĂ€ndare över hela vĂ€rlden. Alla tidszoner som finns, highload pĂ„ max, kan inte stoppas överhuvudtaget. En minut â och det blir sorgligt. Vad gör vi? Vi reserverar, igen, pĂ„ fullskala. Vi har gjort allt som nĂ€mnts i föregĂ„ende exempel och lite till. Den perfekta vĂ€rlden, och vĂ„r infrastruktur â den följer alla DevOps-principer för IaaC. Det vill sĂ€ga, allt finns i git, och du behöver bara trycka pĂ„ knappen.
Vad saknas? En sak â övningar. Utan dem gĂ„r det inte. Det verkar som om allt Ă€r perfekt, vi har allt under kontroll. Vi trycker pĂ„ knappen och allt hĂ€nder. Ăven om det Ă€r sĂ„ â och vi vet att sĂ„ Ă€r det inte alltid â interagerar vĂ„rt system med andra system. Till exempel, DNS frĂ„n Route 53, S3-lagring, integration med olika API:er. Vi kan inte förutse allt i detta hypotetiska experiment. Och sĂ„ lĂ€nge vi inte faktiskt flippar strömbrytaren â kommer vi inte veta om det fungerar eller inte.
Det var nog allt. Var inte lata och överdriv inte. MÄ uptime vara med er!
KĂ€lla: habr.com
