Software AntiPattern di alta disponibilità e ripristino di emergenza

Question

Se dovessi controllare un'applicazione Java per le peggiori pratiche quando si tratta di alta disponibilità e ripristino di emergenza, probabilmente dovresti cercare indirizzi IP codificati e cache non ottimale degli handle di bind. Cos'altro dovrebbe essere considerato?

Answer 1

Mancanza di azione / registrazione dello stato.

Un'applicazione Java dovrebbe essere in grado di riprendere da dove si trovava quando si è schiantato.
Ciò significa che dovrebbe esserci un meccanismo in grado di registrare ciò che è già stato fatto (al fine di non ripetere tutto alla prossima esecuzione).

Ciò significa anche che un tale programma Java dovrebbe sempre raggiungere lo stesso stato dopo la stessa serie di azioni. (Fare qualcosa due volte comporterebbe lo stesso risultato e le azioni già eseguite non dovrebbero essere ripetute, ma semplicemente saltate)

Quel record può assumere molte forme (file, database, metadati in un repository di tipo, ...), ma il punto è: un'applicazione Java disposta a recuperare il più velocemente possibile dovrebbe sapere cosa ha già fatto.

Answer 2

Mancanza di strutture di monitoraggio. Prima o poi, tutte le applicazioni falliranno. Quando ciò accade, ti consigliamo di conoscerlo prima di chiunque altro.

Answer 3

Mancanza di registrazione. Se non riesci a trovare ciò che ha ucciso la tua app, è davvero difficile risolverlo. Ciò è particolarmente brutto quando si verificano guasti molto intermittenti con casi difficili da riproporre.

Answer 4

Dato che è già stato menzionato un monitoraggio adeguato, aggiungerei la presenza di un piano di emergenza. Può essere qualcosa di semplice come: se questo accade, lo facciamo, se succede un'altra cosa, lo facciamo. Quindi quando si verificano problemi basta seguire il piano (precedentemente testato) invece di far prendere il panico da tutti e prendere decisioni rapide.

Answer 5

A mio avviso, ci sono un paio di aspetti chiave di ciò che stai chiedendo. Non penso che sia specifico della lingua e hai usato un'app java come esempio, quindi spero che non ti dispiaccia che io non parli specificamente di Java.

Failover / HA : Qui è dove identifichi il tuo SPoF - Single Point of Failure. Gli esempi includono indirizzi hardcoded come menzionato, ma anche applicazioni che archiviano dati in mezzi non replicabili come un disco locale. Altri elementi potrebbero essere la memorizzazione nella cache delle ricerche DNS per "troppo tempo", non ristabilire connessioni interrotte, cercando informazioni hardware specifiche (come indirizzi MAC, CPUID, chiavi hardware, etichette di partizione, MB o numeri di serie dell'unità, ecc.). Ho visto tutti questi come problemi che portano a soluzioni non necessarie per rendere funzionale BCP / DR.

Integrità dei dati : Come vengono archiviati i dati? Utilizza un formato / struttura personalizzato? In tal caso esiste un "dump e ripristino" meccanismo? Il servizio deve interrompere la manutenzione dei client o degrada il servizio per eseguire i backup? Scrive i dati su un dispositivo in modo asincrono e, in caso affermativo, con quale frequenza vengono "scaricati"? su disco (a volte dipende dall'app, altri non così tanto)? Anche il blocco dei file, i tempi e le capacità di archiviazione persistenti da memoria a memoria fanno parte di questo.

Osserva essenzialmente cosa ti farebbe aggirare. Quindi guarda come è arrivato e probabilmente inizierai a sviluppare due importanti pezzi di conoscenza: i modelli da utilizzare per migliorare BCP / DR e, come hai già detto, AntiPatterns che causano problemi. Iniettare questo tipo di domande nel processo di sviluppo, non appena possibile, aiuterà i tuoi sviluppatori a ricavare gli schemi e gli anti-schemi che stai cercando. Spesso solo porre le domande previene i problemi.

Answer 6

La cosa migliore da fare è programmare dei tempi di inattività e testarli. Troverai molti altri problemi nel fare questo. Dopo aver documentato tutto, chiedi a qualcun altro di farlo senza il tuo aiuto. ;)