På sommaren minskar traditionellt både inköpsaktiviteten och intensiteten i förändringar i infrastrukturen för webbprojekt, berättar Captain Obvious. Helt enkelt för att även IT-specialister ibland åker på semester. Och CTO också. Det är desto svårare för dem som sitter kvar, men det är inte meningen nu: kanske är det därför sommaren är den bästa tiden att långsamt tänka på det befintliga bokningssystemet och utarbeta en plan för att förbättra det. Och erfarenheten av Yegor Andreev från , som han talade om på konferensen .
Det finns flera fallgropar du kan hamna i när du bygger backupsajter. Och det är absolut omöjligt att fastna i dem. Och det som förstör oss i allt detta, som i många andra saker, är perfektionism och... lättja. Vi försöker göra allt, allt, allt perfekt, men vi behöver inte göra det perfekt! Du behöver bara göra vissa saker, men gör dem rätt, slutför dem så att de fungerar som de ska.
Failover är inte någon sorts rolig, rolig sak; det här är en sak som borde göra precis en sak - minska stilleståndstiden så att tjänsten, företaget, förlorar mindre pengar. Och i alla bokningsmetoder föreslår jag att man tänker i följande sammanhang: var är pengarna?
Första fällan: när vi bygger stora, pålitliga system och ägnar oss åt redundans minskar vi antalet olyckor. Detta är en fruktansvärd missuppfattning. När vi ägnar oss åt övertalighet kommer vi sannolikt att öka antalet olyckor. Och om vi gör allt rätt, då kommer vi kollektivt att minska stilleståndstiden. Det blir fler olyckor, men de kommer att ske till lägre kostnader. Vad är en reservation? - Detta är en komplikation av systemet. Alla komplikationer är dåliga: vi har fler kuggar, fler växlar, i ett ord, fler element - och därför en större chans att gå sönder. Och de kommer verkligen att gå sönder. Och de kommer att gå sönder oftare. Ett enkelt exempel: låt oss säga att vi har en webbplats med PHP och MySQL. Och det måste snabbt reserveras.
Shtosh (c) Vi tar den andra platsen, bygger ett identiskt system... Komplexiteten blir dubbelt så stor - vi har två enheter. Vi rullar också ut en viss logik för att överföra data från en plats till en annan – det vill säga datareplikering, kopiering av statisk data och så vidare. Så replikeringslogiken är vanligtvis mycket komplex, och därför kan systemets totala komplexitet inte vara 2, utan 3, 5, 10 gånger större.
Andra fällan: när vi bygger riktigt stora komplexa system fantiserar vi om vad vi vill få till slut. Voila: vi vill få ett superpålitligt system som fungerar utan stillestånd, växlar på en halv sekund (eller ännu bättre, direkt), och vi börjar förverkliga drömmar. Men det finns också en nyans här: ju kortare önskad kopplingstid, desto mer komplex blir systemlogiken. Ju mer komplex vi måste göra denna logik, desto oftare kommer systemet att gå sönder. Och du kan hamna i en mycket obehaglig situation: vi försöker med all vår kraft att minska stilleståndstiden, men i själva verket gör vi allt mer komplicerat, och när något går fel kommer stilleståndstiden att bli längre. Här kommer du ofta på dig själv med att tänka: ja... det vore bättre att inte boka. Det skulle vara bättre om det fungerade ensamt och med förståelig driftstopp.
Hur kan du bekämpa detta? Vi måste sluta ljuga för oss själva, sluta smickra oss själva att vi ska bygga ett rymdskepp här nu, men tillräckligt förstå hur länge projektet kan ligga. Och för denna maximala tid kommer vi att välja vilka metoder vi faktiskt kommer att använda för att öka tillförlitligheten hos vårt system.
Det är dags för "berättelser från w"... från livet, förstås.
Exempel nummer ett
Föreställ dig en webbplats för visitkort för Pipe Rolling Plant No. 1 i staden N. Det står med stora bokstäver - Pipe Rolling Plant No. 1. Strax nedanför är sloganen: "Våra rör är de rundaste rören i N." Och nedan är vd:ns telefonnummer och hans namn. Vi förstår att du behöver göra en reservation - detta är en mycket viktig sak! Låt oss börja ta reda på vad den består av. Html-statik - alltså ett par bilder där generaldirektören faktiskt diskuterar någon form av nästa affär vid bordet i badhuset med sin sambo. Vi börjar fundera på stillestånd. Det kommer att tänka på: du behöver ligga där i fem minuter, inte mer. Och då uppstår frågan: hur många försäljningar var det från denna sida i allmänhet? Hur mycket-hur mycket? Vad betyder "noll"? Och det betyder: för att generalen gjorde alla fyra transaktionerna förra året vid samma bord, med samma personer som de går till badhuset och sitter vid bordet med. Och vi förstår att även om sajten sitter kvar en dag så kommer inget hemskt att hända.
Baserat på den inledande informationen finns det en dag för att lyfta denna historia. Låt oss börja fundera på ett uppsägningsprogram. Och vi väljer det mest ideala redundansschemat för detta exempel: vi använder inte redundans. Det hela kan tas upp av vilken administratör som helst på en halvtimme med rökpauser. Installera en webbserver, lägg till filer - det är allt. Det kommer att fungera. Du behöver inte ha koll på någonting, du behöver inte vara särskilt uppmärksam på någonting. Det vill säga 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 personer skriver nyheter där, vi deltog i en sådan och en utställning, men vi släppte ytterligare en ny produkt, och så vidare. Låt oss säga att detta är standard PHP med WordPress, en liten databas och lite statisk. Naturligtvis kommer det att tänka på igen att du under inga omständigheter ska ligga ner - "inte mer än fem minuter!" Det är allt. Men låt oss tänka vidare. Vad gör den här bloggen? Folk kommer dit från Yandex, från Google baserat på några frågor, organiskt. Bra. Har försäljningen något med det att göra? Epiphany: inte riktigt. Annonstrafiken går till huvudsidan, som är på en annan maskin. Låt oss börja fundera på ett bokningsschema. På ett bra sätt behöver den höjas på ett par timmar, och det skulle vara skönt att förbereda sig för detta. Det vore rimligt att ta en maskin från ett annat datacenter, rulla in miljön på den, det vill säga en webbserver, PHP, WordPress, MySQL, och lämna den där. I det ögonblick när vi förstår att allt är trasigt måste vi göra två saker - rulla ut mysql-dumpen 50 meter, den kommer att flyga dit om en minut och rulla ut ett visst antal bilder från backupen där. Detta finns inte heller där för gud vet hur länge. Alltså, på en halvtimme stiger det hela. Ingen replikering, eller gud förlåt mig, automatisk failover. Slutsats: det vi snabbt kan rulla ut från en backup behöver inte säkerhetskopieras.
Exempel nummer tre, mer komplicerat
Webbutik. PhP med öppet hjärta är lite tweaked, mysql med en solid bas. Ganska mycket statisk (nätbutiken har trots allt vackra HD-bilder och allt sånt), Redis för sessionen och Elasticsearch för sökning. Vi börjar fundera på stillestånd. Och här är det förstås uppenbart att en nätbutik inte kan ligga smärtfritt en dag. När allt kommer omkring, ju längre den ligger, desto mer pengar förlorar vi. Det är värt att skynda på. Hur mycket? Jag tror att om vi ligger ner en timme så blir ingen galen. Ja, vi kommer att förlora något, men om vi börjar jobba hårt blir det bara värre. Vi definierar ett schema för tillåten stilleståndstid per timme.
Hur kan allt detta reserveras? Du behöver en bil i alla fall: en timmes tid är ganska lite. Mysql: här behöver vi redan replikering, livereplikering, för om en timme kommer 100 GB med största sannolikhet inte att läggas till dumpen. Statik, bilder: igen, om en timme kanske 500 GB inte hinner läggas till. Därför är det bättre att kopiera bilderna direkt. Redis: det är här saker och ting blir intressanta. I Redis lagras sessioner - vi kan inte bara ta det och begrava det. För detta kommer inte att bli särskilt bra: alla användare kommer att loggas ut, deras korgar kommer att tömmas och så vidare. Människor kommer att tvingas ange sitt användarnamn och lösenord igen, och många människor kan bryta sig loss och inte slutföra köpet. Återigen kommer konverteringarna att minska. Å andra sidan är Redis direkt uppdaterad, där de senast inloggade användarna förmodligen inte behövs heller. Och en bra kompromiss är att ta Redis och återställa den från en säkerhetskopia från igår, eller, om du gör det varje timme, från en timme sedan. Lyckligtvis innebär att återställa den från en säkerhetskopia att du kopierar en fil. Och den mest intressanta historien är Elasticsearch. Vem har någonsin plockat upp MySQL-replikering? Vem har någonsin plockat upp Elasticsearch-replikering? Och för vem fungerade det normalt efter? Vad jag menar är att vi ser en viss enhet i vårt system. Det verkar vara användbart – men det är komplext.
Komplex i den meningen att våra medingenjörer inte har någon erfarenhet av att arbeta med det. Eller så finns det en negativ upplevelse. Eller så förstår vi att detta fortfarande är en ganska ny teknik med nyanser eller råhet. Vi tänker... Fan, resår är också hälsosamt, det tar också lång tid att återställa det från en backup, vad ska jag göra? Vi förstår att resår i vårt fall används för sökning. Hur säljer vår webbutik? Vi går till marknadsförare och frågar varifrån folk kommer. De svarar: "90 % från Yandex Market kommer direkt till produktkortet." Och antingen köper de det eller så gör de det inte. Därför behövs sökning av 10 % av användarna. Och att hålla elastisk replikering, särskilt mellan olika datacenter i olika zoner, har verkligen många nyanser. Vilken utgång? Vi tar resår från en reserverad sida och gör ingenting med den. Om fallet drar ut på tiden kan vi ta upp det någon gång, men det är inte säkert. Egentligen är slutsatsen densamma, plus eller minus: vi, återigen, reserverar inte tjänster som inte påverkar pengar. För att göra diagrammet enklare.
Exempel nummer fyra, ännu svårare
Integrator: sälja blommor, ringa taxi, sälja varor i allmänhet, vad som helst. En seriös sak som fungerar 24/7 för ett stort antal användare. Med en fullfjädrad intressant stack, där det finns intressanta baser, lösningar, hög belastning, och viktigast av allt, det gör ont att ligga ner i mer än 5 minuter. Inte bara och inte så mycket för att folk inte köper, utan för att folk kommer att se att det här inte fungerar, kommer de att bli upprörda och kanske inte komma tillbaka alls.
OK. Fem minuter. Vad ska vi göra åt detta? I det här fallet använder vi, precis som vuxna, alla pengar för att bygga en riktig backup-sajt, med replikering av allt, och kanske till och med automatisera bytet till den här sajten så mycket som möjligt. Och utöver detta måste du komma ihåg att göra en viktig sak: faktiskt skriva bytesreglerna. Regelverket, även om du har allt automatiserat, kan vara väldigt enkelt. Från serien "kör ett sådant och sådant ansible script", "klicka på en sådan och en sådan kryssruta på väg 53" och så vidare - men det här måste vara någon form av exakt lista över åtgärder.
Och allt verkar klart. Att byta replikering är en trivial uppgift, eller så byter den av sig själv. Att skriva om ett domännamn i DNS är från samma serie. Problemet är att när ett sådant projekt misslyckas, börjar panik, och även de starkaste, skäggiga administratörerna kan vara mottagliga för det. Utan tydliga instruktioner "öppna terminalen, kom hit, vår servers adress är fortfarande så här," är det svårt att uppfylla den 5-minuters tidsfrist som tilldelats för återupplivning. Jo, plus, när vi använder dessa regler är det lätt att registrera vissa förändringar i infrastrukturen, till exempel, och ändra regelverket därefter.
Tja, om bokningssystemet är väldigt komplext och vi någon gång gjorde ett misstag, då kan vi förstöra vår säkerhetskopia, och dessutom förvandla data till en pumpa på båda sidorna - det här kommer att vara helt tråkigt.
Exempel nummer fem, komplett hardcore
En internationell tjänst med hundratals miljoner användare runt om i världen. Alla tidszoner som finns, hög belastning vid maximal hastighet, du kan inte ligga ner alls. En minut - och det blir sorgligt. Vad ska man göra? Reservera, igen, enligt hela programmet. Vi gjorde allt jag pratade om i föregående exempel, och lite till. En idealisk värld, och vår infrastruktur är enligt alla koncept för IaaC devops. Det vill säga, allt är i git, och du trycker bara på knappen.
Vad saknas? En - övningar. Det är omöjligt utan dem. Det verkar som att allt är perfekt hos oss, vi har i allmänhet allt under kontroll. Vi trycker på knappen, allt händer. Även om det är så – och vi förstår att det inte händer på det här sättet – interagerar vårt system med vissa andra system. Detta är till exempel dns från route 53, s3-lagring, integration med något api. Vi kommer inte att kunna förutse allt i detta spekulativa experiment. Och tills vi faktiskt drar i strömbrytaren vet vi inte om det kommer att fungera eller inte.
Det är nog allt. Var inte lat eller överdriv det. Och kan upptid vara med dig!
Källa: will.com