Tvůj systém funguje skvěle. Dokud pracuje člověk, který ví proč.
Firma má systém, který vznikal sedm let. Funguje. Obsluhuje zákazníky. Komunikuje s dalšími systémy. Zajišťuje procesy, bez kterých by firma vlastně nemohla normálně fungovat.
Během těch sedmi let na projektu pracovalo pět programátorů. K tomu dva freelanceři a jedna agentura. Část dokumentace je v Confluence, část na Google Drivu, část v ticketech. Někde je ještě starý dokument týkající se jedné z integrací. A když se někdo ptá, proč konkrétní část systému funguje právě takto, odpověď zní: "Asi si to pamatoval Michal."
Michal odešel před třemi lety.
A právě tehdy začíná skutečný problém.
Ne proto, že by byl systém napsaný špatně. Ne proto, že by najednou přestal fungovat. Problém je v tom, že firma přestala mít úplnou znalost o vlastním systému.
Systém funguje, ale firma ho nemusí ovládat
To je jedna z nejpodceňovanějších forem technologického dluhu.
Když mluvíme o technologickém dluhu, obvykle myslíme na starý kód, neaktuální knihovny, architektonické chyby, chybějící testy nebo řešení, která byla kdysi rychlá, ale dnes brzdí rozvoj.
Mezitím ale existuje ještě jiný druh dluhu. Dluh znalostí.
Vzniká tehdy, když je systém závislý na informacích, které nejsou v dokumentaci, repozitáři, procesech ani v organizaci, ale jen v hlavách konkrétních lidí.
A dokud jsou tito lidé k dispozici, všechno může vypadat normálně.
Problém se objeví při změně týmu, odchodu programátora, ukončení spolupráce se software housem, výpadku serveru, změně administrátora nebo potřebě rychle nasadit nové řešení.
Najednou se ukáže, že firma má kód, ale nemá znalosti.
Má server, ale nemá jistotu, kdo má přístup.
Má integraci, ale neví se, na jakém účtu byla založena.
Má dokumentaci, ale neví se, která její verze je aktuální.
Má proces, ale neví se, proč byl navržen právě takto.
A pak velmi rychle vyvstane otázka: kdo je vlastně vlastníkem tohoto systému?
Bus factor, tedy co se stane, když zmizí jeden člověk?
Ve světě IT funguje pojem bus factor. Zjednodušeně znamená počet lidí, jejichž nedostupnost může způsobit, že tým přestane být schopen projekt efektivně rozvíjet nebo udržovat.
Nejde samozřejmě o doslovnou událost. Je to způsob uvažování o koncentraci znalostí.
Jestliže jen jeden člověk ví, jak funguje kritická integrace, bus factor pro tuto znalost je jedna.
Jestliže jen jeden administrátor má přístup k produkci, bus factor je jedna.
Jestliže jen jeden člověk ví, proč systém každou noc provádí určitý proces, bus factor může být jedna.
Pokud firma spolupracuje s externím software housem a na straně klienta nikdo nerozumí architektuře řešení, vzniká ještě větší problém - znalosti se mohou nacházet mimo organizaci.
To neznamená, že každá firma musí mít pět expertů na každý fragment systému.
Jde o něco mnohem jednoduššího: firma by měla vědět, kde se nachází kritické znalosti a zda je dokáže získat zpět bez konkrétní osoby.
Kód říká jak. Ne vždy říká proč.
Programátor může přečíst kód a pochopit, co daná funkce dělá.
Ne vždy ale bude vědět, proč byla napsána právě tímto způsobem.
To je obrovský rozdíl.
Lze najít část zodpovědnou za odesílání dat do externího systému. Lze analyzovat endpoint, parametry, autorizaci i zpracování chyb.
Ale kód nemusí odpovědět na otázky:
- Proč data odesíláme ve 2:00 v noci?
- Proč je tento konkrétní status vynechán?
- Proč po chybě systém přesně třikrát opakuje pokus?
- Proč je jedna hodnota přepočítávána před odesláním?
- Proč nelze změnit pořadí těchto operací?
- Proč tato integrace používá konkrétní účet?
Odpověď může být v historii projektu, ve starém ticketu, v e-mailu starém šest let nebo - co je horší - pouze v paměti člověka, který už ve firmě nepracuje.
Proto by dobrá dokumentace neměla být jen návodem "kam kliknout".
Měla by uchovávat také kontext a rozhodnutí.
Největším problémem může být integrace, na kterou už si nikdo nepamatuje
Moderní systém téměř nikdy nefunguje úplně samostatně.
Napojení na ERP systém. CRM. Platební bránu. Poskytovatele SMS. Kurýrní systém. API partnera. Cloudovou službu. Analytickou platformu. Účetní systém. Mechanismus autorizace.
Každé takové spojení je součástí technologického řetězce.
A každá část tohoto řetězce může mít svého vlastníka, účet, API klíč, certifikát, smlouvu, limit, verzi API i životní cyklus.
Po několika letech si už nikdo nemusí pamatovat, kdo daný účet zakládal.
A pak stačí vypršení certifikátu nebo změna API, aby systém přestal fungovat.
Ještě horší je, když firma ani neví, že daná závislost existuje.
Proto v dospělém přístupu k systémům nabývá stále většího významu provenience softwaru, správa závislostí a transparentnost softwarového dodavatelského řetězce. NIST ve svých aktuálních materiálech týkajících se bezpečnosti dodavatelského řetězce upozorňuje mimo jiné na význam informací o komponentech, jejich původu, životním cyklu a závislostech. SBOM, tedy Software Bill of Materials, je jedním z nástrojů, které umožňují uspořádat znalosti o tom, z jakých komponent se software skládá.
To už není téma jen pro security tým.
Je to také téma pro vedení.
Protože pokud firma neví, z čeho je její systém postaven, hůře odhaduje riziko, náklady na údržbu i důsledky změn.
Dokumentace není náklad. Je to pojistka.
V mnoha firmách je dokumentace vnímána jako něco, co "se udělá později".
Nejdřív funkcionalita.
Pak nasazení.
Pak opravy.
Pak další projekt.
A dokumentace?
"Až bude čas."
Problém je v tom, že čas na dokumentaci obvykle přichází ve chvíli, kdy už je pozdě.
Dokumentace by měla fungovat jako podnikové pojištění. Ne proto, že by si ji někdo denně četl. Naopak - ideálně by měla být co nejméně potřeba v krizové situaci.
Ale když nastane problém, firma by měla mít možnost odpovědět na základní otázky:
- Jak systém funguje?
- Z čeho se skládá?
- Kde je produkční prostředí?
- Kdo má přístup?
- Jaké jsou kritické integrace?
- Jaké účty a externí služby se používají?
- Jaké jsou závislosti?
- Jak se provádějí zálohy?
- Jak vypadá proces nasazení?
- Co se děje během výpadku?
- Které prvky jsou kritické pro byznys?
- Proč byla učiněna klíčová architektonická rozhodnutí?
- Kdo může převzít údržbu systému?
Nemusí to znamenat stovky stran dokumentace.
Dobrá dokumentace má být především užitečná, aktuální a dostupná pro správné lidi.
"Nesahejme na to, když to funguje" není vždy špatné rozhodnutí
Existuje ještě jeden velmi častý problém.
Systém funguje už roky, takže firma přijímá zásadu: "Nesahejte na to. Funguje to."
A někdy je to naprosto rozumné.
Ne každá stará technologie vyžaduje okamžitou výměnu. Ne každý starší kus kódu je třeba přepisovat. Ne každá knihovna znamená katastrofu. Ne každá architektura z před pár let je chybná.
Problém začíná ve chvíli, kdy "nesahejme na to" znamená také:
- "Neanalyzujme to."
- "Nedokumentujme to."
- "Neověřujme závislosti."
- "Neptejme se, kdo má přístup."
- "Neověřujme, zda stále máme všechny účty."
- "Neřešme, co se stane, když současný dodavatel přestane být dostupný."
Pak absence změn není strategie.
Je to odkládání rizika.
Někdy je skutečně nejlepší technické rozhodnutí nic nepřestavovat.
Ale toto rozhodnutí by mělo vycházet ze znalosti systému, ne z nedostatku znalostí o systému.
Co by měl zahrnovat audit zděděného systému?
Když firma přebírá systém po jiné softwarové firmě, freelancerovi nebo interním týmu, prvním krokem by nemělo být automatické přepisování všeho.
Nejprve je třeba pochopit, co vlastně bylo převzato.
Audit by měl odpovědět alespoň na několik základních oblastí.
Architektura. Jak je systém postaven? Jaké jsou jeho hlavní komponenty? Kde se nacházejí data? Jak spolu jednotlivé prvky komunikují?
Kód a repozitáře. Má firma kompletní zdrojový kód? Je jasné, která větev a verze jsou produkční? Je možné proces buildu a nasazení znovu provést?
Infrastruktura. Kde běží produkce? Jak vypadá testovací prostředí? Kdo má přístup? Jak vypadají monitoring a zálohy?
Integrace. S čím systém komunikuje? Jaká API používá? Kdo je vlastníkem jednotlivých účtů a klíčů?
Závislosti. Jaké knihovny, frameworky a externí komponenty se používají? Jsou aktualizované? Mají známé bezpečnostní problémy? Jaký je jejich životní cyklus?
Proces nasazení. Je nová osoba schopná připravit, otestovat a nasadit změnu bez telefonátu bývalému vývojáři?
Znalosti. Co je v dokumentaci a co stále existuje jen v hlavách lidí?
Byznysové riziko. Co se stane, pokud konkrétní komponenta přestane fungovat na hodinu, den nebo týden?
Současný přístup k bezpečnosti softwarového dodavatelského řetězce stále silněji zdůrazňuje právě potřebu znalostí o komponentách, dodavatelích, závislostech, jejich původu a životním cyklu. NIST také poukazuje na význam due diligence vůči dodavatelům technologií a hodnocení odolnosti a rizik spojených s celým dodavatelským řetězcem.
Audit neznamená "přepišme systém od nuly"
To je důležité, protože technický audit bývá mylně ztotožňován s přestavbou.
Mezitím může audit skončit velmi jednoduchým závěrem: "Systém je v pořádku. Jen je třeba uspořádat znalosti a odstranit několik rizik."
Může se také ukázat, že systém vyžaduje modernizaci pouze v jedné oblasti.
Nebo že největší problém není v kódu, ale v nedostatku přístupu k infrastruktuře.
Nebo že aplikace je dobře napsaná, ale nikdo nemá aktuální znalost procesu nasazení.
Nebo že všechno funguje, ale firma je závislá na jednom externím dodavateli.
Proto by dobrá analýza zděděného projektu měla odpovědět na otázku: "Co je opravdu potřeba změnit a čeho se není třeba dotýkat?"
Teprve pak lze dělat investiční rozhodnutí.
A co když měníte softwarovou firmu?
To je jeden z momentů, kdy se problém neviditelného dluhu znalostí ukáže naplno.
Firma ukončí spolupráci s dodavatelem.
Nový partner obdrží repozitář.
A začne klást otázky:
- "Kde je produkce?"
- "Jak spustit projekt lokálně?"
- "Která verze je aktuální?"
- "K čemu slouží tato služba?"
- "Kdo vlastní účet k tomuto API?"
- "Co dělá tento cron?"
- "Proč se tento proces spouští v tuto hodinu?"
- "Odkud bereme tento parametr?"
- "Co se stane, když ho vypneme?"
Pokud na většinu otázek zní odpověď "nevíme", nový software house projekt nepřebírá. Nejdřív ho musí objevit.
A objevování systému stojí čas. Čas, který později platí klient.
Proto by předání projektu mezi týmy mělo být procesem, ne hozením ZIPu s kódem a hesla k jednomu účtu.
Systém by měl přežít lidi
To je asi nejdůležitější zásada.
Lidé se mění. Vývojáři mění práci. Freelanceři ukončují spolupráci. Softwarové firmy mění klienty. Administrátoři odcházejí do jiných firem. Vedení se mění.
Systém zůstává.
Proto by měl být systém navržen tak, aby bylo možné získat zpět znalosti potřebné k jeho údržbě.
Neznamená to, že každý zaměstnanec má vědět všechno.
Znamená to, že organizace by měla mít mechanismus ukládání znalostí:
- Repozitáře.
- Dokumentaci.
- Registr integrací.
- Informace o infrastruktuře.
- Přístupy spravované firmou.
- Popis klíčových procesů.
- Historii důležitých rozhodnutí.
- Informace o závislostech.
- Nouzové postupy.
- A především - lidi, kteří umí tuto dokumentaci používat.
NIST v aktuálních doporučeních k plánování bezpečnosti systémů také upozorňuje na formální vymezení odpovědnosti, provozního stavu systému a rolí osob, které systém spravují, podporují nebo k němu mají přístup.
To ukazuje širší změnu v přemýšlení o technologii.
Systém není jen kód. Systém jsou také lidé, procesy, infrastruktura, závislosti, data, přístup a odpovědnost.
Ve Web24 často začínáme právě otázkou: "Co tu vlastně máme?"
Převzetí existujícího projektu by nemělo začínat slibem, že vše bude napsáno od nuly.
Mělo by to začít pochopením situace:
- Co funguje?
- Co nefunguje?
- Co je kritické?
- Co je zastaralé?
- Kde jsou největší rizika?
- Co chybí v dokumentaci?
- Jaké závislosti jsou neviditelné?
- Lze bezpečně rozvíjet stávající systém?
- Je potřeba modernizace, nebo jen úklid?
Teprve potom lze rozhodnout, zda je třeba projekt rozvíjet, přestavět, částečně přepsat nebo ho jednoduše dobře zdokumentovat.
To je zvlášť důležité u projektů, které byly po léta rozvíjeny různými lidmi a různými firmami.
Protože dobrý technologický partner by neměl být potřeba proto, že jen on ví, jak systém funguje.
Měl by být potřeba proto, že dokáže tento systém rozvíjet, zabezpečovat a předávat znalosti dál.
Největší hrozbou může být člověk, který už odešel
Ne vždy je problémem starý kód.
Ne vždy je problémem zastaralá technologie.
Ne vždy je problémem absence nejnovějšího frameworku.
Někdy je největším rizikem informace, kterou nikdo nezapsal.
Jedno heslo.
Jedno architektonické rozhodnutí.
Jedna integrace.
Jedna výjimka v procesu.
Jeden člověk, který po léta věděl, jak to funguje.
A pak odešel.
Proto stojí za to položit si dnes velmi jednoduchou otázku: Kdyby zítra z firmy zmizel člověk, který zná váš systém nejlépe, byli byste jej stále schopni spravovat?
Pokud odpověď zní "ano" - skvělé.
Pokud zní "nevím" - stojí za to to prověřit.
A pokud zní "rozhodně ne" - pravděpodobně jste právě našli jednu z nejdůležitějších oblastí technologického rizika ve své firmě.
Systém by měl být větší než paměť jednoho člověka.
