1. Účel a platnost metodiky

• Zodpovědnost za návrh: Test Manager ve spolupráci s DevOps a infrastrukturním týmem.
• Zodpovědnost za exekuci: Systémový inženýr nebo technický tester s patřičnými oprávněními pro manipulaci s infrastrukturou.
• Kritéria platnosti testu: Jakýkoliv DRHA test, který neobsahuje definici zátěže (Background Load) a proceduru navrácení do původního stavu (Failback), je považován za neplatný a nesmí být spuštěn na sdílených prostředích.

2. Klíčové principy DRHA testování

Návrh každého DRHA testovacího případu musí striktně respektovat následující pravidla:

1. Exaktní definice SLA metrik: Test musí měřit a vyhodnocovat dvě základní hodnoty:
   • RTO (Recovery Time Objective): Maximální akceptovatelný čas nedostupnosti systému (např. < 10 sekund pro HA cluster).
   • RPO (Recovery Point Objective): Maximální akceptovatelná ztráta dat (např. 0 ztracených transakcí).
2. Testování pod zátěží (Background Load): Simulace výpadku nesmí probíhat na nečinném systému. Mechanismus přepnutí (Failover) musí být validován pod kontinuální zátěží generovanou automatizovaným skriptem.
3. Deterministická metoda destrukce (Failure Injection): Způsob vyvolání havárie musí být přesně popsán na úrovni příkazů (např. kill procesu, zahození paketů přes iptables, hardwarový shutdown), aby byl test plně reprodukovatelný.
4. Povinný Failback: Úspěšné přepnutí na záložní uzel je pouze polovinou testu. Metodika vyžaduje ověření bezpečné resynchronizace dat a návratu provozu na primární uzel.

3. Standardizovaná šablona DRHA Test Case

Následující struktura je povinnou šablonou pro tvorbu DRHA testovacích případů v centrálním test management nástroji. Každý krok musí být exaktně specifikován.

1. Identifikace testu a SLA Limity (Test Objective)

• Typ testu: např. High Availability – Ztráta primárního databázového uzlu
• Cílové RTO: např. < 15 sekund
• Cílové RPO: např. 0 ztracených záznamů
• Cílová komponenta: např. Oracle DB Cluster – Node A

2. Prerekvizity a generování zátěže (Baseline & Load)

1. Ověřit, že všechny uzly clusteru hlásí stav HEALTHY (verifikace stavových ikon přímo v Zabbixu).
2. Spustit zátěžový skript odesílající konstantní traffic (např. 50 INSERT požadavků za sekundu).
3. Vyčkat 2 minuty na stabilizaci síťového toku.

3. Injekce selhání (Failure Injection)

1. Přihlásit se na primární uzel (Node A).
2. Simulovat okamžitou ztrátu síťové konektivity příkazem: sudo iptables -A INPUT -p tcp --dport [PORT] -j DROP
3. Zaznamenat přesný čas (Timestamp) spuštění příkazu.

4. Validace přepnutí (Failover Validation)

• Analýza dostupnosti: Zátěžový skript detekuje dočasné chyby připojení. Provoz se musí automaticky obnovit do stanoveného RTO limitu.
• Verifikace metrik: Analýza logů aplikačního serveru v OpenSearch potvrdí, že po uplynutí RTO limitu nejsou evidovány žádné další timeouty a ztracené transakce (splnění RPO = 0).
• Stav infrastruktury: Node B automaticky převezme roli MASTER.

5. Návrat do původního stavu (Failback Procedure)

1. Obnovit síťovou vrstvu na Node A příkazem: sudo iptables -D INPUT -p tcp --dport [PORT] -j DROP
2. Ověřit, že se Node A připojí zpět do clusteru jako SLAVE a úspěšně synchronizuje rozdílová data.
3. Provést manuální/automatizovaný Failback a ověřit návrat role MASTER na primární Node A.

4. Proces vyhodnocení a reportingu

Po dokončení exekuce je nutné připojit k testovacímu běhu důkazní materiál (Evidence). Vyžaduje se přiložení grafů nebo exportů z monitorovacích nástrojů, které vizuálně prokazují délku trvání výpadku a potvrzují úspěšnou resynchronizaci dat po Failbacku. Test, který prokáže funkční přepnutí, ale poruší časový limit RTO, musí být klasifikován jako FAILED.

Vizuální diagram: Životní cyklus DRHA testovací šablony

Následující diagram znázorňuje procesní fáze DRHA testu podle předepsané metodiky.