Přeskočit obsah

Plán kontinuity

Matice rizik

Matice rizik definuje úroveň rizika na základě porovnání kategorie "Pravděpodobnost" výskytu incidentu s kategorií "Dopad". Oběma kategoriím je přiřazeno skóre od 1 do 5. Vynásobením skóre pro "Pravděpodobnost" a "Dopad" se získá celkové skóre rizika.

Pravděpodobnost

Likelihood Score
Vzácná 1
Nepravděpodobná 2
Možná 3
Pravděpodobná 4
Téměř jistá 5

Dopad

Impact Score Description
Nevýznamné 1 Funkčnost není ovlivněna, výkon není snížen, odstávka není nutná.
Nezávážné 2 Funkčnost není ovlivněna, výkon není snížen, odstávka ovlivněného uzlu clusteru je nutná.
Středně závažné 3 Funkčnost není ovlivněna, výkon je snížen, odstávka postiženého uzlu clusteru je nutná.
Závažné 4 Funkčnost je ovlivněna, výkon je výrazně snížen, je nutná odstávka clusteru.
Katastrofální 5 Úplná ztráta funkčnosti.

Scénáře incidentu

Úplné selhání systému

Dopad: Katastrofální (5)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: středně vysoká

Zmírnění rizika:

  • Geograficky rozložený klastr
  • Aktivní využívání monitorování a upozorňování
  • Profylaktická údržba
  • Silné kybernetické zabezpečení

Obnova:

  1. Kontaktujte podporu a/nebo dodavatele a konzultujte strategii.
  2. Obnovte funkčnost hardwaru.
  3. Obnovte systém ze zálohy konfigurace webu.
  4. Obnovte data z offline zálohy (začněte od nejčerstvějších dat a pokračujte do historie).

Ztráta uzlu v clusteru

Dopad: Střední (4)
Pravděpodobnost: Malá pravděpodobnost (2)
Úroveň rizika: střední-nízká

Zmírnění rizika:

  • Geograficky rozložený klastr
  • Aktivní využívání monitorování a upozorňování
  • Profylaktická údržba

Obnova:

  1. Kontaktujte podporu a/nebo prodejce a konzultujte strategii.
  2. Obnovte funkčnost hardwaru.
  3. Obnovte systém ze zálohy konfigurace webu.
  4. Obnovte data z offline zálohy (začněte od nejčerstvějších dat a pokračujte do historie).

Ztráta jednotky rychlého úložiště v jednom uzlu clusteru

Dopad: Drobný (2)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: střední-nízká

Rychlé disky jsou v poli RAID 1, takže ztráta jednoho disku není kritická. Zajistěte rychlou výměnu selhané jednotky, abyste zabránili selhání druhé rychlé jednotky. Druhé selhání rychlého disku bude eskalovat na "Ztrátu uzlu v clusteru".

Zmírnění rizika:

  • Aktivní používání monitorování a upozorňování
  • Profylaktická údržba
  • Včasná výměna porouchané jednotky

Obnova:

  1. Vypněte postižený uzel clusteru
  2. Co nejdříve vyměňte selhávající jednotku rychlého úložiště
  3. Zapněte postižený uzel clusteru
  4. Ověřte správnou rekonstrukci pole RAID1

Note

Výměna rychlé úložné jednotky za provozu je podporována na zvláštní přání zákazníka.

Nedostatek místa v rychlém úložišti

Dopad: Střední (3)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: středně vysoká

Tato situace je problematická, pokud k ní dojde na více uzlech clusteru současně. K identifikaci této situace před její eskalací použijte monitorovací nástroje.

Zmírnění rizika:

  • Aktivní používání monitorování a upozorňování
  • Profylaktická údržba

Obnova:

  1. Odstraňte nepotřebná data z rychlého úložného prostoru.
  2. Upravte konfiguraci životního cyklu tak, aby se data dříve přesunula do pomalého úložného prostoru.

Ztráta jednotky pomalého úložiště v jednom uzlu clusteru

Dopad: Nevýznamný (1)
Pravděpodobnost: Pravděpodobná (4)
Úroveň rizika: střední-nízká

Pomalé disky jsou v poli RAID 5 nebo RAID 6, takže ztráta jednoho disku není kritická. Zajistěte rychlou výměnu selhané jednotky, abyste zabránili dalšímu selhání jednotky. Druhé selhání disku v poli RAID 5 nebo třetí selhání disku v poli RAID 6 bude eskalovat na "Ztrátu uzlu v clusteru".

Zmírnění rizika:

  • Aktivní používání monitorování a upozorňování
  • Profylaktická údržba
  • Včasná výměna porouchané jednotky

