{"id":36393,"date":"2019-10-31T22:11:24","date_gmt":"2019-10-31T19:11:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/failover-nas-gubit-perfektsionizm-i-len\/"},"modified":"2019-10-31T22:11:24","modified_gmt":"2019-10-31T19:11:24","slug":"failover-nas-gubit-perfektsionizm-i-len","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: perfektionism och\u2026 lathet d\u00f6dar oss","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u00e5 sommaren minskar traditionellt b\u00e5de k\u00f6pbeteendet och intensiteten i f\u00f6r\u00e4ndringar av infrastruktur f\u00f6r webbprojekt, s\u00e4ger Kapten Upplysning. F\u00f6r att \u00e4ven IT-proffs g\u00e5r p\u00e5 semester d\u00e5 och d\u00e5. Och CTO:n ocks\u00e5. Det g\u00f6r det sv\u00e5rare f\u00f6r dem som stannar kvar p\u00e5 posten, men det \u00e4r inte po\u00e4ngen nu: kanske \u00e4r det just d\u00e4rf\u00f6r sommaren \u00e4r den b\u00e4sta tiden f\u00f6r att i lugn och ro \u00f6verv\u00e4ga den befintliga reservplanen och skapa en plan f\u00f6r dess f\u00f6rb\u00e4ttring. Och i detta kan erfarenheten fr\u00e5n Egor Andreev vara till nytta fr\u00e5n AdminDivision<\/a><\/noindex>, som han ber\u00e4ttade om p\u00e5 konferensen Uptime day<\/a><\/noindex>.<\/i><\/p>\n

N\u00e4r vi bygger reservanl\u00e4ggningar och hanterar reservtagning finns det flera f\u00e4llor som man kan hamna i. Att hamna i dem \u00e4r helt oacceptabelt. Och det som f\u00f6rst\u00f6r oss h\u00e4r, liksom i mycket annat, \u00e4r perfektionism och\u2026 lathet. Vi f\u00f6rs\u00f6ker g\u00f6ra allt perfekt, men vi beh\u00f6ver inte g\u00f6ra allt perfekt! Vi m\u00e5ste bara g\u00f6ra vissa saker p\u00e5 r\u00e4tt s\u00e4tt, genomf\u00f6ra dem fullt ut s\u00e5 att de fungerar ordentligt. <\/p>\n

Failover \u00e4r inte bara n\u00e5got roligt som \u00e4r bra att ha; det \u00e4r en funktion som ska g\u00f6ra precis en sak \u2014 minska stillest\u00e5ndstiden, s\u00e5 att tj\u00e4nsten, f\u00f6retaget, f\u00f6rlorar mindre pengar. Och i alla metoder f\u00f6r reservt\u00e4ckning f\u00f6resl\u00e5r jag att t\u00e4nka i f\u00f6ljande kontext: var ligger pengarna?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nDen f\u00f6rsta f\u00e4llan<\/b>: n\u00e4r vi bygger stora p\u00e5litliga system och hanterar reservtagning minskar vi antalet avbrott. Detta \u00e4r en stor missuppfattning. N\u00e4r vi hanterar reservtagning \u00f6kar vi sannolikt antalet avbrott. Och om vi g\u00f6r allt r\u00e4tt s\u00e5 kommer vi sammanfattningsvis att minska stillest\u00e5ndstiden. Det kommer att bli fler avbrott, men de kommer att ske med mindre kostnader. Vad \u00e4r reservtagning? \u2014 det \u00e4r en komplicering av systemet. All komplicering \u00e4r d\u00e5ligt: vi f\u00e5r fler skruvar, fler kuggdrev, helt enkelt fler komponenter \u2014 och d\u00e4rmed en h\u00f6gre chans f\u00f6r fel. Och de kommer faktiskt att g\u00e5 s\u00f6nder. Och de kommer att g\u00e5 s\u00f6nder oftare. Ett enkelt exempel: s\u00e4g att vi har en viss webbplats, med PHP, MySQL. Och den m\u00e5ste snabbt reserveras. <\/p>\n

