システム障害から戻せる？注文の仕事を確かめる復旧テスト

画面の起動と、注文の仕事の復旧を分ける

この仕事に関わるのは社内IT発注担当、受注担当、出荷管理者、開発会社です。それぞれが何を確かめ、誰へ質問を返すかを、同じ注文の記録へ結びます。

復旧テストは、想定した障害から戻す手順を使い、必要なデータと機能を、合意した条件まで回復できるか確かめるものです。本稿では、その確認を注文の仕事へつなげます。機器やサービスの起動だけでなく、受けた注文を同じ一件として追え、関係する担当が必要な仕事を行えるかが焦点です。

受注担当の画面が開けば、出荷管理者も同じ注文で仕事を始められるでしょうか。

バックアップがあることと、仕事を戻せることを分ける

バックアップを作った記録は、復旧に使う材料の一つです。その材料から対象の環境へ戻せたか、必要な注文が残るか、利用者が仕事へ戻れるかは、実際の試験で確かめる範囲です。「ファイルが存在する」「ログイン画面が出た」という証拠を、注文の照合や出荷側の確認の代わりにしません。

NISTの事業継続計画ガイドも、試験の目的と成功条件を明示し、復旧後のデータと機能を検証する考え方を示しています。本稿はその考え方を参考にしています。米国連邦機関向けの役職や手続き、目標時間を、この架空会社の決まりに移してはいません。

必要な速さや止まった場合の業務影響をまだ説明できないなら、業務に必要な速さ・復旧などの条件を決める方法から相談します。現在の構成が分からない場合は、部品と接続の根拠を確かめる構成図へ戻ります。構成図に線があること自体は、復旧を試した証拠にはなりません。

どこを止め、何で戻すかを、権限と一緒に決める

いきなりシステムを止めず、どの版を、どこで、どの障害を想定して試すかを、開発会社と運用を管理する担当へ確認します。試験用の環境にも外部の接続先や共有データがあれば影響があり得ます。対象と影響、実行してよい操作、異常が広がったときの中止・復元の方法をそろえることが準備です。

試験の紙に「止める対象」と「戻す材料・権限」が対応しているでしょうか。

この節の解説図を原寸で見る

版・環境・想定障害を、一つの試験へ結ぶ

この例の対象版、試験環境、本番との差、想定する障害は、いずれも未確認です。開発会社へ、試験する版と環境、どの処理の途中で何を再現するか、結果をどこまで本番へ当てはめられるかを聞きます。環境が違うなら、その差で試せない範囲も残してください。

例えば「受注登録の途中で対象の処理が止まる条件」を試すなら、止める前の受付記録と、処理が途中だった注文を見分ける材料が必要です。ただし、この例では具体的な停止方式は決まっていません。サーバー停止、接続の遮断、拠点の切替えなどを、すべて実施する前提にはしません。構成と目的に合う再現方法を技術側へ提案してもらいます。

戻す材料と、中止・復旧を指示できる人を確かめる

使うバックアップの世代と、二次拠点の有無は、いずれも未確認です。どの時点の何を戻す材料か、使えることを誰が確かめるかを聞きます。二次拠点があるとも、ないとも決めません。拠点切替えを採用していなければ、それをこの試験へ勝手に足さず、実際の復旧方式を確認します。

停止と切り戻しを指示する権限は未確認です。技術側と運用側へ、誰の判断で開始し、どの状態なら中止し、どの手順で元へ戻すかを相談します。業務を再開してよいと判断する人も未確認です。復旧作業の実行者と業務再開の判断者を同じ人と推測せず、業務責任者へ決め方を聞きます。

停止中の代替受付も未確認です。受注担当と業務責任者へ、その時間も注文を受ける必要があるか、合意する受付方法と記録先は何かを確認します。代替受付を使う方針が決まった場合に、その注文を後からどう照合するかを試験へ含めます。未合意の紙受付やメール受付を、運用済みとして描きません。

GCASガイドでは、障害に対する自動復旧の検証と、人の対応手順を確かめる訓練を分けています。停止・接続断・災害対策環境への切替え等は構成に応じた例です。本例がクラウドや自動復旧、二次拠点を採用している証明としては使いません。

停止前・停止中・復旧後の注文を、別の記録で試す

注文は、停止の前・最中・後で、確かめる理由が違います。停止前の分は戻したデータに残るか、停止中の分は合意された受付があれば復旧後へ引き継げるか、復旧後の分は新しく登録して出荷側へ渡せるかを見ます。三つを一括で「注文が見えた」にまとめないよう、別の記録として準備します。