Obnova:

  1. Vyměňte selhávající pomalou úložnou jednotku co nejdříve (hot swap).
  2. Ověřte správnou rekonstrukci pomalého úložiště RAID

Nedostatek místa v pomalém úložišti

Dopad: Střední (3)
Pravděpodobnost: Pravděpodobná (4)
Úroveň rizika: středně vysoká

Tato situace je problematická, pokud k ní dojde na více uzlech clusteru současně. K identifikaci této situace před její eskalací použijte monitorovací nástroje.

Zmírnění rizika:

  • Aktivní používání monitorování a upozorňování
  • Profylaktická údržba
  • Včasné rozšíření velikosti úložiště pomalých dat

Obnova:

  1. Odstraňte nepotřebná data z pomalého úložného prostoru.
  2. Upravte konfiguraci životního cyklu tak, aby byla data z pomalého úložného prostoru odstraněna dříve.

Ztráta systémové jednotky v jednom uzlu clusteru

Dopad: Menší (2)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: střední-nízká

Systémové disky jsou v poli RAID 1, takže ztráta jednoho disku není kritická. Zajistěte rychlou výměnu selhané jednotky, abyste zabránili druhému rychlému selhání jednotky. Druhé selhání systémové jednotky bude eskalovat na "Ztrátu uzlu v clusteru".

Zmírnění rizika: V případě, že se jedná o chybu, která by mohla vést k poškození disku, je nutné, abyste se vyhnuli riziku:

  • Aktivní používání monitorování a výstrah
  • Profylaktická údržba
  • Včasná výměna porouchané jednotky

Obnova:

  1. Vyměňte selhání rychlé úložné jednotky co nejdříve (jak vyměnit).
  2. Ověřte správnou rekonstrukci pole RAID1

Nedostatek místa v úložišti systému

Dopad: Střední (3)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: nízká

Použijte monitorovací nástroje k identifikaci této situace před eskalací.

Zmírnění rizika:

  • Aktivní využívání monitorování a upozorňování
  • Profylaktická údržba

Obnova:

  1. Odstraňte nepotřebná data ze systémového úložného prostoru.
  2. Kontaktujte podporu nebo prodejce.

Ztráta síťového připojení v jednom uzlu clusteru

Dopad: (2)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: střední-nízká

Zmírnění rizika:

  • Aktivní používání monitorování a upozorňování
  • Profylaktická údržba
  • Redundantní síťové připojení

Obnova:

  1. Obnovení síťového připojení
  2. Ověřte správný provozní stav clusteru

Selhání clusteru ElasticSearch

Dopad: (4)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: středně vysoká

Zmírnění rizika:

  • Aktivní používání monitorování a upozorňování
  • Profylaktická údržba
  • Včasná reakce na zhoršující se stav clusteru ElasticSearch

Obnova:

  1. Kontaktujte podporu a/nebo dodavatele a konzultujte strategii.

Selhání uzlu ElasticSearch

Dopad: Menší (2)
Pravděpodobnost: Pravděpodobná (4)
Úroveň rizika: střední-nízká

Zmírnění rizika:

  • Aktivní využívání monitorování a upozorňování
  • Profylaktická údržba
  • Včasná reakce na zhoršující se stav clusteru ElasticSearch

Obnova:

  1. Sledování automatického opětovného připojení uzlu ElasticSearch ke clusteru
  2. Pokud porucha přetrvává několik hodin, kontaktujte podporu / dodavatele.

Selhání clusteru Apache Kafka

Dopad: (4)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: střední-nízká

Zmírnění rizika:

  • Aktivní využívání monitorování a upozorňování
  • Profylaktická údržba
  • Včasná reakce na zhoršující se stav clusteru Apache Kafka

Obnova:

  1. Kontaktujte podporu a/nebo dodavatele a konzultujte strategii.

Selhání uzlu Apache Kafka

Dopad: Drobné (2)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: nízká

Snížení rizika: nízká (nízká):

  • Aktivní využívání monitorování a upozorňování
  • Profylaktická údržba
  • Včasná reakce na zhoršující se stav clusteru Apache Kafka

Obnova:

  1. Sledování automatického opětovného připojení uzlu Apache Kafka ke clusteru
  2. Pokud porucha přetrvává několik hodin, kontaktujte podporu / dodavatele.

Selhání clusteru Apache ZooKeeper

Dopad: (4)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: střední-nízká

Zmírnění rizika:

  • Aktivní využívání monitorování a upozorňování
  • Profylaktická údržba
  • Včasná reakce na zhoršující se stav clusteru Apache ZooKeeper.

