Facebook: verkeerd commando en audit-tool-bug veroorzaakte de grote storing

De urenlange storing bij Facebook en zijn diensten werd veroorzaakt door een verkeerd commando tijdens routine-onderhoud. Het commando haalde onverhoopt het hele backbone-netwerk offline, wat een volgend probleem met het border gateway-protocol veroorzaakte.

Het betreffende commando dat bij het reguliere onderhoud werd gegeven zou de "wereldwijde beschikbaarheid van de backbone" in kaart hebben moeten brengen, zo legt Facebook in een blogpost uit. In plaats daarvan werd onbedoeld het hele backbone-netwerk offline gehaald, waardoor Facebooks datacenters als het ware volledig ontkoppeld werden van het internet. "Onze systemen zijn ontworpen om dit soort foutieve commando's tegen te houden om zo fouten als deze tegen te gaan, maar door een bug in de audit-tool gebeurde dat niet."

Daaropvolgend ontstond er een tweede fout, in dat geval bij kleinere datacenters waar DNS-verzoeken verwerkt worden. "Om te zorgen dat die betrouwbaar werken, trekken [de betreffende datacenters] BGP-advertisements in als ze niet kunnen communiceren met onze datacenters." Die BGP-advertisements zorgen ervoor dat andere netwerken de Facebook-diensten kunnen vinden op het internet. Vanwege het offline geraken van het backbone-netwerk waren de DNS-servers niet bereikbaar en werden de BGP-advertisements geweigerd. "Het eindresultaat was dat onze DNS-servers onbereikbaar werden, ook al deden ze het nog wel."

Uiteindelijk kon de kettingreactie van technische problemen niet op tijd opgelost worden omdat werknemers fysiek bij de servers moesten komen. Vanwege fysieke- en systeemtechnische beveiligingsmaatregelen bij Facebooks datacenters is dit extra moeilijk; op deze manier wordt misbruik voorkomen. Ook het aanpassen van de routers, servers en andere systemen is om diezelfde reden extra moeilijk gemaakt, wat voor langere debugtijden zorgde.

Na de wereldwijde storing van Facebook en zijn diensten werd veel gespeculeerd over de mogelijke onderliggende redenen. Kort daarna kwam het sociale medium met een relatief beknopte verklaring over wat er de avond ervoor gebeurd was. Tweakers publiceerde dinsdagavond een achtergrondartikel over de storing en de rol van het BGP-protocol, waarbij dieper op de onderliggende techniek ingegaan wordt.

Update, 22.00: In het oorspronkelijke artikel werd 'border gateway-protocol' meermaals foutief afgekort als 'BPG'. Dat is gecorrigeerd. Met dank aan mario963 en markvw.

Reacties (167)

[t-force]

Goed dat men bewust wordt van de tentakels die FB en consorten in de digitale samenleving hebben.

Deze stomme maar zeer menselijke actie had als gevolg dat FB niet bereikbaar was, WhatsApp niet meer functioneerde etc etc.
Dat interesseert me eigenlijk niets, want ik heb geen FB en WhatsApp kan ik missen.

Maar de mensen die FB makkelijk vinden om te gebruiken als login account kunnen ineens niets. Je kantoor niet in, je hotel niet in, sommige sites deden het ineens niet meer vanwege de vele koppelingen neer FB.

Misschien eindelijk eens een eyeopener om je minder afhankelijk te maken van de grote bedrijven zoals FB, Microsoft, Google, Amazon en zelfs Apple.

Wat me irriteerde als netwerkbeheerder, is de vele vragen die ik kreeg. Of de WiFi het niet meer deed etc. Dat omdat FB en WhatsApp eruit lagen en sommige sites vanwege de koppelingen het niet meer of langzaam deden.

Gelukkig deed Tweakers het. Want als Tweakers.net het niet meer doet is er echt iets aan de hand.

[n4m3l355]

Hoewel we nu bewust zien wat de consequenties zijn van deze centrale inlog accounts zoals FB maar ook Google, hoevaak ondervind je daadwerkelijk hier problemen door? En hoevaak ondervind je problemen met je account als je hier geen gebruik van maakt? Ik maak zelf veelvuldig gebruik van mijn Google inlog account, gecombineerd met hun centrale password database / generator is dat toch eigenlijk wel een verademing. Ik weet dat er alternatieven zijn die niet van Google zijn, echter tegelijkertijd gezien hoe uniek het is dat FB (of Google) op z'n gat liggen, heb ik hier toch uiteindelijk beduidend meer vertrouwen in.

Ik zie dit soort functies dan ook meer als toegevoegde waarde in de som van individuele gebruikers samen met alle gebruikers samen, hier praat je over echt veel tijdsbesparing en verhoogde veiligheid ondanks dat het heel soms mis gaat.

Let wel dit staat los voor mij wat voor bedrijven FB/Google zijn, het gebruikersgemak is echt heel veel waard.

[bbob]

Het is idd allemaal eenvoudig maar geeft toch stof tot nadenken.

Als ik dit lees moet ik lachen [quote]Vanwege fysieke- en systeemtechnische beveiligingsmaatregelen bij Facebooks datacentra is dit extra moeilijk; op deze manier wordt misbruik voorkomen. Ook het aanpassen van de routers, servers en andere systemen is om diezelfde reden extra moeilijk gemaakt, wat voor langere debugtijden zorgde.[/qoute]

Datacenters die beveiligd zijn je komt er bijna niet in maar 1 extern commando kan alles wel offline halen. tot zo ver de zwakste schakel in het systeem.

[n4m3l355]

Echter... hoevaak komt dit voor? Ik blijf bij de gedachte ik heb misschien wel 100 websites waar ik veelvuldig gebruik van maak die met wachtwoorden zijn beschermd en met Google kan ik cross platform makkelijk gebruik hiervan maken. Google genereerd voor mij complexe wachtwoorden die ik zelf nooit bij kan houden dus qua veiligheid met wachtwoorden zelf zit ik veel beter. Ik bespaar enorm veel tijd met het aanmaken van accounts en zo in te loggen. Als een account compromised is waarschuwen ze me ook nog.

De offtrade is dat het centraal gebeurd door partijen waar we minder blij van worden. Ik zou graag een alternatief hebben, wellicht met een 2FF mbv een fingerprint bijvoorbeeld maar laat het me graag weten wat het verder geeft. Iets wat ik makkelijk lokaal kan draaien, cross platform. Ik ben zelfs bereid hier voor te betalen, maar om terug te gaan om zelf wachtwoorden te verzinnen (ik val snel terug tot 1 dozijn wachtwoorden waar ik gebruik van maak die niet de meest veilige zijn) gaat niet meer gebeuren voor mij. En eigenlijk wens ik dit mijn employees ook niet toe. Het is minder veilig en kost veel tijd.

[bbob]

Betere opmerking is mag dit voorkomen.
Als je kijkt naar de impact van deze storing toont dat de afhankelijkheid aan maar ook dat het door een kleine menselijke fout dus mogelijk is om bijna een miljard gebruikers te treffen.

[nobraininvolved]

nou, als ik het zo lees, was t geen menselijke fout, maar een fout in de software van het audit programma.
kan gebeuren. Hoe vaak gebeurt t in bedrijven wel niet dat je een uurtje of dagje niet kunt inloggen? Of bij google? al regelmatig de dns servers vd router moeten vervangen omdat er ergens 1 was omgevallen waardoor ik prive zogenaamd geen internet meer had.
En hoeveel instanties zijn niet afhankelijk van bijvoorbeeld een centrale inlog via Digid? Je site kan wel werken, maar als je niet kunt inloggen, hang je toch.
t gebeurt gewoon....goede instanties zorgen er gewoon voor dat er meerdere manieren zijn om in te loggen cq te werken. alles af laten hangen van 1 3e partij zonder work arounds of noodplannen, is in mijn ogen gewoon not done.
t is dan ook aan die bedriiven die nu een paar uur 'grote problemen' hadden om dat eens in orde te maken.
en voor prive personen...ach, 6 uur geen fb overleef je wel en als je afhankelijk bent van whatsapp, zijn er wel andere tools die je binnen no time aan de praat kunt krijgen denk ik dan...desnoods via sms communiceren...

[bbob]

Dat auditprogramma is door mensen geschreven, dat moet als ik het goed begreep voorkomen dat bepaalde commando's uitgevoerd kunnen worden. Door een bug = menselijke fout is het dus toch misgegaan.

[defixje]

Zo kan je alles wel terugkoppelen aan de mens

[bbob]

