Dovremmo progettare programmi per uccidersi a caso? [chiuso]

In breve, dovremmo progettare la morte nei nostri programmi, processi e thread a basso livello, per il bene dell'intero sistema?

I fallimenti accadono. I processi muoiono. Pianifichiamo un disastro e occasionalmente ci riprendiamo. Ma raramente progettiamo e realizziamo la morte imprevedibile del programma. Speriamo che i tempi di attività dei nostri servizi durino quanto ci teniamo a farli funzionare.

Un esempio macro di questo concetto è Chaos Monkey di Netflix , che termina casualmente le istanze AWS in alcuni scenari. Sostengono che ciò li ha aiutati a scoprire problemi e costruire sistemi più ridondanti.

Quello di cui sto parlando è di livello inferiore. L'idea è che i processi tradizionalmente di lunga durata si chiudano casualmente. Ciò dovrebbe forzare la ridondanza nella progettazione e alla fine produrre sistemi più resistenti.

Questo concetto ha già un nome? È già utilizzato nel settore?

MODIFICARE

Sulla base dei commenti e delle risposte, temo di non essere stato chiaro nella mia domanda. Per chiarezza:

• si intendo a caso,
• si, intendo nella produzione e
• no, non solo per i test.

Per spiegare, vorrei tracciare un'analogia con gli organismi pluricellulari.

In natura, gli organismi sono costituiti da molte cellule. Le cellule si forzano per creare ridondanza e alla fine muoiono. Ma dovrebbero sempre esserci abbastanza cellule del giusto tipo per far funzionare l'organismo. Questo sistema altamente ridondante facilita anche la guarigione in caso di infortunio. Le cellule muoiono così vive l'organismo.

Incorporare la morte casuale in un programma costringerebbe il sistema più grande ad adottare strategie di ridondanza per rimanere fattibile. Queste stesse strategie aiuterebbero il sistema a rimanere stabile di fronte a altri tipi di guasti imprevedibili?

E, se qualcuno ha provato questo, come si chiama? Mi piacerebbe saperne di più se esiste già.

No.

Dovremmo progettare una corretta gestione dei percorsi sbagliati e progettare casi di test (e altri miglioramenti del processo) per convalidare che i programmi gestiscano bene queste condizioni eccezionali. Roba come Chaos Monkey può farne parte, ma non appena si fa "deve andare in crash casualmente" un requisito, gli arresti casuali effettivi diventano cose che i tester non possono presentare come bug.

Il processo di introduzione di difetti nel software o nell'hardware per testare i meccanismi di tolleranza agli errori è chiamato iniezione di errori .

Da Wikipedia:

La tecnica di iniezione dei guasti risale agli anni '70, quando fu usata per la prima volta per indurre guasti a livello hardware. Questo tipo di iniezione di errori si chiama HWIFI (Hardware Implemented Fault Injection) e tenta di simulare guasti hardware all'interno di un sistema. I primi esperimenti nell'iniezione di guasti hardware non riguardavano altro che cortocircuitare le connessioni sui circuiti e osservare l'effetto sul sistema (colmare i guasti). È stato utilizzato principalmente come test di affidabilità del sistema hardware. Successivamente è stato sviluppato hardware specializzato per estendere questa tecnica, ad esempio dispositivi per bombardare aree specifiche di un circuito con forti radiazioni. Si è presto scoperto che i guasti potevano essere indotti da tecniche software e che gli aspetti di questa tecnica potevano essere utili per valutare i sistemi software.

Sì. No forse.

La terminazione periodica è un'arma a doppio taglio. Verrai colpito da un lato o dall'altro, e quale è il minore dei due mali dipende dalla tua situazione.

Un vantaggio è l'affidabilità: se costringi il programma a terminare in modo casuale (o prevedibile) e in modo ordinato, puoi essere preparato per quell'evento e affrontarlo. Puoi garantire che il processo verrà chiuso quando non è altrimenti impegnato a fare qualcosa di utile. Ciò garantisce anche che i bug che si manifesterebbero oltre il tempo di esecuzione sanzionato non alleveranno le loro brutte teste in produzione, il che è una buona cosa. Apache HTTPD ha un'impostazione che ti permetterà di mettere a punto quante richieste un processo figlio (o thread nelle versioni più recenti) servirà prima di terminare.

