×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste nieuwssite, beste prijsvergelijker en beste community! Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers en maak kans op mooie prijzen!

Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Systeemstoring leidde wereldwijd tot incheckproblemen vliegmaatschappijen

Door , 58 reacties, submitter: gatlarf

Een storing bij een systeem dat door veel vliegmaatschappijen wordt gebruikt voor het boeken van tickets en inchecken, leidde wereldwijd tot vertragingen van vluchten. Het probleem betrof netwerkproblemen bij de Amadeus Altéa Suite.

De storing vond donderdagochtend plaats. Volgens Amadeus was er sprake van netwerkproblemen die tot gevolg hadden dat sommige Amadeus Altéa-diensten niet meer werkten. Het gaat hier om passenger service systems, die door vliegmaatschappijen worden gebruikt voor het reserveren van tickets en die verbonden zijn met de systemen voor inchecken. Het bedrijf heeft 124 vliegmaatschappijen als klant en claimt dat zijn systemen gebruikt worden voor 80 procent van de reserveringen van vliegtickets.

Air France-KLM is een van de klanten van het bedrijf en had daarom last van de storing. Daarnaast nemen volgens de BBC British Airways, Qantas en Lufthansa de Amadeus Altéa-dienst af. Onder andere op Schiphol, maar ook bij vliegvelden van Parijs, Londen en Melbourne had de storing tot gevolg dat vluchten vertraging opliepen en er tijdelijk geen omboekingen gedaan konden worden.

Volgens Amadeus is de storing verholpen en functioneren de systemen weer. In de loop van donderdag zouden de incheckproblemen voorbij moeten zijn, al kan er sprake zijn van uitloop van de vertragingen. In 2013 vond een vergelijkbare storing plaats bij een leverancier van reserveringsystemen. Ook toen leidde dat wereldwijd tot problemen.

Door Olaf van Miltenburg

Nieuwscoördinator

28-09-2017 • 15:53

58 Linkedin Google+

Submitter: gatlarf

Reacties (58)

Wijzig sortering
Is niet zo simpel.
Amadeus is een van weinige gds systemen en wereldwijd zijn alle reiskantoren, gdsen, airlines, airports etc.. alles met alkaar verbonden.dit is geen systeem die je zomaar even kan uitzetten of updaten of eender wat.
Een online standby system is vrijwel onmogelijk bij dit soort complexe systemen die data in real time verwerken. Facebook heeft geen Facebook2 klaar staan. net als Twitter en YouTube. Dat is niet om financiële reden maar omdat het vrijwel niet kan. Soms is het veel beter om geheel down te zijn dan delen te laten werken die niet voldoende verbonden zijn.

Dit was vrijwel zeker een software issue, de hardware die ze hebben is zeer bestendig tegen storingen.
facebook, twitter en youtube hebben wel risico spreiding ingebouwd. Maar amadeus heeft alles gecentreerd rondom 1 datacenter/database in duitseland. Dat dat datacenter niet realtime gerepliceerd wordt naar een tweede locatie is kennelijk een keuze geweest.
Wie zegt dat het probleem in het centrum zelf zat? Daarbij kan redundancy ook geregeld worden in hetzelfde centrum, kan ook ergens anders en dat zou meer beschermen tegen natuur rampen of andere lokale problemen wat hier niet aan de hand is geweest.

We zullen het nooit weten wat er precies is gebeurd, maar een foutje is menselijk. Kan altijd gebeuren, net zoals Facebook een keer down is geweest (en hadden hun geen risico spreiding?)
Youtube heeft wel degelijk haar diensten opgesplitst over meerdere geografisch gescheiden locaties. Derhalve was de bgp fout van turkije alleen merkbaar in de omgeving van turkije (nederland dus ook) en niet in amerika.

Het is niet zo dat youtube alleen instanties draait in de VS. Ze hebben ook gewoon replicaties in de EU. Zodoende kan het zijn dat je vanuit hier wel kunt uploaden en vanuit swahililand X of eender portugees sprekend zuid amerikaans land niet.
Ik heb het idee dat Amadeus heel oud en redelijk gammel is opgezet. Zo is het mogelijk om een vlucht te boeken waarvan de code al eerder gebruikt is. Dat is super frustrerend als je een systeem bouwt wat daar mee te maken heeft want meerdere mensen hebben dus het zelfde ID binnen Amadeus alleen is de vlucht en datum anders. 6 letters dus 191 miljoen combinaties, dat is niet veel vergeleken met het aantal dagelijks vluchtbewegingen.