Klopt want je kan stellen dat het auditprogramma niet goed getest is waardoor deze bug heeft kunnen ontstaan.
Als je een audit programma heft om commando's te blokkeren dan neem ik aan dat je dat auditprogramma een lijst met commando's geeft en kijkt wat het er mee doet. Schijnbaar is dat dus niet voldoende gedaan als een commando met dit gevolg dus door een auditprogramma komt.
Lijkt me dus gewoon voorbeeld van menselijke fout, niet genoeg testen waardoor fout niet naar voren komt. De zwakste schakel dus.

[nobraininvolved]

sorry, ben ik niet met je eens. als softwaretester kan ik je zeggen dat je nooit 100% van alle eventuele bugs uit software kunt halen als tester. Daarvoor zijn simpelweg teveel parameters en verschillende scenarios nodig. Je kunt niet alle exoten verzinnen of bekijken en dat zou ook nog eens veel te duur zijn.
Ik mag ook aannemen dat het hier niet om het simpel uitvoeren van een commando gaat wat de boel heeft veroorzaakt, maar dat het zoiets is als: als het systeem zich in staat X bevind en het commando wordt gebruikt, dan gaat er op plek Z iets fout waardoor weer iets anders in de keten geraakt wordt etc...ofwel...wss een aaneenschakeling van gebeurtenissen...maar dat is dan natuurlijk weer gewoon miij eigen vermoeden
Eigenlijk zou je dan ook nog een paar stappen terug kunnen gaan, want hoezo zou t testen fout gegaan zijn? Feitelijk is t programmeren fout gegaan, of mss wel uiteindelijk helemaal terug te voeren op t feit dat ze uberhaupt computers gebruiken...ik denk niet dat t fout was gegaan zonder een computern ^^ (maarvdat is flauw, ik weet het)...

[bbob]

Bug ?
als ik het goed gelezen heb is het hier een lijst met commando's die geblokkeerd wordt.
Als die zo een impact kunnen hebben dan controleer je ze dubbel of laat ik een testomgeving commando's los om te zien of ze wel of niet opgepakt worden.

[nobraininvolved]

nou dat is vlgns mij niet zo duidelijk uit t stukje te halen....
ze hebben t nl eerst over een specifiek commando wat de beschikbaarheid van de barebones wereldwijd in kaart zou moeten brengen.
lijkt me dus een legitiem commando wat je gewoon zou moeten kunnen gebruiken tijdens regulier onderhoud toch?
en een paar zinnen later hebben ze t over een fout commando, wat door een audit tool tegengehouden had moeten worden wat niet gebeurd is en wat de hele boel in de soep heeft laten lopen.

dus als ik dat vrij vertaal zoals ik t lees, gaat er bij t eerste commando al iets fout...dat had de beschikbaarheid moeten laten zien, maar heeft de hele bende ontspoort....dat is natuurlijk al erg vreemd...
en dan als 2e fout had t audit systeem t commando moeten herkennen en tegenhouden en heeft dat niet gedaan...

t lijkt er haast wel op dat t gewoon een onschudig commando was (verklaart nl ook dat de audit tool m heeft laten gaan), wat een heel andere dan gewoonlijke uitwerking op de systemen heeft gehad...
kan dus ook gewoon een probleem in 1 of andere hardware apparaat zijn geweest wat het commando verkeerd heeft geinterpreteerd....zal ook niet de 1e keer zijn dat een apparaat een bug bevat...

[ryderblaat]

Precies, de alternatieven zijn echt veel slechter. Op werk zijn wij van PingID overgestapt naar Google Authenticator, de eerste lag er constant uit, werkt traag, soms kreeg je push berichten voor authentication requests niet binnen. Mijn ervaring tot nu toe met Google Authenticator is dat het gewoon ALTIJD goed en snel werkt.

Daarnaast heb ik het gevoel dat ik maandelijks, dan wel niet wekelijks, ergens bij de overheid niet kan inloggen omdat DigiD er weer eens een paar uur uit ligt. Dat wordt van belasting geld betaald en blijkbaar is het compleet acceptabel dat het er constant uit ligt. Maar als FB er eens een paar uur uit ligt, wat echt uniek is, dan is de wereld te klein.

[Reactie gewijzigd door ryderblaat op 23 juli 2024 05:27]

[Flupkees]

Dat Google Authenticator nooit storingen heeft, is natuurlijk ook geen toeval; het werkt tevens offline doordat alles lokaal gebeurt. Test maar eens door je telefoon in vliegtuigmodus te zetten (of de rechten te bekijken die de app heeft). Het is een vrij simpele app, dus inderdaad een goede oplossing voor 2FA (of alternatieve apps die precies hetzelfde werken) - mits je bekend bent met de nadelen.

Het is dus iets anders dan waar n4m3l355 het over heeft, want dat gaat over inlogmethoden waarbij een authenticatiestap via de servers van FB/Google gaat.

[Reactie gewijzigd door Flupkees op 23 juli 2024 05:27]

[jcvw]

Hier viel de schade "nog wel mee" maar in Zuid Amerika worden telefoonabonnementen gesubsidieerd door Facebook: koop een klein data-abo en je krijgt er onbeperkt whatsapp en Facebook bij kado. Die mensen hebben alleen maar whatsapp (en zijn dus niet op een andere manier bereikbaar).

Zij hebben dus 6 uur lang (overdag, want in hun tijdzone begin de storing rond het middaguur). Bedrijven onbereikbaar, niemand die kan bellen... Dus zoiets als dat bij ons van 12:00 - 18:00 alles plat ligt: het vaste net, alle mobiele netwerken en ook 112..
Facebook dus als kritische infrastructuur... (in ieder geval in Zuid Amerika)

Als een service 99.99% uptime biedt, mogen ze ongeveer een half uur per jaar down zijn. Facebook was 6 uur down. dat is dus wat ze (als ze een four-nines service zouden hebben) in 12 jaar tijd aan toegestane downtijd zouden hebben.

Vroegâh werden er door de overheden eisen gesteld aan de "uptime" van telefoon netwerken. AT&T in Amerika heeft tijden gehad dat ze vele jaren achtereen geen enkele storing hadden. Neem de hoorn op, en je krijgt een "dial tone". De betrouwbaarheid van de traditionele telefooncentrales is enorm.

Tijd om weer eens te denken aan op welke manier je je kritieke infrastructuur wilt regelen als land...

[Revres]

Mooi en wel die uptime maar wat is je streven dan? 99%? 99,9%? 100%?
Je kunt afspreken wat je wilt, SLA's maken tot je er bij neer valt maar dit kan gewoon allemaal gebeuren.
Nu weet ik niet hoe het in zuid Amerika zit, als mensen daar afhankelijk zijn van FB voor 112 dan is dat misschien sowieso een slechte zaak.
Verder denk ik dat we het misschien maar moeten omarmen om even zonder de directe communicatie met elkaar te zitten. We doen het immers al langer zonder dan met FB, Whatsapp en andere social media.
Veel paniek, elk medium heeft weer iets te schrijven, maar wat voor gevolgen heeft het nu echt gehad?

edit: bedrijven die hun interne communicatie via whatsapp laten lopen kwam nog even bij mij op, daar zouden inderdaad problemen kunnen ontstaan.

[Reactie gewijzigd door Revres op 23 juli 2024 05:27]

[MSalters]

AT&T is genoemd, en ik heb toevallig aan die centrales gewerkt. De uptime daar was 99.999% tot 99.9999% (5-6 nines). Dat is dus minuten per jaar (gemeten op wjknivo; een graafmachine in een straat kan lokaal veel langer problemen veroorzaken).

Dat was letterlijk met jaren-80 technologie; inmiddels zou dat beter moeten kunnen.

[the_stickie]

Dat was letterlijk met jaren-80 technologie; inmiddels zou dat beter moeten kunnen.

Alleen zijn sinds de jaren 80 de technologie en de diensten een stuk complexer geworden. Een analoge telefooncentrale is vervangen door een hele stack aan technologie. Een onderliggend IP netwerk (met routers, switches, firewalls,...), wifi telefoons, bellen met een app, gevirtualiseerde servers die de 'centrale' draaien,...

[OruBLMsFrl]

Ja, goede grappen dit @MSalters. Onze nationale 112 centrale is urenlang onbereikbaar geweest een paar jaar terug, die is viervoudig ontdubbeld. Daar is bij uitstek heel goed over nagedacht, daar hangen levens vanaf. Facebook preseteert hier in ordegrootte hersteltijd vergelijkbaar, terwijl niemand ooit een nooddienst afhankelijk zal maken van hen.

