復旧訓練の記録で RPO・RTO を測り、事後分析を書く

目標

バックアップのコピー一覧から3-2-1の違反を見つけ、バックアップジョブの記録と障害の記録で実際のデータ損失時間(RPO)と復旧時間(RTO)を測って目標と比べ、リストアしたデータを一覧と照合したうえで、人を責めないポストモーテムと、担当・期限のある改善措置を書きます。

なぜ重要なのか

「RPO 1時間、RTO 90分」は、文書上の目標にすぎません。バックアップが静かに失敗していたなら、実際の損失は何倍にもなり、リストアコマンドの時間だけを測れば、検知と判断にかかった時間が抜け落ちます。復旧訓練はその差を数字で明らかにすることであり、ポストモーテムはその数字を次の改善に変える文書です。誰が悪かったかを書き始めると、事実が隠れ、条件はそのまま残ります。

材料は/opt/lab/capacity/dr/にあり、採点ツールは期待値を元の材料から計算します。

ステップ

/opt/lab/capacity/dr/の内容をすべて/root/dr/へコピーしてください。
3-2-1ルール(コピー3つ・メディア2種類・場所2か所)に違反しているデータを、/root/dr/01-321.txtにviolations=で書いてください。
/root/dr/02-rpo.txtにlast_good=、loss_min=、meets_rpo=を書いてください。
/root/dr/03-rto.txtにrto_min=、meets_rto=、longest_phase=を書いてください。
リストアしたデータをMANIFEST.sha256と照合し、/root/dr/04-verify.txtにmissing=、mismatch=を書いてください。
/root/dr/postmortem.mdに、要約・影響・タイムライン・根本原因・改善措置の5つの節を書いてください(タイムラインの6つの時刻、影響の2つの数字、担当者の名前がない根本原因)。
改善措置を3つ以上書いてください。それぞれに담당:と기한: YYYY-MM-DD(順に、韓国語で「担当」「期限」を意味する語です)を付け、検知・バックアップ・3-2-1の抜けをすべて扱ってください。

参考

時刻の計算: datetime.strptime(s, '%Y-%m-%d %H:%M')、2つの時刻の差は.total_seconds() // 60。
リストアの検証: cd restored && sha256sum -c MANIFEST.sha256。
よくある間違い1: 失敗したバックアップをlast_goodとして数えることです。復元できる時点ではありません。
よくある間違い2: RTOをリストア開始から数えることです。ユーザーは障害の瞬間から止まっていました。

材料のコピー

/opt/lab/capacity/dr/の内容をすべて(restored/ディレクトリを含む)/root/dr/へコピーしてください。

ディレクトリごとコピーするにはcp -rを使います。incident.logとbackup_jobs.logから読んでみてください。

3-2-1ルールの点検

backups.jsonのデータごとにコピー一覧(原本を含む)を見て、コピー3つ以上・メディア(media)2種類以上・場所(site)2か所以上のうち1つでも満たさないデータを、/root/dr/01-321.txtにviolations=<이름들, 쉼표로>(プレースホルダーは名前の一覧をカンマ区切りにしたものです)で書いてください。

データごとにコピーの数、異なるmediaの数、異なるsiteの数を数えます。同じ場所のスナップショット3つは、コピーが3つあってもルールに違反します。

実際のデータ損失時間

incident.logのfailureの時刻とbackup_jobs.logから、/root/dr/02-rpo.txtに3行を書いてください: last_good=<장애 이전에 OK 로 끝난 마지막 백업, YYYY-MM-DD HH:MM>、loss_min=<장애 시각 − last_good, 분>、meets_rpo=<targets.env 의 RPO_MIN 이하면 yes, 아니면 no>(プレースホルダーは、障害より前にOKで終わった最後のバックアップ、障害時刻からlast_goodを引いた分数、targets.envのRPO_MIN以下ならyes、そうでなければnoです)。

最後のバックアップではなく、最後に成功したバックアップです。FAILEDで終わったジョブは、復元できる時点になりません。

実際の復旧時間と最も長い区間

incident.logから、/root/dr/03-rto.txtに3行を書いてください: rto_min=<failure 부터 verified 까지, 분>、meets_rto=<RTO_MIN 이하면 yes, 아니면 no>、longest_phase=<detect·decide·prepare·restore·verify 가운데 가장 긴 구간>(プレースホルダーは、failureからverifiedまでの分数、RTO_MIN以下ならyes、そうでなければno、detect・decide・prepare・restore・verifyのうち最も長い区間です)。区間は順に、failure→detected、detected→declared、declared→restore_start、restore_start→restore_end、restore_end→verifiedです。

リストアコマンドが動いた時間だけでなく、障害が始まった瞬間から数えます。ユーザーにとってサービスは、そのときから止まっていました。

リストアデータの検証

/root/dr/restored/のファイルをMANIFEST.sha256と照合し、/root/dr/04-verify.txtに2行を書いてください: missing=<목록에는 있는데 복원본에 없는 파일, 쉼표로>、mismatch=<있지만 해시가 다른 파일, 쉼표로>(プレースホルダーは、一覧にはあるがリストアしたデータにないファイル、存在するがハッシュが異なるファイルで、どちらもカンマ区切りです)。

restoredディレクトリの中でsha256sum -c MANIFEST.sha256を実行すると、ファイルごとにOK・FAILED・なしが表示されます。エラーで終わっても、出力は最後まで読んでください。

人を責めないポストモーテム

/root/dr/postmortem.mdを書いてください。## 요약、## 영향、## 타임라인、## 근본 원인、## 개선 조치の5つの節が必要です(見出しは順に、韓国語で「要約」「影響」「タイムライン」「根本原因」「改善措置」を意味する語です)。タイムラインにはincident.logの6つの時刻をすべて移し、影響にはステップ3・4で測った実際の損失の分数と復旧の分数を数字で書いてください。根本原因には担当者のアカウント名を書かず、障害を起こした条件と復旧を遅らせた条件を書いてください。

誰がミスをしたかではなく、その人がそうせざるを得なかった条件(アラートがなかった、空き容量を誰も見ていなかった)を書きます。改善措置の節はステップ7で埋めてもかまいませんが、節の見出しは今の時点で必要です。

担当と期限のある改善措置

postmortem.mdの## 개선 조치(韓国語で「改善措置」を意味する語です)の節に、- で始まる項目を3つ以上書いてください。項目ごとに담당: <누구>と기한: YYYY-MM-DD(韓国語の語は順に「担当」「期限」を意味し、プレースホルダーは担当者です)が必要です。この件が明らかにした3つの抜け、つまり検知(アラート)、バックアップ(失敗が静かだった)、3-2-1(ステップ2で見つけた違反)のそれぞれに対する措置が、1つ以上必要です。

担当のない措置は、誰もやりません。「バックアップ失敗時に通知」よりも「最後に成功したバックアップがN分より古くなったら通知」のほうが、ジョブがそもそも動いていない場合まで捉えられます。