停止前・停止中・復旧後の注文は、それぞれ何と何を照合する計画でしょうか。

この節の解説図を原寸で見る

停止前の注文

照合に使う架空の識別名は「注文A」、場面は停止前です。計画する確認は「停止前に受けた注文を復旧後も同じ一件として追えるか確認する予定」です。

受けた注文を見分ける元の資料と、復旧後の注文記録を対応させます。同じ一件と判別する項目は業務仕様と利用できる記録に合わせて決めます。注文番号の存在や採番方式を、この例から補いません。単に注文一覧の件数が同じでも、別の注文への置換えや重複を見落とせるため、内容と状態の対応も確かめます。

この注文の実際の状態、重複件数、欠落件数はいずれも未確認です。未取得の件数をゼロとして埋めず、実行した場合は照合した範囲と根拠を添えて残します。

停止中の注文

照合に使う架空の識別名は「注文B」、場面は停止中です。計画する確認は「受ける代替手段が合意された場合のみ、停止中の受付と復旧後の取込先を照合する予定」です。

まず、代替受付を採用する合意があるかを確認します。合意された場合にだけ、その受付記録と復旧後の取込先を一件ずつ対応させ、登録済みか、まだ引継ぎが必要かを読めるようにします。二重処理を避ける判断方法も受注担当と開発会社でそろえます。受付記録が自動で取り込まれる、紙があれば受付完了、とは扱いません。

この注文の実際の状態、重複件数、欠落件数はいずれも未確認です。未取得の件数をゼロとして埋めず、実行した場合は照合した範囲と根拠を添えて残します。

復旧後の注文

照合に使う架空の識別名は「注文C」、場面は復旧後です。計画する確認は「再開後に受注担当が登録し、出荷管理者が同じ一件を確認できるか試す予定」です。

再開後に受注担当が登録する操作と、出荷管理者がその同じ注文を確認する操作を組にします。ログインや一覧表示だけを済ませず、期待する内容と状態を誰が照合するか決めます。ここで出荷管理者が確認できても、配送や請求など今回の対象外の仕事まで終えた証拠にはしません。

この注文の実際の状態、重複件数、欠落件数はいずれも未確認です。未取得の件数をゼロとして埋めず、実行した場合は照合した範囲と根拠を添えて残します。

同じ注文を、受注側と出荷側の記録で確かめる

開発会社の復旧完了という報告を、業務担当が確認できる記録へつなぎます。技術的に戻した範囲、利用者の操作、注文の一致、出荷管理者の見え方を分け、何を確かめた結果かが分かるようにします。担当や確認の分け方は案であり、この架空会社で了承された役割表ではありません。

元の受付、復旧後の注文、出荷側の確認が、同じ一件につながっているでしょうか。

この節の解説図を原寸で見る

技術的な復旧と、利用者の入口を読む

技術的な復旧の完了、アプリへのログイン、注文一覧の表示は、いずれも未確認です。開発会社へ何を戻し終え、どの記録を根拠にしたか聞きます。その後、許可された試験利用者で、受注側と出荷側に必要な入口を試す計画へ結びます。ログインできた事実と、注文を正しく扱える事実を区別します。

元の注文との一致と、停止中の引継ぎを読む

停止前の注文について、同じ一件との一致確認は未確認です。元の受付と復旧後の記録のどこを対応させ、何が一致すればよいかを、受注担当と技術側で決めます。異なる状態が出たら、元資料の違いか、復旧対象の時点の違いか、処理の問題かを調べる材料を残します。

停止中の注文の代替受付の存在確認と、その受付から復旧後への照合は、いずれも未確認です。代替受付があることを確かめていないため、「受け付けたのに消えた」「照合して問題なかった」とも言えません。方針が合意されたら、受付記録、復旧後の取込先、引継ぎ済みと読む条件を組にして試します。

新しい注文を、出荷側まで確かめる

復旧後の注文登録と、出荷管理者からの見え方は、いずれも未確認です。受注担当が登録した一件を、出荷管理者が同じ注文として見つけ、必要な内容・状態を読めるか確かめます。受注側だけの画面撮影を、出荷側で扱える証拠へ広げません。

結果には、期待と実際と根拠を並べる

実行した結果を記録する際は、対象の版・環境・想定障害・使った復旧材料、元の受付、期待した注文の状態、実際に見た状態、確認した役割、対応する画面やログを一緒に残します。必要な情報を扱える範囲で用い、実在顧客の注文をこの記事の例へ持ち込む必要はありません。