Je mag als maatschappij prima wat van ze verlangen, maar 99,99% vragen op alle diensten is echt roomser dan de paus. Je zou je als maatschappij weerbaarder moeten maken, door te verbieden dat er op andere diensten wordt ingelogd via alles behalve een toegewijde identity provider welke géén hosting of user generated content mag verwerken of aanbieden. Voor zo een identity provider, kun je dan weer vereisen dat er wel aan hogere standaarden voldaan moet worden.

Ontbundelen en opknippen geeft veel meer veerkracht dan enkel het geheel van Facebook een hogere uptime verplichten in zoverre zoiets al kan. Als jij iets fout doet in de ogen van een van die grote tech giganten dan is je account uitgeschakeld en krijg je die nauwelijks meer terug is al bekend uit praktijk. Stel je voor dat er eens wordt gesteld Nederland = drugsland, daar willen we niks meer mee te maken hebben. Dan heb je diezelfde problematiek in de maatschappij en staan we vandaag machteloos en totaal niet georganiseerd opgesteld om er iets mee te doen. Die 6 uur downtime is nog mazzel hebben, een goede wake-up call voor die specifieke account afhankelijkheid.

[Reactie gewijzigd door OruBLMsFrl op 23 juli 2024 05:27]

[carlo]

Complexer, zeker.
Maar ook veel goedkoper geworden. Redundant uitvoeren is daarom nu veel makkelijker dan in de jaren-80.

Ook gebruikers hebben een keuze, als zij geheel afhankelijk zijn van 1 applicatie dan nemen zij een risico. Voor alle Facebook apps bestaan alternatieven.

Dit soort grote storingen komen zo weinig voor dat we er door verrast worden. Het draait uiteindelijk allemaal om geld en gemak. Als dit vaker voorkomt zullen mensen een alternatieve app installeren.

[mjz2cool]

Ook gebruikers hebben een keuze, als zij geheel afhankelijk zijn van 1 applicatie dan nemen zij een risico. Voor alle Facebook apps bestaan alternatieven.

Niet de gebruikers van zo'n abbo als @jcvw noemt, daar kosten andere apps wel gewoon data.

[n4m3l355]

Is dit daadwerkelijk anders dan vroeger? Ik werkte voorheen als second Line in mijn studenten jaren bij een bekende isp in Nederland maar die van origine buitenlands was. Dagelijks lagen er complete dorpen uit voor onbepaalde tijd. Ik heb hier geen data van toentertijd maar ik denk dat het eigenlijk heel veel voorkwam maar nooit een heel land. En wederom dat maakt deze situatie zo uniek, 1 miljard gebruikers er is gewoon geen partij haast met zulke schaalgrootte. Je hebt geen ongelijk qua slam eisen maar zullen ze daadwerkelijk over hun bestaans zover van deze eis afliggen?

Het is van belang dat de overheid eisen stelt en ervoor zorgt dat een partij die naleeft. Ook dat ze FB wederom bestraffen dat dit gebeurd. Echter ... Dit is wereldnieuws voor een goede reden.

[La1974]

Goed dat men bewust wordt van de tentakels die FB en consorten in de digitale samenleving hebben.

Was het maar zo. Men was dit vanochtend alweer vergeten. Mensen zijn gewoontedieren een Facebook weet dat.

Hierbij past een mooie tegelwijsheid:

Ze dronken een glas, deden een plas en alles bleef zoals het was.

Op de beurs ging Facebook 5% onderuit. Ik heb niet gecheckt maar durf te wedden dat de koers al hersteld is. Zo niet, dan uiterlijk vrijdag.

[Reactie gewijzigd door La1974 op 23 juli 2024 05:27]

[Mopperman]

4 oktober om 16.00 - 326,32$
5 oktober om 16.00 - 332,96$

Stand over de laatste 5dgn -2.91%

[kipppertje]

Het aandeel Facebook was al aan het dalen voor de storing. Dat had meer te maken met de klokkenluider icm dat alle techbedrijven nu in de uitverkoop zijn. De storing zal het wellicht iets versterkt hebben, maar het is niet zo dat het aandeel 5% gedaald is door de storing.

[La1974]

Dat is eigenlijk mijn punt. De media schrijft dat Zuckerberg 6 miljard is verloren ivm deze storting.

Dat is echt kolder. De koers zal hier amper door geraakt worden.

Ook alle schandalen hebben beperkte impact op dit bedrijf. Ze willen geld verdienen en alles moet en kan daarvoor wijken.

[the iMad]

tegelwijsheid: Ze dronken een glas, deden een plas en alles bleef zoals het was.

Je komt het zo vaak tegen dit soort onzin en dan ook nog als wijsheid benoemen.

[La1974]

Misschien omdat het waar is?

[the iMad]

Het woord "alles" !!!

[La1974]

Het is maar een tegelwijsheid. Geen natuurkunde. Je moet het niet letterlijk nemen.

Er zijn er ook bij die uit een beker drinken en een plas doen en dat er vrijwel niets veranderde.

Maar vooruit voor jou een aangepaste versie:

Ze dronken een glas, deden een plas en circa 84,56% bleef zoals het was.

Maar even serieus, wat is er nu werkelijk veranderd?

[Reactie gewijzigd door La1974 op 23 juli 2024 05:27]

[Jerie]

Maar even serieus, wat is er nu werkelijk veranderd?

Zelfs m'n vrouw weet inmiddels wat BGP is

[Aalard99]

Op de beurs ging Facebook 5% onderuit. Ik heb niet gecheckt maar durf te wedden dat de koers akker hersteld is. Zo niet, dan uiterlijk vrijdag.

Het zal me dus niets verbazen dat dit juist een positief effect heeft gehad op de koers, het werd nu echt duidelijk waar Facebook met zijn tentakels in zit en hoeveel macht het bedrijf heeft.

[Verwijderd]

Alleen nu is het Facebook, maar denk je dat dit ooit anders zal zijn? Het feit is gewoon dat een netwerk pas waarde heeft als het heel veel gebruikers heeft, dus dan heb je automatisch ook veel schade. Dan maakt het niet uit of het Facebook is of Signal, als iedereen Signal gebruikt en het gaat down heb je net zo veel shit.

Ik denk dat het grotendeels ook gewoon menselijke natuur is. Mensen willen iets wat makkelijk werkt en willen niet 10 oplossingen voor hetzelfde probleem, dus dan kom je al snel op 1 app hebben om contact met mensen te hebben. Dus je gaat je dan minder afhankelijk maken van de grote bedrijven, maar van wie dan wel? Als je een miljard mensen met elkaar wilt laten communiceren, dan zal je infra dus heel belangrijk zijn, ook Signal (ik gebruik het even als voorbeeld door de cult status op Tweakers, maar dit geldt voor iedere app natuurlijk) heeft servers die down kunnen gaan (en dat soms ook gaan). Dus je maakt je niet minder afhankelijk, maar je maakt je afhankelijk van een andere aanbieder.

[telenut]

En waarom zou "u minder afhankelijk van grote bedrijven maken" de oplossing zijn?
Mijn mail dan maar laten hosten bij de locale websitehoster die er dit jaar mogelijks al 5 keer een uur of 2 uit lag is dan beter dan bij Google?
Grote bedrijven hebben doorgaans ook een betere uptime. Het was zelfs een hoofdpunt in het nieuws... Als uw locale provider voor mail of iets anders er uit ligt, zal je al geluk moeten hebben dat hij wakker is op dat moment, of je komt het nooit te weten dat het probleem daar ligt...

[carpcatcher]

Wat me irriteerde als netwerkbeheerder, is de vele vragen die ik kreeg. Of de WiFi het niet meer deed etc. Dat omdat FB en WhatsApp eruit lagen en sommige sites vanwege de koppelingen het niet meer of langzaam deden.


dit zag je ook terug bij allestoringen.nl
veel mensen melde storingen over Vodafone / KPN / Tmobile / Online.nl / Ziggo etc etc.
tuurlijk is het goed dat ze al een storing melden.. maar enige kennis of een extra tooltje zou wel gewenst zijn..

[AlbertVeijer]

Beste t-force,
Dat klinkt allemaal wel héél erg eigenwijs... En dat jij je irriteerde omdat "gewone" mensen vroegen of WiFi het wel of niet meer deed. Niet iedereen is ICT-er, hé?
En dat Tweakers het gelukkig nog wel deed anders zou er wel écht iets aan de hand zijn?
Dit riekt naar behoorlijke zelfoverschatting.
Wanneer je echt zo slim bent leg dan eens aan de normale mens uit hoe wij dan zonder FB, Microsoft, Google, Amazon en Apple moeten leven? Net als jij ook FB-loos?

