Váš systém funguje skvěle. Dokud je tam člověk, který ví proč.
Představte si firmu, která má systém běžící sedm let. Vznikal postupně. Nejprve ho udělal jeden software house. Pak část převzal freelancer. Později další tým doprogramoval modul B2B. Následná agentura připojila CRM. Ještě někdo integroval platby.
Systém funguje.
Firma díky němu vydělává peníze.
Zaměstnanci ho používají každý den.
Klienti ani netuší, kolik procesů běží na pozadí.
Jenže je tu jeden problém.
Už nikdo přesně neví, jak to všechno funguje.
Dokumentace je částečně v Confluence. Něco je na Google Drive. Několik informací je v tiketech. Jedna integrace je popsaná v e-mailu z před čtyř let.
A ta nejdůležitější věc "asi si to pamatuje Lukáš".
Jenže Lukáš odešel před třemi lety.
A po tři roky se nic nestalo.
Až jednoho úterního rána.
Systém funguje. Takže je vše v pořádku?
To je jeden z nejzrádnějších stavů, ve kterém se může firemní systém ocitnout.
Funguje.
Nejsou výpadky.
Uživatelé jsou spokojení.
Obchod používá aplikaci.
Objednávky procházejí.
Data putují do CRM.
Reporty se generují.
Takže přirozená reakce zní: Nerusme to. Proč sahat do něčeho, co funguje?
A skutečně - není důvod měnit fungující systém jen proto, že to jde.
Problém je v tom, že systém může být technicky stabilní a zároveň velmi organizačně nestabilní.
Mohou fungovat dnes, ale nikdo neví, co se stane, když bude třeba změnit server, dodavatele API, doménu, knihovnu, způsob autentizace nebo část obchodního procesu.
Může být spolehlivý, ale závislý na jedné osobě.
Může být bezpečný, ale nikdo neví, kde jsou všechny přístupové klíče.
Může být rozvíjen, ale jen člověkem, který zná historii všech rozhodnutí.
A právě zde se objevuje pojem bus factor.
Kolik lidí může zmizet, než projekt začne mít problém?
Bus factor je velmi jednoduchý, byť brutální koncept.
Ptáme se: Kolik lidí musí přestat být dostupných, aby projekt přestal být možné řádně udržovat?
Pokud je odpověď: "Jedna", máme problém.
Pokud je odpověď: "Dvě, ale obě pracují v jiné firmě", máme ještě větší problém.
Nejde samozřejmě o doslovné "zmizení" lidí.
Programátor může odejít z firmy.
Freelancer může ukončit spolupráci.
Software house může přestat klienta obsluhovat.
Administrátor může změnit práci.
Osoba zodpovědná za konkrétní integraci může přejít do jiného oddělení.
Vlastník znalosti může prostě onemocnět nebo být několik týdnů nedostupný.
Jestliže s ním zmizí možnost porozumět systému, firma nemá kadrový problém.
Má obchodní problém.
Kód ne vždy říká, proč něco funguje
Lze namítnout: "Máme zdrojový kód. Nový vývojář si ho prostě přečte."
Teoreticky ano.
V praxi kód odpovídá především na otázku: jak systém něco dělá.
Ne vždy odpovídá na otázku: proč to dělá právě takto.
A to je obrovský rozdíl.
V kódu může být podmínka: "Pokud má klient určitý typ účtu, proveď operaci X."
Nový developer ji najde.
Ale jak má vědět proč?
Může jít o obchodní požadavek.
Může jít o pozůstatek po staré integraci.
Může to být ochrana proti chybě externího API.
Může to být obcházení problému, který se objevil před pěti lety.
Může to být řešení pro netypický případ jednoho z největších klientů.
Může tam být dobrý důvod.
Nebo žádný.
Bez kontextu je těžké to posoudit.
Proto dokumentace systému by neměla končit u návodu:
"klikněte sem, pak tam".
Nejcennější dokumentace často popisuje rozhodnutí a závislosti, nejen obsluhu funkcí.
Nejnebezpečnější znalost je ta, která existuje jen v něčí hlavě
Firmy často dokumentaci mají. Ale dokumentace není vždy totéž co znalost.
Můžeme mít popis API – ale nemusíme mít informaci, proč právě toto API používáme.
Můžeme mít návod nasazení – ale nemusíme mít seznam všech míst, kde je třeba změnit konfiguraci.
Můžeme mít popis integrace – ale nemusíme vědět, co se stane, když externí dodavatel změní způsob autorizace.
Můžeme mít seznam serverů – ale nemusíme vědět, který z nich je kritický pro konkrétní proces.
Můžeme mít přístup do repozitáře – ale nemusíme mít přístup k účtu, kde je produkční infrastruktura.
To jsou přesně ty prvky, které dokážou proměnit zdánlivě jednoduchou změnu v několikadenní pátrání.
Integrace, která funguje pět let, je pořád závislostí
Jednou z nejčastěji ignorovaných oblastí jsou externí služby;
- Platební brány.
- SMS.
- E-mail.
- CRM.
- ERP.
- Mapy.
- Kurierské systémy.
- Marketingové platformy.
- Účetní systémy.
- Cloudové služby.
- Externí API.
- Open source knihovny.
Každá taková věc je součástí širšího ekosystému.
Pokud systém používá deset externích služeb, nemáme jeden systém. Máme systém plus deset závislostí. A každá z nich se může změnit.
Dodavatel může změnit API.
Může ukončit službu.
Může změnit cenový model.
Může vyřadit starou verzi.
Může zavést nové bezpečnostní požadavky.
Může být koupen jinou firmou.
Proto roste význam znalosti o původu komponent a závislostech softwaru. NIST mimo jiné zdůrazňuje význam SBOM, tedy Software Bill of Materials – formálního výpisu komponent použitých k sestavení softwaru. Takový seznam pomáhá pochopit, z čeho se systém skládá a rychleji odhadnout dopad zranitelností nebo změn v dodavatelském řetězci.
Pro byznys to lze zjednodušit na velmi jednoduchou otázku:
Víte, na čem závisí váš systém?
A teď si představte změnu software houseu
To je jeden z momentů, kdy všechny nedostatky vyjdou na světlo.
Firma dlouhá léta spolupracovala s jedním dodavatelem. Najednou spolupráce končí. Důvodů může být mnoho: změna strategie, rozpočtu, převzetí agentury, organizační problémy, nedostatek kompetencí pro další rozvoj. Nebo prostě firma chce pracovat s jiným partnerem.
Nový software house se ptá:
"Kde je repozitář?" - Je.
"Kde je infrastruktura?" - Je.
"Jak nasazujeme produkci?" - "Nevíme, dělal to předchozí tým."
"Jak funguje integrace s ERP?" - "Asi přes tenhle server."
"Jaké máme API klíče?" - "Měly by být v e-mailu."
"Která API jsou produkční?" - "Nevíme."
"Které procesy jsou kritické?" - "Musíte se zeptat Lukáše."
Lukáš tam už nepracuje...
A právě proto převod projektu není jen převodem kódu. Je třeba převést i znalost.
Dokumentace není náklad. Je to pojistka
V mnoha firmách se dokumentace považuje za něco, co se udělá "až bude čas".
Což obvykle znamená nikdy.
Nebo na konci projektu.
Nebo když někdo začne být dotěrný.
To je chyba.
Dokumentace je jedním z mechanismů snižujících operační riziko. Nepřináší přímo prodeje. nezlepší konverze. Nevypadá efektně na prezentaci.
Ale v krizové situaci může být rozdílem mezi: "opravíme to dnes"
a: "nejprve musíme najít člověka, který si pamatuje, jak to dříve fungovalo".
V nových doporučeních NIST týkajících se plánů bezpečnosti, ochrany soukromí a řízení rizik v dodavatelském řetězci softwaru je dokumentování cíle systému, jeho stavu, kontrol a odpovědností osob, které jím řídí, považováno za součást řádného řízení systému.
To dobře ukazuje změnu myšlení.
Dokumentace není výhradně nástroj pro developera.
Je součástí kontinuity fungování organizace.
Co by mělo být zdokumentované?
Nejde o vytvoření 800stránkové dokumentace, kterou nikdo nikdy neotevře.
Dobrá dokumentace by měla především odpovídat na otázky, které se objeví, když se něco změní nebo přestane fungovat.
- Kdo je vlastníkem systému?
- Kde je kód?
- Kde je produkce?
- Jak vypadá proces nasazení?
- Jaká jsou prostředí?
- Jaké jsou kritické integrace?
- Z jakých externích služeb využíváme?
- Kdo jsou jejich dodavatelé?
- Jaké máme smlouvy a účty?
- Kde jsou klíče a přístupová data?
- Kdo má oprávnění?
- Jak vypadá zálohování?
- Jak vypadá obnova systému?
- Jaké open source komponenty jsou použité?
- Které knihovny jsou zastaralé?
- Jaká jsou klíčová architektonická rozhodnutí?
- Které části jsou kritické pro byznys?
- Co se stane, když konkrétní externí služba přestane fungovat?
To není dokumentace „pro programátory".
Je to mapa závislostí byznysu na technologii.
„Funguje, tak nerušit" může být strategie. Ale je třeba znát cenu
Ne každá firma potřebuje přestavbu starého systému.
Ne každý legacy systém je špatný.
Ne každý starý kód musí být přepsán.
Naopak – někdy je stabilní starší systém lepší řešení než nákladná migrace bez konkrétního důvodu.
Problémem není stáří systému.
Problémem je nedostatek znalostí o jeho stavu.
Pokud víme, jak systém funguje, jaké má závislosti, kde jsou rizika a kdo ho umí udržovat, můžeme vědomě rozhodnout:
- nechat ho,
- modernizovat,
- přepsat část,
- migrovat,
- nebo s ním nic nedělat.
Když to nevíme, rozhodnutí „nerušit" není strategií.
Je to hazard.
Jak vypadá audit děděného systému?
Když do software houseu přichází existující systém, prvním krokem by nemělo být: "Přepišme to." – Nejprve je třeba mu porozumět.
Dobrý audit by měl zahrnovat mimo jiné architekturu aplikace, zdrojový kód, databázi, infrastrukturu, proces nasazení, závislosti, integrace, bezpečnost, přístupy ke službám a dokumentaci.
Neméně důležité je pochopení byznysu;
- Které procesy jsou kritické?
- Které funkce se používají denně?
- Které moduly zajišťují příjem?
- Které prvky lze vypnout bez následků?
- Co se stane, když určitá integrace přestane fungovat?
- Které části jsou nejvíc rizikové?
Až po propojení technické a byznysové perspektivy lze říct, co opravdu potřebuje změnu.
Audit nemusí končit revolucí
Někdy je výsledek auditu překvapivě jednoduchý.
Systém je v pořádku, je potřeba jen:
- doplnit dokumentaci,
- uspořádat přístupy,
- aktualizovat několik knihoven,
- převést vlastnictví účtů,
- popsat proces nasazení,
- přidat monitoring,
- nastavit zálohování,
- zapojit druhou osobu do oblastí, které znal jen jeden developer.
A najednou se bus factor změní z 1 na 3.
Není třeba přepisovat celou aplikaci.
Není třeba zahodit sedm let práce.
Není třeba stavět vše od nuly.
Někdy největším problémem není technologie.
Je jí absence mapy.
Systém by měl přežít lidi, kteří ho vytvořili
To je asi nejdůležitější pravidlo: dobrý systém by měl zvládnout odchod developera.
Měl by přežít změnu administrátora.
Měl by přežít změnu software houseu.
Měl by přežít reorganizaci firmy.
Měl by přežít několik let vývoje.
To neznamená, že každý programátor musí rozumět každé lince kódu. Znamená to, že kritická znalost pro fungování byznysu nemůže existovat výhradně v hlavě jedné osoby.
Protože zaměstnanec může odejít.
Freelancer může ukončit spolupráci.
Agentura může zmizet.
Dodavatel může změnit službu.
A firma musí dál fungovat.
Technologie by měla být vlastníctvím organizace, ne pamětí jednotlivce
To je obzvlášť důležité u systémů vyvíjených mnoho let.
Pokud firma platí za software, měla by vědět nejen kde je kód.
Měla by vědět:
- co vlastní,
- na čem závisí,
- kdo má přístup,
- kdo ho může měnit,
- jak ho lze nasadit,
- jak ho lze obnovit,
- jak ho předat jinému týmu.
NIST ve svých materiálech o due diligence dodavatelů mimo jiné upozorňuje na původ, odolnost, bezpečnostní praktiky a závislosti v dodavatelském řetězci. To ukazuje širší směr: organizace by měly vědět nejen kdo systém dodal, ale také z čeho se systém skládá a jaká rizika souvisí s jeho údržbou.
To už není téma jen pro IT oddělení.
Je to téma řízení obchodního rizika.
Nejhorší okamžik poznat svůj systém je při výpadku
Můžete věnovat několik dní auditu.
Můžete uspořádat dokumentaci.
Můžete zkontrolovat závislosti.
Můžete popsat architekturu.
Můžete ověřit přístupy.
Můžete určit, kdo skutečně odpovídá za jednotlivé oblasti.
Můžete snížit bus factor.
Nebo můžete počkat.
Až do chvíle, kdy systém přestane fungovat.
Tehdy budou otázky přesně stejné.
Jen tlak bude větší, uživatelé budou čekat, prodej může stát a každá hodina bude stát peníze.
Proto se vyplatí položit si jednu otázku dříve, než se objeví problém: Kdyby zítra zmizela osoba, která nejlépe zná váš systém, věděli bychom stále, jak ho udržovat?
Pokud odpověď zní "ne", neznamená to hned, že je systém špatný.
Znamená to, že firma má skryté riziko, které dosud nemusela aktivovat.
Ve Web24 přebíráme nejen kód
Převzetí existujícího projektu je úplně jiná práce než zahájení nového systému od nuly.
Nejprve je třeba porozumět, co už existuje.
Co funguje.
Co je kritické.
Co je závislost.
Co je problém.
Co je jen pozůstatek předchozích rozhodnutí.
A především - kde je znalost, bez které systém nelze bezpečně rozvíjet.
Teprve potom lze plánovat další kroky.
Někdy to bude modernizace.
Někdy rozvoj.
Někdy úprava infrastruktury.
Někdy převzetí údržby.
A někdy prostě vytvoření slušné mapy systému, na kterou nikdo za roky neměl čas.
Proto odpovědný software house by neměl budovat technologii, která funguje jen když u počítače sedí ta správná osoba.
Systém by měl být větší než paměť jedné osoby.
Byznys by měl mít jistotu, že když někdo odejde, technologie s ním neodejde.
