異常状態が発生したときに取るべき最初の行動は、システム全体の動向 を調べ、システムはどの程度稼働しているのか、および何であれその状態を引き起こした外部要因によってどれほどのシステム要素が「サービス停止」となったのかを把握することです。
システムが依然として稼働しているかどうかを判別します。多くの場合、システムは稼働可能でも、過負荷、不適切なチューニング、あるいはその両方の理由により、タスクを迅速に完了していないか、実際には失敗する処理を実行しようとしています。
これらの質問のそれぞれに対するリトマス試験は、デプロイされているソリューションの性質に固有のものです。
数多くの自動化再試行およびさまざまなサポート・ロジックが存在する場合は、アプリケーション自体が、一部のエラーを隠して IT オペレーターに明示されないようにすることがあります。
このような状態は、リカバリー・チームが参照できるよう、周知および文書化される必要があります。
管理コンソールを介して、PID が表示されたか、または Deployment Manager から肯定のフィードバックを取得しましたか?
アンロックされたデータで、何らかの単純な SELECT オペレーションを妥当な時間内に実行することができますか?
データベースが正常に稼働していない場合は、データベースをリカバリーする (これにより、少なくともロック解除され、単純な選択オペレーションを実行できるようになります) ことがシステムのリカバリーにとっても重要です。
メッセージング・システムが正常に稼働していない場合は、メッセージング・サブシステムをリカバリーして最低でも表示および管理できるようにすることが、システムのリカバリーにとっても重要です。
このような基本的な手順および正常性検査の類に含まれるアクティビティーから始めて、いくつかの固有のシチュエーションを探し出す必要があります。パターンについて説明され、仕様が定められ、水面下で進行している状況に関する洞察が与えられます。
このシチュエーション分析は、読み取り専用アクティビティーであることを認識してください。 この分析により、適切なリカバリー・アクションを判別するための重要な情報が提供されますが、検討中のシステムの状態は変更されません。システム障害について考えられる原因すべてを予測し、アクションの規定を設けることは不可能です。例えば、以下のデシジョン・ツリーについて考慮してみます。
計画外の停止イベントでは、調査するカテゴリーが広範に及びます。これらの広範なカテゴリーには、サブカテゴリーなども含まれています。各ノードとその後続ノードについて規定のアクションを定義することは、各調査の結果に依存します。このタイプのリレーションシップは文書形式で伝達することが難しいため、IBM® Guided Activity Assist などのサポート・ツールを活用し、調査および決定プロセス全体を対話式に処理することをお勧めします。最上位から各子ノードに進むにつれ、適切なレベルのシチュエーション分析を実施することが重要になります。