A primeira coisa a fazer quando ocorre uma condição anormal é verificar a condição do sistema geral e ter a sensibilidade para perceber quanto e como o sistema está operacional e como isso afeta a condição de ‘fora de serviço' por qualquer estimulo externo que tenha causado essa condição.
Determine se o sistema ainda está operacional. Frequentemente, um sistema pode estar operacional mas, devido à sobrecarga ou ajuste inapropriado, ou ambos, o sistema não está concluindo tarefas rapidamente e/ou está tentando executar um trabalho que está de fato falhando.
O teste definitivo para cada uma destas questões será específico da natureza da solução implementada.
Se houver muitas novas tentativas automatizadas e várias lógicas de suporte, o próprio aplicativo poderá evitar que ocorram alguns erros no operador de TI.
Estas condições devem ser conhecidas e documentadas par referência pela equipe de recuperação.
Você vê o PID ou obtém um feedback positivo do gerenciador de implementação através do console administrativo?
Você pode desempenhar alguma operação SELECT simples em dados desbloqueados em um período de tempo aceitável?
Se o banco de dados não estiver funcionando corretamente, a recuperação dele (para que ele possa pelo menos liberar bloqueios e desempenhar seleções simples) será vital para a recuperação do sistema.
Se o sistema de mensagens não estiver funcionando corretamente, a recuperação dele, para que possa pelo menos ser visualizado e gerenciado, também será vital para a recuperação do sistema.
A partir destes procedimentos básicos e de tipos de atividades de verificação de funcionamento, precisamos agora começar a consultar algumas situações específicas. Padrões serão descritos, informações específicas serão fornecidas e insights do que está ocorrendo nos bastidores serão fornecidos.
Imagine que esta análise de situação é uma atividade de leitura. Enquanto fornece informações vitais das quais é possível determinar as ações de recuperação apropriadas, ela não deve alterar o estado do sistema em revisão. É impossível prever e fornecer ações prescritivas para todas as possíveis causas de uma interrupção do sistema. Por exemplo, considere a seguinte árvore de decisão:
Existem muitas categorias amplas para investigar em caso de uma interrupção não planejada. Estas categorias amplas terão subcategorias e outros. A definição de ações prescritivas para cada nó e o nó subsequente dependerá dos resultados de cada investigação. Como este tipo de relacionamento é difícil de transmitir em um formato de documento, a utilização de uma ferramenta de suporte como IBM® Guided Activity Assist para conduzí-lo interativamente pelo processo investigativo e de tomada de decisão é recomendada. Conforme progredimos a partir do início para cada nó-filho, é importante conduzir o nível apropriado de análise situacional.