Tvoj systém funguje skvele. Kým pracuje osoba, ktorá vie, prečo.
Predstav si firmu, ktorá má systém fungujúci už sedem rokov. Vznikal postupne. Najprv ho vytvoril jeden software house. Potom časť prevzal freelancer. Neskôr ďalší tím dopísal B2B modul. Ďalšia agentúra pripojila CRM. Ešte niekto integroval platby.
Systém funguje.
Firma na ňom zarába peniaze.
Zamestnanci ho používajú každý deň.
Klienti ani netušia, koľko procesov sa deje v pozadí.
Lenže je tu jeden problém.
Nik už presne nevie, ako to všetko funguje.
Dokumentácia je čiastočne v Confluence. Niečo zostalo na Google Drive. Niekoľko informácií je v ticketoch. Jedna integrácia bola opísaná v e-maile spred štyroch rokov.
A najdôležitejšiu vec "asi si pamätal Lukáš".
Lenže Lukáš odišiel pred tromi rokmi.
A tri roky sa nič nedialo.
Až do jedného utorkového rána.
Systém funguje. Takže je všetko v poriadku?
To je jeden z najzradnejších stavov, v akom sa firemný systém môže ocitnúť.
Funguje.
Nie sú žiadne výpadky.
Používatelia sú spokojní.
Obchod používa aplikáciu.
Objednávky prechádzajú.
Dáta smerujú do CRM.
Reporty sa generujú.
Preto prirodzená reakcia znie: Nerýpme sa v tom. Načo sa vŕtať v niečom, čo funguje?
A naozaj - nie je dôvod meniť fungujúci systém len preto, že sa dá.
Problém je v tom, že systém môže byť technicky stabilný a zároveň veľmi nestabilný z organizačného hľadiska.
Môže fungovať dnes, ale nik nevie, čo sa stane, keď bude treba zmeniť server, poskytovateľa API, doménu, knižnicu, spôsob autentifikácie alebo časť biznis procesu.
Môže byť funkčný, ale závislý od jednej osoby.
Môže byť bezpečný, ale nik nemusí vedieť, kde sa nachádzajú všetky prístupové kľúče.
Môže sa ďalej rozvíjať, ale len vďaka človeku, ktorý pozná históriu všetkých rozhodnutí.
A presne tu sa objavuje pojem bus factor.
Koľko ľudí môže zmiznúť, kým projekt začne mať problém?
Bus factor je veľmi jednoduchý, hoci brutálny koncept.
Pýtame sa: Koľko ľudí musí prestať byť k dispozícii, aby projekt prestal byť možné efektívne udržiavať?
Ak znie odpoveď: "Jedna", máme problém.
Ak znie odpoveď: "Dve, ale obe pracujú v inej firme", máme ešte väčší problém.
Samozrejme, nejde o doslovné "zmiznutie" ľudí.
Programátor môže odísť z firmy.
Freelancer môže ukončiť spoluprácu.
Software house môže prestať obsluhovať klienta.
Administrátor môže zmeniť prácu.
Osoba zodpovedná za konkrétnu integráciu môže prejsť na iné oddelenie.
Držiteľ znalostí môže jednoducho ochorieť alebo byť niekoľko týždňov nedostupný.
Ak spolu s ním zmizne aj možnosť porozumieť systému, firma nemá personálny problém.
Má biznisový problém.
Kód nie vždy hovorí, prečo niečo funguje
Môžeš povedať: "Veď máme zdrojový kód. Keď bude treba, nový programátor si to prečíta."
Teoreticky áno.
V praxi kód odpovedá predovšetkým na otázku: ako systém niečo robí.
Nie vždy odpovedá na otázku: prečo to robí práve takýmto spôsobom.
A to je obrovský rozdiel.
V kóde sa môže nachádzať podmienka: "Ak má klient určitý typ účtu, vykonaj operáciu X."
Nový developer ju môže nájsť.
Ale odkiaľ má vedieť, prečo?
Môže to byť biznisová požiadavka.
Môže to byť zvyšok po starej integrácii.
Môže to byť poistka proti chybe externého API.
Môže to byť obchádzka problému, ktorý sa vyskytoval pred piatimi rokmi.
Môže to byť riešenie netypického prípadu jedného z najväčších klientov.
Môže to tam byť z veľmi dobrého dôvodu.
Alebo bez akéhokoľvek.
Bez kontextu sa to ťažko posudzuje.
Preto by sa dokumentácia systému nemala obmedzovať na pokyny:
"klikni sem, potom sem".
Najcennejšia dokumentácia často opisuje rozhodnutia a závislosti, a nie len používanie funkcií.
Najnebezpečnejšia znalosť je tá, ktorá existuje len v niečej hlave
Firmy veľmi často majú dokumentáciu. Lenže dokumentácia nie je vždy to isté čo vedomosti.
Môžeme mať popis API - ale nemať informáciu, prečo používame práve toto API.
Môžeme mať návod na nasadenie - ale nemať zoznam všetkých miest, kde treba zmeniť konfiguráciu.
Môžeme mať popis integrácie - ale nevedieť, čo sa stane, keď externý dodávateľ zmení spôsob autorizácie.
Môžeme mať zoznam serverov - ale nevedieť, ktorý z nich je kritický pre konkrétny proces.
Môžeme mať prístup do repozitára - ale nemať prístup k účtu, na ktorom sa nachádza produkčná infraštruktúra.
To sú presne tie prvky, ktoré dokážu premeniť zdanlivo jednoduchú zmenu na niekoľkodňové vyšetrovanie.
Integrácia, ktorá funguje už päť rokov, je stále závislosťou
Jednou z najčastejšie ignorovaných oblastí sú externé služby;
- Platby.
- SMS.
- E-mail.
- CRM.
- ERP.
- Mapy.
- Kuriérske systémy.
- Marketingové platformy.
- Účtovné systémy.
- Cloudové služby.
- Externé API.
- Open source knižnice.
Každá takáto vec je súčasťou väčšieho ekosystému.
Ak systém využíva desať externých služieb, nemáme jeden systém. Máme systém plus desať závislostí. A každá z nich sa môže zmeniť.
Dodávateľ môže zmeniť API.
Môže ukončiť službu.
Môže zmeniť cenový model.
Môže stiahnuť starú verziu.
Môže zaviesť nové bezpečnostné požiadavky.
Môže ho kúpiť iná firma.
Preto čoraz väčšiu rolu zohráva aj znalosť pôvodu komponentov a softvérových závislostí. NIST poukazuje okrem iného na význam SBOM, teda Software Bill of Materials - formálneho zoznamu komponentov použitých na zostavenie softvéru. Takýto zoznam pomáha pochopiť, z čoho sa systém skladá, a rýchlejšie posúdiť vplyv zraniteľností alebo zmien v dodávateľskom reťazci.
Pre biznis sa to dá zjednodušiť na veľmi jednoduchú otázku:
Vieš, od čoho závisí tvoj systém?
A teraz si predstav zmenu software house'u
To je jeden z momentov, keď všetky nedostatky vyjdú na svetlo dňa.
Firma dlhé roky spolupracovala s jedným dodávateľom. Zrazu sa spolupráca končí. Dôvodov môže byť veľa; zmena stratégie. Zmena rozpočtu. Prevzatie agentúry. Organizačné problémy. Nedostatok kompetencií na ďalší rozvoj. Alebo jednoducho firma chce pracovať s iným partnerom.
Nový software house sa pýta:
"Kde je repozitár?" - Je.
"Kde je infraštruktúra?" - Je.
"Ako nasadzujeme do produkcie?" - "Nevieme, robil to predchádzajúci tím."
"Ako funguje integrácia s ERP?" - "Asi cez ten server."
"Aké máme API kľúče?" - "Mali by byť v e-maile."
"Ktoré API sú produkčné?" - "Nevieme."
"Ktoré procesy sú kritické?" - "Treba sa spýtať Łukasza."
Łukasz tam už nepracuje...
A práve preto prevzatie projektu nie je len prevzatím kódu. Treba prevziať aj vedomosti.
Dokumentácia nie je náklad. Je to poistka
V mnohých firmách sa dokumentácia považuje za niečo, čo sa robí "keď bude čas".
Teda zvyčajne nikdy.
Alebo na konci projektu.
Alebo keď sa niekto opýta.
To je chyba.
Dokumentácia je jedným z mechanizmov obmedzujúcich prevádzkové riziko. Nevytvára priamo predaj. Nezlepšuje konverziu. Na prezentácii nevyzerá efektne.
Ale v krízovej situácii môže byť rozdielom medzi: "vyriešime to dnes"
a: "najprv musíme nájsť človeka, ktorý si pamätá, ako to fungovalo".
V nových usmerneniach NIST týkajúcich sa plánov bezpečnosti, ochrany súkromia a riadenia rizík dodávateľského reťazca softvéru sa dokumentovanie účelu systému, jeho stavu, kontrol a zodpovednosti a správania osôb, ktoré ho spravujú, považuje za prvok riadeného spravovania systému.
To veľmi dobre ukazuje zmenu myslenia.
Dokumentácia nie je výlučne nástrojom pre developera.
Je prvkom kontinuity fungovania organizácie.
Čo by malo byť zdokumentované?
Nejde o vytvorenie dokumentácie na 800 strán, ktorú nikto nikdy neotvorí.
Dobrá dokumentácia by mala predovšetkým odpovedať na otázky, ktoré sa objavia vtedy, keď sa niečo zmení alebo prestane fungovať.
- Kto je vlastníkom systému?
- Kde sa nachádza kód?
- Kde sa nachádza produkcia?
- Ako vyzerá proces nasadenia?
- Aké sú prostredia?
- Aké sú kritické integrácie?
- Aké externé služby používame?
- Kto je ich dodávateľom?
- Aké máme zmluvy a účty?
- Kde sú kľúče a prístupové údaje?
- Kto má oprávnenia?
- Ako vyzerá záloha?
- Ako vyzerá obnovenie systému?
- Aké komponenty open source sa používajú?
- Ktoré knižnice sú zastarané?
- Aké sú najdôležitejšie architektonické rozhodnutia?
- Ktoré prvky sú kritické pre biznis?
- Čo sa stane, ak konkrétna externá služba prestane fungovať?
Toto nie je dokumentácia "pre programátorov".
To je mapa závislostí biznisu od technológie.
"Funguje to, tak do toho nezasahujme" môže byť stratégia. Ale treba poznať jej cenu
Nie každá firma potrebuje prestavbu starého systému.
Nie každý legacy systém je zlý.
Nie každý starý kód treba prepísať.
Práve naopak - niekedy je stabilný, starší systém oveľa lepším riešením než nákladná migrácia vykonaná bez konkrétneho dôvodu.
Problémom nie je vek systému.
Problémom je nedostatok vedomostí o jeho stave.
Ak vieme, ako systém funguje, aké má závislosti, kde sa nachádzajú riziká a kto ho vie udržiavať, môžeme sa vedome rozhodnúť:
- ponecháme,
- zmodernizujeme,
- prepíšeme časť,
- zmigrujeme,
- alebo nič nemeníme.
Ak to nevieme, rozhodnutie "nič nemeníme" nie je stratégia.
Je to stávka.
Ako vyzerá audit zdedeného systému?
Keď sa do software house'u dostane existujúci systém, prvým krokom by nemalo byť: "Prepíšme ho." - Najprv mu treba porozumieť.
Dobrý audit by mal zahŕňať okrem iného architektúru aplikácie, zdrojový kód, databázu, infraštruktúru, proces nasadenia, závislosti, integrácie, bezpečnosť, prístup k službám a dokumentáciu.
Ale rovnako dôležité je pochopenie biznisu;
- Ktoré procesy sú kritické?
- Ktoré funkcie sa používajú denne?
- Ktoré moduly zodpovedajú za príjem?
- Ktoré prvky možno vypnúť bez následkov?
- Čo sa deje, keď konkrétna integrácia prestane fungovať?
- Ktoré prvky sú najrizikovejšie?
Až po spojení technickej a biznisovej perspektívy možno povedať, čo si skutočne vyžaduje zmenu.
Audit sa nemusí skončiť revolúciou
Niekedy je výsledok auditu prekvapivo jednoduchý.
Systém je v poriadku, treba len:
- Doplniť dokumentáciu.
- Usporiadať prístupy.
- Aktualizovať niekoľko knižníc.
- Preniesť vlastníctvo účtov.
- Opísať proces nasadenia.
- Doplniť monitoring.
- Nastaviť zálohu.
- Zapojiť druhú osobu do oblastí, ktoré poznal len jeden developer.
A zrazu bus factor sa zmení z 1 na 3.
Netreba prepisovať celú aplikáciu.
Netreba vyhodiť sedem rokov práce.
Netreba budovať všetko odznova.
Niekedy najväčším problémom nie je technológia.
Je ním nedostatok mapy.
Systém by mal prežiť ľudí, ktorí ho vytvorili
To je asi najdôležitejšie pravidlo: dobrý systém by mal byť schopný prežiť odchod developera.
Mal by prežiť zmenu administrátora.
Mal by prežiť zmenu software house'u.
Mal by prežiť reorganizáciu firmy.
Mal by prežiť niekoľko rokov vývoja.
To neznamená, že každý programátor musí rozumieť každému riadku kódu. Znamená to, že vedomosti kritické pre fungovanie biznisu nemôžu existovať výlučne v hlave jednej osoby.
Pretože zamestnanec môže odísť.
Freelancer môže ukončiť spoluprácu.
Agentúra môže zmiznúť.
Dodávateľ môže zmeniť službu.
A firma musí stále fungovať.
Technológia by mala byť vlastníctvom organizácie, nie pamäťou jednej osoby
To je obzvlášť dôležité v prípade systémov budovaných mnoho rokov.
Ak firma platí za softvér, mala by vedieť nielen to, kde sa nachádza kód.
Mala by vedieť:
- čo vlastní,
- od čoho závisí,
- kto má prístup,
- kto ho môže meniť,
- ako ho možno nasadiť,
- ako ho možno obnoviť,
- ako ho možno odovzdať inému tímu.
NIST v aktuálnych materiáloch týkajúcich sa due diligence dodávateľov upozorňuje okrem iného na pôvod, odolnosť, postupy kybernetickej bezpečnosti a závislosti v dodávateľskom reťazci. Ukazuje to širší smer: organizácie by mali čoraz častejšie vedieť nielen, kto dodal systém, ale aj z čoho sa systém skladá a aké riziká súvisia s jeho údržbou.
To už nie je výlučne téma pre IT oddelenie.
Je to téma riadenia biznisového rizika.
Najhorší moment na spoznanie vlastného systému je výpadok
Možno venovať niekoľko dní auditu.
Možno usporiadať dokumentáciu.
Možno skontrolovať závislosti.
Možno opísať architektúru.
Možno overiť prístupy.
Možno zistiť, kto skutočne zodpovedá za jednotlivé oblasti.
Možno znížiť bus factor.
Alebo možno počkať.
Do momentu, keď systém prestane fungovať.
Vtedy budú otázky presne tie isté.
Len tlak bude väčší, používatelia budú čakať, predaj sa môže zastaviť a každá hodina bude stáť peniaze.
Preto sa oplatí položiť si jednu otázku skôr, než sa objaví problém: Keby zajtra zmizla osoba, ktorá pozná tvoj systém najlepšie, vedeli by sme stále, ako ho udržiavať?
Ak odpoveď znie "nie", ešte to neznamená, že systém je zlý.
Znamená to, že firma má skryté riziko, ktoré doteraz nemusela aktivovať.
Vo Web24 preberáme nielen kód
Prevzatie existujúceho projektu je úplne iná práca než začatie nového systému od nuly.
Najprv treba pochopiť, čo už existuje.
Čo funguje.
Čo je kritické.
Čo je závislosť.
Čo je problém.
Čo je len pozostatok po predchádzajúcich rozhodnutiach.
A predovšetkým - kde sa nachádzajú znalosti, bez ktorých sa systém nemôže bezpečne rozvíjať.
Až potom možno plánovať ďalšie kroky.
Niekedy to bude modernizácia.
Niekedy rozvoj.
Niekedy usporiadanie infraštruktúry.
Niekedy prevzatie údržby.
A niekedy jednoducho vytvorenie poriadnej mapy systému, ktorú si roky nikto nenašiel čas pripraviť.
Lebo zodpovedný software house by nemal budovať technológiu, ktorá funguje len vtedy, keď pri počítači sedí správny človek.
Systém by mal byť väčší než pamäť jednej osoby.
A biznis by mal mať istotu, že keď niekto odíde, technológia neodíde spolu s ním.