「復旧できた」という一行だけの返却なら、確認した注文と担当の範囲を聞き直します。照合できない部分はその理由と次の確認先を残し、まだ分からないことを実失敗や未実施と断定しません。実際に不一致が出た場合は、その結果を、材料不足の質問とは分けて開発窓口へ返します。

復旧時間・戻る記録・再開判断を、別々に読む

復旧までにかかった時間と、どの時点のデータまで戻せたかは違う問いです。前者が短くても直近の注文が欠けていれば、必要な仕事へ戻れないことがあります。データが残っていても、担当が使えるまで待つなら、その時間の扱いも必要です。

待てる時間と、戻す注文の時点を、別の紙で説明できるでしょうか。

復旧時間の目標と、実際にかかった時間

RTOは復旧時間の目標を表す用語です。何が使えなくなった時点から、何ができる状態までを対象にするかを定めて使います。注文の照合や業務側の確認がその外に残るなら、仕事を再開できるまでの所要時間も別に把握します。「サーバーが起動するまで」と「受注を再開できるまで」を同じ計測値にしないためです。

この例の合意した復旧時間の目標は未確認、実際の経過時間も未確認です。測定の始点・終点、どの手順を含むかを合わせ、時計や記録の時点が対応する証拠を残してから目標と比べます。記事から一律の時間を当てはめません。

戻す記録の時点の目標と、実際に戻った範囲

RPOは、障害前のどの時点までデータを戻すかという目標です。失ってよいデータの時間幅として説明する場合もありますが、試験ではどの注文まで戻る想定かを具体化します。バックアップの作成時刻だけを見ず、受付や処理の記録と復旧後の状態を対応させ、目標とする時点を確かめます。

合意した復旧時点は未確認、実際に戻ったデータの時点も未確認です。停止前の注文をどこまで追え、戻る範囲より後の受付を何で確認するかを聞きます。分からない時点を「障害直前まで戻った」と補いません。

不足があれば、その範囲の判断を保留する

業務再開の判断結果は未確認です。技術的な復旧、注文の一致、停止中の引継ぎ、出荷側の確認、合意目標への評価を対応させ、判断する人へ渡します。技術側の完了連絡だけで業務側の了承を認定しません。

回答・修正・切り戻しを、必要な再確認へ結ぶ

問題や不足が見つかったら、対象の注文、使った材料、試験条件、期待と実際を残して返します。「直しました」という回答は、再確認を始める材料です。前の結果を消さず、どの版や手順が変わり、何を試し直すかを対応させます。

どの修正が、どの注文の再確認へ戻るかをたどれるでしょうか。

元の運用へ戻す方式なら、その後も確認する

二次拠点や代替環境へ切り替える方式を採用した場合は、元の運用へ切り戻すときの記録・手順・担当の扱いも計画に含めます。切替え先で動いたという結果と、切り戻し後も注文を正しく扱える結果を混ぜません。方式によって確認方法が違うため、構成と運用を説明できる担当へ聞きます。

この例の切り戻し結果は未確認です。二次拠点自体も未確認なので、切り戻しが必要だと確定した例ではありません。まず採用方式と必要性を確認し、対象なら操作と注文照合、終了を判断する条件を決めて試します。

システムの版、バックアップの取り方、接続先、復旧手順や担当が変わると、以前の結果がそのまま使えるとは限りません。変更が関係する条件を見直し、必要な範囲の再確認を計画します。毎回すべてを無条件にやり直すのではなく、変わったものと影響を説明できる記録を残します。

全体の対象・担当・開始条件を整理する段階は、試験を始める前の計画をそろえる方法へつなげます。性能や同時利用の結果を、復旧確認の代わりに使うことも避けてください。目的が違う試験は、確認した条件と結果を分けて扱います。

まとめ：一件の注文を、復旧後の仕事まで追える計画へ

復旧テストを業務の判断へ使うには、起動の報告を注文の記録と担当の仕事へつなげます。対象の版・環境・想定障害・復旧材料・実行権限をそろえ、停止前、停止中、復旧後の注文を分けて試します。時間の目標と、戻すデータの時点は別に評価します。

まず、受注担当の注文を一件選び、何を同じ一件として照合するか話せるでしょうか。

元の架空メモの注意は「三記録は架空の試験計画で実結果ではない。注文Bの代替受付は未合意、二次拠点や復旧方式は未確認。画面表示だけで受注照合・業務再開を成功認定しない。」です。実行した場合も、何を確かめ、何が残るかを分けて記録し、判断できる担当へ渡します。