Multi cloud není nezávislost, pokud oba cloudy sdílejí DNS, identitu a provozní tým CIO MAG

Oficiální doporučení pro více regionů vyžadují, aby každé prostředí dokázalo fungovat bez závislosti na primární straně. Mezi závislosti výslovně patří tajné hodnoty, certifikáty, síť, interní služby, třetí strany a identitní systémy. Stejná logika platí pro dva cloudy, pouze počet technologií a provozních rozhraní je vyšší.

NIST ve své analýze cloudových standardů upozorňuje na význam přenositelnosti rozhraní, datových formátů a identity. Přenositelnost ale není okamžitá dostupnost. To, že lze aplikaci teoreticky přesunout, neprokazuje, že druhé prostředí má aktuální data, oprávnění, kapacitu a ověřený postup pro převzetí provozu během incidentu.

Manažerské shrnutí

01Druhý provider není druhá služba. Dostupnost vznikne až tehdy, když náhradní prostředí samostatně dokončí kritickou transakci.

02Společné řízení může zrušit nezávislost. Jedna identita, DNS změna, pipeline nebo tajné úložiště může současně blokovat obě strany.

03Provozní složitost je součást rizika. Dvě platformy vyžadují dvoje dovednosti, testy, oprávnění a aktuální runbooky.

Nejdříve definujte poruchu, proti které se chráníte

Multi cloud může mít smysl kvůli vyjednávací pozici, regulaci, dostupnosti specifické služby nebo ochraně proti dlouhému výpadku poskytovatele. Každý důvod vede k jiné architektuře. Přenos dat jednou denně může stačit pro odchod od dodavatele, ale nesplní krátké RPO. Aktivní provoz ve dvou prostředích může snížit RTO, ale výrazně zvýší nároky na konzistenci a změnové řízení.

Cíl	Co musí být připraveno	Co nestačí
Vyjednávací nezávislost	Export dat, náhradní architektura a realistický migrační plán	Smlouva se dvěma poskytovateli
Obnova po dlouhém výpadku	Aktuální data, artefakty, identita a nacvičené spuštění	Prázdný účet v druhém cloudu
Krátké RTO	Běžící kapacita, směrování a pravidelné přebírání provozu	Infrastructure as Code bez nasazených závislostí
Odolnost proti správní chybě	Oddělené oprávnění, control plane a postup změny	Stejná federovaná role pro obě prostředí

ROZHODOVACÍ PRAVIDLO

Každou multi cloud investici spojte s jedním explicitním scénářem poruchy, požadovaným RTO, RPO a akceptační transakcí. Bez této vazby nelze poznat, zda druhý cloud snižuje konkrétní riziko, nebo jen rozšiřuje technologický inventář.

DNS a identita patří do cesty obnovy

Směrování provozu se často opírá o DNS. Pokud změna záznamu vyžaduje přihlášení přes identitu dostupnou jen z poškozeného prostředí, náhradní infrastruktura zůstane nevyužitá. Podobně může být druhý cloud technicky zdravý, ale tým v něm nedokáže provést zásah, protože federace, privilegovaná role nebo zařízení pro vícefaktorové ověření mají společný bod selhání.

Důležitý je rozdíl mezi datovou a řídicí rovinou. Již existující DNS odpovědi nebo oprávnění mohou během poruchy dál fungovat, zatímco možnost provést změnu je nedostupná. Recovery plán proto nemá předpokládat, že během incidentu lze vytvářet nové role, upravovat DNS nebo měnit globální politiku. Nezbytné prostředky mají být připravené předem.

TEST NEZÁVISLOSTI

Proveďte cvičení, při kterém není dostupný primární cloud ani běžná federovaná identita. Tým musí z čistého pracoviště aktivovat náhradní službu, ověřit DNS, přístup, audit a obchodní transakci pouze s předem připravenými prostředky.

Modelový scénář z praxe: dvě platformy, jeden správce

Modelová organizace provozovala aplikaci u dvou poskytovatelů. Druhé prostředí mělo aktuální image a replikovanou databázi. Při cvičení se však ukázalo, že nouzovou DNS změnu a vydání certifikátu uměl provést jediný seniorní architekt. Jeho účet používal stejnou podnikovou federaci jako primární cloud a postup nebyl popsán tak, aby jej mohl převzít on call tým.

Technická redundance tedy existovala, ale provozní schopnost byla centralizovaná v člověku a identitě. Organizace zavedla oddělené nouzové role, dvojí kontrolu přístupu, předem připravený přepínací mechanismus a pravidelnou rotaci vedoucího cvičení. Druhý cloud se stal odolnostní kontrolou až poté, co jej dokázal použít někdo jiný než jeho původní autor.

POZNÁMKA Z PRAXE

Největší single point of failure multi cloud architektury nemusí být technologie. Často je jím člověk, který jediný rozumí rozdílům obou platforem a drží nezdokumentované pořadí kroků.

Co dva cloudy neprokazují

Úspěšné nasazení stejného kódu u dvou poskytovatelů neprokazuje stejnou bezpečnost, výkon ani provozní chování. Služby mají rozdílné limity, konzistenční modely a správní rozhraní. Abstrakční vrstva může část rozdílů skrýt, ale zároveň může sama vytvořit společnou závislost.

Multi cloud také není automaticky vhodný pro většinu workloadů. Dobře navržená vícezónová nebo více regionální architektura u jednoho poskytovatele může splnit požadované riziko s menší složitostí. Druhý provider má přinést měřitelnou odolnost proti scénáři, který jednodušší varianta nepokrývá.

HRANICE DŮKAZU

To, že aplikace běží ve druhém cloudu, potvrzuje technickou kompatibilitu konkrétní verze. Neprokazuje aktuální data, přeživší kapacitu ani schopnost provést přepnutí bez společné identity a řídicí roviny.

Nezávislost je vlastnost celé provozní cesty

Rozpočet musí zahrnout nejen druhou infrastrukturu, ale také dvojí testování, správu přístupů, aktualizaci artefaktů, kompetence a pravidelnou obnovu. Pokud na tuto provozní vrstvu nejsou peníze a vlastník, teoretická přenositelnost postupně degraduje.

Nosná teze zní: nezávislost se nepočítá podle počtu dodavatelů. Měří se tím, zda organizace dokáže bez primární platformy a jejích společných závislostí dokončit službu v předem schváleném čase.