- Přehledy IS
- APS (20)
- BPM - procesní řízení (22)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (33)
- CRM (51)
- DMS/ECM - správa dokumentů (20)
- EAM (17)
- Ekonomické systémy (68)
- ERP (79)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (36)
- WMS (29)
- Dodavatelé IT slueb a řeení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (39)
- Dodavatelé CRM (33)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (71)
- Informační bezpečnost (50)
- IT řeení pro logistiku (45)
- IT řeení pro stavebnictví (26)
- Řeení pro veřejný a státní sektor (27)
Tematické sekce
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údrby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tiskBranové sekce
![]() | |
| Přihlaste se k odběru newsletteru SystemNEWS, který kadý týden přináí výběr článků z oblasti podnikové informatiky | |
![]() | |
Partneři webu
Jaké ponaučení si vzít z výpadků Cloudflare?
Multi-cloud můe pomoci, ale není to velék
Hned dva globální výpadky sluby Cloudflare v nedávné době opět ukázaly, e ani největí světoví hráči nejsou imunní vůči interním chybám. V obou případech lo o konfigurační změny, které se rozířily na celou sí dřív, ne se projevil problém klasický failure mode distribuovaných systémů.

Kdo to pocítil nejvíc?
Výpadky sluby Cloudflare, které nastaly 18. listopadu na cca 5,5 hodiny a 5. prosince na cca 25 minut nejvíce zasáhly e-shopy a SaaS sluby s vysokou závislostí na real-time dostupnosti. Podle naich interních dat jsme u některých klientů zaznamenali 100% nedostupnost po dobu incidentu. U větích e-shopů to můe znamenat ztráty v řádu desítek tisíc korun za minutu konkrétní čísla se ale dramaticky lií podle segmentu, mare a denní doby. Finanční sektor a kritická infrastruktura byly zasaeny méně, větinou díky existujícím multi-vendor řeením a přísnějím regulatorním poadavkům.
Dopad kadého výpadku se zvyuje
Podle reportu Parametrix vzrostl počet kritických incidentů u top 3 cloud providerů (AWS, Azure, GCP) o 18 % v roce 2024 oproti 2023. Důleité ale je, e současně dramaticky roste objem slueb běících v cloudu a závislost na něm take relativní spolehlivost se nemusí zhorovat tak výrazně, jak absolutní čísla naznačují. Co se ale určitě zhoruje, je dopad kadého jednotlivého výpadku, protoe více byznysu závisí na méně providerech.
Multi-cloud můe pomoci, ale není to velék
Klientům, pro které takový výpadek představuje citelné ztráty, doporučujeme zváit aktivní multi-CDN/multi-cloud strategii. Je ale fér říct, co to obnáí:
- Vyí provozní náklady platíte za redundanci, kterou větinu času nevyuijete. U meních projektů můe roční cena multi-CDN setupu převýit očekávané ztráty z výpadků.
- Komplexita debugování problémů napříč providery je výrazně těí. Potřebujete lidi, kteří rozumí více platformám, a unified monitoring, který není triviální postavit.
- Nové failure modes multi-cloud setup můe selhat koordinovaně (společná závislost na DNS, certifikátech, nebo třeba na tom samém podmořském kabelu). Přidáváte resilience, ale také nové vektory selhání.
Co má smysl pro koho?
- Pro velké e-shopy a SaaS s vysokými náklady na výpadek (řádově statisíce Kč/hodinu a více) dává smysl investovat do aktivního multi-CDN s automatickým failoverem a hybridního modelu s lokálním DC jako fallbackem.
- Pro střední projekty můe být rozumnějí pasivní připravenost mít otestovaný plán B, který aktivujete manuálně, místo plně automatizovaného (a drahého) řeení.
- Pro mení projekty je často nejefektivnějí přijmout, e občasný výpadek je součást ivota, a investovat spí do rychlé komunikace se zákazníky a kompenzačních mechanismů.
Vendor-neutrální nástroje pomáhají, ale nejsou magie
Kubernetes, HAProxy, Nginx nebo BGP routing skutečně usnadňují přenositelnost a sniují vendor lock-in. Zároveň ale přináejí vlastní provozní komplexitu Kubernetes cluster vyaduje netriviální expertízu a sám o sobě můe být zdrojem výpadků. Cílem by nemělo být zbavit se závislostí" (to nejde), ale vědomě si vybrat, na čem závisíte, a mít plán pro případ selhání.
Závěr
Kdo dnes spoléhá pouze na jednoho globálního poskytovatele, přijímá riziko, e jeho dalí výpadek bude i vaím výpadkem. Jestli je to akceptovatelné riziko, záleí na konkrétním byznysu. Důleité je, aby to bylo vědomé rozhodnutí, ne jen důsledek setrvačnosti.
![]() |
Jan Skalla Autor článku působí na pozici Innovation Tech Lead ve společnosti MasterDC. |
IT Systems podporuje
Formulář pro přidání akce