Obnova:

  1. Kontaktujte podporu a/nebo dodavatele a konzultujte strategii.

Selhání uzlu Apache ZooKeeper

Dopad: Nevýznamný (1)
Pravděpodobnost: Vzácná (1)
Úroveň rizika: nízká

Snížení rizika: nízká (nízká):

  • Aktivní využívání monitorování a upozorňování
  • Profylaktická údržba
  • Včasná reakce na zhoršující se stav clusteru Apache ZooKeeper.

Obnova:

  1. Sledujte automatické připojení uzlu Apache ZooKeeper ke clusteru.
  2. Pokud porucha přetrvává několik hodin, kontaktujte podporu / dodavatele.

Selhání mikroslužby bezstavové cesty dat (kolektor, parser, dispečer, korelátor, watcher)

Dopad: Menší (2)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: střední-nízká

Zmírnění rizika:

  • Aktivní využívání monitorování a upozorňování
  • Profylaktická údržba

Zotavení:

  1. Restartujte selhávající mikroslužbu.

Selhání bezstavové podpůrné mikroslužby (všechny ostatní)

Dopad: Nevýznamný (1)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: střední a nízká

Zmírnění rizika:

  • Aktivní využívání monitorování a upozorňování
  • Profylaktická údržba

Zotavení:

  1. Restartujte selhávající mikroslužbu.

Výrazné snížení výkonu systému

Dopad: Mírné (3)
Pravděpodobnost: Pravděpodobná (3)
Úroveň rizika: středně vysoká

Zmírnění rizika:

  • Aktivní používání monitorování a upozorňování
  • Profylaktická údržba

Zotavení:

  1. Identifikace a odstranění hlavní příčiny snížení výkonu
  2. V případě potřeby pomoci kontaktujte dodavatele nebo podporu

Strategie zálohování a obnovy

Offline zálohování příchozích protokolů

Příchozí protokoly jsou duplikovány do offline zálohovacího úložiště, které není součástí aktivního clusteru LogMan.io (proto je "offline"). Offline záloha poskytuje možnost obnovit logy do LogMan.io po kritické poruše apod.

Strategie zálohování pro rychlé úložiště dat

Příchozí události (logy) se kopírují do archivního úložiště, jakmile vstoupí do LogMan.io. To znamená, že vždy existuje způsob, jak v případě potřeby "přehrát" události do systému TeskaLabs LogMan.io. Také data jsou replikována do ostatních uzlů clusteru ihned po příchodu do clusteru. Z tohoto důvodu se tradiční zálohování nedoporučuje, ale je možné.

Obnovu zajišťují komponenty clusteru replikací dat z ostatních uzlů clusteru.

Strategie zálohování pro pomalé ukládání dat

Data uložená v pomalém úložišti dat jsou VŽDY replikována do ostatních uzlů clusteru a také uložena v archivu. Z tohoto důvodu se tradiční zálohování nedoporučuje, ale je možné (vezměte v úvahu obrovskou velikost pomalého úložiště).

Obnovu zajišťují komponenty clusteru replikací dat z ostatních uzlů clusteru.

Strategie zálohování systémového úložiště

Doporučuje se pravidelně zálohovat všechny systémy souborů v systémovém úložišti, aby je bylo možné v případě potřeby použít pro obnovení instalace. Zálohovací strategie je kompatibilní s většinou běžných zálohovacích technologií na trhu.

  • Cíl bodu obnovy (RPO): úplné zálohování jednou týdně nebo po větších údržbových pracích, přírůstkové zálohování jednou denně.
  • Cíl doby obnovy (RTO): 12 hodin.

Note

RPO a RTO jsou doporučené za předpokladu vysoce dostupného nastavení clusteru LogMan.io. To znamená tři a více uzlů, aby úplný výpadek jednoho uzlu neměl vliv na dostupnost služby.

Obecná pravidla zálohování a obnovy

  1. Zálohování dat: Pravidelně zálohujte data na bezpečné místo, například do cloudového úložiště nebo na záložní pásky, abyste minimalizovali ztrátu dat v případě selhání.

  2. Plánování zálohování: Stanovte plán zálohování, který odpovídá potřebám organizace, například denní, týdenní nebo měsíční zálohování.

  3. Ověřování zálohování: Pravidelně ověřujte integritu zálohovaných dat, abyste zajistili, že je lze použít pro obnovu po havárii.

  4. Testování obnovy: Pravidelně testujte obnovu záložních dat, abyste se ujistili, že proces zálohování a obnovy funguje správně, a abyste identifikovali a vyřešili případné problémy dříve, než se stanou kritickými.

  5. Uchovávání záloh: Stanovte zásady uchovávání záloh, které vyváží potřebu dlouhodobého uchování dat a náklady na jejich uchovávání.