L'altro vantaggio è anche l'affidabilità: se non si consente al programma di funzionare a lungo, non si troveranno mai bug che si manifestano nel tempo. Quando finalmente ti imbatti in uno di quei bug, è molto più probabile che il programma restituisca una risposta errata o non riesca a restituirla affatto. Peggio ancora, se si eseguono più thread dello stesso lavoro, un bug indotto dal tempo o dal conteggio potrebbe influire su un numero molto elevato di attività contemporaneamente e comportare un viaggio in ufficio entro le 3:00.

In un'impostazione in cui si eseguono molti degli stessi thread (ad esempio, su un server Web), la soluzione pratica è quella di adottare un approccio misto che si traduca in un tasso di errore accettabile. Se esegui 100 thread, l'esecuzione di un rapporto breve-lungo di 99: 1 significa che solo uno mostrerà bug a lungo termine mentre gli altri continuano a fare tutto ciò che fanno senza fallire. Contrastalo con una durata del 100%, dove corri un rischio molto più alto di far fallire tutti i thread contemporaneamente.

Laddove hai un singolo thread, è probabilmente meglio lasciarlo funzionare e fallire, perché il tempo morto durante un riavvio può comportare una latenza indesiderata quando c'è un vero lavoro da fare che si completerebbe correttamente.

In entrambi i casi, è importante che ci sia qualcosa che supervisiona i processi in modo che possano essere riavviati immediatamente. Inoltre, non esiste una legge che stabilisca che le tue decisioni iniziali su quanto tempo deve essere eseguito un processo devono essere espresse nella pietra. La raccolta di dati operativi ti aiuterà a ottimizzare il tuo sistema per mantenere i guasti a un livello accettabile.

Vorrei sconsigliare di terminare in modo casuale, perché ciò rende più difficile individuare i bug relativi al tempo. Chaos Monkey lo fa per assicurarsi che il software di supervisione funzioni, il che è un problema leggermente diverso.

Intendi davvero casuale? Fare in modo che il tuo software si uccida a caso sembra un'idea terribile. Che punto servirebbe?

Immagino che ciò che realmente intendi è che dovremmo essere realistici riguardo ai thread / processi a esecuzione prolungata e accettare che più a lungo corrono, più è probabile che abbiano riscontrato una sorta di bug nascosto e siano entrati in un non funzionale stato. Quindi, come misura puramente pragmatica, la durata dei processi e dei thread dovrebbe essere limitata.

Credo che alla fine degli anni '90 il web server Apache usasse qualcosa del genere. Avevano un pool di processi di lavoro (non thread) e ogni processo di lavoro sarebbe stato ucciso dopo una durata fissa. Ciò ha impedito al server di essere monopolizzato da processi di lavoro che erano rimasti bloccati in qualche stato patologico.

Non lavoro nella zona da un po 'di tempo, quindi non so se sia ancora così.

Il problema che vedo è che se un tale programma muore, diremo semplicemente "Oh, è solo un'altra interruzione casuale - niente di cui preoccuparsi". Ma cosa succede se esiste un problema reale che deve essere risolto? Verrà ignorato.

I programmi già "casualmente" falliscono a causa degli sviluppatori che creano mystayke, bug che lo trasformano in sistemi di produzione, guasti hardware, ecc. Quando ciò accade, vogliamo conoscerlo in modo da poterlo correggere. Progettare la morte in programmi aumenta solo la probabilità di fallimento e ci costringerebbe solo ad aumentare la ridondanza, il che costa denaro.

Non vedo nulla di male nell'uccidere i processi in modo casuale in un ambiente di test durante il test di un sistema ridondante (questo dovrebbe accadere più di quello che è) ma non in un ambiente di produzione. Estrarremmo un paio di hard disk da un sistema di produzione live ogni pochi giorni, o disattiveremmo uno dei computer su un aereo mentre sta volando pieno di passeggeri? In uno scenario di test - bene. In uno scenario di produzione dal vivo, preferirei di no.

