Prima che il sistema applicativo venga lanciato, difetti e pericoli nascosti possono essere notevolmente ridotti attraverso test intensivi, ma poiché l'ambiente di simulazione del test non può essere esattamente lo stesso dell'ambiente reale dopo il lancio del sistema, il lavoro di test non può coprire tutti gli scenari di produzione e funzionamento del sistema applicativo IT, ed è difficile evitare il verificarsi di guasti del sistema applicativo IT in uno scenario specifico.
Poiché il pericolo nascosto del fallimento è inevitabile, è molto importante saper affrontare il guasto con calma! È meglio sapere in anticipo, prevedere i possibili problemi del sistema applicativo IT e adottare misure quando il problema non si presenta per eliminare il guasto sul nascere. Non importa quanto grave sia, dobbiamo sapere il prima possibile quali problemi si sono verificati nel sistema e dove si sono verificati, e affrontarli in tempo prima che si diffondano per evitare l'escalation della situazione. In realtà, poiché questi due aspetti sono ancora difficili da realizzare, la pressione dell'operazione e della manutenzione è senza precedenti!
Guardando alle attuali imprese con un alto grado di costruzione delle informazioni rappresentate dalle banche, lo sviluppo del business sta diventando sempre più dipendente dall'IT, la complessità delle loro applicazioni IT aumenta sempre di più e la controllabilità peggiora sempre di più. Ma ciò che è un problema è che in una situazione di inseguimento e intercettazione ad alta intensità, i guasti del sistema continuano a verificarsi, i rischi si manifestano ripetutamente e, molte volte, piccoli problemi si trasformano in guasti gravi, qual è la causa? Perché c'è sempre un ritardo nella scoperta? Perché vari metodi di monitoraggio non possono rilevare anomalie al primo intento? È necessario analizzare tutto questo.
Per quanto riguarda gli aspetti principali, la sala computer è suddivisa in due categorie: risorse di base e sistemi applicativi IT. Per molto tempo attribuiamo grande importanza a risorse di base come rete, host, archiviazione, temperatura e umidità della sala computer, e i metodi di monitoraggio possono essere descritti come "armati fino ai denti".
Per il monitoraggio dei sistemi applicativi IT, attualmente, produttori e fornitori di servizi nazionali e stranieri forniscono molti prodotti o soluzioni; il contenuto del monitoraggio ha un proprio focus, analisi completa; la loro pratica è principalmente osservare le prestazioni del sistema applicativo IT sul livello base delle risorse, attraverso traffico di rete, prestazioni di sistema, occupazione della CPU, occupazione della memoria, accesso al database, stato middleware e altri indicatori, combinati con analisi dei log, esplorazione delle sonde, accesso alla simulazione ed estrazione dei proxy e altri metodi per ottenere determinate informazioni temporali sul funzionamento del sistema. Valutando grosso modo lo stato operativo complessivo di un sistema, questi prodotti o soluzioni mancano di un tracciamento e monitoraggio continui dei dettagli operativi del sistema, quindi non possono comprendere i dettagli dello stato operativo di ogni modulo all'interno del sistema applicativo IT e persino i punti funzionali sotto il modulo; questi dettagli includono: Quali transazioni sta elaborando il sistema? Quale ha avuto successo? Cosa è problematica? Chi avvia la transazione? Quando viene lanciato? Che lavoro fai? Quale modulo del sistema è coinvolto? Quale punto di funzione è responsabile dell'elaborazione? A che ora arriva la risposta? Ci sono anomalie di prestazioni? Se non ha successo, qual è la colpa? Sono molto importanti per giudicare lo stato operativo di un sistema applicativo IT.
In pratica, all'inizio del guasto del sistema applicativo IT, quando il punto di guasto ha scarso impatto sulle risorse di base o non è ancora stato trasmesso allo strato di risorse di base, o il guasto si verifica nel gap tra l'uso di log, sonde, proxy e altri mezzi, anche se il rischio di sistema è stato "sottocorrente", spesso i metodi di monitoraggio esistenti non possono avere un ruolo e la presentazione esterna è anche "nessuna anomalia". Questa è anche la ragione fondamentale per cui il rilevamento dei guasti è in ritardo ed è difficile da gestire! Si può vedere che la rilevazione tempestiva dei guasti di sistema alla "prima volta" è una carenza del lavoro operativo e di manutenzione IT attuale, ed è di grande importanza compensare l'operazione e la manutenzione IT.
Cos'è la "prima volta"? Cioè, nel processo di risposta di un sistema applicativo IT alle richieste di accesso, nel momento in cui una transazione fallisce o avviene in modo anomalo, deve essere catturata con precisione! Tutti sanno che la rilevazione precoce può essere affrontata in tempo e, per invertire la situazione passiva attuale dell'operatività IT e compensare le carenze dell'operazione e della manutenzione IT, è tecnicamente necessario risolvere il problema di rilevare i guasti di sistema "al primo tentativo". Attraverso la ricerca comparativa e la pratica del funzionamento di un gran numero di sistemi applicativi IT, questa idea è in realtà tecnicamente fattibile, ma le persone nel bureau possono essere influenzate dal pensiero inerziale, non uscire dalla mentalità originale e persino pensare che ciò non sia fattibile nella coscienza soggettiva, senza alcun progresso sostanziale in questo aspetto del lavoro, e i rischi operativi delle applicazioni IT sono sempre in una situazione passiva di risposta frammentaria.
La chiave per realizzare la rilevazione "alla prima volta" dei guasti di sistema è essere "attenti" al sistema applicativo IT, padroneggiarne ogni mossa, nello specifico condurre un'osservazione approfondita dei dettagli operativi del sistema applicativo IT e sottoporre il funzionamento di ogni modulo e punto funzionale sotto rigoroso monitoraggio; allo stesso tempo, questo monitoraggio deve essere continuo e ininterrotto, solo in questo modo non perdere alcuna anomalia nelle transazioni di sistema, così che il funzionamento del sistema applicativo IT sia in uno stato controllabile.
Poiché questo processo può ottenere e accumulare informazioni dettagliate sullo stato operativo del sistema, stabilire un prezioso file operativo di sistema, attraverso la sua analisi e utilizzo, può non solo fornire un riferimento per valutare la qualità di ogni modulo e di ogni punto funzionale, ma anche fornire una base per analizzare lo sviluppo e il cambiamento dello stato operativo del sistema, rendendo possibile prevedere la tendenza di salute di un sistema applicativo IT.
|
Pubblicato su 13/10/2014 10:36:01
|
|
|