Monitorování a upozorňování

Monitorování je důležitou součástí plánu kontinuity, protože pomáhá včas odhalit potenciální selhání, identifikovat příčinu selhání a podpořit rozhodování během procesu obnovy.

Mikroslužby LogMan.io poskytují rozhraní API OpenMetrics a/nebo odesílají svou telemetrii do databáze InfluxDB a jako monitorovací nástroj používají nástroj Grafana.

  1. Strategie monitorování: Pro sběr telemetrie ze všech mikroslužeb v clusteru, operačního systému a hardwaru se používá rozhraní OpenMetrics API. Telemetrie se sbírá jednou za minutu. K ukládání telemetrických dat se používá InfluxDB. Jako webové uživatelské rozhraní pro kontrolu telemetrie se používá Grafana.

  2. Upozorňování a oznamování: Monitorovací systém je nakonfigurován tak, aby generoval výstrahy a oznámení v případě potenciálních selhání, jako je málo místa na disku, vysoké využití prostředků nebo zvýšená chybovost.

  3. Monitorovací panely: Monitorovací panely jsou k dispozici v prostředí Grafana a zobrazují nejdůležitější metriky systému, jako je využití prostředků, míra chybovosti a doba odezvy.

  4. Konfigurace monitorování: Pravidelně jsou prováděny revize a aktualizace konfigurace monitorování, aby bylo zajištěno, že je účinná a že odráží změny v systému.

  5. Školení v oblasti monitorování: Pro monitorovací tým a další relevantní strany jsou poskytována školení týkající se monitorovacího systému a monitorovacích panelů v aplikaci Grafana.

Architektura vysoké dostupnosti

Systém TeskaLabs LogMan.io je nasazen ve vysoce dostupné architektuře (HA) s více uzly, aby se snížilo riziko selhání jednoho bodu.

Architektura vysoké dostupnosti je návrhový vzor, jehož cílem je zajistit, aby systém zůstal funkční a dostupný i v případě selhání nebo přerušení provozu.

V clusteru LogMan.io zahrnuje architektura vysoké dostupnosti následující součásti:

  1. Vyrovnávání zátěže: Rozložení příchozího provozu mezi více instancí mikroslužeb, čímž se zvyšuje odolnost systému a snižuje dopad selhání.

  2. Redundantní úložiště: Ukládání dat redundantně ve více uzlech úložiště, aby se zabránilo ztrátě dat v případě selhání úložiště.

  3. Více zprostředkovatelů: Použití více zprostředkovatelů v systému Apache Kafka pro zvýšení odolnosti systému přenosu zpráv a snížení dopadu selhání zprostředkovatele.

  4. Automatické převzetí služeb při selhání: Automatické mechanismy failover, jako je například volba lídra v Apache Kafka, zajišťují, že systém bude fungovat i v případě selhání uzlu clusteru.

  5. Monitorování a upozorňování: Použití monitorovacích a výstražných komponent k detekci potenciálních selhání a spuštění mechanismů automatického převzetí služeb při selhání v případě potřeby.

  6. Průběžné aktualizace: Upgrade systému bez narušení jeho běžného provozu, a to tak, že se uzly upgradují postupně, bez odstávky.

  7. Replikace dat: Replikace protokolu ve více uzlech clusteru, aby bylo zajištěno, že systém bude fungovat i v případě selhání jednoho nebo více uzlů.

Komunikační plán

Jasný a dobře komunikovaný plán reakce na selhání a komunikace se zúčastněnými stranami pomáhá minimalizovat dopady selhání a zajistit, aby všichni byli na stejné vlně.

  1. Identifikace zúčastněných stran: Identifikujte všechny zúčastněné strany, které může být třeba informovat během havárie a po ní, například zaměstnance, zákazníky, dodavatele a partnery.

  2. Zúčastněné organizace: Provozovatel LogMan.io, integrující strana a dodavatel (TeskaLabs).

  3. Komunikační kanály: Komunikační kanály, které se budou používat během katastrofy a po ní, jsou Slack, e-mail, telefon a SMS.

  4. Plán eskalace: Určete eskalační plán, abyste zajistili, že během katastrofy budou ve správný čas informováni ti správní lidé a že komunikace bude koordinovaná a účinná.

  5. Aktualizace a údržba: Pravidelně aktualizujte a udržujte komunikační plán, abyste zajistili, že odráží změny v organizaci, například nové zúčastněné strany nebo komunikační kanály.