Web funguje, objednávky chodí a interní aplikaci lidé používají každý den. Pak ale potřebujete změnit cenu, opravit chybu nebo vyměnit dodavatele. Teprve v tu chvíli zjistíte, že doména je v cizím účtu, zdrojový kód nikdo ve firmě neviděl a poslední ověřená záloha možná neexistuje.

Taková závislost nemusí znamenat, že současný dodavatel odvádí špatnou práci. Vzniká spíš tím, že se všichni soustředili na spuštění a nikdo průběžně neověřoval, zda může provoz převzít i někdo další. Dobré předání se proto nepřipravuje až při výpovědi smlouvy. Je součástí návrhu a provozu systému.

Cílem není držet všechny technologie uvnitř firmy ani umět aplikaci bez pomoci přepsat. Firma však potřebuje rozumět tomu, co vlastní, kde služba běží, jak získá svá data a jak bude pokračovat, když klíčový člověk nebo dodavatel nebude dostupný.

Převzatelný systém není ten, ke kterému máte složku s hesly. Je to systém, který dokáže jiný odpovědný člověk bezpečně zprovoznit, zkontrolovat a dál spravovat.

Nejdřív určete, co nesmí přestat fungovat

Jiný plán potřebuje prezentační web a jiný aplikace, přes kterou každý den procházejí zakázky. Začněte proto dopadem na provoz, ne seznamem technologií.

Vyberte jednu konkrétní službu a projděte s lidmi, kteří ji používají, tři otázky:

  1. Co firma přestane dělat, když služba nebude dostupná?
  2. Jak dlouhý výpadek ještě zvládnete a jak budete dočasně pracovat bez systému?
  3. O kolik posledních dat můžete přijít, aniž by vznikla vážná škoda?

Odpověď nemusí být technická. U webu může být přijatelné, že úprava obsahu počká dva dny, ale doména a kontaktní stránka musí zůstat dostupné. U provozní aplikace může firma několik hodin zapisovat požadavky ručně, musí však vědět kam a jak je později doplní.

Tím získáte hranice pro další rozhodování. Nemá smysl platit složitou záložní infrastrukturu pro stránku, kterou lze znovu sestavit za hodinu. Stejně tak nestačí měsíční kopie databáze u systému, ve kterém se během dne mění stovky důležitých záznamů. Přiměřenost se odvíjí od dopadu, ne od velikosti dodavatele.

Projďte šest vrstev převzetí

1. Účty, vlastnictví a platby

Sepište služby, bez kterých web nebo aplikace neběží: registrátor domény, DNS, hosting nebo cloud, repozitář se zdrojovým kódem, databáze, e-mailové a platební služby, monitoring a další napojení. U každé položky zjistěte, kdo je vlastníkem účtu, kdo má správcovský přístup, z čí karty se platí a kam chodí upozornění na chybu nebo blížící se obnovu.

Firma by neměla být odkázaná na osobní účet jediného člověka. To neznamená, že všichni dostanou všechna oprávnění. Stačí jasně určit firemního vlastníka, provozního správce a nouzovou cestu k obnovení přístupu. Přístupy ukládejte v určeném správci hesel, ne v předávacím dokumentu nebo e-mailu.

Zvlášť zkontrolujte doménu. Pokud vyprší nebo zůstane v účtu nedostupného dodavatele, samotná kopie webu vám nepomůže. Ověřte také, kdo může měnit DNS záznamy a zda kontaktní e-mail pro obnovu patří firmě.

2. Kód, obsah, data a licence

Ujasněte si, co přesně lze předat. Patří sem aktuální zdrojový kód, grafické podklady, texty a média, databáze, historie změn, konfigurace a seznam použitých knihoven nebo placených služeb. U SaaS aplikace nemusíte dostat její kód, ale měli byste vědět, jak exportovat firemní data v použitelném formátu a co se s nimi stane po ukončení služby.

