{"id":35092,"date":"2019-10-31T22:02:18","date_gmt":"2019-10-31T19:02:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim\/"},"modified":"2019-10-31T22:02:18","modified_gmt":"2019-10-31T19:02:18","slug":"bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","title":{"rendered":"\"Bitrix24\": \"Snabbt uppbyggt r\u00e4knas inte som fallen\"","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I dagsl\u00e4get har tj\u00e4nsten \"Bitrix24\" varken hundratals gigabit trafik eller en stor serverpark (\u00e4ven om det finns en hel del). Men f\u00f6r m\u00e5nga kunder \u00e4r det det viktigaste arbetsverktyget i f\u00f6retaget, en verklig business-critical applikation. D\u00e4rf\u00f6r f\u00e5r det inte krascha \u2014 p\u00e5 n\u00e5got s\u00e4tt. Men vad h\u00e4nder om det faktiskt intr\u00e4ffar, men tj\u00e4nsten \"\u00e5teruppst\u00e5r\" s\u00e5 snabbt att ingen m\u00e4rker n\u00e5got? Och hur lyckas man genomf\u00f6ra en failover utan att f\u00f6rlora kvalitet och kunder? Alexander Demidov, chef f\u00f6r den molnbaserade tj\u00e4nsteverksamheten \"Bitrix24\", ber\u00e4ttade f\u00f6r v\u00e5r blogg om hur reservsystemet har utvecklats under de 7 \u00e5r produkten funnits.<\/p>\n

\""Bitrix24":
\n<\/a><\/noindex>
\nSom SaaS lanserade vi \"Bitrix24\" f\u00f6r 7 \u00e5r sedan. Den st\u00f6rsta utmaningen var nog f\u00f6ljande: innan lanseringen som SaaS fanns produkten bara i form av en boxl\u00f6sning. Kunder k\u00f6pte den fr\u00e5n oss, installerade den p\u00e5 sina servrar, skapade en f\u00f6retagsportal \u2014 en gemensam l\u00f6sning f\u00f6r anst\u00e4lldas kommunikation, filhantering, uppgiftshantering, CRM, allt detta. Och vi best\u00e4mde oss 2012 f\u00f6r att vi ville lansera detta som SaaS, administrera det sj\u00e4lva och s\u00e4kerst\u00e4lla just den drifts\u00e4kerheten och tillf\u00f6rlitligheten. Vi samlade erfarenhet under processen, eftersom vi innan dess inte hade n\u00e5got \u2014 vi var bara programvarutillverkare, inte tj\u00e4nsteleverant\u00f6rer. <\/p>\n

N\u00e4r vi lanserade tj\u00e4nsten f\u00f6rstod vi att det viktigaste var att s\u00e4kerst\u00e4lla drifts\u00e4kerhet, p\u00e5litlighet och st\u00e4ndig tillg\u00e4nglighet av tj\u00e4nsten, f\u00f6r om du har en vanlig webbsida, som en butik, och den kraschar och ligger nere i en timme \u2014 d\u00e5 drabbas bara du, du f\u00f6rlorar best\u00e4llningar och kunder, men f\u00f6r din kund \u2014 f\u00f6r honom \u00e4r det inte s\u00e5 kritiskt. Han blir besviken, s\u00e5klart, men g\u00e5r vidare och k\u00f6per p\u00e5 en annan webbplats. Men om det \u00e4r en applikation som hela f\u00f6retagets arbete, kommunikation och beslut h\u00e4nger p\u00e5, \u00e4r det avg\u00f6rande att vinna anv\u00e4ndarnas f\u00f6rtroende, dvs. att inte svika dem och att inte krascha. F\u00f6r hela arbetet kan stanna av om n\u00e5got inuti inte fungerar.<\/p>\n

Bitrix.24 som SaaS<\/h4>\n

\nDen f\u00f6rsta prototypen satte vi ihop ett \u00e5r innan den offentliga lanseringen, 2011. Vi byggde den p\u00e5 ungef\u00e4r en vecka, testade och vridbygde \u2014 den fungerade till och med. Man kunde logga in i formul\u00e4ret, ange namnet p\u00e5 portalen, en ny portal skulle skapas och en anv\u00e4ndardatabas etableras. Vi tittade p\u00e5 den, v\u00e4rderade produkten i stort, lade ner den, och fortsatte att arbeta med den i ett helt \u00e5r. Vi hade en stor uppgift: vi ville inte skapa tv\u00e5 olika kodbaser, vi ville inte st\u00f6dja en separat boxprodukt och separata molnl\u00f6sningar \u2014 vi ville g\u00f6ra allt inom en och samma kod. <\/p>\n

\""Bitrix24":
\n
\nEtt typiskt webbapplikation p\u00e5 den tiden var \u2014 en server d\u00e4r n\u00e5got php-kod k\u00f6rdes, en mysql-databas, filer laddades upp, dokument och bilder lades i en upload-mapp \u2013 och allt det h\u00e4r fungerade. Tyv\u00e4rr g\u00e5r det inte att lansera en kritiskt stabil webbservice p\u00e5 detta. D\u00e4r st\u00f6ds inte distribuerad cache, och replikering av databaser st\u00f6ds inte. <\/p>\n

Vi formulerade kraven: det handlar om att kunna placera sig p\u00e5 olika platser, st\u00f6dja replikering, helst att finnas i geografiskt f\u00f6rdelade datacenter. Dela upp produktens logik och lagring av data. Dynamiskt kunna skalas efter belastningen, och statiska datan ska flyttas ut. Utifr\u00e5n dessa \u00f6verv\u00e4ganden skapades kraven p\u00e5 produkten vi utvecklade under det \u00e5ret. Under den tiden i plattformen, som blev enhetlig \u2014 f\u00f6r boxl\u00f6sningar, f\u00f6r v\u00e5r egen tj\u00e4nst \u2014 gjorde vi st\u00f6d f\u00f6r de saker som var n\u00f6dv\u00e4ndiga f\u00f6r oss. St\u00f6d f\u00f6r mysql-replikering p\u00e5 produktniv\u00e5: det vill s\u00e4ga utvecklaren som skriver koden beh\u00f6ver inte t\u00e4nka p\u00e5 hur deras f\u00f6rfr\u00e5gningar distribueras, de anv\u00e4nder v\u00e5rt api, och vi kan korrekt f\u00f6rdela skriv- och l\u00e4sf\u00f6rfr\u00e5gningar mellan master- och slave-servrar. <\/p>\n

Vi implementerade st\u00f6d p\u00e5 produktiv niv\u00e5 f\u00f6r olika molnbaserade objektlagringssystem: google storage, amazon s3 \u2014 plus, st\u00f6d f\u00f6r open stack swift. D\u00e4rf\u00f6r var det praktiskt b\u00e5de f\u00f6r oss som tj\u00e4nst och f\u00f6r utvecklarna som arbetar med boxl\u00f6sningen: om de enbart anv\u00e4nder v\u00e5rt api f\u00f6r arbete, beh\u00f6ver de inte t\u00e4nka p\u00e5 var filen slutligen sparas, om det \u00e4r lokalt p\u00e5 filsystemet eller om det hamnar i objektlagringssystemet.<\/p>\n

Som resultat beslutade vi direkt att vi skulle g\u00f6ra reservationer p\u00e5 hela datacenter-niv\u00e5. \u00c5r 2012 startade vi helt p\u00e5 Amazon AWS eftersom vi redan hade erfarenhet av att arbeta med denna plattform \u2013 v\u00e5r egen webbplats var placerad d\u00e4r. Det som lockade oss var att det i varje region p\u00e5 Amazon finns flera tillg\u00e4nglighetszoner \u2013 i deras terminologi, flera datacenter, som \u00e4r mer eller mindre oberoende av varandra och g\u00f6r att vi kan g\u00f6ra reservationer p\u00e5 datacenter-niv\u00e5: om ett av dem skulle g\u00e5 ner, s\u00e5 replikeras databaserna master-master, webbapplikationsservrarna \u00e4r reserverade och statiska filer lagras i S3-objektslagring. Belastningen balanseras \u2013 vid den tiden med Amazons ELB, men lite senare kom vi till v\u00e5ra egna lastbalanserare eftersom vi beh\u00f6vde en mer komplex logik. <\/p>\n

Vad vi ville ha, fick vi...<\/h4>\n

\nAlla grundl\u00e4ggande saker som vi ville s\u00e4kerst\u00e4lla \u2013 redundans f\u00f6r sj\u00e4lva servrarna, webbapplikationerna, databaserna \u2013 fungerade bra. Det enklaste scenariot: om n\u00e5gon av v\u00e5ra webbapplikationer g\u00e5r ner, \u00e4r det h\u00e4r enkelt \u2013 de tas bort fr\u00e5n lastbalanseringen. <\/p>\n

\""Bitrix24":
\n
\nDe utrustningar som gick ner markerades som unhealthy av lastbalanseraren (d\u00e5 var det Amazons ELB), som st\u00e4ngde av lastbalanseringen p\u00e5 dem. Amazons autoskalning fungerade: n\u00e4r belastningen \u00f6kade, lades nya maskiner till autoskalningsgruppen, och belastningen distribuerades p\u00e5 de nya maskinerna \u2013 allt fungerade bra. Med v\u00e5ra lastbalanserare \u00e4r logiken i stort sett densamma: om n\u00e5got h\u00e4nder med applikationsservern tar vi bort f\u00f6rfr\u00e5gningar fr\u00e5n den, sl\u00e4nger dessa maskiner, startar nya och forts\u00e4tter arbeta. Schemat har f\u00f6r\u00e4ndrats n\u00e5got genom \u00e5ren, men forts\u00e4tter att fungera: det \u00e4r enkelt, tydligt och det finns inga sv\u00e5righeter med det. <\/p>\n

Vi arbetar \u00f6ver hela v\u00e4rlden, och belastningstoppar hos kunderna \u00e4r helt olika, och f\u00f6r att vara \u00e4rliga b\u00f6r vi kunna utf\u00f6ra servicearbete p\u00e5 alla komponenter i v\u00e5rt system n\u00e4r som helst \u2013 utan att kunderna m\u00e4rker det. D\u00e4rf\u00f6r har vi m\u00f6jlighet att st\u00e4nga av databasen och omf\u00f6rdela belastningen till det andra datacentret. <\/p>\n

Hur fungerar allt detta? \u2014 Vi v\u00e4xlar trafiken till det fungerande datacentret \u2014 om det \u00e4r en krasch i datacentret, s\u00e5 g\u00f6r vi det helt, om det \u00e4r v\u00e5rt planerade arbete i n\u00e5gon specifik databas, s\u00e5 v\u00e4xlar vi en del av trafiken som betj\u00e4nar dessa kunder till det andra datacentret, replicationen pausas. Om vi beh\u00f6ver nya maskiner f\u00f6r webbapplikationer eftersom belastningen har \u00f6kat i det andra datacentret, startar de automatiskt. Vi avslutar arbetet, replicationen \u00e5terst\u00e4lls, och vi \u00e5terf\u00f6r hela belastningen. Om vi beh\u00f6ver genomf\u00f6ra speglade arbeten i det andra DC, till exempel installera systemuppdateringar eller \u00e4ndra inst\u00e4llningar i den andra databasen, s\u00e5 g\u00f6r vi i stort sett exakt samma, bara i den andra riktningen. Och om det \u00e4r en krasch, g\u00f6r vi helt enkelt f\u00f6ljande: i \u00f6vervakningssystemet anv\u00e4nder vi mekanismen event-handlers. Om flera kontroller aktiveras och status \u00f6verg\u00e5r till kritisk, aktiveras denna handler, en bearbetare som kan utf\u00f6ra viss logik. F\u00f6r varje databas har vi angivit vilken server som \u00e4r failover f\u00f6r den och vart trafiken ska omkopplas i h\u00e4ndelse av att den inte \u00e4r tillg\u00e4nglig. Historiskt sett har vi anv\u00e4nt nagios eller dess varianter. I princip finns s\u00e5dana mekanismer i praktiskt taget alla \u00f6vervakningssystem, n\u00e5got mer komplext anv\u00e4nder vi \u00e4n s\u00e5 l\u00e4nge inte, men vi kanske kommer att g\u00f6ra det i framtiden. F\u00f6r tillf\u00e4llet reagerar \u00f6vervakningen p\u00e5 brister i tillg\u00e4ngligheten och har m\u00f6jligheten att omdirigera n\u00e5got.<\/p>\n

Har vi reserverat allt?<\/h4>\n

\nVi har m\u00e5nga kunder fr\u00e5n USA, m\u00e5nga kunder fr\u00e5n Europa, och m\u00e5nga kunder som ligger n\u00e4rmare \u00f6st \u2014 som Japan, Singapore och s\u00e5 vidare. Sj\u00e4lvklart \u00e4r en betydande del av kunderna fr\u00e5n Ryssland. Det betyder att verksamheten inte bara \u00e4r i ett enda omr\u00e5de. Anv\u00e4ndarna vill ha snabb respons, det finns krav p\u00e5 att f\u00f6lja olika lokala lagar, och inom varje region reserverar vi oss f\u00f6r tv\u00e5 datacenter, plus att det finns vissa ytterligare tj\u00e4nster som \u00e4r bekv\u00e4ma att placera inom en region \u2014 f\u00f6r kunder som arbetar i det omr\u00e5det. REST-handlarna, autentiseringservrarna, de \u00e4r mindre kritiska f\u00f6r kundens \u00f6vergripande arbete, man kan v\u00e4xla mellan dem med en liten acceptabel f\u00f6rdr\u00f6jning, men man vill inte uppfinna hjulet p\u00e5 nytt n\u00e4r det g\u00e4ller hur man \u00f6vervakar dem och vad man ska g\u00f6ra med dem. D\u00e4rf\u00f6r f\u00f6rs\u00f6ker vi maximalt anv\u00e4nda redan existerande l\u00f6sningar, snarare \u00e4n att utveckla en egen kompetens inom ytterligare produkter. Och p\u00e5 vissa st\u00e4llen anv\u00e4nder vi helt enkelt DNS-niv\u00e5sv\u00e4ngningar, d\u00e4r vi best\u00e4mmer tj\u00e4nstens livskraft med samma DNS. I Amazon finns tj\u00e4nsten Route 53, men det \u00e4r inte bara DNS d\u00e4r man kan l\u00e4gga in poster och vara klar \u2014 det \u00e4r mycket mer flexibelt och praktiskt. Genom den kan man bygga geografiskt distribuerade tj\u00e4nster med geografiska platser, n\u00e4r man med hj\u00e4lp av den best\u00e4mmer varifr\u00e5n kunden kom och ger dem olika poster \u2014 med den kan man bygga failover-arkitekturer. De samma h\u00e4lsokontroller st\u00e4lls in i Route 53, man anger endpoint som \u00f6vervakas, anger m\u00e4tv\u00e4rden, och specificerar vilka protokoll som ska anv\u00e4ndas f\u00f6r att best\u00e4mma tj\u00e4nstens<\/p>\n

F\u00f6rsta \"men\"<\/b>: men hur och med vad reserverar man egentligen route 53? Man vet aldrig, om det h\u00e4nder n\u00e5got med det? Vi har, lyckligtvis, aldrig st\u00f6tt p\u00e5 dessa problem, men jag har en ber\u00e4ttelse om varf\u00f6r vi t\u00e4nkte att vi \u00e4nd\u00e5 beh\u00f6vde ha en backup. H\u00e4r f\u00f6rbereder vi oss i f\u00f6rv\u00e4g. Flera g\u00e5nger om dagen g\u00f6r vi en fullst\u00e4ndig export av alla zoner som vi har registrerat i route 53. Amazons API g\u00f6r det m\u00f6jligt att enkelt exportera dem i JSON-format, och vi har flera backupsservrar d\u00e4r vi konverterar detta, exporterar som konfigurationer och har, grovt sett, en backupkonfiguration. Vid behov kan vi snabbt \u00e5terst\u00e4lla den manuellt, vi f\u00f6rlorar inte DNS-inst\u00e4llningarna.<\/p>\n

Det andra 'men'<\/b>: vad \u00e4r inte reserverat i denna bild? Sj\u00e4lva lastbalanseraren! Vi har f\u00f6rdelat kunderna efter regioner p\u00e5 ett mycket enkelt s\u00e4tt. Vi har dom\u00e4ner som bitrix24.ru, bitrix24.com, .de \u2014 just nu har vi cirka 13 olika dom\u00e4ner som fungerar i m\u00e5nga olika zoner. Vi har kommit fram till f\u00f6ljande: varje region har sina egna lastbalanserare. Det \u00e4r l\u00e4ttare att f\u00f6rdela baserat p\u00e5 var den h\u00f6gsta n\u00e4tbelastningen \u00e4r. Om det blir ett fel p\u00e5 en specifik lastbalanserare s\u00e5 tas den helt enkelt ur bruk och tas bort fr\u00e5n DNS. Om det uppst\u00e5r problem med en grupp lastbalanserare s\u00e5 reserveras de p\u00e5 andra platser, och omkopplingen mellan dem g\u00f6rs med samma Route 53, eftersom omkopplingen sker med en kort TTL, max inom 2, 3, 5 minuter. <\/p>\n

Det tredje 'men'<\/b>: vad \u00e4r \u00e4nnu inte reserverat? S3, korrekt. N\u00e4r vi lagrar filer som anv\u00e4nds av v\u00e5ra anv\u00e4ndare i S3, trodde vi verkligen att det var of\u00f6rst\u00f6rbart och att vi inte beh\u00f6vde g\u00f6ra n\u00e5gra reservationer d\u00e4r. Men historien visar att det fungerar annorlunda. Faktum \u00e4r att Amazon beskriver S3 som en grundl\u00e4ggande tj\u00e4nst, eftersom Amazon sj\u00e4lv anv\u00e4nder S3 f\u00f6r lagring av maskinbilder, konfigurationer, AMI-bilder, snapshots\u2026 Och om S3 skulle falla, som det en g\u00e5ng gjorde under de 7 \u00e5r vi har anv\u00e4nt Bitrix24, drar det med sig en massa saker \u2014 fr\u00e5n att virtuella maskiner inte kan starta till problem med API:et och s\u00e5 vidare. <\/p>\n

Och S3 kan faktiskt falla \u2014 det h\u00e4nde en g\u00e5ng. D\u00e4rf\u00f6r kom vi fram till f\u00f6ljande plan: f\u00f6r flera \u00e5r sedan fanns det inga seri\u00f6sa offentliga objekthanteringslagringssystem i Ryssland, och vi \u00f6verv\u00e4gde att skapa n\u00e5got eget... Som tur var p\u00e5b\u00f6rjade vi aldrig det, f\u00f6r vi skulle ha fastnat i den expertis vi saknar och s\u00e4kert \u201dslarvat\u201d. Nu finns det S3-kompatibla lagringsl\u00f6sningar fr\u00e5n Mail.ru, Yandex och flera andra leverant\u00f6rer. Vi kom slutligen fram till att vi ville ha, f\u00f6r det f\u00f6rsta, reservkopiering och f\u00f6r det andra, m\u00f6jlighet att arbeta med lokala kopior. F\u00f6r den ryska regionen anv\u00e4nder vi Mail.ru Hotbox-tj\u00e4nsten, som \u00e4r API-kompatibel med S3. Vi beh\u00f6vde inga st\u00f6rre kodf\u00f6r\u00e4ndringar f\u00f6r applikationen, och vi implementerade f\u00f6ljande mekanism: det finns triggers i S3 som aktiveras vid skapande\/ta bort av objekt, och Amazon erbjuder en tj\u00e4nst som heter Lambda \u2014 det \u00e4r en serverl\u00f6s k\u00f6rning av kod som utf\u00f6rs just n\u00e4r de olika triggerna aktiveras.<\/p>\n

\""Bitrix24":
\n
\nVi gjorde det v\u00e4ldigt enkelt: n\u00e4r en trigger aktiveras, k\u00f6r vi koden som kopierar objektet till Mail.ru-lagringen. F\u00f6r att kunna arbeta fullt ut med lokala datakopior beh\u00f6ver vi ocks\u00e5 bak\u00e5tsynkronisering, s\u00e5 att kunder i den ryska sektorn kan arbeta med lagringen som ligger n\u00e4rmare dem. Mail kommer snart att slutf\u00f6ra triggerna i sin lagring \u2014 det kommer att vara m\u00f6jligt att utf\u00f6ra bak\u00e5tsynkronisering p\u00e5 infrastrukturniv\u00e5, men hittills g\u00f6r vi det p\u00e5 niv\u00e5n av v\u00e5r egen kod. Om vi ser att en kund har laddat upp en fil, placerar vi en h\u00e4ndelse i k\u00f6n p\u00e5 v\u00e5r kodniv\u00e5, bearbetar den och g\u00f6r bak\u00e5treplikering. Det som \u00e4r d\u00e5ligt med detta \u00e4r: om vi har n\u00e5got arbete med v\u00e5ra objekt utanf\u00f6r v\u00e5r produkt, med andra externa verktyg, s\u00e5 r\u00e4knar vi inte med det. D\u00e4rf\u00f6r v\u00e4ntar vi tills triggerna finns p\u00e5 lagringsniv\u00e5n, s\u00e5 att oavsett varifr\u00e5n vi k\u00f6r koden, kan objektet som kom till oss kopieras \u00e5t andra h\u00e5llet. <\/p>\n

P\u00e5 kodniv\u00e5 anges b\u00e5da lagringsl\u00f6sningarna f\u00f6r varje kund: en som \u00e4r prim\u00e4r och en som \u00e4r backup. Om allt fungerar bra arbetar vi med den lagringsl\u00f6sning som \u00e4r n\u00e4rmast oss: det vill s\u00e4ga v\u00e5ra kunder som anv\u00e4nder Amazon arbetar med S3, medan de som verkar i Ryssland anv\u00e4nder Hotbox. Om en signal sl\u00e5r till m\u00e5ste v\u00e5r failover kopplas in, och vi v\u00e4xlar kunderna till en annan lagringsl\u00f6sning. Vi kan aktivera denna signal oberoende av regioner och v\u00e4xla dem fram och tillbaka. I praktiken har vi \u00e4nnu inte anv\u00e4nt detta, men mekanismen \u00e4r f\u00f6rberedd och vi hoppas att vi en dag beh\u00f6ver och f\u00e5r anv\u00e4ndning f\u00f6r denna v\u00e4xling. Detta har redan h\u00e4nt en g\u00e5ng. <\/p>\n

Oj, har er Amazon flytt?<\/h4>\n

\nI april i \u00e5r \u00e4r det \u00e5rsdag f\u00f6r start av blockeringen av Telegram i Ryssland. Den mest drabbade leverant\u00f6ren som p\u00e5verkades \u00e4r Amazon. Och tyv\u00e4rr har det framf\u00f6rallt drabbat ryska f\u00f6retag som arbetade globalt. <\/p>\n

Om f\u00f6retaget \u00e4r globalt och Ryssland utg\u00f6r en v\u00e4ldigt liten del, 3-5% \u2013 ja, p\u00e5 ett eller annat s\u00e4tt kan man offra dem. <\/p>\n

Om det \u00e4r ett rent ryskt f\u00f6retag \u2013 jag \u00e4r s\u00e4ker p\u00e5 att man beh\u00f6ver vara lokaliserad \u2013 det kommer helt enkelt att vara enklare och mer bekv\u00e4mt f\u00f6r anv\u00e4ndarna, med f\u00e4rre risker. <\/p>\n

Och om det \u00e4r ett f\u00f6retag som arbetar globalt och har ungef\u00e4r lika m\u00e5nga kunder i Ryssland som i resten av v\u00e4rlden? Samarbetet mellan segmenten \u00e4r viktigt, och de m\u00e5ste p\u00e5 n\u00e5got s\u00e4tt arbeta tillsammans. <\/p>\n

I slutet av mars 2018 skickade Roskomnadzor ett brev till de st\u00f6rsta operat\u00f6rerna, d\u00e4r de meddelade att de planerade att blockera flera miljoner IP-adresser fr\u00e5n Amazon f\u00f6r att blockera... meddelandetj\u00e4nsten Zello. Tack till dessa leverant\u00f6rer \u2013 de l\u00e4ckte framg\u00e5ngsrikt brevet, och det blev klart att anslutningen till Amazon kan kollapsa. Det var en fredag, och vi rusade i panik till kollegorna p\u00e5 servers.ru och sa: \"V\u00e4nner, vi beh\u00f6ver flera servrar som inte ligger i Ryssland, inte i Amazon, utan till exempel n\u00e5gonstans i Amsterdam\", f\u00f6r att ha m\u00f6jlighet att p\u00e5 n\u00e5got s\u00e4tt placera egna. vpn<\/a> och proxy f\u00f6r vissa endpointar, som vi inte kan p\u00e5verka, till exempel endpointar f\u00f6r samma s3 \u2014 det g\u00e5r inte att f\u00f6rs\u00f6ka starta en ny tj\u00e4nst och f\u00e5 en annan ip, vi m\u00e5ste \u00e4nd\u00e5 n\u00e5 dit. Inom n\u00e5gra dagar hade vi konfigurerat dessa servrar, startat dem, och i stort sett var vi f\u00f6rberedda till blockeringarnas b\u00f6rjan. Intressant nog sa RKN, som s\u00e5g p\u00e5 kaoset och den uppbl\u00e5sta paniken: 'Nej, vi kommer inte att blockera n\u00e5got just nu.' (Men det var precis fram till det \u00f6gonblicket d\u00e5 blockeringen av telegram b\u00f6rjade.) Efter att vi hade st\u00e4llt in m\u00f6jligheterna att kringg\u00e5 blockeringen och f\u00f6rst\u00e5tt att blockeringen inte genomf\u00f6rdes, beslutade vi \u00e4nd\u00e5 att vi inte skulle b\u00f6rja riva upp allt detta. S\u00e5, f\u00f6r s\u00e4kerhets skull. <\/p>\n

\""Bitrix24":
\n
\nOch h\u00e4r lever vi faktiskt 2019 under blockeringar. Jag kollade i g\u00e5r kv\u00e4ll: ungef\u00e4r en miljon ip-blockeringar forts\u00e4tter. Visserligen har de n\u00e4stan helt avblockerat Amazon, vid toppar n\u00e5dde det upp till 20 miljoner adresser\u2026 I allm\u00e4nhet \u00e4r verkligheten s\u00e5dan att det kan saknas anslutning, bra anslutning \u2014 pl\u00f6tsligt. Det kan saknas av tekniska sk\u00e4l \u2014 br\u00e4nder, gr\u00e4vmaskiner och allt det d\u00e4r. Eller, som vi har sett, inte helt tekniska sk\u00e4l. S\u00e5 n\u00e5gon stor och betydande, med egna AS:er, kan f\u00f6rmodligen styra det p\u00e5 andra s\u00e4tt \u2014 direct connect och andra attribut som redan p\u00e5 niv\u00e5 l2. Men i en enklare variant, som vi eller \u00e4nnu mindre, kan man f\u00f6r s\u00e4kerhets skull ha reservkopplingar p\u00e5 serverniv\u00e5, startade n\u00e5gon annanstans, f\u00f6rkonfigurerade vpn, proxy, med m\u00f6jlighet att snabbt v\u00e4xla konfiguration i de segment som \u00e4r kritiska f\u00f6r anslutningen. Detta har vi haft nytta av flera g\u00e5nger n\u00e4r blockeringarna av Amazon b\u00f6rjade, vi dirigerade i v\u00e4rsta fall faktiskt S3-trafik genom dem, men s\u00e5 sm\u00e5ningom l\u00f6ste allt sig.<\/p>\n

Men hur reserverar man\u2026 en hel tj\u00e4nsteleverant\u00f6r?<\/h4>\n

\nF\u00f6r n\u00e4rvarande har vi ingen plan f\u00f6r en total nedst\u00e4ngning av Amazon. Vi har en liknande plan f\u00f6r Ryssland. Vi anv\u00e4nde en leverant\u00f6r i Ryssland d\u00e4r vi valde att ha flera platser. F\u00f6r ett \u00e5r sedan st\u00f6tte vi p\u00e5 ett problem: \u00e4ven om det \u00e4r tv\u00e5 datacenter kan det p\u00e5 leverant\u00f6rens n\u00e4tverkskonfiguration uppst\u00e5 problem som p\u00e5verkar b\u00e5da datacentren. Vi kan f\u00e5 otillg\u00e4nglighet p\u00e5 b\u00e5da platserna. Och s\u00e5 blev det. I slut\u00e4ndan har vi omv\u00e4rderat v\u00e5r arkitektur. Den har inte f\u00f6r\u00e4ndrats s\u00e5 mycket, men f\u00f6r Ryssland har vi nu tv\u00e5 platser, som inte ligger hos samma leverant\u00f6r utan hos tv\u00e5 olika. Om n\u00e5got g\u00e5r fel hos en av dem kan vi v\u00e4xla till den andra.<\/p>\n

Hypotetiskt sett \u00f6verv\u00e4ger vi att f\u00f6r Amazon reservera hos en annan leverant\u00f6r; kanske Google, eller n\u00e5gon annan... Men hittills har vi i praktiken sett att om Amazon drabbas av problem i en enskild availability-zon s\u00e5 \u00e4r stora problem p\u00e5 regional niv\u00e5 ganska s\u00e4llsynta. D\u00e4rf\u00f6r har vi en teoretisk uppfattning om att vi kanske kommer att g\u00f6ra en reservl\u00f6sning f\u00f6r \"Amazon - inte Amazon\", men i praktiken har det \u00e4nnu inte h\u00e4nt. <\/p>\n

N\u00e5gra ord om automatisering<\/h4>\n

\n\u00c4r automatisering alltid n\u00f6dv\u00e4ndig? H\u00e4r \u00e4r det l\u00e4mpligt att p\u00e5minna om Dunning-Kruger-effekten. P\u00e5 x-axeln har vi v\u00e5r kunskap och erfarenhet som vi samlar, och p\u00e5 y-axeln sj\u00e4lvf\u00f6rtroendet i v\u00e5ra handlingar. F\u00f6rst vet vi ingenting och har v\u00e4ldigt lite sj\u00e4lvf\u00f6rtroende. Sedan vet vi lite b\u00e4ttre och blir megasj\u00e4lvs\u00e4kra - det kallas \"dumhetens topp\", v\u00e4l illustrerat av bilden \"idioti och mod\". D\u00e4refter har vi l\u00e4rt oss lite och \u00e4r redo att g\u00e5 in i striden. Sedan trillar vi p\u00e5 n\u00e5gra allvarliga fallgropar, hamnar i f\u00f6rtvivlans dal, d\u00e4r vi verkar veta n\u00e5got, men i sj\u00e4lva verket vet vi fortfarande v\u00e4ldigt lite. Sedan, med mer erfarenhet, blir vi mer sj\u00e4lvs\u00e4kra.<\/p>\n

\""Bitrix24":
\n
\nV\u00e5r logik kring olika omkopplingar automatiskt vid olika incidenter beskrivs mycket v\u00e4l av denna graf. Vi b\u00f6rjade med att vi ingenting kunde, n\u00e4stan allt arbete utf\u00f6rdes manuellt. Sedan ins\u00e5g vi att vi kunde s\u00e4tta p\u00e5 en automatisk l\u00f6sning f\u00f6r allt och, liksom, sova lugnt. Men pl\u00f6tsligt snubblade vi p\u00e5 stora problem: vi f\u00e5r en falsk positiv, och vi v\u00e4xlar fram och tillbaka trafik n\u00e4r vi egentligen inte borde ha gjort det. D\u00e4rmed g\u00e5r replikeringen s\u00f6nder eller n\u00e5got annat \u2014 det \u00e4r den ber\u00f6mda dalen av f\u00f6rtvivlan. Och sedan kommer vi till insikten att man alltid m\u00e5ste t\u00e4nka smart. Det vill s\u00e4ga, det \u00e4r meningsfullt att f\u00f6rlita sig p\u00e5 automatik, med tanke p\u00e5 m\u00f6jligheten f\u00f6r falska positiva. Men! Om konsekvenserna kan vara f\u00f6r\u00f6dande, \u00e4r det b\u00e4ttre att \u00f6verl\u00e5ta detta till skiftledningen, de jouransvariga ingenj\u00f6rerna, som kan se till att det verkligen \u00e4r en incident och utf\u00f6ra de n\u00f6dv\u00e4ndiga \u00e5tg\u00e4rderna manuellt\u2026<\/p>\n

Slutsats<\/h4>\n

\nUnder 7 \u00e5r har vi g\u00e5tt fr\u00e5n att n\u00e4r n\u00e5got kraschade var det panik-paniken, till att f\u00f6rst\u00e5 att problem inte existerar, det finns bara uppgifter som m\u00e5ste - och kan - l\u00f6sas. N\u00e4r du bygger en tj\u00e4nst, se p\u00e5 den fr\u00e5n ovan, bed\u00f6m alla risker som kan intr\u00e4ffa. Om du genast ser dem - f\u00f6rutse reservl\u00f6sningar och m\u00f6jligheten att bygga en fel-tolerant infrastruktur, eftersom varje punkt som kan g\u00e5 s\u00f6nder och f\u00e5 tj\u00e4nsten att inte fungera - kommer definitivt att g\u00f6ra det. Och \u00e4ven om det verkar som om vissa infrastrukturelement absolut inte kommer att g\u00e5 s\u00f6nder \u2014 som s3 \u2014 kom ih\u00e5g att de kan. Och \u00e5tminstone i teorin, ha en uppfattning om vad du ska g\u00f6ra med dem om n\u00e5got skulle h\u00e4nda. Ha en plan f\u00f6r riskhantering. N\u00e4r du \u00f6verv\u00e4ger att g\u00f6ra allt automatiskt eller manuellt - bed\u00f6m riskerna: vad h\u00e4nder om automatik b\u00f6rjar v\u00e4xla allt \u2014 kommer det att leda till en \u00e4nnu s\u00e4mre situation j\u00e4mf\u00f6rt med en incident? Kanske beh\u00f6ver man n\u00e5gonstans ett rimligt avv\u00e4gande mellan anv\u00e4ndningen av automatik och reaktionen fr\u00e5n den jouransvarige ingenj\u00f6ren, som bed\u00f6mer den verkliga situationen och f\u00f6rst\u00e5r om n\u00e5got hastigt beh\u00f6ver v\u00e4xlas eller \"ja, men inte just nu\".<\/p>\n

En rimlig kompromiss mellan perfektionism och de verkliga resurser, tiden och pengarna som du kan l\u00e4gga p\u00e5 den l\u00f6sning du kommer att f\u00e5.<\/p>\n

Denna text \u00e4r en ut\u00f6kad och f\u00f6rdjupad version av Alexander Demidovs rapport vid konferensen Uptime dag 4<\/a><\/noindex>.<\/i>
\n
K\u00e4lla: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35092","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\udd47\"Bitrix24\": \"Snabbt uppf\u00f6rt r\u00e4knas inte som nedfallet\" | ProHoster","description":"I dagsl\u00e4get har tj\u00e4nsten \"Bitrix24\" varken hundratals gigabit trafik eller en stor serverpark (\u00e4ven om det finns ganska m\u00e5nga).","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","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\udd47\u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb: \u00ab\u0411\u044b\u0441\u0442\u0440\u043e \u043f\u043e\u0434\u043d\u044f\u0442\u043e\u0435 \u043d\u0435 \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u0443\u043f\u0430\u0432\u0448\u0438\u043c\u00bb | ProHoster","og:description":"\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e).","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","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:02:18+00:00","article:modified_time":"2019-10-31T19:02:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35092","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-02-04 14:51:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:10:27","updated":"2026-02-04 14:51: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\/35092","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=35092"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/35092\/revisions"}],"predecessor-version":[{"id":156668,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/35092\/revisions\/156668"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/26389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=35092"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=35092"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=35092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}