I dagslĂ€get har tjĂ€nsten "Bitrix24" varken hundratals gigabit trafik eller en stor serverpark (Ă€ven om det finns en hel del). Men för mĂ„nga kunder Ă€r det det viktigaste arbetsverktyget i företaget, en verklig business-critical applikation. DĂ€rför fĂ„r det inte krascha â pĂ„ nĂ„got sĂ€tt. Men vad hĂ€nder om det faktiskt intrĂ€ffar, men tjĂ€nsten "Ă„teruppstĂ„r" sĂ„ snabbt att ingen mĂ€rker nĂ„got? Och hur lyckas man genomföra en failover utan att förlora kvalitet och kunder? Alexander Demidov, chef för den molnbaserade tjĂ€nsteverksamheten "Bitrix24", berĂ€ttade för vĂ„r blogg om hur reservsystemet har utvecklats under de 7 Ă„r produkten funnits.
Som SaaS lanserade vi "Bitrix24" för 7 Ă„r sedan. Den största utmaningen var nog följande: innan lanseringen som SaaS fanns produkten bara i form av en boxlösning. Kunder köpte den frĂ„n oss, installerade den pĂ„ sina servrar, skapade en företagsportal â en gemensam lösning för anstĂ€lldas kommunikation, filhantering, uppgiftshantering, CRM, allt detta. Och vi bestĂ€mde oss 2012 för att vi ville lansera detta som SaaS, administrera det sjĂ€lva och sĂ€kerstĂ€lla just den driftsĂ€kerheten och tillförlitligheten. Vi samlade erfarenhet under processen, eftersom vi innan dess inte hade nĂ„got â vi var bara programvarutillverkare, inte tjĂ€nsteleverantörer.
NĂ€r vi lanserade tjĂ€nsten förstod vi att det viktigaste var att sĂ€kerstĂ€lla driftsĂ€kerhet, pĂ„litlighet och stĂ€ndig tillgĂ€nglighet av tjĂ€nsten, för om du har en vanlig webbsida, som en butik, och den kraschar och ligger nere i en timme â dĂ„ drabbas bara du, du förlorar bestĂ€llningar och kunder, men för din kund â för honom Ă€r det inte sĂ„ kritiskt. Han blir besviken, sĂ„klart, men gĂ„r vidare och köper pĂ„ en annan webbplats. Men om det Ă€r en applikation som hela företagets arbete, kommunikation och beslut hĂ€nger pĂ„, Ă€r det avgörande att vinna anvĂ€ndarnas förtroende, dvs. att inte svika dem och att inte krascha. För hela arbetet kan stanna av om nĂ„got inuti inte fungerar.
Bitrix.24 som SaaS
Den första prototypen satte vi ihop ett Ă„r innan den offentliga lanseringen, 2011. Vi byggde den pĂ„ ungefĂ€r en vecka, testade och vridbygde â den fungerade till och med. Man kunde logga in i formulĂ€ret, ange namnet pĂ„ portalen, en ny portal skulle skapas och en anvĂ€ndardatabas etableras. Vi tittade pĂ„ den, vĂ€rderade produkten i stort, lade ner den, och fortsatte att arbeta med den i ett helt Ă„r. Vi hade en stor uppgift: vi ville inte skapa tvĂ„ olika kodbaser, vi ville inte stödja en separat boxprodukt och separata molnlösningar â vi ville göra allt inom en och samma kod.
Ett typiskt webbapplikation pĂ„ den tiden var â en server dĂ€r nĂ„got php-kod kördes, en mysql-databas, filer laddades upp, dokument och bilder lades i en upload-mapp â och allt det hĂ€r fungerade. TyvĂ€rr gĂ„r det inte att lansera en kritiskt stabil webbservice pĂ„ detta. DĂ€r stöds inte distribuerad cache, och replikering av databaser stöds inte.
Vi formulerade kraven: det handlar om att kunna placera sig pĂ„ olika platser, stödja replikering, helst att finnas i geografiskt fördelade datacenter. Dela upp produktens logik och lagring av data. Dynamiskt kunna skalas efter belastningen, och statiska datan ska flyttas ut. UtifrĂ„n dessa övervĂ€ganden skapades kraven pĂ„ produkten vi utvecklade under det Ă„ret. Under den tiden i plattformen, som blev enhetlig â för boxlösningar, för vĂ„r egen tjĂ€nst â gjorde vi stöd för de saker som var nödvĂ€ndiga för oss. Stöd för mysql-replikering pĂ„ produktnivĂ„: det vill sĂ€ga utvecklaren som skriver koden behöver inte tĂ€nka pĂ„ hur deras förfrĂ„gningar distribueras, de anvĂ€nder vĂ„rt api, och vi kan korrekt fördela skriv- och lĂ€sförfrĂ„gningar mellan master- och slave-servrar.
Vi implementerade stöd pĂ„ produktiv nivĂ„ för olika molnbaserade objektlagringssystem: google storage, amazon s3 â plus, stöd för open stack swift. DĂ€rför var det praktiskt bĂ„de för oss som tjĂ€nst och för utvecklarna som arbetar med boxlösningen: om de enbart anvĂ€nder vĂ„rt api för arbete, behöver de inte tĂ€nka pĂ„ var filen slutligen sparas, om det Ă€r lokalt pĂ„ filsystemet eller om det hamnar i objektlagringssystemet.
Som resultat beslutade vi direkt att vi skulle göra reservationer pĂ„ hela datacenter-nivĂ„. Ă r 2012 startade vi helt pĂ„ Amazon AWS eftersom vi redan hade erfarenhet av att arbeta med denna plattform â vĂ„r egen webbplats var placerad dĂ€r. Det som lockade oss var att det i varje region pĂ„ Amazon finns flera tillgĂ€nglighetszoner â i deras terminologi, flera datacenter, som Ă€r mer eller mindre oberoende av varandra och gör att vi kan göra reservationer pĂ„ datacenter-nivĂ„: om ett av dem skulle gĂ„ ner, sĂ„ replikeras databaserna master-master, webbapplikationsservrarna Ă€r reserverade och statiska filer lagras i S3-objektslagring. Belastningen balanseras â vid den tiden med Amazons ELB, men lite senare kom vi till vĂ„ra egna lastbalanserare eftersom vi behövde en mer komplex logik.
Vad vi ville ha, fick vi...
Alla grundlĂ€ggande saker som vi ville sĂ€kerstĂ€lla â redundans för sjĂ€lva servrarna, webbapplikationerna, databaserna â fungerade bra. Det enklaste scenariot: om nĂ„gon av vĂ„ra webbapplikationer gĂ„r ner, Ă€r det hĂ€r enkelt â de tas bort frĂ„n lastbalanseringen.
De utrustningar som gick ner markerades som unhealthy av lastbalanseraren (dĂ„ var det Amazons ELB), som stĂ€ngde av lastbalanseringen pĂ„ dem. Amazons autoskalning fungerade: nĂ€r belastningen ökade, lades nya maskiner till autoskalningsgruppen, och belastningen distribuerades pĂ„ de nya maskinerna â allt fungerade bra. Med vĂ„ra lastbalanserare Ă€r logiken i stort sett densamma: om nĂ„got hĂ€nder med applikationsservern tar vi bort förfrĂ„gningar frĂ„n den, slĂ€nger dessa maskiner, startar nya och fortsĂ€tter arbeta. Schemat har förĂ€ndrats nĂ„got genom Ă„ren, men fortsĂ€tter att fungera: det Ă€r enkelt, tydligt och det finns inga svĂ„righeter med det.
Vi arbetar över hela vĂ€rlden, och belastningstoppar hos kunderna Ă€r helt olika, och för att vara Ă€rliga bör vi kunna utföra servicearbete pĂ„ alla komponenter i vĂ„rt system nĂ€r som helst â utan att kunderna mĂ€rker det. DĂ€rför har vi möjlighet att stĂ€nga av databasen och omfördela belastningen till det andra datacentret.
Hur fungerar allt detta? â Vi vĂ€xlar trafiken till det fungerande datacentret â om det Ă€r en krasch i datacentret, sĂ„ gör vi det helt, om det Ă€r vĂ„rt planerade arbete i nĂ„gon specifik databas, sĂ„ vĂ€xlar vi en del av trafiken som betjĂ€nar dessa kunder till det andra datacentret, replicationen pausas. Om vi behöver nya maskiner för webbapplikationer eftersom belastningen har ökat i det andra datacentret, startar de automatiskt. Vi avslutar arbetet, replicationen Ă„terstĂ€lls, och vi Ă„terför hela belastningen. Om vi behöver genomföra speglade arbeten i det andra DC, till exempel installera systemuppdateringar eller Ă€ndra instĂ€llningar i den andra databasen, sĂ„ gör vi i stort sett exakt samma, bara i den andra riktningen. Och om det Ă€r en krasch, gör vi helt enkelt följande: i övervakningssystemet anvĂ€nder vi mekanismen event-handlers. Om flera kontroller aktiveras och status övergĂ„r till kritisk, aktiveras denna handler, en bearbetare som kan utföra viss logik. För varje databas har vi angivit vilken server som Ă€r failover för den och vart trafiken ska omkopplas i hĂ€ndelse av att den inte Ă€r tillgĂ€nglig. Historiskt sett har vi anvĂ€nt nagios eller dess varianter. I princip finns sĂ„dana mekanismer i praktiskt taget alla övervakningssystem, nĂ„got mer komplext anvĂ€nder vi Ă€n sĂ„ lĂ€nge inte, men vi kanske kommer att göra det i framtiden. För tillfĂ€llet reagerar övervakningen pĂ„ brister i tillgĂ€ngligheten och har möjligheten att omdirigera nĂ„got.
Har vi reserverat allt?
Vi har mĂ„nga kunder frĂ„n USA, mĂ„nga kunder frĂ„n Europa, och mĂ„nga kunder som ligger nĂ€rmare öst â som Japan, Singapore och sĂ„ vidare. SjĂ€lvklart Ă€r en betydande del av kunderna frĂ„n Ryssland. Det betyder att verksamheten inte bara Ă€r i ett enda omrĂ„de. AnvĂ€ndarna vill ha snabb respons, det finns krav pĂ„ att följa olika lokala lagar, och inom varje region reserverar vi oss för tvĂ„ datacenter, plus att det finns vissa ytterligare tjĂ€nster som Ă€r bekvĂ€ma att placera inom en region â för kunder som arbetar i det omrĂ„det. REST-handlarna, autentiseringservrarna, de Ă€r mindre kritiska för kundens övergripande arbete, man kan vĂ€xla mellan dem med en liten acceptabel fördröjning, men man vill inte uppfinna hjulet pĂ„ nytt nĂ€r det gĂ€ller hur man övervakar dem och vad man ska göra med dem. DĂ€rför försöker vi maximalt anvĂ€nda redan existerande lösningar, snarare Ă€n att utveckla en egen kompetens inom ytterligare produkter. Och pĂ„ vissa stĂ€llen anvĂ€nder vi helt enkelt DNS-nivĂ„svĂ€ngningar, dĂ€r vi bestĂ€mmer tjĂ€nstens livskraft med samma DNS. I Amazon finns tjĂ€nsten Route 53, men det Ă€r inte bara DNS dĂ€r man kan lĂ€gga in poster och vara klar â det Ă€r mycket mer flexibelt och praktiskt. Genom den kan man bygga geografiskt distribuerade tjĂ€nster med geografiska platser, nĂ€r man med hjĂ€lp av den bestĂ€mmer varifrĂ„n kunden kom och ger dem olika poster â med den kan man bygga failover-arkitekturer. De samma hĂ€lsokontroller stĂ€lls in i Route 53, man anger endpoint som övervakas, anger mĂ€tvĂ€rden, och specificerar vilka protokoll som ska anvĂ€ndas för att bestĂ€mma tjĂ€nstens
Första "men": men hur ska man sÀkerhetskopiera Route 53? Vad hÀnder om nÄgot gÄr fel? Lyckligtvis har vi aldrig stött pÄ det problemet, men jag kommer att berÀtta varför vi tycker att det Àr viktigt att sÀkerhetskopiera. HÀr förbereder vi oss i förvÀg. Flera gÄnger om dagen gör vi en fullstÀndig export av alla zoner vi har i Route 53. Amazons API gör det enkelt att exportera dem i JSON-format, och vi har nÄgra reservservrar dÀr vi konverterar och exporterar dem som konfigurationer, och har, grovt sett, en backupkonfiguration. Om nÄgot skulle hÀnda kan vi snabbt ÄterstÀlla den manuellt och vi förlorar inte nÄgra DNS-instÀllningar.
Det andra 'men': vad Ă€r inte reserverat i denna bild? SjĂ€lva lastbalanseraren! Vi har fördelat kunderna efter regioner pĂ„ ett mycket enkelt sĂ€tt. Vi har domĂ€ner som bitrix24.ru, bitrix24.com, .de â just nu har vi cirka 13 olika domĂ€ner som fungerar i mĂ„nga olika zoner. Vi har kommit fram till följande: varje region har sina egna lastbalanserare. Det Ă€r lĂ€ttare att fördela baserat pĂ„ var den högsta nĂ€tbelastningen Ă€r. Om det blir ett fel pĂ„ en specifik lastbalanserare sĂ„ tas den helt enkelt ur bruk och tas bort frĂ„n DNS. Om det uppstĂ„r problem med en grupp lastbalanserare sĂ„ reserveras de pĂ„ andra platser, och omkopplingen mellan dem görs med samma Route 53, eftersom omkopplingen sker med en kort TTL, max inom 2, 3, 5 minuter.
Det tredje 'men': vad Ă€r Ă€nnu inte reserverat? S3, korrekt. NĂ€r vi lagrar filer som anvĂ€nds av vĂ„ra anvĂ€ndare i S3, trodde vi verkligen att det var oförstörbart och att vi inte behövde göra nĂ„gra reservationer dĂ€r. Men historien visar att det fungerar annorlunda. Faktum Ă€r att Amazon beskriver S3 som en grundlĂ€ggande tjĂ€nst, eftersom Amazon sjĂ€lv anvĂ€nder S3 för lagring av maskinbilder, konfigurationer, AMI-bilder, snapshots⊠Och om S3 skulle falla, som det en gĂ„ng gjorde under de 7 Ă„r vi har anvĂ€nt Bitrix24, drar det med sig en massa saker â frĂ„n att virtuella maskiner inte kan starta till problem med API:et och sĂ„ vidare.
Och S3 kan faktiskt falla â det hĂ€nde en gĂ„ng. DĂ€rför kom vi fram till följande plan: för flera Ă„r sedan fanns det inga seriösa offentliga objekthanteringslagringssystem i Ryssland, och vi övervĂ€gde att skapa nĂ„got eget... Som tur var pĂ„började vi aldrig det, för vi skulle ha fastnat i den expertis vi saknar och sĂ€kert âslarvatâ. Nu finns det S3-kompatibla lagringslösningar frĂ„n Mail.ru, Yandex och flera andra leverantörer. Vi kom slutligen fram till att vi ville ha, för det första, reservkopiering och för det andra, möjlighet att arbeta med lokala kopior. För den ryska regionen anvĂ€nder vi Mail.ru Hotbox-tjĂ€nsten, som Ă€r API-kompatibel med S3. Vi behövde inga större kodförĂ€ndringar för applikationen, och vi implementerade följande mekanism: det finns triggers i S3 som aktiveras vid skapande/ta bort av objekt, och Amazon erbjuder en tjĂ€nst som heter Lambda â det Ă€r en serverlös körning av kod som utförs just nĂ€r de olika triggerna aktiveras.
Vi gjorde det vĂ€ldigt enkelt: nĂ€r en trigger aktiveras, kör vi koden som kopierar objektet till Mail.ru-lagringen. För att kunna arbeta fullt ut med lokala datakopior behöver vi ocksĂ„ bakĂ„tsynkronisering, sĂ„ att kunder i den ryska sektorn kan arbeta med lagringen som ligger nĂ€rmare dem. Mail kommer snart att slutföra triggerna i sin lagring â det kommer att vara möjligt att utföra bakĂ„tsynkronisering pĂ„ infrastrukturnivĂ„, men hittills gör vi det pĂ„ nivĂ„n av vĂ„r egen kod. Om vi ser att en kund har laddat upp en fil, placerar vi en hĂ€ndelse i kön pĂ„ vĂ„r kodnivĂ„, bearbetar den och gör bakĂ„treplikering. Det som Ă€r dĂ„ligt med detta Ă€r: om vi har nĂ„got arbete med vĂ„ra objekt utanför vĂ„r produkt, med andra externa verktyg, sĂ„ rĂ€knar vi inte med det. DĂ€rför vĂ€ntar vi tills triggerna finns pĂ„ lagringsnivĂ„n, sĂ„ att oavsett varifrĂ„n vi kör koden, kan objektet som kom till oss kopieras Ă„t andra hĂ„llet.
PÄ kodnivÄ anges bÄda lagringslösningarna för varje kund: en som Àr primÀr och en som Àr backup. Om allt fungerar bra arbetar vi med den lagringslösning som Àr nÀrmast oss: det vill sÀga vÄra kunder som anvÀnder Amazon arbetar med S3, medan de som verkar i Ryssland anvÀnder Hotbox. Om en signal slÄr till mÄste vÄr failover kopplas in, och vi vÀxlar kunderna till en annan lagringslösning. Vi kan aktivera denna signal oberoende av regioner och vÀxla dem fram och tillbaka. I praktiken har vi Ànnu inte anvÀnt detta, men mekanismen Àr förberedd och vi hoppas att vi en dag behöver och fÄr anvÀndning för denna vÀxling. Detta har redan hÀnt en gÄng.
Oj, har er Amazon flytt?
I april i Är Àr det Ärsdag för start av blockeringen av Telegram i Ryssland. Den mest drabbade leverantören som pÄverkades Àr Amazon. Och tyvÀrr har det framförallt drabbat ryska företag som arbetade globalt.
Om företaget Ă€r globalt och Ryssland utgör en vĂ€ldigt liten del, 3-5% â ja, pĂ„ ett eller annat sĂ€tt kan man offra dem.
Om det Ă€r ett rent ryskt företag â jag Ă€r sĂ€ker pĂ„ att man behöver vara lokaliserad â det kommer helt enkelt att vara enklare och mer bekvĂ€mt för anvĂ€ndarna, med fĂ€rre risker.
Och om det Àr ett företag som arbetar globalt och har ungefÀr lika mÄnga kunder i Ryssland som i resten av vÀrlden? Samarbetet mellan segmenten Àr viktigt, och de mÄste pÄ nÄgot sÀtt arbeta tillsammans.
I slutet av mars 2018 skickade Roskomnadzor ett brev till de största operatörerna, dĂ€r de meddelade att de planerade att blockera flera miljoner IP-adresser frĂ„n Amazon för att blockera... meddelandetjĂ€nsten Zello. Tack till dessa leverantörer â de lĂ€ckte framgĂ„ngsrikt brevet, och det blev klart att anslutningen till Amazon kan kollapsa. Det var en fredag, och vi rusade i panik till kollegorna pĂ„ servers.ru och sa: "VĂ€nner, vi behöver flera servrar som inte ligger i Ryssland, inte i Amazon, utan till exempel nĂ„gonstans i Amsterdam", för att ha möjlighet att pĂ„ nĂ„got sĂ€tt placera egna. vpn och proxy för vissa endpointar, som vi inte kan pĂ„verka, till exempel endpointar för S3 â vi kan inte bara försöka starta en ny tjĂ€nst och fĂ„ en annan ip, vi mĂ„ste fortfarande nĂ„ dit. Under nĂ„gra dagar konfigurerade vi dessa servrar, startade dem, och i allmĂ€nhet var vi förberedda tills blockeringarna började. Det Ă€r intressant att RKN, efter att ha sett all uppstĂ„ndelse och panik, sa: "Nej, vi kommer inte att blockera nĂ„got nu". (Men det var precis fram till dess att de började blockera Telegram.) NĂ€r vi hade stĂ€llt in bypass-möjligheter och förstĂ„tt att blockeringen inte infördes, valde vi Ă€ndĂ„ att inte ta itu med hela situationen. SĂ„, bara för sĂ€kerhets skull.
Och hĂ€r lever vi faktiskt 2019 under blockeringar. Jag kollade i gĂ„r kvĂ€ll: ungefĂ€r en miljon ip-blockeringar fortsĂ€tter. Visserligen har de nĂ€stan helt avblockerat Amazon, vid toppar nĂ„dde det upp till 20 miljoner adresser⊠I allmĂ€nhet Ă€r verkligheten sĂ„dan att det kan saknas anslutning, bra anslutning â plötsligt. Det kan saknas av tekniska skĂ€l â brĂ€nder, grĂ€vmaskiner och allt det dĂ€r. Eller, som vi har sett, inte helt tekniska skĂ€l. SĂ„ nĂ„gon stor och betydande, med egna AS:er, kan förmodligen styra det pĂ„ andra sĂ€tt â direct connect och andra attribut som redan pĂ„ nivĂ„ l2. Men i en enklare variant, som vi eller Ă€nnu mindre, kan man för sĂ€kerhets skull ha reservkopplingar pĂ„ servernivĂ„, startade nĂ„gon annanstans, förkonfigurerade vpn, proxy, med möjlighet att snabbt vĂ€xla konfiguration i de segment som Ă€r kritiska för anslutningen. Detta har vi haft nytta av flera gĂ„nger nĂ€r blockeringarna av Amazon började, vi dirigerade i vĂ€rsta fall faktiskt S3-trafik genom dem, men sĂ„ smĂ„ningom löste allt sig.
Men hur reserverar man⊠en hel tjÀnsteleverantör?
För nÀrvarande har vi ingen plan för en total nedstÀngning av Amazon. Vi har en liknande plan för Ryssland. Vi anvÀnde en leverantör i Ryssland dÀr vi valde att ha flera platser. För ett Är sedan stötte vi pÄ ett problem: Àven om det Àr tvÄ datacenter kan det pÄ leverantörens nÀtverkskonfiguration uppstÄ problem som pÄverkar bÄda datacentren. Vi kan fÄ otillgÀnglighet pÄ bÄda platserna. Och sÄ blev det. I slutÀndan har vi omvÀrderat vÄr arkitektur. Den har inte förÀndrats sÄ mycket, men för Ryssland har vi nu tvÄ platser, som inte ligger hos samma leverantör utan hos tvÄ olika. Om nÄgot gÄr fel hos en av dem kan vi vÀxla till den andra.
Hypotetiskt sett övervÀger vi att för Amazon reservera hos en annan leverantör; kanske Google, eller nÄgon annan... Men hittills har vi i praktiken sett att om Amazon drabbas av problem i en enskild availability-zon sÄ Àr stora problem pÄ regional nivÄ ganska sÀllsynta. DÀrför har vi en teoretisk uppfattning om att vi kanske kommer att göra en reservlösning för "Amazon - inte Amazon", men i praktiken har det Ànnu inte hÀnt.
NĂ„gra ord om automatisering
Ăr automatisering alltid nödvĂ€ndig? HĂ€r Ă€r det lĂ€mpligt att pĂ„minna om Dunning-Kruger-effekten. PĂ„ x-axeln har vi vĂ„r kunskap och erfarenhet som vi samlar, och pĂ„ y-axeln sjĂ€lvförtroendet i vĂ„ra handlingar. Först vet vi ingenting och har vĂ€ldigt lite sjĂ€lvförtroende. Sedan vet vi lite bĂ€ttre och blir megasjĂ€lvsĂ€kra - det kallas "dumhetens topp", vĂ€l illustrerat av bilden "idioti och mod". DĂ€refter har vi lĂ€rt oss lite och Ă€r redo att gĂ„ in i striden. Sedan trillar vi pĂ„ nĂ„gra allvarliga fallgropar, hamnar i förtvivlans dal, dĂ€r vi verkar veta nĂ„got, men i sjĂ€lva verket vet vi fortfarande vĂ€ldigt lite. Sedan, med mer erfarenhet, blir vi mer sjĂ€lvsĂ€kra.
VĂ„r logik kring olika omkopplingar automatiskt vid olika incidenter beskrivs mycket vĂ€l av denna graf. Vi började med att vi ingenting kunde, nĂ€stan allt arbete utfördes manuellt. Sedan insĂ„g vi att vi kunde sĂ€tta pĂ„ en automatisk lösning för allt och, liksom, sova lugnt. Men plötsligt snubblade vi pĂ„ stora problem: vi fĂ„r en falsk positiv, och vi vĂ€xlar fram och tillbaka trafik nĂ€r vi egentligen inte borde ha gjort det. DĂ€rmed gĂ„r replikeringen sönder eller nĂ„got annat â det Ă€r den berömda dalen av förtvivlan. Och sedan kommer vi till insikten att man alltid mĂ„ste tĂ€nka smart. Det vill sĂ€ga, det Ă€r meningsfullt att förlita sig pĂ„ automatik, med tanke pĂ„ möjligheten för falska positiva. Men! Om konsekvenserna kan vara förödande, Ă€r det bĂ€ttre att överlĂ„ta detta till skiftledningen, de jouransvariga ingenjörerna, som kan se till att det verkligen Ă€r en incident och utföra de nödvĂ€ndiga Ă„tgĂ€rderna manuelltâŠ
Slutsats
Under 7 Ă„r har vi gĂ„tt frĂ„n att nĂ€r nĂ„got kraschade var det panik-paniken, till att förstĂ„ att problem inte existerar, det finns bara uppgifter som mĂ„ste - och kan - lösas. NĂ€r du bygger en tjĂ€nst, se pĂ„ den frĂ„n ovan, bedöm alla risker som kan intrĂ€ffa. Om du genast ser dem - förutse reservlösningar och möjligheten att bygga en fel-tolerant infrastruktur, eftersom varje punkt som kan gĂ„ sönder och fĂ„ tjĂ€nsten att inte fungera - kommer definitivt att göra det. Och Ă€ven om det verkar som om vissa infrastrukturelement absolut inte kommer att gĂ„ sönder â som s3 â kom ihĂ„g att de kan. Och Ă„tminstone i teorin, ha en uppfattning om vad du ska göra med dem om nĂ„got skulle hĂ€nda. Ha en plan för riskhantering. NĂ€r du övervĂ€ger att göra allt automatiskt eller manuellt - bedöm riskerna: vad hĂ€nder om automatik börjar vĂ€xla allt â kommer det att leda till en Ă€nnu sĂ€mre situation jĂ€mfört med en incident? Kanske behöver man nĂ„gonstans ett rimligt avvĂ€gande mellan anvĂ€ndningen av automatik och reaktionen frĂ„n den jouransvarige ingenjören, som bedömer den verkliga situationen och förstĂ„r om nĂ„got hastigt behöver vĂ€xlas eller "ja, men inte just nu".
En rimlig kompromiss mellan perfektionism och de verkliga resurser, tiden och pengarna som du kan lÀgga pÄ den lösning du kommer att fÄ.
Denna text Àr en utökad och fördjupad version av Alexander Demidovs rapport vid konferensen .
KĂ€lla: habr.com