Technický přístup a právo s podklady dál pracovat nejsou totéž. Smlouva by měla srozumitelně popsat licence, zdrojové soubory, data, součinnost při předání a případné náklady na ukončení. Konkrétní znění patří právníkovi; provozní tým má dodat seznam toho, bez čeho pokračování nebude možné.

3. Sestavení a nasazení

Repozitář s kódem je užitečný jen tehdy, když z něj lze vytvořit fungující verzi. Potřebujete znát podporovanou verzi prostředí, příkaz pro sestavení, způsob spuštění testů a postup nasazení. Dále seznam konfiguračních hodnot a tajných klíčů — nikoli jejich kopii v dokumentaci, ale místo, kde jsou bezpečně uložené a jak se obnovují.

Nechte člověka, který systém běžně nenasazuje, připravit testovací prostředí podle návodu. Každá otázka, kterou musí položit původnímu autorovi, ukazuje chybějící část předání. Pokud postup funguje jen na notebooku jednoho vývojáře, systém zatím převzatelný není.

U starší aplikace nemusí být okamžitě reálné vše automatizovat. I ruční postup je lepší než žádný, pokud je aktuální, opakovatelný a uvádí, co se má po nasazení zkontrolovat.

4. Zálohy a obnova

Informace „zálohy běží“ nestačí. Zjistěte, co se zálohuje, jak často, jak dlouho se kopie uchovávají, kdo k nim má přístup a zda nejsou všechny ve stejném účtu jako produkce. Potom proveďte řízenou obnovu do odděleného prostředí a ověřte data i hlavní funkce.

NIST ve svých doporučeních spojuje zálohování s údržbou a testováním. Důvod je praktický: nečitelná, neúplná nebo nedostupná záloha se projeví až ve chvíli, kdy je pozdě. Test obnovy zároveň ukáže, zda máte správné verze aplikace, databáze a konfigurace.

Obnovu nezkoušejte poprvé během skutečného výpadku. Zapište si, kdo ji spouští, jak dlouho trvá a podle čeho poznáte, že se služba vrátila do správného stavu. Pokud po obnově chybí poslední objednávky, musí být jasné, odkud a jak je doplníte.

5. Dohled nad provozem a řešení incidentů

Předání nekončí spuštěním aplikace. Nový správce potřebuje vědět, jak pozná problém. Sepište, které kontroly a upozornění existují, kde jsou dostupné logy, kdo na ně reaguje a jak se rozlišuje běžná chyba od výpadku s dopadem na firmu.

U každého důležitého upozornění by měl existovat konkrétní další krok. Zpráva „server hlásí chybu“ bez kontaktu, kontextu a postupu jen přesune nejistotu z aplikace na člověka. Naopak není nutné budit tým kvůli každému jednotlivému neúspěšnému požadavku, pokud se systém sám bezpečně zotaví a událost zůstane dohledatelná.

6. Odpovědnosti a skutečné předání

Nakonec určete jména nebo role, ne neurčité „IT“. Kdo rozhodne o odstávce? Kdo komunikuje s uživateli? Kdo může schválit náklad na opravu? A kdo potvrdí, že jsou po obnově data i hlavní funkce v pořádku?

GOV.UK ve svém Digital, Data and Technology Playbooku doporučuje řešit ukončení dodávky včas a zahrnout do exit plánu činnosti, milníky, odpovědnosti, závislosti, aktiva, data a znalosti. Pro menší firmu nemusí vzniknout rozsáhlý dokument. Stejný princip se dá zachytit na několika stránkách, pokud podle nich jiný člověk opravdu dokáže postupovat.

Proveďte malý test místo velkého auditu