S\u00e5, vi tar en andra plattform, bygger ett identiskt system... Sv\u00e5righetsgraden blir dubbelt s\u00e5 stor \u2014 vi har tv\u00e5 enheter. Och dessutom l\u00e4gger vi p\u00e5 en viss logik f\u00f6r att \u00f6verf\u00f6ra data fr\u00e5n en plattform till en annan\u2014det vill s\u00e4ga datarreplication, kopiering av statik och s\u00e5 vidare. S\u00e5, logiken f\u00f6r replikering \u00e4r vanligtvis mycket komplex, och d\u00e4rmed kan den totala sv\u00e5righetsgraden f\u00f6r systemet vara inte bara 2, utan 3, 5, 10 g\u00e5nger st\u00f6rre. <\/p>\n

Den andra f\u00e4llan<\/b>: n\u00e4r vi bygger verkligt stora komplexa system, fantiserar vi om vad vi vill uppn\u00e5 i slut\u00e4ndan. Voil\u00e0: vi vill ha ett superp\u00e5litligt system som fungerar helt utan driftstopp, v\u00e4xlar p\u00e5 en halv sekund (eller helst omedelbart), och vi b\u00f6rjar f\u00f6rverkliga v\u00e5ra dr\u00f6mmar. Men h\u00e4r finns ocks\u00e5 en nyans: ju kortare den \u00f6nskade omst\u00e4llningstiden, desto mer komplex blir logiken i systemet. Ju sv\u00e5rare vi m\u00e5ste g\u00f6ra denna logik, desto oftare kommer systemet att g\u00e5 s\u00f6nder. Och man kan hamna i en mycket otrevlig situation: vi f\u00f6rs\u00f6ker med alla medel minska driftstoppets tid, men egentligen g\u00f6r vi allt mer komplicerat, och n\u00e4r n\u00e5got g\u00e5r fel, kommer driftstoppet i slut\u00e4ndan bli l\u00e4ngre. Man f\u00e5ngar ofta sig sj\u00e4lv med tanken: tja... det vore b\u00e4ttre att inte reservera. B\u00e4ttre att det fungerade ensam och med en tydlig driftstoppstid. <\/p>\n

Hur kan man bek\u00e4mpa detta? Man m\u00e5ste sluta ljuga f\u00f6r sig sj\u00e4lv, sluta smickra sig sj\u00e4lv med att vi h\u00e4r ska bygga en rymdfarkost, utan ist\u00e4llet f\u00f6rst\u00e5 hur l\u00e4nge projektet kan ta. Och utifr\u00e5n denna maximala tid v\u00e4ljer vi vilka metoder vi egentligen ska anv\u00e4nda f\u00f6r att \u00f6ka v\u00e5rt systems p\u00e5litlighet. <\/p>\n

\"Failover:
\n
\nDet \u00e4r dags f\u00f6r 'historier fr\u00e5n livet'... fr\u00e5n livet, s\u00e5klart. <\/p>\n

Exempel nummer ett<\/h4>\n

\nF\u00f6rest\u00e4ll dig en visitkortsliknande webbplats f\u00f6r r\u00f6rproduktionsf\u00f6retag nr 1 i staden N. P\u00e5 den st\u00e5r med stora bokst\u00e4ver \u2014 R\u00d6RPRODUKTION \u2116 1. Lite l\u00e4ngre ner \u2014 en slogan: \"V\u00e5ra r\u00f6r \u00e4r de mest perfekta r\u00f6ren i N\". Och l\u00e4ngst ner finns telefonnumret till verkst\u00e4llande direkt\u00f6ren och hans namn. Vi f\u00f6rst\u00e5r att det \u00e4r viktigt att reservera \u2014 det \u00e4r ju en v\u00e4ldigt viktig grej! Vi b\u00f6rjar f\u00f6rst\u00e5 vad det handlar om. Html-statik \u2014 allts\u00e5 ett par bilder d\u00e4r chefen, faktiskt, sitter vid bordet i bastun med sin partner och diskuterar n\u00e5got aff\u00e4rsavtal. Vi b\u00f6rjar t\u00e4nka p\u00e5 stillest\u00e5ndstiden. Det sl\u00e5r oss: man beh\u00f6ver ligga d\u00e4r i fem minuter, max. Och h\u00e4r kommer fr\u00e5gan: hur m\u00e5nga f\u00f6rs\u00e4ljningar har vi haft fr\u00e5n denna webbplats? Hur m\u00e5nga? Vad betyder \"noll\"? Det betyder att alla fyra aff\u00e4rer fr\u00e5n f\u00f6rra \u00e5ret blev avslutade vid samma bord, med samma personer, som de g\u00e5r till bastun med och sitter vid bordet. Och vi f\u00f6rst\u00e5r att \u00e4ven om webbplatsen ligger nere en dag \u2014 s\u00e5 \u00e4r det inget som \u00e4r s\u00e4rskilt farligt. <\/p>\n

