Storing die vliegtuigen aan grond hield kwam vermoedelijk door corrupt bestand

De computerstoring die vliegtuigen woensdag in de VS urenlang aan de grond hield, kwam niet door een cyberaanval. Dat zegt de Amerikaanse luchtvaartorganisatie FAA. De storing kwam vermoedelijk door een 'corrupt databasebestand', aldus de organisatie.

FAA notam

Behalve dat het gaat om een beschadigd bestand, zegt Federal Aviation Administration niets over de oorzaak in zijn statement. "De FAA gaat door met een onderzoek om de oorzaak van de storing in notice to air missions te bepalen. Wij werken hard door om verder te lokaliseren wat de oorzaken van het probleem waren en nemen alle noodzakelijke stappen om te voorkomen dat het nog een keer gebeurt."

De storing zat in het notam-systeem, waarmee vluchtcrews en luchtvaartleiders op het laatste moment actuele informatie over een vlucht binnenkrijgen. Het gaat dan ook bijvoorbeeld over informatie van de vertrek- of aankomstvliegvelden, of over procedures en het weer op een route. De storing had woensdag tot gevolg dat vliegtuigen in de VS urenlang niet mochten opstijgen of landen.

Reacties (126)

Is er geen fail over systeem?
Een redundant systeem lijkt me bij z'n organisatie toch wel op ze plek.
Of is plan B gewoon: We vliegen niet

Lijkt me een aardig kostenplaatje te hebben en slechte reclame dat zoiets gebeurt.

Failover is voor systemen, de corrupte data zelf zal nog steeds gerepliceerd worden naar het failover systeem en dan werkt ook dat systeem niet meer.

Ik denk dat @pekeltje een duplicaat systeem bedoeld. Dus twee systemen die dezelfde data verwerken. Mocht 1 systeem falen dat de ander door kan werken.

Hierbij zijn de clusters los van elkaar met dezelfde data. Vaak wordt dit niet gedaan omdat dit de kosten voor beheer en onderhoudt verdubbeld.

Volgens mij zie je dat wel in de vliegtuigen zelf voor all cruciale onderdelen van de besturing.
In de ruimtevaart heb je het zelfs driemaal en moeten 2 van de 3 systemen dezelfde uitkomst geven voordat bijvoorbeeld een koers correctie wordt uitgevoerd. Dan gaat het niet alleen om de data verwerkingen maar ook sensoren zijn meervoudig uitgevoerd.

Een Lufthansa piloot demonstreerde mij eens (in de tijd dat je nog in de cockpit mocht komen) dat alles meer dan dubbel is uitgevoerd.
Het mooiste onderdeel is het ouderwetse kompas in het midden boven de ramen, dit voor als het complete dashboard zwart is.

klopt, maar dit gaat niet om een sensor in een vliegtuig, maar om het (inter)nationale informatie systeem.
de NOTAM's zijn berichten over veiligheid informatie in en om een bepaald stuk luchtruim. bijvoorbeeld sluitingen door weersomstandigheden, gezien het in amerika is mogelijk tornado's. je wilt niet vertrekken en ineens een tornado tegenkomen bij het landen. maar ook bijvoorbeeld rook door een onstaande bosbrand, of een mogelijke militaire of politionele actie waardoor bepaalde stukken luchtruim zonder waarschuwing vooraf kunnen worden afgesloten.

als er geen duidelijke updates voor de notams zijn is het werkelijk gevaarlijk. mischien niet voor 1 vliegtuig, maar op schaal kan dit voor grote problemen zorgen

Dus dan ga je data 2 keer opslaan? Doodzonde nummer 1 in ICT. En hoe garandeer je dat wijzigingen altijd exact hetzelfde op 2 systemen worden verwerkt?

Er schijnt een Backup systeem te zijn, maar die had hetzelfde "corrupte databasebestand".

Dat suggereert dat de oorzaak niet een of ander defect in de hardware was, maar eerder een programmafout en/of incorrecte data invoer.

Of een erg knullige manier om een backup systeem bij te houden.

