Falla informatica per la United Airlines: migliaia di passeggeri bloccati

  • Autore Discussione Autore Discussione A381
  • Data d'inizio Data d'inizio

A381

Principiante
Utente Registrato
31 Luglio 2007
659
1
66
Lombardia
Falla informatica mette in ginocchio la United Airlines: migliaia di passeggeri bloccati
Dopo sei ore i computer sono stati ripristinati ma i disagi sono stati notevoli in diversi aeroporti


Tutti i voli della compagnia aerea americana United Airlines sono stati fermati venerdì sera a causa di un blocco informatico che impediva di imbarcare passeggeri. Lo ha reso noto un portavoce della compagnia. "I nostri tecnici sono al lavoro per risolvere il problema in tempi rapidi" ha aggiunto il portavoce. Dopo circa sei ore i computer hanno lentamente ricominciato a funzionare ma i disagi per i clienti sono stati notevoli.
I computer di United Airlines hanno ripreso a funzionare dopo un blocco durato circa sei ore. Migliaia di passeggeri sono rimasti a terra a seguito di un tilt informatico che ha fermato tutte le operazioni di prenotazione e negli aeroporti. Il portavoce di United Airlines, Charles Hobart, ha riferito che i problemi ai computer sono iniziati alle 19.16 ora locale, ma non ha fornito dettagli sulle cause del problema. Una lunga fila di passeggeri in attesa si è formata ai check-in dell'aeroporto internazionale O'Hare di Chicago, uno degli hub principali di United Airlines.

Nell'ottobre scorso, la United si è fusa con la Continental Airlines creando la maggiore compagnia aerea mondiale, con un volume d'affari intorno 29 miliardi di dollari e più di 370 destinazioni; le due compagnie mantengono però separata la struttura informatica, per cui i voli della Continental non sono stati interessati dall'avaria.

http://www.tgcom.mediaset.it/mondo/...irlines-migliaia-di-passeggeri-bloccati.shtml
 
Se il sistema informatico di imbarco non funzionava potevano passare alla procedura con carta di imbarco manuali, in casi analoghi altre compagnie hanno adottato questo sistema. Ma sono americani, quindi spirito di improvvisazione zero e se si ferma un computer sono uomini morti.

Quoto..... Era ed è ancora famosissima la vicenda dove ad una signora hanno pignorato beni perchè risultava da un computer che doveva la cifra di $0 e 0 cent..... Per terminare la vicenda ha dovuto emettere un'assegno di $0 e 0 cent.....

Quando l'informatica rende gli uomini inutili....... :)
 
Se il sistema informatico di imbarco non funzionava potevano passare alla procedura con carta di imbarco manuali, in casi analoghi altre compagnie hanno adottato questo sistema. Ma sono americani, quindi spirito di improvvisazione zero e se si ferma un computer sono uomini morti.

In certe situazioni si può operare manualmente, ma non in casi come questi dove tutto si blocca improvvisamente (sia i sistemi operativi che quelli di prenotazione). E per di più su tutta la rete e non solo su determinati scali. Continuare manualmente le operazioni per più di 15.000 voli mi sembra fantascienza onestamente.
 
Questo perchè usano Windows e non Apple