Med dessa f\u00f6ruts\u00e4ttningar finns det en dag f\u00f6r att lyfta denna historia. Vi b\u00f6rjar t\u00e4nka p\u00e5 reservschemat. Och vi v\u00e4ljer det mest ideala schemat f\u00f6r reservering f\u00f6r detta exempel: vi anv\u00e4nder ingen reservdelning. Den h\u00e4r alltet kan lyftas av vilken administrat\u00f6r som helst p\u00e5 en halvtimme med pauser. S\u00e4tta upp webbservern, l\u00e4gga filerna \u2014 klart. Det kommer att fungera. Inget att h\u00e5lla koll p\u00e5, inget att ge s\u00e4rskild uppm\u00e4rksamhet. S\u00e5 slutsatsen fr\u00e5n exempel nummer ett \u00e4r ganska uppenbar: tj\u00e4nster som inte beh\u00f6ver reserveras \u2014 beh\u00f6ver inte reserveras.<\/p>\n

\"Failover:
\n<\/p>\n

Exempel nummer tv\u00e5<\/h4>\n

\nF\u00f6retagsblogg: Speciellt tr\u00e4nade skrivare l\u00e4gger dit nyheter, h\u00e4r deltog vi i en viss m\u00e4ssa, och h\u00e4r sl\u00e4ppte vi \u00e4nnu en ny produkt och s\u00e5 vidare. L\u00e5t oss s\u00e4ga att det \u00e4r standard PHP med WordPress, en liten databas och lite statisk inneh\u00e5ll. Sj\u00e4lvklart t\u00e4nker man igen att man absolut inte kan l\u00e5ta det ligga \u2014 \"inte mer \u00e4n fem minuter!\", allt det d\u00e4r. Men l\u00e5t oss t\u00e4nka l\u00e4ngre. Vad g\u00f6r den h\u00e4r bloggen? Den f\u00e5r bes\u00f6k fr\u00e5n Yandex och Google via vissa s\u00f6kningar, organiskt. Fantastiskt. Men hur h\u00e4nger f\u00f6rs\u00e4ljning ihop med den? Insikt: inte s\u00e4rskilt mycket. Den reklamtrafik g\u00e5r till huvudsajten, som ligger p\u00e5 en annan server. Vi b\u00f6rjar t\u00e4nka p\u00e5 en reservplan f\u00f6r bloggen. Egentligen b\u00f6r vi kunna st\u00e4lla upp den p\u00e5 ett par timmar, och det vore bra att f\u00f6rbereda sig. Det skulle vara klokt att ta en maskin i ett annat datacenter, installera milj\u00f6n, det vill s\u00e4ga webbserver, PHP, WordPress, MySQL, och l\u00e5ta det ligga som en standby. N\u00e4r vi inser att allt har kraschat, beh\u00f6ver vi g\u00f6ra tv\u00e5 saker \u2014 \u00e5terst\u00e4lla en 50 MB stor MySQL-dump, det tar en minut, och \u00e5terst\u00e4lla ett visst antal bilder fr\u00e5n en s\u00e4kerhetskopia. Det \u00e4r inte s\u00e5 mycket. S\u00e5 p\u00e5 en halvtimme kan allt det h\u00e4r s\u00e4ttas upp. Ingen replikering, eller f\u00f6rl\u00e5t, automatisk failover. Slutsats: det vi snabbt kan \u00e5terst\u00e4lla fr\u00e5n backup beh\u00f6ver inte reserveras. <\/p>\n