Het probleem is dat je niks meer kunt wijzigen aan Amadeus omdat het een systeem is waar dus letterlijk miljoenen andere systemen aan hangen. Alle bugs daar hebben mensen ook al weer omheen geprogrammeerd die juist die bugs verwachten. Geen idee waar het in geschreven is, zou me niks verbazen als het oorspronkelijke deel nog in COBOL draait
Dat klopt niet helemaal... (heb 8 jaar voor Amadeus gewerkt :))

Amadeus heeft de PNR en de bijbehorende record locator van 6 cijfers/letters niet zelf bedacht. Het is ook alfanumeriek, dus theoretisch iets van 2 miljard combinaties (alhoewel er geloof ik sommige getallen/letters niet in mogen). Ook hangen niet alle systemen noodzakelijk samen aan die ene identifier. Er zijn bijv. ook e-ticket en frequent flyer nummers.

De meeste legacy systemen (zoals TPF - https://en.wikipedia.org/...ction_Processing_Facility) worden gedecommissioneerd. Veel componenten zijn een stuk moderner en worden in C++ geprogrammeerd.

En er zijn uiteraard backup systemen, maar de complexiteit van de luchtvaart systemen is enorm. Amadeus heeft een grote infrastructuur waar talloze software componenten en databases draaien. Zoals falconhunter zegt, je kan niet zomaar even overschakelen naar een backup met de druk op een knop :)

** edit ** CyBeR was me voor ;)

[Reactie gewijzigd door _Tygernoot op 28 september 2017 17:14]

Wat ik er van gezien heb een paar jaar geleden is dat de dames nog op een soort van terminal achtige interface inlogden op Amadeus, iets wat ik alleen bij grote bedrijven met mainframe legacy systemen heb gezien. Het was wel krachtig maar absoluut niet makkelijk om te gebruiken.
Er bestaat inderdaad terminal-achtige access voor reservatie systemen. Een PNR is uiteindelijk een reeks van lijnen tekst.
Ik weet dat sommige airlines wel een GUI-achtige wrapper hebben gemaakt om een PNR te maken of te wijzigen, maar vaak gaat het toch makkelijker/sneller via text input. Denk aan alle helpdesks die boekingen moeten doen/wijzigen.
Dat betekent niet noodzakelijk dat de achterliggende systemen "oud en gammel" zijn opgezet? :)
Als je bijv. een vlucht boekt via de websites dan wordt de informatie via (modernere) web services gestuurd, maar het reservatie systeem is hetzelfde.
Je hebt een steilere leercurve maar dat is het ook zowat. Zodra je het in de vingers hebt is er niks sneller dan alles via je toetsenbord te doen; onderschat niet hoeveel tijd je verliest door eenvoudigweg je hand op je muis te leggen en die op het scherm te verplaatsen, en van je hand terug op je toetsenbord om verder te tikken.
alle gds en zijn oud.
Ze maken nog steeds allemaal gebruik van terminal schermen met beperkt aantal characters in een response etc...
Maar alle airlines zitten ook nog met heel oude systemen.

Uiteraard er wordt er wel gewerkt aan nieuwere systemen.
Voorlopig bestaat deze nog uit layers rond het oude deel. Oude deel moet nog helaas nog even meegaan vooralleer alles omgezet kan worden naar nieuwere structuren hardwarematig maar ook softwarematig.
Niets mis met een terminal of een TUI. Iemand die vlot met een toetsenbord kan werken gaat er een stuk sneller door dan wanneer je met een moderne GUI werkt.
Als die modernere GUI gebouwd is met goede shortcuts dan kan het wel degelijk van toegevoegde waarde zijn.

Waarom denk je dat we niet meer alles prgorammeren met VI of notepad? Juist. Omdat het met fatsoenlijke IDE’s een stuk sneller gaat.
> Zo is het mogelijk om een vlucht te boeken waarvan de code al eerder gebruikt is.