Nejlepší kontrola převzatelnosti je omezený praktický úkol. Nečekejte na konec smlouvy. Vyberte bezpečnou změnu a nechte ji provést člověka, který systém dosud nespravoval.

  1. Získejte přístup přes běžný firemní proces, ne přes dočasně přeposlané heslo.
  2. Stáhněte kód a podle dokumentace sestavte aplikaci.
  3. Spusťte automatické kontroly a vytvořte testovací prostředí.
  4. Proveďte drobnou změnu, nasaďte ji mimo produkci a ověřte hlavní funkci.
  5. Obnovte testovací kopii dat ze zálohy a zaznamenejte čas i chybějící kroky.
  6. Sepište otázky, které bez původního dodavatele nešlo zodpovědět.

Výsledek není známka dodavatele. Je to seznam konkrétních rizik. Některá vyřeší doplnění přístupu, jiná krátký návod nebo úprava smlouvy. Teprve závažné mezery — například chybějící kód, neobnovitelná data nebo nejasné právo službu dál provozovat — mohou vyžadovat samostatný plán nápravy.

Co napravit jako první

Když najdete více problémů, nezačínejte přepisováním dokumentace. Nejdřív řešte věci, jejichž ztráta může službu zastavit nebo výrazně prodražit:

  1. Doména, účty a platby: dostaňte kritické služby pod kontrolu firmy a nastavte obnovu přístupu.
  2. Data a zálohy: vytvořte použitelný export nebo zálohu a ověřte obnovu.
  3. Aktuální kód a nasazení: potvrďte, že repozitář odpovídá provozu a že z něj lze připravit novou verzi.
  4. Provozní odpovědnost: určete, kdo sleduje službu a kdo rozhoduje při výpadku.
  5. Smluvní a licenční mezery: nechte prověřit vše, co může bránit pokračování nebo předání.
  6. Dokumentace a pravidelný test: doplňte návod podle skutečně provedeného převzetí a naplánujte jeho další ověření.

Pokud systém právě hoří, potřebujete nejdřív stabilizovat provoz. Změna účtů, migrace hostingu nebo aktualizace knihoven ve stejný okamžik může riziko ještě zvýšit. Oddělte nouzovou opravu od následného převzetí a každou změnu ověřujte na bezpečné kopii.

Kdy není cílem úplná nezávislost

Převzatelnost neznamená provozovat všechno vlastními silami ani se vyhýbat službám třetích stran. Hotový systém může být rozumnější než vlastní aplikace a zkušený dodavatel může být pro provoz klíčový. Firma jen potřebuje vědět, co udělá při změně podmínek, ceny nebo dostupnosti.

U běžné cloudové služby může stačit spravovaný firemní účet, pravidelný export důležitých dat, seznam napojení a postup pro přechod. U vlastního provozního systému budete potřebovat i kód, sestavení, databázi, monitoring a odpovědnost za opravy. Hloubka předání má odpovídat dopadu.

Stejně tak není vždy nutné měnit dodavatele, když test odhalí mezery. Často je nejlepší doplnit předání společně se současným týmem, dokud má znalosti i motivaci pomoci. Dobrý exit plán chrání obě strany: firma ví, co dostane, a dodavatel neřeší narychlo neurčité požadavky v posledním týdnu spolupráce.

Kontrolní otázky pro vedení firmy

Na příští provozní poradě si zkuste odpovědět bez pomoci současného dodavatele:

Pokud na některou otázku neznáte odpověď, nemusíte hned spouštět migraci. Vyberte jednu kritickou službu, doplňte inventář a proveďte malý test převzetí. Během něj rychle poznáte, co je skutečný provozní problém a co jen chybějící poznámka.

Pro další přípravu se hodí Digital, Data and Technology Playbook od GOV.UK, přehled plánování kontinuity od NIST, doporučení NIST k udržovaným a testovaným zálohám a otázky NCSC pro prověření dodavatele.

Pokud teprve rozhodujete, zda současný problém řešit daty, automatizací nebo novým nástrojem, pokračujte článkem Co vyřeší váš problém? Pro příklady práce se můžete podívat také na vybrané projekty Duha Works.