\"Failover:
\n<\/p>\n

Exempel nummer tre, lite mer komplicerat<\/h4>\n

\nE-handelsbutik. PHP med en n\u00e5got modifierad Open Heart, MySQL med en solid databas. Ganska mycket statisk information (eftersom e-handelsbutiker har vackra HD-bilder och allt det d\u00e4r), Redis f\u00f6r sessioner och Elasticsearch f\u00f6r s\u00f6k. Vi b\u00f6rjar t\u00e4nka p\u00e5 stillest\u00e5ndstid. Och h\u00e4r \u00e4r det uppenbart att en dag utan problem kan e-handelsbutiken inte ligga nere. Ju l\u00e4ngre den \u00e4r nere, desto mer pengar f\u00f6rlorar vi. Vi m\u00e5ste \u00f6ka takten. Men hur mycket? Jag tror att om vi ligger nere i en timme, s\u00e5 ger ingen sig till vansinne. Ja, vi kommer att f\u00f6rlora n\u00e5got, men om vi stressar, kommer det bara att bli s\u00e4mre. Vi definierar schemat f\u00f6r det acceptabla stillest\u00e5ndet per timme.<\/p>\n

Hur kan man boka allt detta? En maskin beh\u00f6vs i vilket fall som helst: en timme \u00e4r ganska lite. Mysql: h\u00e4r beh\u00f6vs det replikering, levande replikering, eftersom 100 GB inte kommer att rymmas p\u00e5 en timme. Statisk information, bilder: \u00e5nyo, 500 GB kanske inte hinner rymmas p\u00e5 en timme. S\u00e5 det \u00e4r b\u00e4st att kopiera bilderna direkt. Redis: h\u00e4r blir det intressantare. I Redis ligger sessionerna \u2014 vi kan inte bara ta bort det. F\u00f6r det skulle inte vara bra: alla anv\u00e4ndare skulle loggas ut, kundvagnarna skulle t\u00f6mmas och s\u00e5 vidare. Folk tvingas skriva in sina inloggningsuppgifter p\u00e5 nytt, och m\u00e5nga kanske tappar intresset och inte slutf\u00f6r k\u00f6pet. \u00c5terigen, konversionen skulle sjunka. \u00c5 andra sidan, Redis \u00e4r r\u00e4tt s\u00e5 uppdaterad, med de senast inloggade anv\u00e4ndarna, kanske det inte heller \u00e4r n\u00f6dv\u00e4ndigt. En bra kompromiss \u00e4r att ta Redis och \u00e5terst\u00e4lla det fr\u00e5n backupen, den fr\u00e5n ig\u00e5r eller, om den g\u00f6rs varje timme, den fr\u00e5n f\u00f6r en timme sedan. Bra att \u00e5terst\u00e4lla det fr\u00e5n en backup \u00e4r att kopiera en fil. Och den mest intressanta historien \u00e4r Elasticsearch. Vem har n\u00e5gonsin satt upp MySQL-replikering? Vem har n\u00e5gonsin satt upp Elasticsearch-replikering? Och vem har den fungerat bra f\u00f6r efter\u00e5t? Jag menar: vi ser en viss enhet i v\u00e5rt system. Det verkar vara anv\u00e4ndbart \u2014 men det \u00e4r komplicerat.
\nKomplext p\u00e5 s\u00e5 s\u00e4tt att v\u00e5ra ingenj\u00f6rskollegor saknar erfarenhet av den. Antingen har de en negativ erfarenhet, eller s\u00e5 f\u00f6rst\u00e5r vi att det h\u00e4r fortfarande \u00e4r en ganska ny teknik med sina nyanser eller brister. Vi t\u00e4nker... \u00c5h, elastic \u00e4r ocks\u00e5 stort, det tar ocks\u00e5 l\u00e5ng tid att \u00e5terst\u00e4lla fr\u00e5n backup, vad ska vi g\u00f6ra? Vi f\u00f6rst\u00e5r att elastic i v\u00e5rt fall anv\u00e4nds f\u00f6r s\u00f6k. Men hur s\u00e4ljer v\u00e5r webbshop? Vi g\u00e5r till marknadsf\u00f6rarna och fr\u00e5gar varifr\u00e5n folk kommer. De svarar: \"90% av bes\u00f6karna kommer direkt till produktkortet fr\u00e5n Yandex Market.\" Antingen k\u00f6per de eller s\u00e5 g\u00f6r de inte det. D\u00e4rf\u00f6r beh\u00f6vs s\u00f6k f\u00f6r 10% av anv\u00e4ndarna. Och att h\u00e5lla replikering av elastic, s\u00e4rskilt mellan olika datacenter i olika zoner, d\u00e4r finns det faktiskt m\u00e5nga nyanser. Vad \u00e4r l\u00f6sningen? Vi tar elastic p\u00e5 en reserverad plattform och g\u00f6r inget med det. Om processen drar ut p\u00e5 tiden kanske vi kommer att aktivera det senare, men det \u00e4r inte s\u00e4kert. Egentligen \u00e4r slutsatsen plus minus densamma: de tj\u00e4nster som inte p\u00e5verkar int\u00e4kterna reserverar vi \u00e5terigen inte. F\u00f6r att schemat ska f\u00f6rbli enklare.<\/p>\n