L'aggiunta di un codice di uscita casuale all'applicazione non dovrebbe essere necessaria. I tester possono scrivere script che uccidono casualmente i processi dell'applicazione.

Nel networking, è necessario simulare una rete inaffidabile per testare un'implementazione del protocollo. Questo non viene integrato nel protocollo; può essere simulato a livello di driver di dispositivo o con hardware esterno.

Non aggiungere il codice di prova per il programma per situazioni che possono essere raggiunte esternamente.

Se questo è destinato alla produzione, non posso credere che sia serio!

Innanzitutto, a meno che i processi non si interrompano bruscamente in modo da perdere le transazioni in corso e i dati volatili, non si tratta di un'implementazione onesta del concetto. Le uscite pianificate e aggraziate, anche se temporizzate in modo casuale, non aiutano adeguatamente a preparare l'architettura per far fronte a crash reali, che non sono aggraziati.

Se nell'applicazione vengono incorporati malfunzionamenti reali o realistici, potrebbero verificarsi danni economici, proprio come i malfunzionamenti reali e un danno economico intenzionale è fondamentalmente un atto criminale quasi per definizione.

Potresti essere in grado di cavartela con le clausole del contratto di licenza che rinunciano alla responsabilità civile da qualsiasi danno derivante dal funzionamento del software, ma se tali danni sono di progettazione, potresti non essere in grado di rinunciare alla responsabilità penale.

Non pensare nemmeno ad acrobazie come questa: fallo funzionare nel modo più affidabile possibile e inserisci scenari di errore falsi solo in build o configurazioni speciali.

Potresti voler cercare " recupero proattivo " e " ringiovanimento " nel contesto di sistemi distribuiti a tolleranza d'errore, per far fronte a guasti arbitrari (vale a dire, non solo processi bloccati, ma anche dati corrotti e comportamenti potenzialmente dannosi). Sono state fatte molte ricerche su quanto spesso e in quali condizioni dovrebbe essere riavviato un processo (in senso astratto, in realtà può essere una macchina virtuale o un host). Intuitivamente, puoi comprendere i vantaggi dell'approccio preferendo affrontare un processo morto piuttosto che un processo traditore ...

Questo non è davvero diverso dal test. Se stai progettando una soluzione di failover sempre disponibile (come Netflix), allora sì, dovresti testarla. Tuttavia, non so che uscite casuali sparse in tutta la base di codice siano un modo appropriato per testarlo. A meno che tu non sia davvero intenzionato a testare che il tuo progetto è resistente a spararti ai piedi, sembrerebbe più appropriato testarlo manipolando l' ambiente attorno al codice e verificando che si comporti in modo appropriato.

Se non stai progettando sistemi ridondanti, allora no, non dovresti aggiungere quella funzione perché hai aggiunto alcune uscite casuali. Dovresti semplicemente rimuovere le uscite casuali e quindi non avrai questo problema. Il tuo ambiente potrebbe ancora fallire, a quel punto lo segnerai come non supportato / non riparerà o indurirai il tuo codice contro quell'errore e aggiungerai un test per esso. Farlo abbastanza spesso, e vi renderete conto che in realtà sta progettando un sistema ridondante - vedere lo scenario # 1.

Ad un certo punto, potresti determinare che non sei più sicuro di quali errori siano o non vengano gestiti. Ora puoi iniziare a estrarre in modo casuale il tappeto per rilevare i punti di errore.

L'unica cosa interessante dell'esempio di Netflix è che eseguono questi test in produzione. Ciò ha un certo senso: alcuni bug sono in realtà solo cose di produzione molto difficili o impossibili da simulare in un ambiente isolato. Sospetto che Netflix abbia trascorso molto tempo in ambienti di test prima che fossero abbastanza comodi da farlo in produzione. E davvero tutto ciò che stanno facendo è cercare di far sì che si verifichino arresti anomali durante l'orario di lavoro, il che ha un certo senso per il loro mercato, ma non per molti altri.