[Jarno99]

Ik zie het al helemaal voor me...

"Welkom op je eerste stagedag, Peter.
Vandaag ga ik je laten zien hoe we onderhoud aan het volledige backbone-netwerk van het bedrijf uitvoeren.
Het mooie is dat het bijna niet fout kan gaan. We draaien namelijk een audit-systeem die alle verkeerde en gevaarlijke commando's er tussenuit plukt voordat ze daadwerkelijk uitgevoerd worden.
Type maar eens voor de grap 'sudo rm -rf --no-preserve-root /' in! Hij zal het commando er gewoon uitplukken en alles blijft mooi doorwerken."

[Stoney3K]

Doe dan op zijn minst 'sudo rm -rvf' zodat je de puinhoop op een heel dramatische manier over het scherm kan zien rollen.

[Jerie]

U vergeet --no-preserve-root

[Odie]

Waarom moet ik denken aan:

https://xkcd.com/327/

[NoobishPro]

Hahaha zoiets heb ik oprecht meegemaakt bij mijn eerste stage. Note dat ik de programmeur specialisatie dat jaar pas had gekozen en absoluut 0 kennis had. Zag voor het eerst in m'n leven een IDE.

"Ja joh, je kunt in dit project aankloten wat je wil. Je hebt je eigen dev deploy en toch geen toegang tot de productie server. Kijk maar eens of het je lukt om te zorgen dat als je een plek aanklikt, hij reserveert."

Ik: Begint alle functies uit elkaar te trekken en te debuggen zodat de routes kan volgen en kan ontdekken hoe "routing" werkt.

De telefoon in het kantoortje ernaast: Roodgloeiend

De lead dev: OOOOOOEEEEEPS.

Hij had mij dus per ongeluk juist direct op de productie omgeving laten deployen ipv op mijn eigen dev. (of gewoon vergeten dit daadwerkelijk om te zetten)

Note dat dit intussen al ergens tussen de 10-15 jaar geleden was. In die tijd waren dit soort dingen nog makkelijk fout te doen.

[Reactie gewijzigd door NoobishPro op 23 juli 2024 05:27]

[jcvdyk]

rm -rf lol doet me denken aan mn oude Unix tijd!

[bbob]

Mooi voorbeeld en het toont dus aan dat die audittool de zwakste schakel in het hele systeem is.

Vanwege fysieke- en systeemtechnische beveiligingsmaatregelen bij Facebooks datacentra is dit extra moeilijk; op deze manier wordt misbruik voorkomen. Ook het aanpassen van de routers, servers en andere systemen is om diezelfde reden extra moeilijk gemaakt, wat voor langere debugtijden zorgde.

Je hoeft dus niet eens toegang te hebben tot de servers om ze helemaal offline te kunnen halen. Het omzeilen van de audittool geeft je de mogelijkheid om hele facebook netwerk dus uit te zetten.

[david-v]

Je zou die ene beheerder zijn die het commando intikte. Man man man, dan krijg je het wel benauwd. Uit ervaring weet ik dat je bij dit soort situaties het heel warm krijgt en een rode kop krijgt van de adrenaline kick die je krijgt. Ik zou niet graag in zijn schoenen willen staan toen het gebeurde.... Op maandag ochtend ook nog eens.

[Odie]

Ik denk dat elke netwerkbeheerder minimaal 1x in z’n carrière verantwoordelijk is geweest voor een actie waarbij het hele netwerk op z’n hol gaat. Been there done that.

Je ramt op enter, je beseft dat je terminal geen nieuwe prompt meer geeft, je ramt nog eens op enter. En nog eens. En nog eens drie keer achter elkaar. En dan besef je wat er gebeurd, wat je gedaan hebt. De rillingen lopen over je rug, het zweet breekt je uit, je vraagt je af of je het kan negeren of verbergen of ontkennen of dat je misschien iets of iemand anders de schuld kan geven … en dan breekt de realiteitszin door en nét voor je “oeps” kan zeggen hoor je collega’s achter je roepen “is er soms iets met het netwerk aan de hand?”….

Jep, classic.

[hackerhater]

Per ongeluk de main firewall neer halen en daarmee de internet-toegang voor het hoofdkantoor en de connectie-feed voor de andere locaties
Been there, done that.

En dan de "a shit" en de sleutels pakken van het server-hok want natuurlijk reageerde die machine niet meer remote.

[Reactie gewijzigd door hackerhater op 23 juli 2024 05:27]

[Odie]

Bofkip. Easy fix.

Ik wilde ooit “no bgp neighbour…” op een remote core router tikken maar somehow produceerde mijn vingers met eigen willetje “no router bgp”. Tis héél lang geleden, ik weet niet meer precies waar het fout ging maar dat de effecten redelijk desastreus waren mag duidelijk zijn.

[Reactie gewijzigd door Odie op 23 juli 2024 05:27]

[Trippol]