\"Failover:
\n<\/p>\n

Exempel nummer fyra, \u00e4nnu sv\u00e5rare.<\/h4>\n

\nIntegrat\u00f6r: f\u00f6rs\u00e4ljning av blommor, best\u00e4llning av taxi, f\u00f6rs\u00e4ljning av produkter, kort sagt, vad som helst. En seri\u00f6s l\u00f6sning som arbetar 24\/7 med ett stort antal anv\u00e4ndare. Med en helhetsl\u00f6sning som har intressanta databaser, l\u00f6sningar, h\u00f6g belastning, och framf\u00f6r allt, att ligga nere mer \u00e4n 5 minuter \u00e4r problematiskt. Inte bara f\u00f6r att m\u00e4nniskor inte k\u00f6per, utan f\u00f6r att de ser att denna tj\u00e4nst inte fungerar, blir besvikna och kanske inte kommer tillbaka en andra g\u00e5ng. <\/p>\n

Okej. Fem minuter. Vad ska vi g\u00f6ra \u00e5t detta? I det h\u00e4r fallet bygger vi en riktig reservl\u00f6sning f\u00f6r alla pengar, med replikering av allt och alla, och kanske automatiserar vi \u00e4ven \u00f6verg\u00e5ngen till denna plattform s\u00e5 mycket som m\u00f6jligt. Dessutom b\u00f6r vi inte gl\u00f6mma att g\u00f6ra en viktig sak: faktiskt skriva en \u00f6verg\u00e5ngsprotokoll. Protokollet, \u00e4ven om allt \u00e4r automatiserat, kan vara mycket enkelt. I stil med \"starta detta Ansible-scenario\", \"tryck p\u00e5 denna kryssruta i Route 53\" osv. \u2013 men det m\u00e5ste vara en tydlig lista \u00f6ver \u00e5tg\u00e4rder. <\/p>\n

Och allt verkar klart. Att v\u00e4xla replikation \u00e4r en trivial uppgift, antingen sker det automatiskt eller s\u00e5 g\u00f6r vi det manuellt. Att skriva om dom\u00e4nnamnet i DNS \u00e4r en liknande uppgift. Problemet \u00e4r att n\u00e4r ett s\u00e5dant projekt kraschar, uppst\u00e5r panik, och \u00e4ven de mest erfarna administrat\u00f6rerna kan bli drabbade. Utan en tydlig instruktion som \"\u00f6ppna terminalen, g\u00e5 hit, adressen till v\u00e5r server \u00e4r fortfarande s\u00e5 h\u00e4r\" \u00e4r det sv\u00e5rt att hantera en tidsram p\u00e5 5 minuter f\u00f6r \u00e5terupplivning. Dessutom, n\u00e4r vi f\u00f6ljer detta regelverk, \u00e4r det l\u00e4tt att dokumentera f\u00f6r\u00e4ndringar i infrastrukturen och justera reglerna d\u00e4refter.
\nMen om reservsystemet \u00e4r mycket komplext och vi g\u00f6r ett misstag vid n\u00e5got tillf\u00e4lle, kan vi b\u00e5de krossa och v\u00e5r reservplats, och dessutom f\u00f6rvandla data till pumpor p\u00e5 b\u00e5da platserna \u2013 det skulle bli riktigt tragiskt. <\/p>\n