Niet alleen is dat mogelijk, dat is standaard. PNR record locators worden na een tijdje hergebruikt, en niet alle mogelijkheden zijn mogelijk. Als je een unieke referentie wilt hebben moet je niet de PNR gebruiken maar het e-ticketnummer.
Oh ja geen probleem hoor. Dankzij blockchain technology kan dat nu heel makkelijk. Iedereen die mee doet heeft automatisch alle gegevens en als er ergens een node omvalt is dat geen enkel probleem
Gat in de markt waar wacht je op
I know. Zijn we dan ook mee bezig. Naast die uptime gatantie zijn er namelijk nog meer mooie voordelen.
Je zou eens moeten weten wat er allemaal je kant op komt op Blockchain-gebied binnen de komende jaren ;)
Dat weet ik het was meer een reactie op supersnathan94 dat ie het wel even snel kan oplossen.
Toch eigenlijk best wel slecht dat er geen back-up methode beschikbaar is om de diensten alsnog door te laten werken.
Kwestie van afwegen. Let er op dat bedrijven bedoeld zijn om geld te verdienen. Dit betekend dat dit in vrijwel alle besluiten wordt meegenomen. Het risico afwegen kan per saldo meer opleveren in tegenstelling tot naar technische perfectie streven. Af en toe een storing is acceptabel, zeker als het slechts een ochtend is.
In deze branche is af en toe een storing totaal niet acceptabel. wat denk je dat het vandaag gekost heeft. Vluchten die vertraagd zijn, mensen die dan weer een aansluiting missen. De luchtvaartmaatschappij moet ze dan omboeken, hotel betalen enz enz enz.
Daarnaast hele vliegplan bij vliegvelden in de war ook dat kost geld. Dat zal iemand moeten betalen.

De totale schade van dit soort storingen loopt in de papieren.

Vraag me bijv wel af hoe de goedkope maatschappijen dit doen, Eigen systeem of andere anbieder ?

[Reactie gewijzigd door bbob1970 op 28 september 2017 16:23]

In deze branche is af en toe een storing totaal niet acceptabel. wat denk je dat het vandaag gekost heeft.
Waarschijnlijk heeft Amadeus ingeschat dat een dag als vandaag minder kost dan het streven naar, zeg, 99.99% uptime.
Rule of thumb is dat elke extra 9 een verdubbeling is van de benodigde investering.

Stel je neemt als baseline dat een systeem dat 99% uptime heeft je 1M¤ kost, dan kost:
99,9% uptime: 2M¤ (statistisch 8 uur down per jaar)
99.99% uptime: 4M¤ (statistisch 45 minuten down per jaar)
99.999% uptime: 8M¤ (statistisch 5 minuten down per jaar)
99.9999% uptime: 16M¤ (statistisch 30 sec down per jaar)
etc.
Die laatste is stiekem 31,6. Dat is toch een behoorlijk verschil op 30 seconden. Neemt niet weg dat het ontzettend weinig is.

Als je wekelijks een update zou draaien in de vorm van een switch van loadbalancer naar andere serverinstantie die de nieuwe versie zou hebben dan mag dit maximaal 0,6 seconden voor oponthoud mogen zorgen. Agile technieken die niet met CI en CD werken, maar oplevering per 2wekelijkse sprint hebben per oplevering dan dus maar 1,2 seconden om alles te switchen. Dat is ontzettend weinig tijd voor een mens om uberhaupt ergens op te reageren. Dergelijke updates moeten dan ook volledig autonoom en dubbel failsafe worden uitgeroldmet een loadbalancer erbij die rekening houd met eventuele requests die nog in behandeling zijn bij de oude instantie.

Een six nines SLA is dan ook bijna onhoudbaar zonder een heeeeel groot budget.
zo zwart wit is het niet, het ligt er maar net aan wat je doet met geplande downtime voor onderhoud in de berekening van je uptime en hoe je dat beschrijft in de SLA.
Ook dan kan gepland onderhoud nooit heel lang duren bij dit soort systemen. Vliegen gaat het hele jaar door dus zomaar een dag offline gaan zit er niet bij. Onderhoud heeft dus ook maar een klein window en dan is uitlopen direct een probleem.
Vorige storing was in 2013 als het goed begrijp, dus 4 jaar terug. Bij 0,01% downtime per 365 dagen * 24 uur = 0,876 uur * 4 jaar = 3,5 uur = ongeveer een ochtend, zoals nu aan de hand was.

