La première action à entreprendre face à une situation anormale est de prendre le pouls de l'ensemble du système en vue d'évaluer son niveau de service et de déterminer dans quelle mesure l'événement externe ayant entraîné cette situation entrave son fonctionnement.
Déterminez si le système est toujours opérationnel. Parfois le système est toujours opérationnel, mais en raison d'une surcharge ou d'une optimisation inadaptée, voire les deux, le système effectue les tâches lentement et/ou tente d'effectuer des tâches en cours d'échec.
Le test pour chacune de ces questions sera propre à la nature de la solution déployée.
S'il y a beaucoup de tentatives automatisées et diverses logiques de support, l'application elle-même peut empêcher que l'opérateur soit averti de certaines erreurs.
Ces conditions doivent être connues et documentées afin de fournir des références à l'équipe chargée de la reprise.
Voyez-vous le PID ou avez-vous un retour positif du gestionnaire de déploiement via la console d'administration ?
Pouvez-vous effectuer une simple sélection, sur les données déverrouillées, dans un lapse de temps raisonnable ?
Si la base de données ne fonctionne pas correctement, il est vital de la récupérer (afin de débloquer au moins les verrous et d'effectuer de simples sélections) pour la reprise du système.
Si le système de messagerie ne fonctionne pas correctement, la reprise du sous-système de messagerie, pour au moins l'afficher et pouvoir le gérer, est également vitale pour la reprise du système.
A partir de ces procédures de base et de ces types d'activité de vérification de la santé du système, il faut ensuite commencer à s'intéresser à certaines situations particulières. Des modèles seront décrits, des caractéristiques seront fournies ainsi qu'une analyse de ce qui se passe.
Cette analyse situationnelle est une activité en lecture seule. Elle fournit des informations vitales permettant de déterminer les corrections nécessaires et ne doit pas modifier l'état du système en cours de révision. Il est impossible de prévoir et de fournir les actions nécessaires pour toutes les causes possibles d'une indisponibilité du système. Soit l'arbre de décisions suivant :
Il existe un grand nombre de catégories à examiner dans le cas d'une indisponibilité non planifiée. Ces catégories ont par ailleurs des sous-catégories et ainsi de suite. La définition des actions pour chaque noeud et le noeud suivant dépend des résultats de chaque examen. Ce type de relation étant difficile à transmettre dans un format document, il est recommandé d'utiliser un outil de support tel que IBM® Guided Activity Assist pour examiner le problème et prendre des décisions en conséquence en mode interactif. La progression s'effectuant du haut vers chaque noeud enfant, il est important d'utiliser le niveau d'analyse situationnelle approprié.