\"Failover:
\n<\/p>\n

Exempel nummer fem, ren hardcore<\/h4>\n

\nEn internationell tj\u00e4nst med hundratals miljoner anv\u00e4ndare \u00f6ver hela v\u00e4rlden. Alla tidszoner som finns, highload p\u00e5 max, kan inte stoppas \u00f6verhuvudtaget. En minut \u2013 och det blir sorgligt. Vad g\u00f6r vi? Vi reserverar, igen, p\u00e5 fullskala. Vi har gjort allt som n\u00e4mnts i f\u00f6reg\u00e5ende exempel och lite till. Den perfekta v\u00e4rlden, och v\u00e5r infrastruktur \u2013 den f\u00f6ljer alla DevOps-principer f\u00f6r IaaC. Det vill s\u00e4ga, allt finns i git, och du beh\u00f6ver bara trycka p\u00e5 knappen. <\/p>\n

Vad saknas? En sak \u2013 \u00f6vningar. Utan dem g\u00e5r det inte. Det verkar som om allt \u00e4r perfekt, vi har allt under kontroll. Vi trycker p\u00e5 knappen och allt h\u00e4nder. \u00c4ven om det \u00e4r s\u00e5 \u2013 och vi vet att s\u00e5 \u00e4r det inte alltid \u2013 interagerar v\u00e5rt system med andra system. Till exempel, DNS fr\u00e5n Route 53, S3-lagring, integration med olika API:er. Vi kan inte f\u00f6rutse allt i detta hypotetiska experiment. Och s\u00e5 l\u00e4nge vi inte faktiskt flippar str\u00f6mbrytaren \u2013 kommer vi inte veta om det fungerar eller inte. <\/p>\n

\"Failover:
\n
\nDet var nog allt. Var inte lata och \u00f6verdriv inte. M\u00e5 uptime vara med er!
\n
K\u00e4lla: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a. \u0418 C\u0422\u041e \u0442\u043e\u0436\u0435. \u0422\u0435\u043c \u0442\u044f\u0436\u0435\u043b\u0435\u0435 \u0442\u0435\u043c, \u043a\u0442\u043e \u043e\u0441\u0442\u0430\u0451\u0442\u0441\u044f \u043d\u0430 \u043f\u043e\u0441\u0442\u0443, \u043d\u043e \u0441\u0435\u0439\u0447\u0430\u0441 \u043d\u0435 \u043e\u0431 \u044d\u0442\u043e\u043c: \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043b\u0435\u0442\u043e \u2014 \u043b\u0443\u0447\u0448\u0438\u0439 \u043f\u0435\u0440\u0438\u043e\u0434 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u0442\u043e\u0440\u043e\u043f\u044f\u0441\u044c \u043e\u0431\u0434\u0443\u043c\u0430\u0442\u044c \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0443\u044e \u0441\u0445\u0435\u043c\u0443 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27235,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36393","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Failover: perfektionism och\u2026 lathet d\u00f6dar oss | ProHoster","description":"Under sommaren minskar traditionellt b\u00e5de k\u00f6parens aktivitet och intensiteten av f\u00f6r\u00e4ndringar i infrastrukturen f\u00f6r webbprojekt, s\u00e4ger Kapten Uppenbarhet. Bara f\u00f6r att \u00e4ven IT-tekniker ibland g\u00e5r p\u00e5 semester.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Failover: \u043d\u0430\u0441 \u0433\u0443\u0431\u0438\u0442 \u043f\u0435\u0440\u0444\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0437\u043c \u0438\u2026 \u043b\u0435\u043d\u044c | ProHoster","og:description":"\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a.","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:11:24+00:00","article:modified_time":"2019-10-31T19:11:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36393","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 03:07:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:45:36","updated":"2026-01-22 03:07:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}