Dus pakweg 99,99% uptime, daar zitten ze nu al aan ;) Zou best kunnen dat dit financieel optimaal is qua kosten. Die laatste 0,01% is aanzienlijk duurder dan de kosten van zo'n storing af en toe, om te verzekeren of een compleet backup-systeem voor aan te schaffen, dus die neemt men dit risico / deze kosten voor lief.
En die daar net voor in 2012.. al was daar Linux de boosdoener.
https://www.theregister.c..._second_crashes_airlines/
Nog iets waarschijnlijker is dat ze wel streven naar five nines, maar dat er ergens een fout gemaakt is. Of dat beide netwerkleveranciers tegelijk een flinke DDOS voor de kiezen kregen. Of ...
Hoge uptime is makkelijk gezegd, moeilijker te bereiken, en verduiveld moeilijk vol te houden. Je hebt nou eenmaal niet alles zelf in de hand.
Dit loopt inderdaad in de papieren, dit is één dag. Er is vast een kosten/baten analyse gemaakt, indien dit juist gemaakt is wordt dit verlies gewoon genomen en ben je nog goedkoper uit dan wanneer je alles had dicht getimmerd.
Het kost ze waarschijnlijk minder dan het back-up systeem. Anders hadden ze een back-up systeem.
Vraag me bijv wel af hoe de goedkope maatschappijen dit doen, Eigen systeem of andere anbieder ?
De Ryanairs en Transavias in de branche hechtten (en nog steeds) veel waarde aan hun eigenlijk online kanaal en waren/zijn dus niet allemaal aangesloten op een GDS (wat Amadeus is). Je ziet echter dat zelfs Ryanair teruggaat naar Amadeus vanwege het distributie netwerk dat ze bieden. Waarschijnlijk tegen sterk concurrerende prijzen ten opzichte van de traditionele airlines: http://travel360benelux.c...-consument-als-beslisser/
'Slechts' een ochtend? Enig idee hoeveel vluchten door 'slechts' een ochtend geraakt worden? Hoeveel honderdduizenden passagiers? :?

Daarnaast worden vliegtuigen kop-staart ingedeeld. Een vertraging in de erste wave, heeft meteen gevolgen voor de rest van de dag en soms de dagen erna.... (groot) onderhoud loopt daardoor in de knoop. Een stilstaand vliegtuig kost kapitalen.

Dus.... Slechts een ochtend is onacceptabel.
Daarnaast worden vliegtuigen kop-staart ingedeeld. Een vertraging in de erste wave, heeft meteen gevolgen voor de rest van de dag en soms de dagen erna.... (groot) onderhoud loopt daardoor in de knoop. Een stilstaand vliegtuig kost kapitalen.
Vliegtuigen worden in blokken ingedeeld. Een vertraging in de eerste wave zorgt er voor dat een blok omgeboekt wordt. Niets meer en niets minder. Vluchten worden nu simpelweg gevlogen met andere vliegtuigen dan dat ze origineel gepland waren. Ja, dat heeft gevolgen voor dagen, weken, maanden daarna. Maar niet in financiele zin, alleen in plenaire zin. De gevolgen zijn dus beperkt tot de IDs in een tabel, niet meer en niet minder.
Naaaaaah.....

Ik weet niet waar jij je kennis vandaan haalt, of bij welke maatschappij.... Maar het is toch iets gecompliceerder dan jij stelt. Er zit geen tot weinig marge in een vliegtuig planning. Dus een verstoring in de ochtend geeft wel degelijk grote problemen tijdens de ochtend. Zeker als het met een groot deel van de vloot en meerdere uten betreft. Alles moet zo efficiënt en goedkoop mogelijk uitgevoerd worden.

Hoe is dat weet? Makkelijk, het is mijn werk.
Begrijp me niet verkeerd. Het is uiterst vervelend voor alle betrokkenen, zeker voor de passagiers, maar ik heb het over het risico. Zeker in deze branche worden risico’s berekend. Onder aan de streep blijkt af en toe een storing dus acceptabel zakelijk gezien.
Waarschijnlijk zijn die alarmbellen nu geactiveerd!
Dat was toen toch bij sabre corp, net zo als in 2015. Anyhoe, omdat er steeds gevochten wordt voor de laagste prijs is er geen geld om dat op te lossen.
Ook weer zo. Zullen ze waarschijnlijk pas over nadenken als het vaker gebeurt. :/
Heb jij een back-up auto voor als je auto kapot is? En een back-up wasmachine, back-up koelkast, etc? Ik gok van niet. Je weegt het risico en de gevolgen af tegen de kosten.
Op vraag 1 ja, daarnaast is het appels en peren vergelijken wat je nu doet. Of het nu impact op alleen mij of duizenden mensen heeft is toch een groot verschil...
Nope, geen enkel verschil. In beide gevallen maak je een afweging van kans maal gevolg.

De gemiddelde auto heeft geen 99.99% uptime, noch heeft hij deze nodig. Dit systeem heeft wel een 99.99% uptime en dat heeft het ook nodig. Dat betekend alsnog dat dingen wel eens fout gaan.