De beslissing om niet te vliegen komt gelukkig niet vaak voor.
De bekendste in mijn herinnering waren 9/11, en het luchtverkeer in Europa ten tijde van die spugende vulkaan op Ijsland.
Kostte in beide gevallen bakken met geld maar het waren verdedigbare beslissingen ( die overigens niets te maken hadden met een falend NOTAM systeem.

Slechte reclame?
Het was weliswaar een belangrijk systeem maar niet nodig om alsnog te kunnen vliegen.
Een bedrijf wat onder grote financiële druk en druk van zijn klanten (je zou maar ergens heen moeten of vracht aan boord hebben) besluit om toch de procedures te volgen en niet te vliegen heeft bij mij een streepje voor. Dat is juist reclame. Als het nu nog een keer om dezelfde reden zou voorkomen dan wordt het pas slechte reclame want dan is men niet in staat om te verbeteren.

In de VS zijn notams wel nodig om te kunnen vliegen. Via notams wordt aangegeven welke restricted areas actief zijn. Het is verboden om door deze gebieden te vliegen.

Notams worden ook de ATC gebruikt om commerciële vliegtuigen om gesloten gebieden heen te loodsen.
Dit is de eerste keer in ruim 70 jaar dat dit systeem een probleem geeft...

"De storing zorgde er woensdag voor dat vluchten in de VS urenlang niet mochten opstijgen of landen."

Dat opstijgen kan ik me voorstellen, maar niet mogen landen wordt met lege tanks toch wel een dingetje

"het systeem geeft mededelingen met essentiële informatie aan luchtvaartpersoneel. Het gaat bijvoorbeeld om de weersvoorspellingen voor luchthavens, actieve taxibanen of sluitingen van het luchtruim"

Wellicht moet er extra toezicht gehouden worden, of uitgeweken naar andere vliegvelden waar het landen minder toezicht vereist.

Mijn ervaring in de laatste jaren (SAP domein) is dat kritische systemen wel redundant zijn uitgevoerd, de database netjes repliceert conform SLA etc. Maar vervolgens de afdeling beheer urenlang bezig is de juiste approvals te verkrijgen voor failover/restore. Dan de serviceprovider/subcontractor te bereiken en daar nog enkele uren te verliezen voor er op de juiste knoppen is gedrukt.

Het is toch best grappig om te lezen dat redelijk grote deel van tweakers wel een mening heeft waarom er geen failover, ducplicatie etc etc zijn.

Steel jij bent die gene die on call is. System faalt. Weet jij dan meteen dat het om een corrupt best and gaat? En misschien erger, het system is helemaal niet offline maar werkt alleen niet naar verwachting. En de backup systemen hebben ook het zelfde gedrag, wat dan? Wie besluit dat je een backup mag terug zetten? Niet de on call medewerker lijk me. Serieus voordat door heb de ernst van dit probleem en iedereen erbij betrokken moet zijn, ben je zo een uur verder.

En dan begint de zoektoch naar hoe nu verder. Het zijn allemaal aannames. Maar zoveel info is er nu ook niet gegeven. Ze hebben nu alleen gezegt, corrupt data bestand en tel maar in de comments hoeveel mogelijke variaties men kan bedenken om dit goed te doen, laat staan hoeveel mogelijke manoer er zijn om data te laten corrupten. Er is simpelweg te weinig vrijgegeven om tot een conclusive te komen of ze goed hebben ingericht. Wacht gewoon even af. Wij krijgen het misschien wel te horen.

best slecht,, waarom namen de fail over systemen het niet over ? ze hebben toch wel plan B ?

Dit is geen kwestie van fail-over systeem, want er is niks met je systemen, het is je data die corrupt is.

Dus je serveert prima data, maar de data zelf is waardeloos.

De vraag is dan vooral: waarom duurde dienstherstel zo (relatief) lang.

Of om hem iets positiever te stellen: hoe kun je als IT zorgen dat in geval van corrupte data je snel naar een acceptabele staat kunt terugvallen.

Vaak is dit een kwestie van een back-up terugzetten en logs opnieuw draaien. Dat is iets dat je wilt automatiseren en/of oefenen.

Wat ik ook weet van een organisatie met een zeer belangrijke database is dat ze 2 versies draaiden: 1tje die up-to-date was, en eentje waar ze alle transactielogs naartoe verscheepten en met een vertraging van enkele uren toepasten. Die konden ze dan in geval van corruptie inzetten in plaats van de primaire.

Dit heb ik verder eigenlijk niet zo heel veel gezien, hoewel het geen gekke oplossing was.

Ook dan bestaan er toch error correction systems met hashes die bij een mismatch direct alarm geven en de spiegelbit overzetten? Of heb ik teveel vertrouwen in dit bedrijf dat dagelijks grote hoeveelheden data moet verwerken?

Het hoeft geen hardwarefout te zijn. Kan ook gewoon een softwarebug zijn die corrupte data schrijft. Dan kan je het 100x repliceren en schaduwsystemen hebben, maar die zullen allemaal dezelfde fout bevatten. Hardware kan je redelijk failsafe krijgen, maar software is een stuk lastiger. Unit testen dekken alleen waar je aan gedacht hebt (fuzz testing uitgezonderd) en ook integratietesten zijn nooit 100% dekkend.

Dit is toch niet helemaal juist, je kan prima de input managen, bijvoorbeeld door het invoer bestand te laten genereren met een stuk software die alleen het juiste format kan genereren. Dit had ook de grote outages bij Cloudflare en AWS, als ik het goed herinner kunnen voorkomen, enkele jaren terug. In beide gevallen was er bij mijn weten sprake van foute configuraties die ingeladen werden door een engineer.

Het is inderdaad mogelijk om 100% bugvrije software te maken zonder ook maar een enkele fout.

De kans dat je 't voor elkaar krijgt is alleen onnoemelijk klein.

Toch was het NOTAM er zeer dicht bij, want dit is de eerste 'bug' in het systeem er vanuit gaande dat het bestand corrupt is geraakt door software en niet een falende fileserver waardoor het bestand corrupt is geraakt...

Ik vermoed dat men gewoon het bestand opnieuw gegenereerd heeft.

Edsger Dijkstra bewees wiskundig, vroeg in de jaren 50, de mogelijkheid van programmeren zonder bugs, zag ik eens op Zembla maar dat weet ik niet zeker meer. Hiermee ging hij naar IBM en HP, maar die wilden hun op service gebaseerd businessmodel niet afschaffen. Dijkstra ging naar de universiteit van Texas en zette e.e.a. op Internet: https://www.cs.utexas.edu/users/EWD/

[Reactie gewijzigd door wolf47 op 13 januari 2023 13:40]

De realiteit van alle dag is complexer dan de wiskundige wereld van Dijkstra.

Ada was een poging om een programmeertaal te maken waarin je foutloos kunt programmeren. Er was een fighter, ik dacht de F16, waarvan de fly-by-wire software in Ada was geschreven. Maar als de piloot op zijn display zag "Ada run time error: division by zero", dan was de schietstoel het enige wat het nog deed.

En hoe je het ook wendt of keert, je blijft afhankelijk niet alleen van je eigen code, maar ook van libraries, de compiler run-time en het OS.

En tot slot: zelfs als je programma 100% foutloos is, moet de specificatie van het programma dat ook zijn. Iedere programmeur kent wel een voorbeeld van code die "broken by design" is. Volgens spec gebouwd, maar doet niet wat het moet doen. "I really hate this damn machine, I wish that they would sell it. It never does quite what I want, but only what I tell it."

Van origine was de fly-by-wire computer van de F16 analoog dus hoogst waarschijnlijk gen Ada.
https://duotechservices.com/what-is-fly-by-wire
"The F-16 Flight Control System is an analog, quadruple-redundant computer system"
"In the late 1980s, USAF introduced the Block 40 F-16. This version upgrade to the F-16 included numerous improvements to most major systems on the aircraft, including the flight control system. The FLCC was replaced with the DFLCC or Digital Flight Control Computer."

https://duotechservices.com/flight-control-computer-flcc
Nog niet gevonden of de DFLCC op Ada of iets anders gebaseerd is...
https://en.wikipedia.org/..._Fighting_Falcon_variants

Je doet Dijkstra te kort, kijk eens naar hem op de Engelstalige Wikipedia (de Nederlandstalige is lang niet zo uitvoerig). Als ik het goed heb, trok hij zich snel terug uit de groep die ADA ging ontwikkelen. Zijn Dijkstra-algoritme blijft gebruikt in navigatie-apparaten als de TomTom, om maar wat te noemen.
Maar de kans om 100%-bugvrije software te schrijven is echt niet minimaal, ook al heb je te maken met de menselijke omgeving.

[Reactie gewijzigd door wolf47 op 15 januari 2023 14:42]

Ik heb Dijkstra en Knuth gelezen in mijn jonge jaren, taaie kost!

Dijkstra's algorithme is misschien 1% van de bewegende delen van de TomTom software. Een beperkt algorithme kan je wiskundig bewijzen. Een grote codebase niet.

Het NOTAM systeem waar de discussie mee begon is een typisch voorbeeld van software die niet volledige gespecificeerd kan worden, en dus niet foutvrij gebouwd kan worden. NOTAM's zijn door mensen ingeklopte gestructureerde data met overal en nergens vrije tekst. Ik vermoed dat er een entry in de NOTAM database stond, die tijdens het invoeren door de validatie is gekomen, maar bij de reboot niet gevalideerd kon worden. En dat de specificatie zegt dat de applicatie niet mag opstarten als er corrupted entries zijn.

Ergens in de persuitingen had de FAA gezegd dat restarts van het NOTAM systeem zeer zeldzaam zijn, dan kom je gauw op bovenstaand scenario.

Merci en dat verheldert het weer.

Geen idee waarom @flurb gedownmod wordt want zijn punt is prima valide.
Hij heeft het ook helemaal niet over 100% bugvrije software, enkel over input validatie volgens mij.

Maar er zijn natuurlijk tientallen manieren om redundancy te faciliteren. Van hardware opslag tot software clusters... Ook data corruptie is prima op te vangen (mede door input validatie). Iedereen weet bugs er zijn dus bereid je juist verschillende lagen voor zodat je onverwachte problemen op kunt vangen. Een corrupt bestand of zelfs ook al maar een niet-valide waarde in een database zou niet de uitval van het gehele systeem moeten betekenen...

Je kan het ook andersom benaderen en Chaos engineering hanteren... Een voorbeeld hiervan is ChaosMonkey van Netflix dat willekeurig storingen veroorzaakt om zwakke punten te vinden.

Het zal iets zijn als de kans dat een geheim uitlekt, het aantal mensen dat het weten in het kwadraat. Maar dan het aantal regels code in het kwadraat. Om software te maken die niet alleen nu geen fouten heeft maar ook voor alle situaties in de toekomst.

Je leest mijn post niet.

Maar om het iets verder te duiden je kan prima always on systemen ontwikkellen, alleen de crux is dat je er juist van uit moet gaan dat er zaken onvoorzien anders lopen.

Een soort integrale exceptie handling op basis van processen en techniek.

Mainframes zijn een aardig voorbeeld van een dergelijk concept. Die zijn conceptueel dusdanig ingericht voor wat betreft proces, software en hardware dat het behoorlijk knap is als je dat volledig onderuit krijgt.
Combineer 2-3 van dit soort systemen op verschillende locaties met ondersteuning door de juist ontworpen processen en invoer validaties en dan ben je al een aardig eind onderweg naar nooit meer offline.

Daarnaast heb je bijvoorbeeld ook concepten zoals Google, waarbij iedere server op ieder moment vervangbaar is maar daar hebben Cloudflare en AWS laten zien dat het inladen van (niet goed gevalideerde) configuraties toch een heel platform kunnen ondermijnen.

Er zijn diverse startegien naar "always up" maar de kern zit hem in het anticiperen op niet voorziene situaties, dat geeft de robuustheid die leidt tot extreme uptimes.

Dit is toch niet helemaal juist, je kan prima de input managen, bijvoorbeeld door het invoer bestand te laten genereren met een stuk software die alleen het juiste format kan genereren

Het formaat kan perfect in orde zijn, maar dat betekent nog niet dat de data zelf ook correct is.

Dat “stuk software dat alleen de juiste input kan genereren” kan ook een foutje hebben. Of in de verwerking van die data zit een foutje. Stel dat je het verschil van twee waardes uit verschillende records gebruikt in een deling. Als beide waardes gelijk zijn dan heb je een “divide by zero”. De data zelf is wellicht helemaal valide. Er kan gewoon heel veel mis gaan en dan laat ik concurrency issues nog buiten beschouwing.

Zelfs dan zou je met een basic version control system zeer eenvoudig terug kunnen schakelen naar een moment waarop de software wel goed functioneerde. Maar zoals het artikel al vermelde ging het hier dus om een corrupt bestand, wat wel degelijk met error correction opgelost had kunnen worden in een fractie van de tijd die ze nu kwijt zijn.

Leuk dat je de applicatie kan terugrollen naar een vorige versie, maar je data blijft dan alsnog corrupt. Het is duidelijk dat je er veel te makkelijk over denkt terwijl het niet zo simpel in elkaar zit. Claimen dat het met "error correction" opgelost had kunnen worden zonder ook maar iets van de systemen te weten kan je gewoon niet doen.

Als het allemaal echt zo simpel was geweest zoals jij het doet voorkomen, dan was dit probleem niet ontstaan en had het zeker niet zo lang geduurd.

Als de software niet goed functioneert, voer je een rollback uit middels VCS. Precies waarvoor het bedoeld is. Als je data corrupt is, voer je een rollback uit middels VCS of error correction. Precies waarvoor beide bedoeld zijn.

Je kan wel stellen dat het "niet zo simpel" is, maar dat is het mooie aan deze methoden: dat is het wel. Het feit dat het probleem zo lang geduurd heeft wijst er eerder op dat ze VCS en/of error correction dus niet adequaat geïmplementeerd hebben. Om nog maar te zwijgen over backups. Om je patroniserende toon even een tandje lager te zetten: het principe van backups werkt ook ongeacht het soort data waarmee gewerkt wordt. Je hoeft het systeem niet te kennen om te snappen dat de aanwezigheid van backups bepaalde soort problemen kan attenueren.

Rollback vd data waardoor je veel data kwijt bent of heel lastig terug moet migreren. Je denkt er echt te simpel over.

Het is inmiddels duidelijk dat het probleem van het nieuwsartikel een menselijke fout was. Geen VSC of "error correction" gaat je daar van redden. En ik weet niet over wat voor "error correction" jij het hebt, maar als je EEC geheugen bedoelt, dat helpt hier geen malle moer mee. En wanneer je "error correction" in de applicatie hebt, dan kan je er ook voor zorgen dat errors niet eens ingevoerd kunnen worden.

En wat betreft backups, bij grote systemen zoals dit is het niet zomaar even een kwestie van een rollback doen. Vooral niet als je het probleem binnen acceptabele tijd kunt oplossen (uiteindelijk was dit systeem 1.5 uur down, zonder backup te hoeven herstellen, en dus geen data loss).

Je kunt heel makkelijk vanaf de zijlijn roeptoeteren, maar als je geen ervaring hebt met grote en complexe enterprise systemen, dan komt dat groep niet heel intelligent over.

Ik denk dat vele mensen dit soort complexe systemen zeer onderschatten en het afdoen met "zeker weer geen budget gesteld". Je kan nooit alles afvangen, zeker bij real-life datasystemen. Soms kan iets kleins wat over het hoofd wordt gezien zoals een gebruiker die een emoticon kan invullen in een postcodeveld een heel database systeem doen crashen. Dus dan moet je buiten je datacorruptie checks ook nog datacorrectie checks implementeren. Dat maakt het al veel complexer en soms ook gewoon niet haalbaar aan de database kant als de data bijvoorbeeld wordt gebruikt in calculaties.

Wat ik ook weet van een organisatie met een zeer belangrijke database is dat ze 2 versies draaiden: 1tje die up-to-date was, en eentje waar ze alle transactielogs naartoe verscheepten en met een vertraging van enkele uren toepasten. Die konden ze dan in geval van corruptie inzetten in plaats van de primaire.

NoTAM staat voor Notice To Airmen (zie https://skybrary.aero/articles/notice-airmen-notam): zeer actuele informatie die piloten nodig hebben over weer, faciliteiten, obstructies, storingen en grondsituatie op hun route en eindbestemming. Als het ouder is dan een uur is het totaal onbruikbaar.

Totaal onbruikbaar is nonsens.

Een vlucht naar de VS duurt rustig 8 uur, dan kun je de NOTAMs niet per se bijwerken…

Ook is de overgrote hoeveelheid van de NOTAMs niet echt zo nuttig hoor*. De keuze om het vliegverkeer neer te leggen was precies dat: een keuze. (Die ik overigens volledig begrijp)

*en dat is niet iets dat ik alleen vind, maar iets dat de hoogste baas van de Amerikaanse transportveiligheidraad een aantal jaar terug meldde: https://m.youtube.com/watch?v=LWLPDOXF7e4

Of: https://www.ainonline.com...rman-calls-notams-garbage

“Notams are just a pile of garbage nobody pays any attention to”

Dat was natuurlijk zwaar gechargeerd, maar NOTAMs maken niet het verschil tussen leven en dood. Ik zou echter niet zonder willen vliegen.

Dat was natuurlijk zwaar gechargeerd, maar NOTAMs maken niet het verschil tussen leven en dood. Ik zou echter niet zonder willen vliegen.

Het probleem is dat tussen die 95% ruis/routinemeldingen ook aanwijzingen staan over restricted airspace en bijvoorbeeld gesloten runways. Ik deel je beeld dat dit beter kan, maar zoals je zelf eigenlijk ook al zegt: je kunt niet zonder...

De (geplande) sluiting van een landingsbaan komt echter ruim van te voren op de NOTAM, niet een paar uur van te voren.

In het voorbeeld was de landingsbaan gesloten omdat hij opnieuw geasfalteerd werd. Dat wordt natuurlijk ruim van te voren gecommuniceerd.

Als er een acute sluiting is, dan geeft de luchtverkeersleiding dat door.

Ik zou niet zonder NOTAMs willen vliegen (wat de situatie was), maar met de NOTAMs van gisteren (of een paar uur oud) zie ik het probleem niet zo.

Nu was uiteraard het hele systeem plat, dus niet vliegen was de verstandige keuze.

Met de kennis die ik heb: het systeem moet heel hoge beschikbaarheid hebben, maar hoeft niet per se real-time up-to-date te zijn (ik zou het wel real-time inrichten).

[Reactie gewijzigd door Keypunchie op 13 januari 2023 01:39]

Notice to Airmen is in 2021 al hernoemd naar Notice to Air Missions

https://www.faa.gov/docum....2S_Chg_2_dtd_12-2-21.pdf

De vraag is waarom is die data corrupt geraakt. Stel dat het een hardware issue is dan had een fail-over kunnen werken, hoewel het heel lastig is om een fail-over systeem een dergelijke fout te laten detecteren. (vaak moet je dan manueel een fail-over triggeren)

Als een input verantwoordelijk is voor het corrupteren van je database dan mag je inderdaad nog zo redunant mogelijk draaien, diezelfde input had al je databases om zeep geholpen.

Op je vraag waarom duurde de hersteldienst zo lang, een vraag die ik hier nog zie passeren.

Als ik morgen geconfronteerd word met een safety systeem welke volledig tilt is geslagen waarbij ik zie dat een of andere config corrupt is geraakt;

Dan ga ik niet even die config file herstellen om vervolgens te zeggen, start het systeem erachter maar weer op want dan ben je aan het spelen met levens.

Die config file herstellen is 1 ding, de root cause achterhalen is iets anders, de volledige werking van je safety systeem controleren zodat je absoluut zeker bent dat hij terug volledig correct werkt, dat is nog een geheel andere koek.

Immers mogelijk is niet enkel die ene config file of dat ene datafile corrupt, mogelijks zijn er ook andere incorrect. Je wilt er niet achter komen dat je safety systeem wel terug online is maar eigenlijk zijn werk niet meer correct doet omdat jij snel snel dat systeem terug hebt vrijgegeven als klaar voor gebruik want kijk, het draait terug en van wat ik hier 1-2-3 zie lijkt het wel ok te zijn.

[Reactie gewijzigd door sprankel op 12 januari 2023 23:32]

Ik ben blij dat iemand dat inziet.

Het doet me denken aan mensen die denken dat een replica van data een soort van backup is, terwijl een fout in data gewoon mee grepliceerd word...
Of erger data delete in 1 systeem word dan ook gedelete op het andere...

veel mensen hebben echt die logica niet meer tegenwoordig en voel zich te vlug veilig omdat ze de zogezegde veilige oplossing niet kunnen challengen, het lijkt namelijk veilig en goed concept

Dus je serveert prima data, maar de data zelf is waardeloos.

Je gaat hier best snel overheen.

Wij werken hier ook met veel databestanden maar die kon je benaderen en bewerken met verschillende programma’s om vb tzt web-browsed te werken. Dat was in eerste instantie alleen data en dat blijft voorlopig ook zo omdat het niet echt werkt voor alle functies.


Nu wordt er de mededeling gegeven “dat “een” bestand corrupt” is maar verder geen invulling wat best vreemd is voor een luchtvaartmaatschappij.

Juist daar wil je dat alles bewezen is en werkt en niet de praktijken uit de ICT importeert waar je producten verkoopt die niet af zijn om tzt up te daten.

Dit gaat zover ik kan zien bijna om reallife data. Dat valt amper te back uppen. Ja met Copy on write misschien?

Jep, en die copy bevat dan ook de corrupte data.

Ik denk dat we aan mogen aannemen dat deze systemen zeer robust zijn uitgevoerd.

Wellicht dat er een bepaalde input validate ontbrak en bepaalde invoer invloed had op de rest van de records.
Althans dat zie ik in de praktijk als meest voorkomende oorzaak, alle systemen hebben capaciteit van minimaal dubbel de normale peak load, hot standby, multi zone, multi region en auto scaling en een read replica en dan nog steeds de input validatie niet tip top in orde op alle input.

Dat laten ze dan bijvoorbeeld over aan tools als Imperva in plaats van het gewoon zelf goed doen.

[Reactie gewijzigd door djwice op 12 januari 2023 23:41]

Maar dan zou er toch nog Journalizing toe worden gepast? Zo heeft zfs geen Journalizing maar wel COW. En heeft BTRFS wel Journalizing en COW. Maar is daardoor weer trager.

Wat zou jij dan doen kiezen voor zfs of BTRFS of dan toch misschien Reiser4?

Dit is inderdaad een manier om snel terug te kunnen naar een database die nog goed was. Software en mensen kunnen ervoor zorgen dat corruptie optreed, replicatie wapent je daar niet tegen. Lastig blijft te bepalen hoever je terug in de tijd moet om de laatste niet corrupte stand terug te zetten. Ga je gever terug moet je heel veel goede transacties herhalen. Ga je niet ver genoeg terug kan (het begin van) je corruptie er al in zitten.

Plan B was de vliegtuigen niet laten vliegen, dat is, zover ik het begrijp, goed uitgevoerd.
Je hebt ook geen reservevliegtuigen klaarstaan voor elk vliegtuig wat op moet stijgen en een technisch defect heeft. Nou staat er te weinig gegevens in het bericht om tot een goede conclusie te komen, dus misschien had er prima een backup kunnen zijn, maar dat weten we niet ...

Er staat dat het om een corrupt databasebestand ging.
Dat dit het effect heeft dat:
- men niet eens weet wat er mis is
- men niet vliegt voor 'enkele uren'
Zegt wel nogal iets.

Ik kan je vertellen dat je voor de geleden kosten/schade die ze nu hebben gemaakt voor decennia lang elke relevante database 2 of 3x redundant met naadloze balancering en fail-over kunt uitvoeren en enkele systeembeheerders 24/7 on-call kunt betalen.. en waarschijnlijk nog geld over hebt voor een absurde bonus voor je CTO.

Bedrijven investeren pas in ICT wanneer ze de kosten moeten happen van het niet gedaan te hebben.. en zelfs dan is het nog erg lastig om gedaan te krijgen want gewoon even een verontschuldigingsbrief schrijven is een stuk goedkoper.. tot de aanklachten voor wanpraktijken aanwaaien natuurlijk

[Reactie gewijzigd door Ayporos op 12 januari 2023 21:52]

Ik kan je vertellen dat je voor de geleden kosten/schade die ze nu hebben gemaakt voor decennia lang elke relevante database 2 of 3x redundant met naadloze balancering en fail-over kunt uitvoeren en enkele systeembeheerders 24/7 on-call kunt betalen.. en waarschijnlijk nog geld over hebt voor een absurde bonus voor je CTO.

Daar ga ik ook wel van uit. Maar ... zijn er meer delen in het geheel die dit effect kunnen hebben en deze redundancy behoeven? Als dit systeem redundant uitgevoerd zal gaan worden, dan vraag ik me af of we volgend jaar niet dezelfde soort situatie gaan meemaken. Dan gaat het mis op B en dan denken we: ja maar dat had makkelijk opgelost kunnen worden.

redudantie lost dit soort problemen niet op, bij een redudant systeem word er immers een synchronisatie uitgevoerd zodanig dat het redudant systeem onmiddelijk kan overnemen.
In dit geval zou de corrupte db meegekopierd zijn en dan heeft het redudant systeem exact hetzelfde probleem.
Je zou al twee apparte systemen nodig hebben die exact hetzelfde doen zonder dat ze verbonden zijn met elkaar of op dezelfde locatie staan.Maar wel gefeed worden met dezelfde informatie.

Als beide systemen identiek zijn is de kans natuurlijk ook redelijk aanwezig dat beide systemen een corrupte dataset opleveren.

De vraag is dan ook wat corrupte data juist is, is het door de input dat het corrupt raakte, of door de verwerking (iemand die misschien een update van de tabellen deed, of andere db maintenance)

De kans is groot dat het een human error is. Iets dat gedaan werd waardoor de data corrupt werd.

En laatst is er ook cosmishe neutronen die bits omdraaien als ze zeer toevallig door een SSD vliegen (is al een paar keer bewezen geweest)
Voor zo een systemen hoop ik dat ze toch in een Faraday kooi zitten

Een kooi van Faraday helpt tegen elektrische velden.
Dat doet dan erg weinig tegen deeltjes zoals een neutron.

Dat hangt af van welk materiaal je gebruikt, en Faraday cage van koper of lood zou het een goede bescherming moeten geven tegen neutronen

Dat is geen kooi van faraday, maar gewoon een afscherming met een absorberend materiaal.

De beschermende laag rondom een kerncentrale is ook geen kooi van faraday.

En dan nog moet je bekijken wat je gaat doen als blijkt dat Systeem A een andere output levert als Systeem B. Welke van de 2 heeft gelijk?

Ik kan je vertellen dat je voor de geleden kosten/schade die ze nu hebben gemaakt voor decennia lang elke relevante database 2 of 3x redundant met naadloze balancering en fail-over kunt uitvoeren en enkele systeembeheerders 24/7 on-call kunt betalen.. en waarschijnlijk nog geld over hebt voor een absurde bonus voor je CTO.

Ik kan je ook vertellen dat als je dat allemaal doet er nog steeds situaties als deze voor kunnen komen...

Er staat dat het om een corrupt databasebestand ging.

Nee dat staat er niet, dat was het waarschijnlijk!

ik heb wat dingen op Schiphol gedaan, en voor de KLU, en die hebben hele belangrijke systemen meervoudige redundant staan , dus op meerdere plekken server parken, en meerdere connecties dus als er een kabel kapot is of bliksem inslag hebben ze wel iets, dus als er wat kapot gaat is er een fall over , en nog wat kaarten achter de hand, het kunnen vliegen is te belangrijk .

het vlieg verkeer stil liggen is een uiterst nood plan .

maar je heb gelijk er is te weinig informatie voorhanden , misschien dat er nog wat naar buiten komt.

ik denk dat redudant ook niet zou helpen in dit geval, aangezien een fout in een DB gewoon mee gerepliceerd zou worden naar de redudante systemen
Je hebt al twee onafhankelijke systemen nodig om dit niet voor te hebben, ik vermoed dat wel niemand dat gaat willen betalen.

ik denk dat redudant ook niet zou helpen in dit geval, aangezien een fout in een DB gewoon mee gerepliceerd zou worden naar de redudante systemen.

Je controleert toch eerst de integriteit van de data om zeker te weten dat je geen onzin repliceert?

Dan zou je in een situatie komen waarin er data in de DB staat die wel (technisch) valide is, maar niet de juiste informatie zou bevatten. De enige manier waardoor dat veroorzaakt kan worden is door menselijke fouten omdat iemand wat verkeerds heeft ingevoerd.

Integriteit op databanken controleren terwijl alles live is ? Zou dat de read & write niet enkel beïnvloeden?

En verkeerde data hoeft niet enkel van een gebruiker te komen, er kan iets mislopen tijdens het sturen of maken van de insert/update statement

Bij NS niet daar kan alles gewoon plat nieuws: NS-storing legt alle treinverkeer van vervoerder plat - update 3

Daar hadden ze hetzelfde probleem als hier: data is corrupt geraakt en niet bruikbaar meer, dus kon het systeem niet meer vertrouwd worden.

Ik heb ook gehoord dat een vliegmaatschappij een tijdje zonder redundancy heeft gedaan (kostenbesparing) en daar op een harde, dure manier achterkwam dat die toch wel nodig is.

"Niet vliegen" is ook een fail-safe keuze. Tuurlijk kost het bakken met geld om vliegtuigen aan de grond te houden, maar dat is nog altijd veiliger dan een vliegtuig weg sturen wat een NOTAM gemist heeft, en daardoor ineens op een hijskraan knalt die er een week geleden nog niet stond.

Veiligheid heeft in de luchtvaart echt de hoogste prioriteit, daarna pas komt de continuïteit van dienstverlening.

De FAA gaat door met een onderzoek om de oorzaak van de storing in Notice to Air Missions te bepalen

geduld is een mooie zaak (en lezen een goede skill)

Dit soort zaken komt door centraal te opereren. Beter als iets betrouwbaar moet zijn de-centraal opzetten. Kijk naar uptime van bijvoorbeeld Bitcoin.

Hoe zou jij het implementeren?

Dus voor zo'n kritisch systeem heb je geen redundantie, mirroring en/of snapshots ingericht? Je zou toch verwachten dat je binnen een minuut kunt overschakelen op de fail-over? Of op zijn minst een verse back-up teug kan zetten.

Klinkt beetje als houwtje-touwtje oplossing die je bij een hippe start-up zou verwachten. Niet bij een organisatie waar honderden vluchten en miljoenen dollars per dag geregistreerd worden.

Een snapshot zou kunnen helpen. Maar mirroring zou waarschijnlijk beiden corrupten.

Naar een snapshot terug zou kunnen helpen. Maar je wilt eerst zeker weten wat er mis is voordat je een aantal minuten tot uren aan meest recente data over boord gooit.

Als mirroring voor dubbele corruptie zou zorgen, heeft mirroring überhaupt geen bestaansrecht. Mits juist uitgevoerd in combinatie met hashes voor integriteitscontroles, moet mirroring er juist voor zorgen dat dit soort problemen automatisch opgelost worden.

Als mirroring voor dubbele corruptie zou zorgen, heeft mirroring überhaupt geen bestaansrecht.

Mirroring heeft nut voor redundantie. Valt de één uit, kan de ander het overpakken. Verder kan data corruptie voorkomen worden door mirrors met een oneven aan te maken. Het antwoord gegeven door de meeste mirrors wint.

Mirroring heeft nut voor redundantie. Valt de één uit, kan de ander het overpakken. Verder kan data corruptie voorkomen worden door mirrors met een oneven aan te maken. Het antwoord gegeven door de meeste mirrors wint.

Het hangt een beetje af van het soort corruptie. Met checksums kun je prima detecteren welke van de twee wel of niet goed is. Er vanuit gaand dat de oorzaak buiten de programmatuur ligt: bijvoorbeeld omdat een sector op de harddisk slecht is geworden. Als de programmatuur zelf voor corruptie gezorgd heeft (een datumveld bevat bijvoorbeeld ineens datums in de toekomst, terwijl dat in die toepassing niet mogelijk zou moeten zijn), dan zijn die foute datums waarschijnlijk ook netjes naar je mirrors gekopieerd, met correcte checksums...

Als mirroring voor dubbele corruptie zou zorgen, heeft mirroring überhaupt geen bestaansrecht. Mits juist uitgevoerd in combinatie met hashes voor integriteitscontroles, moet mirroring er juist voor zorgen dat dit soort problemen automatisch opgelost worden.

Welk soort problemen ? Weet jij dan precies wat het probleem was, waardoor het veroorzaakt was ? Als de software door een bug een aantal wijzigingen incorrect uitvoert, dan wordt dat gewoon gemirrord, en zijn beide/alle kopieën dus corrupt. En dat kan dan niet automatisch opgelost worden, totdat uitgezocht is was er mis ging en waarom.

Nee. Bij Microsoft SQL Server kan mirroring automatisch een corrupte pagina herstellen.

Nee. Bij Microsoft SQL Server kan mirroring automatisch een corrupte pagina herstellen.

Ik heb geen verstand van SQL server, maar ik weet zeker dat die niet alle soorten corruptie kan herstellen. Ja, als er een sector onleesbaar wordt op de harddisk, of als er een bitje omflipt in het geheugen, dan waarschijnlijk (?) wél, maar als bijvoorbeeld een tekstveld door een bug in de software (of zo) onzinnige data bevat, of een verwijzing van een tabel naar een andere klopt ineens niet, dan is dat ook corrupte data, maar dat kan SQL server beslist niet herstellen. En dan moet je dus heel voorzichtig zijn met wat je doet, want er kan nog meer mis zijn, en/of de problemen kunnen nog erger worden.

Uit wat ik heb gelezen over het voorval is de server instabiel geworden in de dag voordat het platging. Dit klinkt niet als een data manipulation bug maar een data corruption probleem. Dus een disk sector die gaandeweg slechter werd, en door de controller opnieuw gelezen werd tot het niet meer ging. En in zo'n situatie, waar SQL server een suspect page vindt, kan het deze pagina opvragen uit een mirror. Zie hier voor meer uitleg: https://learn.microsoft.c...ing?view=sql-server-ver16

Ik weet wel hoe dat werkt, en ook dat een mirror bad-sector problemen kan helpen voorkomen. Als de server instabiel werd, dan zou inderdaad kunnen zijn dat een sector slecht is geworden. Maar er zijn ook andere manieren waarop een server instabiel kan worden. Bijvoorbeeld als een geheugen (RAM) chip niet meer 100% lekker functioneert, maar er zijn nog heel veel meer mogelijkheden.

Echter: zoals ik zeg in mijn reactie, data corruption is niet noodzakelijkerwijs een bad sector. Er zijn heel veel manieren waarop data corrupt kan raken, en voor sommige van die manieren heeft het zin om een gemirrorde SQL server te gebruiken. Of RAID 1 / 5 / 6 harddisks of zo. Voor andere manieren waarop data corrupt kan raken helpt dat soort redundantie niet. Maar goed, dat zeg ik ook al in mijn reactie, dus blijkbaar begrijpen we elkaar niet ?

Of dacht je dat de term 'corruptie' gereserveerd was voor sectoren op een harddisk ? Je zegt: 'dus een disk sector'...

Als ik even aanhaak op het bericht van de FAA: die zeggen 'damaged database file'. Wellicht is dat SQL Server, maar het kan ook iets anders zijn. Afhankelijk van welke database het was, kan dat ook komen doordat een disk volgeraakt was, doordat een systeembeheerder een fout maakte, door een bug in de database software, of een bug in een andere programma, door een defecte RAM-chip, en nog veel meer. En dan ga ik er vanuit dat de database file zelf corrupt is geworden. Het kan dus ook zijn dat de database perfect was, maar dat alleen de gegevens erin niet klopten. Afhankelijk van de manier waarop ze niet kloppen, kan dat als 'data-corruptie' omschreven worden.

Edit: Volgens dit artikel, was het probleem veroorzaakt door twee 'contractors', die de procedures niet gevolgd hadden, waardoor de database dus beschadigd is geraakt. Niets kapotte sector, of zo dus, gewoon operator error.

[Reactie gewijzigd door RJG-223 op 17 januari 2023 23:55]

Het probleem zal vooral het opsporen van het probleem geweesd zijn.

Data corruptie is niet eenvoudig vast te stellen.

Natuurlijk is er wel redundantie bij zo'n systeem. Bij corrupte data is zeer moeilijk de oorzaak te vinden, eerst komt er een melding binnen van iemand dat hij een foutmelding krijgt bij het ophalen van de data. Andere gebruikers lijken wel normaal te kunnen werken, dus ga je eerst kijken bij die ene gebruiker. Langzaam komen er meer meldingen van gebruikers met foutmeldingen, maar niet bij iedereen. Dan ga je kijken of alles op de server nog goed draait en of je zelf de fout kunt reproduceren. De monitoring tools op de server zullen misschien aangeven dat alles goed draait, is immers alleen maar data corrupt. Omdat er toch veel meldingen zijn en veel gebruikers niet bij de data kunnen wordt voor de zekerheid het vliegverkeer maar stil gelegd. Uiteindelijk komt men tot de conclusie dat het door een corrupt bestand komt, men fixed dit of schakelt over naar een backup systeem, doet eerst nog wat tests en vluchtverkeer dan wordt weer langzaam opgestart. Bij een stroomuitval weet je het probleem en kun je direct overschakelen naar een backup systeem, bij corrupte data waarbij de monitoring tools aangeven dat alles correct draait kan het enkele uren duren voordat je de oorzaak weet en actie kunt ondernemen.

Slechte SQL query misschien?

Dat slechte databestand kwam nog wel eens voor by MySQL... dan duurt het een eeuw voordat dit bestand gefixed is?
Blijft nog wel een vaag verhaal... Maaar, als het goed is zouden we het uiteindelijk wel moeten horen. ben Benieuwd!

[Reactie gewijzigd door rvt1 op 12 januari 2023 21:18]

Ook bij MySQL en MariaDB kan je de database redundend uitvoeren. Herstellen is dan echt niet zo tijdrovend. Als het moet kan het systeem zelfs gewoon online blijven.

Het fixen zelf duurt misschien niet zo lang, maar het vinden van het probleem kan wel lang duren als je geen goede monitoring opgezet hebt die zo gedetailleerde metrics in het oog zou houden.(data validity)

Of slechte input validatie: "This is to inform that runway 36L at KLAX will be closed 10Z00; DROP DATABASE;"

hopelijk komt er snel een corruptieonderzoek in de VS
het gaat em nu zelfs ook al in de bestanden zitten
kwalijke zaak

Ik vond hem grappig

flight.exe crashed

Misschien windows 3.11 probleem.

https://nos.nl/artikel/20...oring-op-vliegveld-parijs