La prima operazione da eseguire quando si verifica una condizione anomala è quella di sondare il sistema globale per vedere quanto il sistema sia operativo e quanto del sistema sia reso ‘fuori servizio’ da qualunque sia stato lo stimolo esterno che ha provocato tale condizione.
Determinare se il sistema è ancora operativo. Spesse volte, un sistema può essere operativo, ma a causa del sovraccarico o di un'ottimizzazione non corretta, o entrambi, il sistema non completa le attività rapidamente e/o prova a eseguire del lavoro che di fatto non riesce.
La prova tornasole per ciascuna di queste domande sarà specifica alla natura della soluzione distribuita.
Se vi sono molti tentativi automatizzati e diverse logiche di supporto, l'applicazione stessa potrebbe impedire che gli errori si manifestino all'operatore IT.
Tali condizioni devono essere note e documentate per essere utilizzate come riferimento dal team per il ripristino.
Si visualizza il PID o si ha un feedback positivo dal gestore distribuzione mediante la console di gestione?
È possibile eseguire alcune semplici operazioni SELECT, su dati non bloccati in un periodo di tempo ragionevole?
Se il database non funziona correttamente, il ripristino del database (così che possa almeno rilasciare i blocchi ed eseguire delle semplici operazioni SELECT) è fondamentale per il ripristino del sistema.
Se il sistema di messaggistica non funziona correttamente, anche il ripristino del sottosistema di messaggistica, così che possa almeno essere visualizzato e gestito, è fondamentale per il ripristino del sistema.
Da queste procedure di base e dalle attività relative al controllo della funzionalità, ora occorre iniziare a osservare delle situazioni specifiche. Verranno descritti i pattern, verranno fornite specifiche e approfondimenti su ciò che in realtà si verifica.
Tener presente che tale analisi della situazione è un'attività di sola lettura. Sebbene fornisca delle informazioni fondamentali da cui determinare le azioni di ripristino appropriate, non deve modificare lo stato del sistema sottoposto a revisione. Non è possibile prevedere e fornire delle azioni prescrittive per tutte le cause possibili dell'interruzione di un sistema. Ad esempio, considerare la seguente struttura ad albero delle decisioni:
Vi sono molte ampie categorie per esaminare l'evento di un'interruzione non pianificata. Tali ampie categorie avranno delle categorie secondarie e così via. La definizione delle azioni prescrittive per ciascun nodo e il nodo successivo dipenderà dai risultati di ciascun esame. Poiché questo tipo di relazione è difficile da convogliare nel formato di un documento, si consiglia l'utilizzo di uno strumento di supporto come IBM® Guided Activity Assist che guida interattivamente nel processo di indagine e decisionale. Man mano che si procede dal nodo iniziale a ciascun nodo child, è importante condurre il livello appropriato di analisi della situazione.