Facebook forklarer hvordan den historiske undergangen skjedde og hvordan den løste det

Høsten av Facebook over hele verden som skjedde på mandag har vært en før og etter i selskapet, og det er at de var fullstendig koblet fra Internett i mer enn 5 timer, noe uten sidestykke for et av de største selskapene i verden. Nå som Facebook -plattformen, WhatsApp og Instagram har kommet seg 100% fra krasjet som skjedde mandag, har Facebook -teamet publisert detaljer om hvordan krasjet skjedde, hvorfor det skjedde og også hvordan de klarte å fikse det. Vil du vite alle detaljene om den største krasjen i Facebook -historien så langt?

Facebook forklarer hvordan den historiske undergangen skjedde

Hvordan fungerer Facebook, og hvorfor skjedde den totale undergangen?

Facebook har indikert at det totale avbruddet i tjenesten over hele verden skyldtes en feil i systemet som administrerer kapasiteten til selskapets ryggrad, denne ryggraden er "ryggraden" i Facebook -nettverket, for å koble alle datasentrene som Facebook har spredt alle over hele verden, som består av tusenvis av servere og hundrevis av kilometer med fiberoptikk, siden de også kobler datasentrene sine med sjøkabler. Noen Facebook -datasentre har millioner av servere som lagrer dataene og har høy beregningsbelastning, men i andre tilfeller er fasilitetene mindre og er ansvarlige for å koble ryggraden til Internett generelt for at folk skal bruke plattformene sine.

Når en bruker som oss kobler seg til Facebook eller Instagram, reiser forespørselen om data fra enheten til det nærmeste anlegget geografisk, for senere å kommunisere direkte med ryggraden for å få tilgang til de største datasentrene, det er her den henter den forespurte informasjonen og er behandlet, slik at vi kan se det på smarttelefonen.

All datatrafikk mellom de forskjellige datasentrene administreres av rutere, som bestemmer hvor inn- og utgående data skal sendes. Som en del av det daglige arbeidet må Facebooks ingeniørteam vedlikeholde denne infrastrukturen og utføre oppgaver som oppgradering av rutere, reparasjon av fiberlinjer eller mer kapasitet på bestemte nettverk. Dette var problemet med den globale Facebook -krasjen mandag.

Under vedlikeholdsarbeid ble det sendt en kommando med den hensikt å evaluere tilgjengeligheten av den globale ryggradskapasiteten, men den avbrøt ved et uhell alle ryggradstilkoblinger og koblet alle Facebook -datasentre globalt. Vanligvis bruker Facebook systemer for å revidere denne typen kommandoer, og redusere eller unngå feil som dette, men en feil (feil) i dette revisjons- og endringskontrollverktøyet forhindret at utførelsen av ordren ble stoppet, og da falt alt fra hverandre.

Hva skjedde på Facebook da jeg kjørte kommandoen?

Så snart kommandoen ble utført, forårsaket det en total frakobling av Internett og datasenterforbindelser, det vil si at vi ikke kunne få tilgang til noen av Facebook -tjenestene fordi de ikke lenger var synlige på Internett. I tillegg forårsaket denne totale frakoblingen en annen katastrofal svikt i systemet, nærmere bestemt i DNS. En av oppgavene som mindre datasenterinstallasjoner utfører, er å svare på DNS-forespørsler, disse spørsmålene besvares av autoritative navneservere som har kjente IP-adresser, og som annonseres til resten av Internett ved hjelp av BGP-protokollen.

For å sikre en mer pålitelig drift har Facebook DNS -serverne slått av disse BGP -annonsene hvis de ikke kan snakke med Facebooks datasentre selv, fordi dette indikerer at nettverkstilkoblingen ikke fungerer som den skal. Med den totale forstyrrelsen av ryggraden, var det disse DNS -serverne gjorde å fjerne BGP -annonsene. Resultatet av dette er at Facebooks DNS -servere ble utilgjengelige selv om de fungerte perfekt. Av denne grunn kunne ikke resten av verden få tilgang til Facebook -tjenester.

Logisk sett var hele denne prosessen i løpet av sekunder, mens Facebook -ingeniører prøvde å finne ut hva som skjedde og hvorfor de møtte to kritiske problemer:

  • Det var ikke mulig å få tilgang til datasentrene normalt, fordi nettverkene var helt nede fra det første problemet.
  • Krasj av DNS brøt mange interne verktøy som ofte brukes til å undersøke og løse problemer av denne typen.

Tilgangen til hovednettverket og out-of-band-nettverket var nede, ingenting fungerte, så de måtte fysisk sende et team med mennesker til datasenteret for å fikse problemet og starte systemet på nytt. Dette tok lang tid fordi den fysiske sikkerheten i disse sentrene er maksimal, faktisk, som bekreftet av Facebook, er det til og med vanskelig for dem å fysisk få tilgang til dem for å gjøre endringer for å unngå eller redusere mulige fysiske angrep på nettverket deres. Dette tok lang tid før de klarte å autentisere seg til systemet og se hva som skjedde.

Kommer tilbake til livet ... men litt etter litt for ikke å kaste hele systemet

Når ryggradstilkoblingen ble gjenopprettet i de forskjellige områdene i Facebooks datasentre, fungerte alt bra igjen, men ikke for brukerne. For å unngå kollaps i systemene på grunn av det enorme antallet brukere som ønsket å gå inn, måtte de aktivere tjenestene litt etter litt, for å unngå å forårsake nye problemer på grunn av den eksponentielle trafikkøkningen.

Et av problemene er at de enkelte datasentrene brukte svært lite elektrisk strøm, og plutselig reversering av all trafikk kan gjøre at strømnettet ikke klarer å absorbere så mye ekstra strøm, og det kan også sette elektriske systemer i fare. Jeg bufret dem. Facebook har trent for denne typen hendelser, så de visste godt hva de skulle gjøre for å unngå flere problemer i tilfelle en global krasj som den som har skjedd. Selv om Facebook hadde simulert mange problemer og krasjer på serverne og nettverkene sine, hadde de aldri tenkt på et totalt fall i ryggraden, så de har allerede uttalt at de vil lete etter en måte å simulere dette på i nær fremtid for å forhindre at det kommer tilbake. pass, og det tar så lang tid å fikse.

Facebook har også indikert at det var veldig interessant å se hvordan fysiske sikkerhetstiltak for å forhindre uautorisert tilgang forårsaket at tilgangen til servere bremset enormt da de prøvde å komme seg etter denne feilen globalt. Uansett er det bedre å beskytte deg selv daglig mot slike problemer og få en noe tregere utvinning enn å slappe av sikkerhetstiltakene til datasentrene.