Het is onmogelijk te zorgen dat het nooit fout gaat. Hier is de afweging gemaakt om 99.99% uptime te regelen. Had men een hogere uptime gewild dan had men waarschijnlijk meer moeten investeren dan het oplevert. En er is dus voor gekozen om dat niet te doen.

Op dezelfde manier als dat jij het risico dat je wasmachine kapot gaat minder erg vindt dan het aanschaffen van een tweede wasmachine "just in case".
Sterker nog, dit systeem heeft five nines, 3,5 uur downtime in 4 jaar tijd, 99,999% uptime.
De kosten om dit te verhogen naar 99,9999% is ongeveer het dubbele van de huidige kosten, en ik ben geen expert maar ik kan je wel vertellen dat het in het geval van Amadeus niet bepaald rendabel zou zijn om zoveel extra uit te geven.

3,5 uur storing in deze sector op zo'n grote schaal is best ernstig, maar blijkbaar toch vele malen goedkoper dan streven naar een nóg hogere uptime. De gevolgen voor de planning kan weken, misschien wel maanden blijven doortikken. Storing slaat vroeg of laat toch toe. 100% uptime bestaat niet. Zou mooi zijn, maar alles kan kapot.

Je analogie is in principe redelijk correct. De schaal is alleen anders.
Het is praktisch onbetaalbaar om zo'n extreem complex, wereldwijd systeem te repliceren om een exacte 1:1 backup te hebben die in real-time ingezet kan worden voor 3,5 uurtjes in de 4 jaar.

[Reactie gewijzigd door Zexion op 28 september 2017 17:32]

6 nines is dan ook niet meer reeel om wat te kunnen. Als een systeem als dit omvalt is dat doordat de betreffende personen waarschijnlijk even geen idee hebben wat er gebeurt. Anders was het systeem niet omgevallen lijkt me. Het is dan niet reel om te zeggen fiks dit maar binnen 31,6 seconden.

Overigens is 3,5 uur in 4 jaar echt maar 99,99%. 5 nines is 5 minuten en 35,7 seconden per jaar. Ook al geen makelijke opgave.
Ben ik toch benieuwd: Heb je een tweede, eigen auto, die puur en alleen aangeschaft is / altijd klaar staat voor het geval je dagelijkse auto kapot gaat? ;)
Op vraag 1 ja, dat geloof ik niet :D. En back-up auto staat permanent stil hè. Daar rijd je nooit in, tenzij je primaire auto kapot is. De boodschappenauto van je vrouw is geen back-up auto. Dat is gewoon je tweede auto.
Een persoonlijke situatie vergelijken met een bedrijf die een dienst levert - waar heel wat geld mee gemoeid is. Hou toch op, dergelijke vergelijkingen zie je vaker hier voorbij komen...maar zijn echt totaal zinloos.

Vertraagde vluchten van meerdere maatschappijen; vertraagt ook de connection-flights of terugvlucht; zijn al snel duizenden passagiers die er last van hebben; dus ook honderden zakenlui met strakke planningen; kost snel tonnen of miljoenen.

Een kapotte wasmachine of koelkast..lastig maar dan koop je voor een paar-100 euro een nieuwe...kan binnen een uur thuis staan. Auto kapot? Taxi indien dringend, anders fiets en OV?
Heb jij een back-up auto voor als je auto kapot is?
Fiets, bus.
En een back-up wasmachine
teiltje, emmer
, back-up koelkast,
vandaag eten wat in de koelkast stond, rest weggooien :(
etc? Ik gok van niet.
Jawel dus
Dat is geen back-up, dat is een alternatief.
Ik denk dat je wellicht onderschat wat voor soort systeem hier de fout in ding.
Ze zullen wel enorm veel backups hebben, maar soms is een single point of failure niet uit te sluiten. Daarnaast kan je ook in een situatie komen waar je primaire systeem faalt en je backup even later ook of waar je primaire systeem faalt en door een fout je backup het niet overneemt. Het is vandaag allemaal zo complex en echt niet eenvoudig om een complex systeem van high availability te voorzien.
Ik hoorde het net op onze afdeling. Wel frappant is dat hun facturatiesysteem wel werkt...
Facturatiesystemen werken altijd :P
Maar daar komt een dagje later als het goed is ook niet zo nauw en veel acties zijn al van te voren ingepland/ingeboekt.
Lag bij ons ook plat hoor.


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*