hemm.. credo che non cambi più di tanto in questi casi quale sistema operativo utilizza la compagnia aerea (che a dire il vero la frase sarebbe dovuta essere "Questo perchè usano Windows e non Mac). in quanto il problema credo sia stato scatenato dal programma che utilizza la compagnia aerea e non il sistema operativo del singolo computer... questa è la mia supposizione eh ;) :)
 
hemm.. credo che non cambi più di tanto in questi casi quale sistema operativo utilizza la compagnia aerea (che a dire il vero la frase sarebbe dovuta essere "Questo perchè usano Windows e non Mac). in quanto il problema credo sia stato scatenato dal programma che utilizza la compagnia aerea e non il sistema operativo del singolo computer... questa è la mia supposizione eh ;) :)

Si infatti era una battuta

In quali aeroporti hanno i Mac?

Che io sappia ben pochi o forse nessuno. Il motivo è che comunque hanno un costo unitario ben superiore rispetto ad un pc assemblato e per quello che sono tenuti a fare il gioco non vale la candela.
 
Che io sappia ben pochi o forse nessuno. Il motivo è che comunque hanno un costo unitario ben superiore rispetto ad un pc assemblato e per quello che sono tenuti a fare il gioco non vale la candela.

Appunto. Poi immagino che praticamente tutti i sistemi girino solo su Windows
 
Dunque, se si blocca il "cuore" del sistema informatico, costituito generalmente da un potente mainframe ( quei calcolatori grossi come un furgone ), che usa generalmente in questi casi il sistema operativo TPF ( Transaction Processing Facility, di IBM, fatto appositamente per le compagnie aeree ) , si blocca TUTTO: non solo il check-in, ma anche le procedure di bilanciamento aeromobile, indirizzamento bagagli, i piani di volo non arrivano, gli equipaggi non si sa più dove stanno e quale volo devono operare, e un mucchio di altre cose ( impossibilità di emettere tkts, prenotare, eccetera ).

In generale, come scala di gravità, il blocco totale del sistema informatico è considerabile al terzo posto, dopo l'incidente aereo e il dirottamento.

Sei ore di fermo lasciano ipotizzare un guasto fisico del calcolatore o di qualche grosso componente di rete, più che un guasto software, che in genere si risolve rapidamente ricaricando il sw stesso o la sua modifica più recente.

Per ognuno di questi casi c'è la procedura manuale, ma è evidente che tutto rallenta in maniera mostruosa.

Windows viene utilizzato sui pc locali che poi si collegano al sistema centrale. Fino a qualche anno fa, in molti casi i terminali locali avevano un loro sistema operativo "proprietario" che li rendeva compatibili con il mainframe utilizzato, mentre oggi quasi tutti i dati viaggiano via ip.
 
Dunque, se si blocca il "cuore" del sistema informatico, costituito generalmente da un potente mainframe ( quei calcolatori grossi come un furgone ), che usa generalmente in questi casi il sistema operativo TPF ( Transaction Processing Facility, di IBM, fatto appositamente per le compagnie aeree ) , si blocca TUTTO: non solo il check-in, ma anche le procedure di bilanciamento aeromobile, indirizzamento bagagli, i piani di volo non arrivano, gli equipaggi non si sa più dove stanno e quale volo devono operare, e un mucchio di altre cose ( impossibilità di emettere tkts, prenotare, eccetera ).

In generale, come scala di gravità, il blocco totale del sistema informatico è considerabile al terzo posto, dopo l'incidente aereo e il dirottamento.

Sei ore di fermo lasciano ipotizzare un guasto fisico del calcolatore o di qualche grosso componente di rete, più che un guasto software, che in genere si risolve rapidamente ricaricando il sw stesso o la sua modifica più recente.

Per ognuno di questi casi c'è la procedura manuale, ma è evidente che tutto rallenta in maniera mostruosa.

Windows viene utilizzato sui pc locali che poi si collegano al sistema centrale. Fino a qualche anno fa, in molti casi i terminali locali avevano un loro sistema operativo "proprietario" che li rendeva compatibili con il mainframe utilizzato, mentre oggi quasi tutti i dati viaggiano via ip.

A parte le battute di rito, Windows o Mac, quoto in parte. Un guasto non credo perchè sicuramente tutto è basato su sistemi "Fault Tolerant" (dovrebbero assicurare il servizio anche con grossi problemi) per cui un grosso guasto dovrebbe fargli il solletico, anche perchè di solito questi sistemi sono in "Cluster" (due o più macchine che condividono le medesime informazioni) in edifici se non in luoghi differenti con reti differenti. E' piu' probabile invece un problema a livello di software in quanto questo è identico per tutte le macchine condivise.

Ne' e' stato un'esempio recente le Poste Italiane.
 
I sistemi sono "fault tolerant" fino ad un certo punto, in quanto non è possibile prevedere tutto quello che può accadere. I cluster non si usano nei mainframe, ma si utilizzano calcolatori attivi ed in stand/by ( che è un po' la stessa cosa, ma l'attivazione dell'uno o dell'altro non è automatica e prevede una lunga serie di manovre ), ed inoltre dipende da cosa si è guastato: se ad esempio si rompe un tubo dell'aria condizionata e ti allaga il locale dove c'è il calcolatore attivo, ti va a fregare pure i collegamenti con quello in stand/by ( succede, succede...). Una grande criticità è infatti rappresentata dal collegamento fisico tra i vari elementi che garantiscono la fault tolerance: un tempo, con i cavi in rame, la lotta era contro i topi che si mangiavano le guaine e mandavano tutto in corto ! E non sia mai ti si rompe l'impianto di condizionamento son dolori: le macchine si spengono automaticamente oltre una certa temperatura ( a volte dopo i 25 gradi si comincia a tremare...).


La cosa peggiore è il guasto hardware: spesso non ha evidenza fisica, e per capire che un aggeggio è proprio "andato" ci si mette un sacco di tempo perso in tentativi classici di ripristino.

Insomma non è proprio tutto così semplice ed immediato, ma alla fine questi guasti sono piuttosto rari, proprio grazie a tutte le ridondanze previste.
 
Se il sistema informatico di imbarco non funzionava potevano passare alla procedura con carta di imbarco manuali, in casi analoghi altre compagnie hanno adottato questo sistema. Ma sono americani, quindi spirito di improvvisazione zero e se si ferma un computer sono uomini morti.

Cesare, per favore!

1- il sistema bloccato era quello del W&B (basta approfondire 3 minuti cercando la news sul A.Net): considerando l'enorme mole di voli che ha United, e' impossibile gestire il W&B in manuale
2- se anche fosse stato il sistema di imbarco, qualche volo si può gestire in manuale, non l'intero network di quel giorno
3- con gli americani evidentemente non hai mai lavorato, altro che improvvisazione zero
4- meglio se torni a parlare di aperture, chiusure e frequenze. Li nessuno batte la tua conoscenza enciclopedica.
 
I sistemi sono "fault tolerant" fino ad un certo punto, in quanto non è possibile prevedere tutto quello che può accadere. I cluster non si usano nei mainframe, ma si utilizzano calcolatori attivi ed in stand/by ( che è un po' la stessa cosa, ma l'attivazione dell'uno o dell'altro non è automatica e prevede una lunga serie di manovre ), ed inoltre dipende da cosa si è guastato: se ad esempio si rompe un tubo dell'aria condizionata e ti allaga il locale dove c'è il calcolatore attivo, ti va a fregare pure i collegamenti con quello in stand/by ( succede, succede...). Una grande criticità è infatti rappresentata dal collegamento fisico tra i vari elementi che garantiscono la fault tolerance: un tempo, con i cavi in rame, la lotta era contro i topi che si mangiavano le guaine e mandavano tutto in corto ! E non sia mai ti si rompe l'impianto di condizionamento son dolori: le macchine si spengono automaticamente oltre una certa temperatura ( a volte dopo i 25 gradi si comincia a tremare...).

La cosa peggiore è il guasto hardware: spesso non ha evidenza fisica, e per capire che un aggeggio è proprio "andato" ci si mette un sacco di tempo perso in tentativi classici di ripristino.

Insomma non è proprio tutto così semplice ed immediato, ma alla fine questi guasti sono piuttosto rari, proprio grazie a tutte le ridondanze previste.

A quanto risulta da questo articolo
http://www.canadianbusiness.com/art...lems-affecting-departing-flights-reservations

è stato un problema di "network".

Non sono per niente d'accordo su quanto sopra scrivi, a parte l'impianto di condizionamento.

Come da documentazione IBM, il TPF "gira" sui System Z IBM
http://www-01.ibm.com/software/htp/tpf/
http://en.wikipedia.org/wiki/IBM_System_z

Diciamo che dove collaboro, ne abbiamo due in cluster da 3 terabyte con 192 Gbyte di RAM ognuno (System / z890). Se stavi parlando della serie 9000 ero d'accordo con te.

In riferimento a quanto affermavo prima

A direct comparison of System z servers with other computing platforms is difficult. For example, System z servers offload such functions as I/O processing, cryptography, memory control, and various service functions (such as hardware configuration management and error logging) to dedicated processors. These "extra" processors are in addition to the (up to) 80 main CPs per frame. System z cores include extensive self checking of results, and if an error is detected the server retries the instruction. If the instruction still fails, the server shuts down the failing processor and shifts workload, "in flight," to a surviving spare processor. The IBM mainframe then "calls home" (automatically places a service call to IBM). An IBM service technician replaces the failed component with a replacement part (possibly even a new processor book, consisting of a group of processors). With System z9 servers, the technician installs the new book and removes the old one without interruption to running applications. (Note that IBM mainframe processors have a reported 40 year MTBF.) Similar design redundancies exist in memory, I/O, power, cooling, and other subsystems. All these features exist at the hardware and microcode level, without special application programming.

Specie su questo

The same concepts can extend to coupled frames separated by up to 100 kilometers in a Geographically Dispersed Parallel Sysplex when z/OS is used.

Scusate l'OT informatico, anche se collegato all'argomento
 
Sostanzialmente giusto quel che dici ( a parte che il TPF gira dagli anni '70, sulla serie ibm os/390 e successivi :) ), io volevo dare un'altra angolazione e forse non ci sono riuscito.
Un blocco di diverse ore non si spiegano con la ridondanza che il parallel sysplex consente: vero che l'attività di una cpu viene spostata sull'altra, e ce ne puoi mettere tante. Non a caso avevo scritto che: " Sei ore di fermo lasciano ipotizzare un guasto fisico del calcolatore o di qualche grosso componente di rete " . Ed infatti pare si sia trattato di un problema di network. Ovvero, puoi avere tutte le cpu che vuoi, ma se gli apparati che da lì devono trasportare il dato sono guasti... In teoria, ma anche in pratica, pure la rete è ridondata, duplicata eccetera: ma prima o poi un collo di bottiglia lo si incontra.

Diciamo che quando avviene una cosa del genere, si è parecchio sfortunati, in quanto il guasto è andato oltre la fantasia progettuale degli specialisti. Nella mia esperienza, fermi totali dei sistemi in svariati contesti sono al 90% legati a guasti imprevedibili quali black-out e mancata partenza dei gruppi elettrogeni, guasti all'impianto di condizionamento, lavori stradali dove una ruspa trancia un bel mucchio di fibre ottiche interrate, fulmini che riescono in qualche modo ad entrare nella rete elettrica ( che botto !! ), cavi elettrici a mollo per temporali e allagamenti, insomma cose sulle quali non ci si può fare molto.

ciaociao
 
bravi Fabiazzo e red.... un po' di luce dietro le quinte dei sistemi che utilizziamo; altro che OT, ci fossero post tecnici anche su questioni piu' "in tema" , per quanto mi riguarda, il forum saebbe piu' utile ed interessante .
 
E' da un po' che hanno problemi informatici... volo a fine marzo da MIA fila lunghissima per il checkin avevano fatto un update al sistema ed era saltato tutto... parecchi casini...
sono i problemi a cui si va incontro integrando due sistemi (penso sia legato alla merger con CO).
 
Sostanzialmente giusto quel che dici ( a parte che il TPF gira dagli anni '70, sulla serie ibm os/390 e successivi :) ), io volevo dare un'altra angolazione e forse non ci sono riuscito.
Un blocco di diverse ore non si spiegano con la ridondanza che il parallel sysplex consente: vero che l'attività di una cpu viene spostata sull'altra, e ce ne puoi mettere tante. Non a caso avevo scritto che: " Sei ore di fermo lasciano ipotizzare un guasto fisico del calcolatore o di qualche grosso componente di rete " . Ed infatti pare si sia trattato di un problema di network. Ovvero, puoi avere tutte le cpu che vuoi, ma se gli apparati che da lì devono trasportare il dato sono guasti... In teoria, ma anche in pratica, pure la rete è ridondata, duplicata eccetera: ma prima o poi un collo di bottiglia lo si incontra.

Diciamo che quando avviene una cosa del genere, si è parecchio sfortunati, in quanto il guasto è andato oltre la fantasia progettuale degli specialisti. Nella mia esperienza, fermi totali dei sistemi in svariati contesti sono al 90% legati a guasti imprevedibili quali black-out e mancata partenza dei gruppi elettrogeni, guasti all'impianto di condizionamento, lavori stradali dove una ruspa trancia un bel mucchio di fibre ottiche interrate, fulmini che riescono in qualche modo ad entrare nella rete elettrica ( che botto !! ), cavi elettrici a mollo per temporali e allagamenti, insomma cose sulle quali non ci si può fare molto.

ciaociao

Per chiudere l'OT (che è piaciuto :)) che poi non è molto OT in forma molto simpatica, l'informatica in generale è basata su :

- La fortuna è cieca, ma la sfiga ci vede benissimo

Ed è per questo che amo molto l'MD 80..... Sapete il perchè :)