Il termine che stai cercando è stato recentemente coniato da Nassim Nicholas Taleb: Antifragility. Il suo libro Antifragile è decisamente raccomandato. Menziona a malapena l'IT, ma i paralleli inespressi e ovvi sono molto stimolanti. La sua idea è di estendere la scala dell'antifragile fragile <-> robusto a fragile <-> robusto <->. Fragili interruzioni con eventi casuali, robusto gestisce con eventi casuali e guadagni anti-fragili con eventi casuali.

Dipende. Ho notato che i programmatori tendono a generalizzare troppo le tecniche che si applicano al loro dominio specifico ignorando tutti gli altri. Ad esempio, ottenere il rilascio del programma a scapito di tutti i bug può essere buono ... a meno che non si programmino controllori di aeromobili, reattori nucleari, ecc. "Non ottimizzare - il costo del programmatore è maggiore del costo di esecuzione del programma" non è necessario valido per HPC in quanto un programma relativamente semplice può occupare cluster per mesi ecc. (o anche un programma popolare che viene utilizzato da un gran numero di utenti). Quindi, anche se la compagnia X sta facendo Y per un'ottima ragione, non è necessario seguire le loro orme poiché la tua situazione potrebbe essere diversa.

Di solito gli errori nella gestione delle routine sono la parte peggiore del codice testata - sebbene sembri semplice, è difficile simulare che la memoria sia insufficiente o che non ci sia un file importante. Per questa ragione ho letto dei testi che proponevano che il kernel Unix fallisse in modo casuale alcune chiamate di sistema. Tuttavia, sarebbe più difficile scrivere un programma semplice (se devo collegare 3 librerie C ++ insieme per eseguire un programma su 2 file quando non voglio preoccuparmi della gestione degli errori). Anche con le eccezioni, GC è necessario assicurarsi di aver lasciato indietro lo stato coerente (immagina un'eccezione nel mezzo dell'aggiunta del nodo all'elenco collegato).

Maggiore è il numero di servizi distribuiti, maggiore è il numero di guasti dovuti a "quanto frequente", quindi "se" o "quando". Nei data center la sostituzione del disco nei RAID fa parte delle operazioni di routine da quello che so, non errori imprevisti. Se si opera su larga scala è necessario tenerne conto, anche se la probabilità di guasto di un componente è ridotta, è probabile che qualcosa non vada a buon fine.

Non so cosa stai facendo esattamente, ma per sapere se ne vale la pena devi pensare se il fallimento è qualcosa che devi prendere in considerazione (come ignorarlo costa) o è qualcosa di troppo costoso da analizzare (come prendere errori in considerazione i tempi di sviluppo dei costi).

Il server IIS ha una funzione configurabile che ricicla automaticamente i processi di lavoro dopo che hanno utilizzato una determinata quantità di memoria o dopo aver gestito un certo numero di richieste o dopo che sono stati attivi per un periodo di tempo specificato. ( http://msdn.microsoft.com/en-us/library/ms525803(v=vs.90).aspx ) e ( http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ 1652e79e-21f9-4e89-bc4b-c13f894a0cfe.mspx? Mfr = true )

Quando lo fa un CONTENITORE come IIS, ha senso proteggere il server da processi non autorizzati. Tuttavia preferirei che questo fosse disattivato, perché non ha senso se hai sufficientemente testato il tuo codice.

Lavoriamo già su livelli inaffidabili (hardware, rete), quindi non scriverei mai alcun codice che uccida intenzionalmente i suoi thread o processi. L'omicidio casuale è anche una cattiva idea da un punto di vista economico: nessuno userebbe la mia API se pensasse che l'ho programmato per un arresto casuale. Infine, se dovessi consumare un'API o utilizzare un sistema con thread che si arrestano in modo casuale, dovrei spendere molti soldi per creare un meccanismo di monitoraggio abbastanza robusto per poter dormire sonni tranquilli durante la notte.

Invece, se stavo sviluppando un sistema o un'API, scriverei degli script o utilizzerei un cablaggio che lo farebbe puramente per stressare la resistenza del sistema. E farei un test del genere su tutte le build per identificare build errate. Tuttavia, mentre questo sarebbe un test necessario, non potrebbe mai essere un test "sufficiente".

C'è una letteratura correlata a questa idea, il suo software chiamato Crash-Only (anche Recovery Oriented Computing) e puoi iniziare con questo documento usenix di Candea & Fox del 2003. Invece di uccisioni casuali, l'autore sostiene che puoi migliorare l'affidabilità del sistema solo fermare mai i programmi uccidendoli, quindi avere un singolo kill switch come pulsante di spegnimento e un unico percorso di avvio ben allenato per il recupero.

Anche se non sono sicuro di quanto l'idea abbia preso piede, alcune delle tecniche specifiche rimangono utili. Ad esempio, non fidarsi del proprio software per essere in grado di arrestarsi automaticamente quando richiesto e quindi utilizzare programmi di supervisione specializzati (ad esempio supervisord, ecc.), E anche riflettere attentamente su quale stato del programma è essenziale e assicurarsi che sia registrato nei momenti appropriati in un archivio dati progettato per abilitare il recupero (ad es. un database sql).

Veramente a caso, no. Ma è probabilmente una buona idea per processi / thread a esecuzione prolungata uscire / riavviare a un determinato intervallo o dopo essere stati inattivi per una determinata durata (ma dipende da determinati criteri) o dopo aver eseguito un determinato tipo di attività. I processi a lungo termine che si accumulano inevitabilmente includendo oggetti obsoleti, possono presumibilmente aggrapparsi alla memoria impedendo il rilascio dello spazio di swap, che viene (o dovrebbe essere) ripulito quando escono, migliorando la stabilità generale del sistema.

Dipende dal tipo di applicazione che stai progettando.

Gli arresti anomali casuali sono un ottimo modo per testare e migliorare la robustezza dei sistemi distribuiti (in rete).

Nell'esempio di Netflix, quando il tuo programma dipende da servizi remoti che possono fallire per una serie di ragioni che sfuggono al tuo controllo (il disco rigido si guasta, la perdita di potenza, il meteorite si arresta nel data center, ecc.). Tuttavia, il tuo servizio deve continuare a funzionare comunque.

Come si fa a farlo? Aggiungi ridondanza e ridimensionamento è una soluzione comune.

Ad esempio, se un mouse mastica attraverso il cavo di alimentazione del server, il servizio dovrebbe disporre di una soluzione per continuare a funzionare. Ad esempio, può mantenere server di backup ridondanti che inizierà invece a utilizzare.

Tuttavia, se il tuo programma è un'applicazione a processo singolo che non funziona in una rete, allora ucciderlo non proverà nulla poiché non c'è modo di recuperarlo.

Ecco alcuni commenti extra sul concetto di Chaos Monkeys http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

È possibile che si verifichi un capovolgimento casuale a causa della radiazione cosmica . Questo problema è stato riconosciuto e sono state sviluppate varie tecniche per evitare che si verifichino capovolgimenti dei bit.

Tuttavia, non è possibile risolverlo al 100% e il danneggiamento della memoria può ancora causare problemi e questi problemi si verificano ancora ( con probabilità molto bassa ).

Ora, per rispondere alla tua domanda. Che tu debba o meno progettare un sistema molto robusto, dipende da cosa stai facendo. Se devi creare un veicolo spaziale, è meglio renderlo super robusto, e quindi dovrai prendere in considerazione ogni possibile problema.

Se devi progettare una normale applicazione desktop, allora dovresti considerare gli arresti casuali come bug nel tuo codice.

Questo non sembra così assurdo da un'idea.

Il sistema operativo Android uccide e riavvia in modo casuale app / servizi utente in ogni momento. Nella mia esperienza mi ha sicuramente aiutato a riflettere più a fondo sulle condizioni di errore e a progettare architetture più robuste.