Sudo rm -rf /* enter oeps

[J_van_Ekris]

Ik heb dat een keer door een typo gehad op een testmachine (gelukkig). Ik had met een recursive chmod 775 per ongeluk een spatie in het pad zitten waardoor ik bij de root begon....

[Stoney3K]

<user> is not in the sudoers file. This incident will be reported.

[vdburg]

Iets soorteglijks: bij een klant een kernel mode patch geinstalleerd van 'dat gaat altijd goed', na enter geen response meer. mensen op terminals naast mij 'he ik krijg geen response', een ander 'he ik ook niet' Zweet breekt mij uit.... Blijkt later dat iemand op dat moment een modem op de coax netwerk kabel in teststand heeft gezet waardoor het hele backbone in het bedrijf er uit lag. Oeps.... Dat kon nog rond 1980....

[Odie]

1980? My goodness, toen leerde ik net met twee woorden spreken ;-)

Maar ook in mijn early days (1997, Demon internet) ging alles er heel anders aan toe. Al was het maar dar de twee core routers (COW-1 en COW-2 en in tegenstelling tot wat veel mensen dachten was dat geen referentie aan koeien maar stond het voor : center of the world *kuch*) een 486DX2 waren die een poor-mans versie van VRRP/HSRP deden middels een eigen geschreven stukje code die 'arpcow' heette, waarbij beide machines om de x seconden hun eigen MAC voor het floating IP eruit boerde.

Ach, mooie tijden. Nu is alles corporate...

Iets anders wat in mijn jonge dagen nogal eens fout ging: teveel willen doen in één nacht. Wel netjes een sort-of design en plan maken, maar dan denken dat je tussen middernacht en 02:00 de boel 'wel effe omklust' met je kont op een tegel en je rug tegen een 19" rack... In die tijd uiteraard vaak nog niet met gehoorbescherming op (ja, milde tinnitus nu) en er dan om 02:00 achterkomen dat het plan niet had gewerkt maar dat je te ver van het startpunt af was om nog fatsoenlijk terug te kunnen draaien. Of niet terug willen draaien, want teken van onvermogen dus stug doorgaan. Tot je om 04:00 dacht "hmmmmmm, en nu?" en dan vervolgens mensen gaat proberen wakker te bellen in een wanhopige poging om de boel weer dansend te krijgen voor de klanten er serieus impact van zouden gaan ondervinden. En dat met je groggy kop die moe is en overprikkeld door de herrie in het DC.

[Reactie gewijzigd door Odie op 23 juli 2024 05:27]

[TunderNerd]

Als beginnend engineer een RB-PI in het netwerk knallen, niet goed nakijken of er geen DHCP server op draait...
een dag later hadden de 3 vestigingen (Amsterdam, Amerika, en Azie) bijna geen internet meer, niemand snapte waarom. Wat bleek? wij waren sneller met IP's uitdelen dan de echte DHCP servers, en de pool was vrij snel leeg.

Tot zo ver maand 3 van baan 1...

[tweaker2010]

Die beheerder is niet verantwoordelijk, is uiteindelijk zijn supervisor die op het matje zal moeten komen bij het management. Alles valt of staat goede voorbereiding en mitigerende maatregelen, dit is niet enkel de schuld van een techneut die een vinkje aanzet of een commando intikt.

[david-v]

Zijn supervisor ook niet, dit is een bedrijfsbreed probleem. Je kan zoiets niet bij één persoon neerleggen, of het nou de beheerder is of de supervisor. Het aanwijzen van een schuldige is in deze totaal nutteloos.

Dat ze overigens audit tooling hebben om dit soort commando's te voorkomen klinkt mij als een "excuus". Uiteindelijk moet je dit soort problemen anders oplossen en aanpakken, duidelijk een single point of failure die aangepakt moet worden.

[mphilipp]

Het aanwijzen van een schuldige is in deze totaal nutteloos.

En ook volledig contra-productief. @Odie refereerde er al aan in zijn zinsnede:

je vraagt je af of je het kan negeren of verbergen of ontkennen of dat je misschien iets of iemand anders de schuld kan geven

Dat geeft al aan wat de standaard reactie is op dit soort gebeurtenissen. Iemand moet zijn baan kwijtraken, op zijn flikker krijgen, te kakken worden gezet of wat dan ook; als het maar erg is. Alsof een fout maken al niet erg genoeg is. In principe is de beste reactie op zoiets, meteen opstaan, je vinger opsteken en roepen 'Ik heb hulp nodig, want ik heb iets verkeerd gedaan'. Vervolgens moet iedereen aan de slag om het probleem op te lossen. Vingerwijzen kan altijd nog, maar heeft geen nut.

Eigenlijk zou het niet zo mogen zijn dat je op een dergelijk systeem zo'n fout kunt maken. Wat er exact fout is gegaan is ook niet helemaal duidelijk. Is er een totaal verkeerd commando gebruikt, of is er een typfout gemaakt in de opties oid? Je mag hopen dat wat er dan ook moet gebeuren ergens in een draaiboek volledig uitgeschreven staat. En dat meerdere mensen hebben gekeken of dat echt de juiste commando's zijn. En dan nóg kan er van alles verkeerd gegaan zijn, maar het is eigenlijk niet mogelijk dat dat de 'schuld' is van één persoon. Iemand doet zoiets niet bewust en op dat nivo mag je verwachten dat het professionals zijn die echt wel weten wat ze doen en niet voor de grap format c: intypen op een productieserver.
Maar helaas is het de gewoonte om echt iemand aan te wijzen die dan de Sjaak is.
Ik werkte ooit kort bij een bedrijf waar ik zo nu en dan wat software moest uitrollen die de ontwikkelaars hadden opgeleverd. Een van de eerste keren dat ik dat moest doen, heb ik een keer per ongeluk een verkeerde versie uitgerold, en had dat niet in de gaten, totdat ik alles net weer had vrijgegeven. Dus ik stuur er een mail achteraan dat ik iets te enthousiast was geweest en ik dan nu echt de juiste versie uit zou rollen. Met excuus enzo. Krijg ik later reacties als 'dat je dat zomaar aan iedereen durft te zeggen dat je het eerst fout had gedaan'. Dat kenmerkte de cultuur daar (vandaar dat ik er niet lang bleef). Ik denk dan 'wat had ik dan moeten doen?' Niets zeggen en hopen dat niemand iets door heeft? Dat is nóg dommer, want als ze het merken, vragen ze zich af waarom ik niets zeg. En een smoes gebruiken is een beetje dom tussen allemaal IT'ers. Iedereen kan gewoon zien wat er gebeurd is. Nee, gewoon zeggen wat er gebeurt is, daar heeft (bijna) niemand een probleem mee. Maar....je moet dat niet 3x achter elkaar doen natuurlijk. Zolang je leert van je fouten is er naar mijn idee niets aan de hand.

[Reactie gewijzigd door mphilipp op 23 juli 2024 05:27]

[Odie]

Blameless post mortem is een hippe visie waarin men stimuleert om zo snel mogelijk de vinger op te steken dan wel zo eerlijk mogelijk te zijn in de analyse. Met als enige doel: snellere recovery en verbeteren van procedures.

Edit: hippe weg, gaf verkeerd beeld van mijn mening

[Reactie gewijzigd door Odie op 23 juli 2024 05:27]

[jcvw]

Niets hips aan: het werkt gewoon. Zie overigens ook die hoofdstuk uit het Google SRE boek.

Als er iets misgaat, heb je lesgeld betaald. Als je vervolgens niet de lering uit dat lesgeld trekt, is het weggegooid geld (in het geval van facebook: 10 miljoen per uur downtime: omzet 86 miljard in heel 2020 gedeeld door 8760 uur per jaar). Zoiets dus als 60K betalen in een jaar voor een studie bij harvard en dan niet op komen dagen.

Het omgekeerde van blameless postmortems: asscovering. Dé manier om gebreken in het systeem zo lang mogelijk verborgen te houden en je beste mensen te ontslaan.

[mphilipp]

Je gebruikt de term 'hip' waarschijnlijk om aan te geven dat je het niets vindt. Wat stel jij dan voor? Zoveel mogelijk proberen je fouten te verbergen? Snel weghollen as if nothing happened? Iemand anders de schuld geven?
In de eerste plaats is het proberen te verbergen van 'iets' dat je doet op een computersysteem nogal onzinnig. Er is iets als logging en ook gewoon logica als men erachter wil komen wat er gebeurd is. Door je te verstoppen frustreer je dat proces alleen maar, en uiteindelijk komen ze er toch wel achter. Een netwerk gaat niet spontaan uit zichzelf down zonder enige aanleiding. Dat is één.
Twee is dat het ook nog eens mijn ervaring is dat eerlijkheid nog altijd het meest op prijs wordt gesteld. Uiteraard zal je misschien wel de wind van voren krijgen als het écht iets stoms was, maar in het kader van het probleem oplossen is het wel het beste. Je zit niet voor jezelf op die plek (dat is tenminste mijn instelling). Het is geen bezigheidstherapie.

En zoals @jcvw opmerkt: je doet iets, het blijkt niet goed, dus daar leer je van. Als je leert fietsen, zul je ook wel een keer op je plaat gaan. Leer daarvan om de volgende keer niet wéér te vallen. En als je in een organisatie werkt waar ze graag mensen aan de schandpaal nagelen als ie een fout maakt, neem dan ontslag en ga bij een gezond bedrijf werken. Zo'n cultuur is nergens goed voor.

[Stoney3K]

Je gebruikt de term 'hip' waarschijnlijk om aan te geven dat je het niets vindt. Wat stel jij dan voor? Zoveel mogelijk proberen je fouten te verbergen? Snel weghollen as if nothing happened? Iemand anders de schuld geven?

Precies dat. Uiteindelijk bereik je met de 'er moeten koppen rollen'-houding die er in sommige organisaties heerst, heel weinig om het daadwerkelijke probleem op te lossen, het enige wat er gebeurt is dat mensen zich nog meer gaan verschuilen en indekken en er uiteindelijk alleen maar eilandjes ontstaan. Problemen worden dan heen en weer gegooid over de schutting omdat niemand echt de verantwoordelijkheid wil nemen.

De enige reden waarom die cultuur is ontstaan, is doordat de Amerikaanse aanklaag- en schadevergoeding-mentaliteit hoogtij viert. En uiteindelijk is die mentaliteit maar voor één ding goed, en dat is het vullen van de zakken van letselschade-advocaten. Voor een onderneming of voor werknemers, voegt het helemaal niets toe.

[Odie]

Ik gebruikte de term niet sarcastisch en ik ben voorstander. Er is overigens links en rechts ook wat kritiek op de aanpak, omdat het ingaat tegen de natuurlijke “hardwiring” van de menselijke aard en het gevaar van tiptoeing door een mijnenveld met uiteindelijk een onbevredigend resultaat. Er is altijd blame, dat aspect volledig ontkennen kan onnatuurlijk voelen.

Verder is mijn persoonlijke opvatting altijd “own it” geweest, ik kan er dus ook bijzonder slecht tegen als een andere engineer dat niet doet. En dan komt onderstaand verhaal weer om de hoek kijken.

Maar het probleem ownen moet wel uitgelokt worden door de organisatie. Daar staat dan weer tegenover dat je ook oog moet hebben voor mensen die maar in herhaling blijven vallen en dankzij het blameless principe overal mee weg komen.

https://techbeacon.com/ap...dont-work-heres-what-does

[Reactie gewijzigd door Odie op 23 juli 2024 05:27]

[mphilipp]

Tuurlijk is er blame, als je iets fout doet, kun je daar niet onderuit. Dus je zult best op je falie krijgen, maar dingen proberen te verstoppen is dom en zinloos. Ik ga dat artikel niet helemaal lezen, want ik heb een hekel aan die wijze figuren die wel eens uit zullen leggen hoe dingen werken. Daarbij worden er vaak volledig onrealistische scenario's aangehaald en gaat het op de typisch Amerikaanse polariserende manier. Dus complete tegenstellingen neerzetten om te bewijzen dat blameless niet werkt. Ja, als je een gedroomd bedrijf aanhaalt dat een blameless love-fest is, haak ik af. Dat bestaat natuurlijk niet. Gewoon een gezonde cultuur, accepteren dat waar gehakt wordt, spaanders vallen. Als je geen fouten maakt, maak je niets. Dat is gewoon de realiteit. We hoeven echt niet elke ochtend een groepshug te doen ofzo, maar iemand compleet afbranden of zelfs ontslaan omdat er een fout wordt gemaakt is ook weer overdreven.
Er zijn natuurlijk verschillende soorten fouten: je kunt gewoon een typfout maken, een slordigheidje. Maar je kunt ook nalatig zijn, en bv procedures helemaal niet volgen. Of je gaat dingen doen die ofwel niet nodig zijn of die jij helemaal niet mag doen. Dat is dan natuurlijk ook een organisatorisch probleem omdat je dat niet zomaar zou moeten kunnen. Maar nalatigheid is wél erg. En daar mag je best een flinke uitbrander voor krijgen. Je bent professional, dus moet je je ook zo gedragen.

Leergeld betalen doen we allemaal, soms meer dan anders. Als je verwacht dat je in de carrière nooit een vervelende fout zult maken, heb je een lesje realiteitszin nodig. Maar uiteindelijk hebben we het niet over tegenstellingen: het gaat niet om een pure blame cultuur vs totaal blameless. Het gaat om een gulden middenweg. Realistisch. Maar wel een beetje meer richting blameless, want anders durft niemand zijn vinger op te steken en daar is niemand bij gebaat.

[Odie]

Volgens mij tik je aardig wat punten uit het artikel aan zonder het gelezen te hebben

[Reactie gewijzigd door Odie op 23 juli 2024 05:27]

[mphilipp]

Daarom heb ik ook die goeroes niet nodig die vertellen hoe het zit. Het is doorgaans common sense óf volslagen slap gelul. Een van de twee

Ik heb dat ook met al die nieuwe wondermethodes die elke zoveel jaar worden gepresenteerd. Eigenlijk alleen maar voer voor consultants en opleiders. Meestal verandert er in de praktijk helemaal niets. Ik werk in de IT sinds 1989 ofzo en projecten lopen nog steeds uit tijd/budget en de wordt nog steeds buggy software opgeleverd, ongeacht de wondermethode die gebruikt wordt. Vertel me wat er beter gaat...zoveel jaar ICT beheer en nog steeds is men in staat om met één druk op de knop de hele boel naar de gallemiezen te helpen. Gek toch? Al die mooie methodieken om software te ontwikkelen, hele volksstammen studeren af op foutvrij programmeren en weetikwat, en nog steeds zit er bugs in onze software. Rarara...

Nee, met goeroes heb ik niet zoveel

[henk717]

Ken uit eigen ervaring dat direct toegeven en samen met anderen oplossen veel beter werkt dan stilzwijgen en hopen. Heb op die manier een groot probleem weten te voorkomen nadat ik zelf een catastrofaal ongeluk had. Mijn gedachtegang was niet fout. Er was een gebruiker in het veld die zijn PC niet meer in kon en dus niet met het domein was verbonden. Sommige oude PC's bij die klant hadden een voor ons onbekend local admin wachtwoord en dan was het aan ons die even te wijzigen in het standaard wachtwoord zodat je er vervolgens in kon om de gebruiker te helpen.

Simpel toch? Dus ik had de remote tooling opgestart, het scherm geopend naar een command prompt om het wachtwoord aan te passen. Maar op dat moment spreekt een collega mij aan en moest ik even snel op de domain controller iets voor hem wijzigen. Hierna ging ik verder en voerde ik het bekende net use commando in om het local admin wachtwoord te wijzigen. Ik log in met het local admin wachtwoord en het werkt niet. Gek, zal wel een typo hebben gemaakt. Dus ik voer nogmaals het commando uit om het wachtwoord te wijzigen. Werkt weer niet. Dat is wel heel raar, dit werkt altijd. Dus ik kijk nog maals naar het tab en zie tot mijn schrik dat ik nog in het venster van de server zit in plaats van die van de client (Zelfde beheer tool).

Vervolgens ben ik direct naar de derde lijn gelopen (die ook systeembeheer doen) en heb ik uitgelegd dat ik perongeluk het local admin wachtwoord van de DC heb gewijzigd omdat ik door een snelle vraag van mijn collega het verkeerde tab had open staan terwijl ik met een lokale machine bezig was. "Die hebben geen local admin wachtwoord henk dat is onmogelijk". - "Nou, het is me toch echt gelukt hem te wijzigen". "Nee, die hebben geen local admin wachtwoord dus wat heb je precies gedaan?" - "Gewoon een net use zoals ik altijd zou doen op een lokale machine". "Oh.. maar dan heb je het domain admin wachtwoord gewijzigd die op alle servers wordt gebruikt door de services!".

Gelukkig had een project teamlid aan die tafel het juiste wachtwoord nog en konden we het terug draaien voor dit was gerepliceerd over het netwerk. Downtime 0 en de klant heeft het nooit gemerkt. Omdat ik het eerlijk had gemeld, we de schade konden voorkomen en het een begrijpelijke fout was waarbij ik niet zomaar buiten het boekje had gehandeld is het bij een 'beter opletten' gebleven en heb ik er nog jaren daarna prettig gewerkt. Had ik niets gezegd had het waarschijnlijk bij de directie gekomen, hadden ze in de logs gezien dat mijn account die actie had gedaan en was ik op staande voet ontslagen.

[wankel]

Ken uit eigen ervaring dat direct toegeven en samen met anderen oplossen veel beter werkt dan stilzwijgen en hopen.
------>%------>%---- knip spannende annecdote ------->%------------
Had ik niets gezegd had het waarschijnlijk bij de directie gekomen, hadden ze in de logs gezien dat mijn account die actie had gedaan en was ik op staande voet ontslagen.

Het is wat off-topic, maar dat laatste lijkt me averechts werken. Als je (aantoonbaar) met opzet de boel om zeep helpt is het wat anders, maar als een bedrijf alle mensen ontslaat die een vergissing maken, hebben ze alleen onervaren mensen in dienst.

[MSalters]

Dat is ook niet mogelijk, in Nederland. Een enkele vergissing, in een omgeving waar het bedrijf er niet voor heeft gekozen om met het 4-ogen principe te werken? Het stikt van de jurisprudentie dat je daar niet eens voor ontslagen kunt worden, laat staan op staande voet.

[mphilipp]

hadden ze in de logs gezien dat mijn account die actie had gedaan

Dat dus...verstoppen heeft geen zin en maakt het alleen maar erger.
Ontslag was het misschien niet persé geworden, maar je had op zijn minst wel een flinke uitbrander gehad.

Het voorbeeld dat jij noemt was voor mij reden om de Putty connecties die naar productiesystemen gingen een heel irritant kleurenschema te geven, of in ieder geval opvallend/afwijkend, zodat je niet per ongeluk commando's invoert op het verkeerde systeem. Sowieso nooit langer dan noodzakelijk connecties naar productie open houden.

[WhatsappHack]

Het aanwijzen van een schuldige is in deze totaal nutteloos.

Het stelt waarschijnlijk wat oppervlakkige aandeelhouders, die niet gehinderd worden door enige technische kennis, tevreden.

[dasiro]

inderdaad, als je goed en/of snel kan mitigeren dan wordt er minder op gezeikt.
Zo heb ik ooit eens gescript alle NIC's op 100+ RODC's weggesmeten ipv enkel een specifieke overbodige. Half uurtje later waren ze via de management interface/hypervisor terug online doordat er snel geëscaleerd was en ik er niet alleen voor stond om de fysieke machines over te nemen.

[IrBaboon79]

Foutje kan gebeuren - hier een soortgelijke ervaring. Na het uitvoeren van een - door development ‘getest’ - script een paar miljoen smartcards en secure chipsets van nieuwe sleutels voorzien waardoor een half land geen TV meer had; gelukkig ter plekke dat script gefixed en de juiste sleutels erin gezet…duurde een uurtje en was even zweten maar de hele boel weten te redden. Naderhand een vrij stevig gesprek gehad met die tester die dat eventjes gemist had…

[jcvw]

Naderhand een vrij stevig gesprek gehad met die tester die dat eventjes gemist had…

Ik denk dat het beter is om met de tester te praten hoe het mis kon gaan en een en ander zo aan te passen dat het niet nog eens op dezelfde manier fout kan gaan. (bijvoorbeeld eerst een deployment op een kleine kleine groep (echte klanten) doen en na OK bevinden pas groter uitrollen.)

[anboni]

De beheerder is wel degelijk verantwoordelijk. Dat wil verder niet zoveel zeggen, zolang het een oprechte vergissing was (en het niet al vaker is voorgekomen), zou de enige juiste reactie van het bedrijf zijn 'wat kunnen we hiervan leren?'

[Wobblier]

Ik vermoed dat met deze ervaring dit de beheerder noooooit meer gaat overkomen. En daarmee juiste man voor toekomstig onderhoud

[LeoT]

Vroeger, werden er bij risicovolle acties, de commando’s functioneel en technisch van te voren uitgeschreven. Een andere eventuele collega deskundige keek eventueel, ook hiernaar.
Alleen jammer dat bij dit soort super acties gelijkwaardige deskundige collega's, vaak niet voorhanden zijn.
Tijdens de uitvoering mocht de <Enter> knop pas uitgevoerd worden na mede instemming.

Scripten kan ook. Een goede programmeur/scripter kan dat verduidelijken voor “leken” met een goed simpel functioneel ontwerp met bijbehorende technische commando’s alsof het schijnbaar lijkt alsof elke boer dat zou kunnen. Maar dat is nu net de kunst, zelfs al heb je een HBO/universitair IT-niveau.
En netwerk wijzigingen of onderhoud zijn extra risicovol.

Een “goede” supervisor zou dit soort functionele kwaliteit moeten bewaken, en verder maar op vertrouwen dat deze, goed omgezet was naar de bijbehorende uitvoering.
Helaas hebben IT managers vaak geen enkel benul van basale kwalitatieve IT.
Technisch hoeft niet, maar wel net de laag daarboven. De functionaliteit.

[djdaan]

Hoef je in iedergeval niet je vrijdag avond weg te gooien

[rene_fb]

Zoals men wel eens zegt: een mooi verhaal voor de verjaardag.

[slowdive]

Maar serieus. Hoe zou het met haar/hem zijn? Jong? Oud? Gepokt en gemazeld of net nieuw? Doet dit iets met haar/hem? Of een vervelend incident; kan gebeuren? Is er nog iets te evalueren of einde verhaal bij Facebook?

[Odie]

Dit kan iedereen overkomen, hoe stom de actie misschien was.

Niemand besluit onder normale omstandigheden “zo, nu ga ik het hele netwerk eens effe op z’n hol helpen”. Het is vaak een samenloop van omstandigheden. Iemand lette net op, iemand had haast, iemand heeft slecht geslapen want kind/vrouw/familie en is er dus slecht bij, iemand heeft net teveel permissies dan BV oef voor hem/haar zijn, iemand wijkt één keer af van de procedure en heeft de MOP niet goed uitgedacht of gevolgd, etc etc.

Dit had mij twintig jaar geleden als broekie kunnen overkomen en het kan me nu (hoewel, ik ken inmiddels het klappen van de zweep en ik heb een hóóp geleerd hoe je dit soort dingen zo goed mogelijk kan voorkomen) nog steeds overkomen.

[J_van_Ekris]

In ieder geval een ervaring rijker die hem uniek maakt in de wereld: door een typo de halve wereld een stel populaire apps even uitgezet.

[Marve79]

Staat goed op je CV

[david-v]

Hahaha remember, remember, the 4th of october....that was me!

Ik denk dat die persoon nog niet geslapen heeft sinds gisteren

[aadje93]

Gezien de meeste IT tegenwoordig uitbesteed word naar India en consorten zal het eerder maandag->dinsdag nacht geweest zijn

[dev10]

Gezien de meeste IT tegenwoordig uitbesteed word naar India en consorten...

Waar baseer je dat op?

En daarnaast: denk je echt dat een miljardenbedrijf als Facebook met meer dan 60.000 werknemers hun IT gerelateerde zaken uitbesteed aan Indiërs?

[Rudyy]

Gewoon gelijk de vinger naar de audit software met “bug” wijzen.

[BeQuietAndDrive]

Even een leek-vraag: waarom bestaat een dergelijk commando eigenlijk? Wat kan een praktijksituatie zijn waarbij je met dit commando een complete backbone offline wilt trekken?

[Tozz]

Omdat je soms een router uit je netwerk wilt halen. Of een topologie wijziging wil doen. Waarom bestaat het "format" commando? Omdat je soms een disk wil formatteren. Waarom bestaat een "shutdown" commando op een server? Omdat je 'm soms uit wil zetten.

In dit geval is er sprake van een managementsysteem dat routers kan beheren. Er logt dus niemand in op 1 losse router, dat doet het managementsysteem dat een centraal platform is. Als de beheerder iets heeft gezegd als 'Disconnect alle poorten op router *1' waarbij het sterretje een typo is en wordt vervangen door 'Alle routers', en het managementsysteem rolt dat vervolgens uit op alle routers en op router 1.. En de 'debug tool' heeft die typo niet gezien als problematisch.. Dan ga je.

[david-v]

Een commando, en het maakt eigenlijk niet uit waar het voor gebruikt wordt, is een "abstractie" op de aansturing van je programmatuur/hardware. Die commando's heb je nodig omdat je anders serieuze problemen zou kunnen hebben bij het down brengen of opschonen van een omgeving.

Stel dat FB een massive aanval zou krijgen op hun systemen die ze niet kunnen tegenhouden, dan is een dergelijk commando de spreekwoordelijke bijl die een kabel doorsnijdt en je de verbinding met het internet stopt.

Bijvoorbeeld tooling voor het verwijderen van data uit een server, die schoont dus alles op, en dat gebeurd niet met een simpele delete of format, maar door het overschrijven van elke bit op de harde schijf. Zonder dergelijke tools en commando's kan het behoorlijk lastig worden omdat je dan hardware moet gaan versnipperen, en dat wil je niet.

Zo heb je een commando voor een database, truncate, waarmee je hele tabellen vrijwel direct kan verwijderen. Die commando's heb je echt nodig.

Maar....en nu komt het...dergelijke commando's moeten beperkt worden tot een handvol accounts, er moet auditing op plaatsvinden én er moet een failsafe zijn. Die failsafe kan zijn dat je tig keer akkoord moet geven op het uitvoeren van het commando of dat er een andere persoon akkoord moet geven. FB heeft aangegeven dat die failsafe wel aanwezig was maar door een bug in die failsafe alsnog het commando uitgevoerd kon worden (ik laat even in het midden of dat waar is of niet).

[mario963]

In het artikel worden BPG-advertisements besproken, is dat een fout en bedoelen we BGP (Border Gateway Protocol)? Of wat is BPG?

[Reactie gewijzigd door mario963 op 23 juli 2024 05:27]

[tweaker2010]

In het artikel worden BPG-advertisements besproken, is dat een fout en bedoelen we BGP (Border Gateway Protocol)? Of wat is BPG?

Klopt, dit is een foutje van Tweakers redactie. Het gaat hier om BGP, en niet om BPG.
https://networklessons.com/bgp/troubleshooting-bgp-route-advertisement
https://blog.cloudflare.com/october-2021-facebook-outage/

[Yariva]

Ik denk in deze context BGP notifications tussen BGP neighbors. A.k.a. het slopen van je TCP sessies naar je neighbors. Maar slecht vertaald is het zeker.

[Reactie gewijzigd door Yariva op 23 juli 2024 05:27]

[phosporus]

Ze hebben het onderhand aangepast. Jammer genoeg staat er nog wel een paar keer BGP protocol waarbij de p in BGP al voor protocol staat.

[vtsalf]

Het protocol _heet_ BGP. Waarbij de P voor protocol staat. Het lijkt dan ook redundant om nogmaals protocol te noemen. Echter is dit niet zo. Ik heb het uitgezocht. Op onzetaal.nl overigens als bron.

[Reactie gewijzigd door vtsalf op 23 juli 2024 05:27]

[GeeBee]

Doe eens een linkje, want BGP is geen lemma op OnzeTaal.nl
https://onzetaal.nl/zoekresultaten?keywords=BGP

Edit: Ah… hier wel.
https://onzetaal.nl/taaladvies/apk-keuring

[Reactie gewijzigd door GeeBee op 23 juli 2024 05:27]

[xmenno]

Eigenlijk wel maar dat zijn maar kleine gemiste details, de hele artikelen over deze storing zijn niet erg sterk.
Gisteren werd er overigens ook al gesproken over een "bga-activiteit".
nieuws: WhatsApp, Instagram en Facebook komen weer online na storing - update 5

[Yzord]

Ik geloof niks meer wat deze bedrijven ons proberen te vertellen. Het zal allemaal wel. Feit blijft dat ze evil zijn en geld verdienen aan de opgekropte woede van mensen welke zich uiten op de so called "social media".

Nogmaals lieve mensen, dump die zooi toch uit je leven. Het leven moet je vieren met werkelijke dingen en niet opvullen met allemaal fake zooi. Want alles is fake...alles wat je voorgeschoteld wordt is simpelweg nep. Al die influencers, gelukkige foto kiekjes etc.

Wat echt is is wat je voelt. In je hart en niet in je hoofd. Likes stimuleren alleen maar de receptoren in je hersenen waar je verslaafd aan raakt en dus wil je meer.

[Reactie gewijzigd door Yzord op 23 juli 2024 05:27]

[Verwijderd]

Dat u met uw bericht spotlights en Informatieve beoordelingen krijgt... dat vind ik bijzonder. U reageert niet eens inhoudelijk op het bericht, maar grijpt de kans aan om een soort anti-evangelische boodschap te verkondigen. Ik vind uw bericht vrij kort door de bocht en eenzijdig en absoluut niks informatief of "spotlight-achtig" toevoegen.

Want alles is fake...alles wat je voorgeschoteld wordt is simpelweg nep.

Alles is fake en nep? Heeft en deelt u wel eens blije momenten?

Nogmaals lieve mensen...

U heeft vrijheid van meningsuiting maar de plek, het moment en inhoud van uw reactie op een toelichting van een storing doet me denken aan een welbekend beeld van een persoon die op de hoek van een kruispunt staat te roepen dat de wereld tot een eind gaat komen als wij, lieve mensen (?), niet veranderen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 05:27]

[Calypso]

Helemaal eens met @conces; ik vind het niet alleen bijzonder maar ook gevaarlijk. "Feit blijft dat ze evil zijn" is zo'n uitspraak die voor mij het hele betoog compleet onderuit haalt. De onderliggende gedachte van het bericht ("er is zoveel meer als social media, geniet van het leven") kan best wel kloppen, maar door dat soort uitspraken ("evil") wordt het helemaal ondergesneeuwd.

En dan een uitspraak als "likes stimuleren alleen maar de receptoren in je hersenen waar je verslaafd aan raakt", dat is exact hetzelfde met al het andere waar je een "prettig gevoel" van krijgt, inclusief hetgeen wat @YZord probeert te promoten - en daar is niets mis mee, want zo zitten wij als mens in elkaar. Social media kan een middel zijn om een stukje geluk te verwerven; maar zoals met alles (inclusief het leven zelf) is er een verslavingsrisico waar mensen zich bewust van moeten zijn om er adequaat mee om te kunnen gaan. Het promoten om af te zien van zaken die "de receptoren in je hersenen waar je verslaafd aan raakt" stimuleren is eigenlijk een oproep om te stoppen met alles waar je je prettiger bij voelt in het leven.

En het sarcasme: het promoten via een reactie op een nieuwsposting: ook een vorm van social media.

[Verwijderd]

Jij hebt het misschien wel beter en objectiever verwoord dan ik heb gedaan. Thumbs up.

[S-A-I-N-T]

Zo enorm met je eens

Deze docu legt dat ook zo mooi uit

https://youtu.be/7mqR_e2seeM

[FiberSam]

Klassiek SNAFU geval. Dit verzin je niet.

[Zalmanman]

Nou... Minstens een TARFUN toch?

[TheVivaldi]

Zeker weten dat het geen PEBKAC was?

[Stoelpoot]

Nope, Facebook lijkt zelf de schuld primair te leggen bij faulty beveiligingstools. Op deze schaal kan je eigenlijk ook niet de schuld bij 1 persoon leggen, dit soort dingen horen beveiligd te zijn.

[WhatsappHack]

Op deze schaal kan je eigenlijk ook niet de schuld bij 1 persoon leggen

Alles kan in een corporate omgeving. Zeker als er een zwart schaap nodig is om op te offeren.

[Genosha]

Faulty beveiligingstool? Ik geloof er geen snars van. Zo'n commando word toch niet silent uitgevoerd? Iemand heeft dat commando uitgevoerd en doelbewust op Y gedrukt.

[Daoka]

Wie zegt dat er nog een bevestiging nodig was? Misschien is de foute commando wel met /y gedaan.

[hottestbrain]

Kun je onderbouwen hoe je aan de kennis komt dat iemand doelbewust op Y moest drukken en uberhaupt die prompt kreeg? Welk commando werd uberhaupt uitgevoerd? Wie zegt dat dit geen custom script is zonder yes/no optie?

[Odie]

Best wel FUBAR. En ik ben niet eens in dienst geweest 😂😂

[GeeBee]

Het is inmiddels gerepareerd, dus wel FU maar niet BAR.
Wel in dienst gezeten

[webfreakz.nl]

Heeft iemand daar wellicht een "clear isis database purge" uitgevoerd en probeert men dat te verhullen? Dat zou namelijk typisch een commando zijn wat je wilt blokkeren met een audit-tool.

[Kwomkwommr]

Je zou toch verwachten dat een partij als Facebook wel een compleet losstaand netwerk buiten hun publieke lijn heeft, dat er niemand snel in de auto hoeft te springen als er iets kapot gaat of je niet meer bij een locatie kan. Ook dat je toegang via die lijn verloopt en niet via de publieke routers / ranges. Out of band network oid.

Denk dat er nog wel meer op de schop moet voor alles "netjes" is

[Reactie gewijzigd door Kwomkwommr op 23 juli 2024 05:27]

[Keypunchie]

Ze zullen vast wel een los beheernetwerk hebben (meerdere, ongetwijfeld) maar wel binnen hun eigen AS.

Dus als je BGP het niet doet…

En laten we ook eerlijk zijn: zo essentieel is Facebook niet. Dat het er een dagje uit ligt is wel duur voor hunzelf, maar de vraag is of het de investering om het te voorkomen echt waard is.

[jcvw]

In Zuid Amerika (en andere gebieden) sponsort Facebook data abo's met gratis data voor whatsapp en facebook: https://www.theguardian.c...basics-developing-markets. In hele landen was 6 uur geen communicatie mogelijk! https://www.theguardian.c...reliance-on-its-services:

“Developing nations such as India, Mexico and Brazil have come to rely on these free messaging services,” said Callum Sillars, social media expert at Ampere Analysis. “They are often the backbone of communication in these countries. Small businesses and informal economies in particular rely on Facebook’s services. In Europe and North America there were more fall-back options for communication during the outage, for consumers and businesses in developing nations, which are most reliant on Facebook, that was not the case.”

[Keypunchie]

Als Facebook daar zo belangrijk is, dan is dat een bug, geen feature.*

Daarnaast, ook voor een klein bedrijfje is 6 uur geen onoverkomelijke ramp.

*Helemaal omdat het “gratis” is. Dan heb en kun je geen SLA afsluiten. Iedereen die überhaupt zijn zakelijk succes volledig laat afhangen van Facebook is onverstandig bezig: hun beleid wisselt constant en zij hebben totaal geen empathie voor hun gebruikers

[GMJansen]

Dat hebben ze.
De blog had het er echte over dat dit OOB netwerk ook niet meer bereikbaar was.

Ps.
Fysieke toegang: niet in deze blog, maar las t ergens anders: het pasjessysteem was ook offline?
Vreemd dat deze geen lokale dump van authorisaties heeft.
Heb dat al eerder gezien: bij een wan outage kun je je eigen serverruimte niet in om de wan router te rebooten.
Of 's morgens om 0830 duurt t bij de tourniquets (toegangspoortjes) tussen elke opening even wat langer omdat iedereen binnen inlogt en de wanlink dus vol zit.

Zo is elke outage weer een leerschool voor toekomstige ontwerpen.

[Verwijderd]

De gevoeligheid om zulke foutieve commando's tegen te houden was net aangepast naar een ander niveau door facebook. Toen de advertentie inkomsten omlaag gingen die weer naar het oude niveau.
Zuckerberg houdt nl. die persoonlijk dag en nacht in de gaten...de advertentie inkomsten natuurlijk, wat anders.

[tapkcir]

"waardoor Facebooks datacentra als het ware volledig ontkoppeld werden van het internet". Voor heel even was er sprake van vooruitgang .