Technický audit firemní aplikace není soutěž o nejhezčí zdrojový kód. Je to podklad pro rozhodnutí, zda systém opravit, stabilizovat, modernizovat po částech, nebo postupně nahradit.
Kvalitní audit musí posoudit nejen samotnou aplikaci, ale také databázi, integrace, infrastrukturu, bezpečnost, nasazování změn a způsob dlouhodobé správy. Výsledkem nemá být dlouhý seznam technických nedostatků. Vedení firmy potřebuje pochopit, která rizika ohrožují provoz, co musí tým řešit okamžitě a do čeho má smysl investovat později.
V článku vysvětlujeme, kdy se technický audit vyplatí, jaké oblasti musí pokrýt a jaký výstup by měla firma požadovat.
Anonymizovaný příklad z praxe: Firma XY původně plánovala kompletní přepis. Audit ale ukázal, že hlavní problém způsobovala jedna integrace, pomalé databázové dotazy a chybějící testy. Stabilizace těchto oblastí umožnila odložit přepis a bezpečně pokračovat v postupné modernizaci.
Obsah článku
Kdy se technický audit vyplatí
Co technický audit není
Co musí audit obsahovat
Jak audit probíhá
Jaké podklady připravit
Jaký výstup požadovat
Jak poznat kvalitní audit
Co může následovat
Kdy se technický audit firemní aplikace vyplatí
Audit dává největší smysl ve chvíli, kdy firma potřebuje udělat technické nebo investiční rozhodnutí, ale nemá dostatek spolehlivých informací o současném stavu systému.
Typickým důvodem není pouze stáří aplikace. Rozhodující je dopad na provoz, náklady, bezpečnost a schopnost systému podporovat další rozvoj firmy.
Původní dodavatel už systém nerozvíjí
Firma potřebuje předat aplikaci novému týmu, ale neví, v jakém stavu ji přebírá. Chybí dokumentace, nikdo nezná všechny závislosti a běžná změna může ovlivnit několik dalších částí systému.
Audit v takové situaci zmapuje architekturu, data, integrace, infrastrukturu i provozní postupy. Nový tým pak nezačíná naslepo a vedení firmy získá realistickou představu o rizicích převzetí.
Znalosti drží jeden člověk
Systém může fungovat spolehlivě, dokud se o něj stará původní vývojář nebo dlouholetý administrátor. Jakmile tento člověk odejde, firma zjistí, že nezná přístupy, způsob nasazování, závislosti ani postup obnovy po výpadku.
Technický audit odhalí, kde firma závisí na jednotlivci, a navrhne, jak znalosti převést do dokumentace, automatizace a sdílené odpovědnosti.
Každá změna trvá příliš dlouho
Dlouhá doba vývoje nemusí automaticky znamenat, že firma musí systém přepsat. Příčinou mohou být chybějící testy, složitá architektura, ruční nasazování, nejasné zadání nebo nekvalitní datové vazby.
Audit oddělí technické příčiny od organizačních a ukáže, které změny mohou vývoj skutečně zrychlit.
Firma plánuje větší modernizaci nebo přepis
Před velkou investicí potřebuje vedení vědět, co lze zachovat a co už další rozvoj omezuje. Bez tohoto posouzení může firma přepsat i části, které fungují dobře, nebo naopak ponechat komponenty, které budou nový systém dál brzdit.
Než schválíte kompletní přepis, projděte si také 12 otázek před přepisem firemního systému.
Aplikace je pomalá nebo nestabilní
Pomalá odezva může vznikat v aplikaci, databázi, infrastruktuře nebo externí integraci. Stejně tak výpadek nemusí způsobovat chyba v kódu, ale nedostatek prostředků, špatná konfigurace nebo chybějící řízení front a časových limitů.
Audit musí příčinu ověřit měřením, logy a analýzou provozu. Pouhý dojem uživatelů nestačí.
Firma chce nezávisle ověřit práci dodavatele
Vedení firmy může potřebovat druhý odborný pohled před prodloužením smlouvy, investicí nebo převzetím systému. Nezávislý audit pomůže ověřit kvalitu technického řešení, stav dokumentace, provozní rizika i dlouhodobou udržitelnost.
Co technický audit není
Technický audit není automatický výpis chyb z analytického nástroje. Nástroje mohou upozornit na duplicity, zranitelné knihovny nebo složitý kód, ale samy neurčí dopad na provoz firmy.
Audit také není hodnocení jednotlivých programátorů. Jeho cílem je posoudit systém, procesy a rizika, ne hledat viníka za rozhodnutí, která často vznikala postupně během mnoha let.
Kvalitní auditor automaticky nedoporučí kompletní přepis. Nejprve ověří, zda firma může problém odstranit stabilizací, úpravou konkrétní části nebo postupnou modernizací.
Audit nemá skončit dlouhým seznamem nálezů bez priorit. Pokud vedení neví, co musí řešit nyní, co může odložit a jaký první krok dává smysl, audit nesplnil svůj účel.
Co musí technický audit firemní aplikace obsahovat
Rozsah auditu se vždy přizpůsobuje konkrétnímu systému a cíli firmy. U firemní aplikace by ale měl zahrnout následující oblasti.
Architektura systému
Auditor zmapuje hlavní části aplikace, jejich odpovědnosti a vzájemné závislosti. Prověří, zda architektura odpovídá současnému provozu a plánovanému rozvoji.
Důležité je zjistit, kde jedna změna ovlivňuje celý systém, které komponenty lze rozvíjet samostatně a kde vznikají kritická místa nebo zbytečně složité vazby.
Výstup nemá obsahovat pouze diagram. Musí vysvětlit, jak architektura ovlivňuje rychlost změn, stabilitu a budoucí náklady.
Kvalita zdrojového kódu
Auditor prověří strukturu projektu, čitelnost, duplicity, technický dluh, správu závislostí, práci s chybovými stavy a kvalitu dokumentace.
Nejde o to označit každý starší postup za chybu. Důležité je najít místa, kde změny představují vysoké riziko, kde tým opakovaně opravuje stejné problémy nebo kde kód brání bezpečnému rozvoji.
Automatické testy
Samotná existence testů nestačí. Auditor musí ověřit, které důležité procesy testy chrání, zda se spouštějí automaticky a zda jejich výsledkům tým důvěřuje.
Zvláštní pozornost si zaslouží fakturace, oprávnění, objednávky, synchronizace dat a další procesy, jejichž chyba může mít finanční nebo provozní dopad.
Databáze a výkon
Audit databáze zahrnuje datový model, indexy, pomalé dotazy, blokování, růst objemu dat, archivaci, zálohování a rizika budoucí migrace.
Auditor by měl pracovat s reálnými provozními daty, statistikami a plány dotazů. Teprve potom může určit, zda problém způsobuje databázový návrh, aplikace nebo nedostatečná infrastruktura.
Bezpečnost a oprávnění
Bezpečnostní část musí prověřit autentizaci, uživatelské role, přístupová práva, správu citlivých údajů, tajné klíče, zranitelné závislosti a dohledatelnost důležitých operací.
Auditor má posoudit také proces aktualizací a reakce na bezpečnostní incidenty. I dobře navržený systém představuje riziko, pokud ho nikdo pravidelně neaktualizuje. Pokud audit souvisí s regulovanou službou, je nutné zohlednit také požadavky NIS2 na aplikace, infrastrukturu a incidentní procesy.
Infrastruktura a provoz
Audit prověří hosting nebo cloud, konfiguraci jednotlivých prostředí, škálování, dostupnost, zálohy, obnovu po havárii, monitoring a logování.
Firma musí vědět, jak rychle tým zjistí výpadek, kde najde příčinu a jak obnoví provoz. Záloha bez pravidelně ověřené obnovy nepředstavuje spolehlivý plán.
Nasazování změn
Auditor zjistí, jak tým sestavuje, testuje a nasazuje nové verze. Prověří automatizaci, oddělení vývojového, testovacího a produkčního prostředí i možnost návratu k předchozí verzi.
Ruční kroky zvyšují riziko chyby a často vytvářejí závislost na jednom člověku. Audit proto musí popsat, které části procesu lze bezpečně automatizovat.
Integrace a datové toky
Firemní aplikace obvykle komunikuje s ERP, CRM, účetnictvím, skladem, e-shopem, výrobními zařízeními nebo externími službami.
Auditor musí zmapovat API, importy, exporty, automatické úlohy, chybové stavy a odpovědnost za jednotlivá napojení. Prověří také duplicity dat, ruční zásahy a situace, kdy si systémy předávají rozdílné informace.
Jak technický audit probíhá
Kvalitní audit začíná stanovením cíle. Jinak bude auditor postupovat před převzetím aplikace, jinak před investicí do modernizace a jinak při řešení bezpečnostních nebo výkonnostních problémů.
Obvyklý postup zahrnuje:
- Stanovení cíle, rozsahu a hlavních otázek auditu.
- Převzetí dostupné dokumentace a potřebných přístupů.
- Rozhovory s vedením, uživateli a technickým týmem.
- Analýzu zdrojového kódu, databáze, infrastruktury a integrací.
- Ověření provozních, výkonnostních a bezpečnostních rizik.
- Seřazení zjištění podle dopadu a naléhavosti.
- Předání zprávy a prezentaci doporučeného postupu.
Auditor nemůže posoudit podnikový systém pouze pohledem do repozitáře. Musí znát jeho provozní význam, uživatele, kritické procesy a důsledky případného výpadku.
Jaké podklady musí firma připravit
Firma by měla podle rozsahu auditu připravit zejména:
- přístup ke zdrojovému kódu,
- přehled vývojového, testovacího a produkčního prostředí,
- databázové schéma nebo řízený přístup k databázi,
- seznam integrací a datových toků,
- dostupnou technickou a provozní dokumentaci,
- přístup k logům a monitoringu,
- popis procesu nasazování,
- přehled známých problémů a incidentů,
- kontakty na technické a provozní vlastníky systému.
Chybějící dokumentace audit neznemožňuje. Její absence sama představuje důležité zjištění. Auditor však bude muset část informací znovu získat z kódu, konfigurace a rozhovorů, což může audit prodloužit.
Jaký výstup musí firma dostat
Vedení firmy potřebuje výstup, podle kterého může rozhodnout o dalším postupu. Technická zpráva proto musí být srozumitelná nejen vývojářům.
Kvalitní výstup by měl obsahovat:
- popis současného stavu systému,
- hlavní technická, provozní a bezpečnostní rizika,
- vysvětlení jejich dopadu na firmu,
- priority podle závažnosti a naléhavosti,
- rychlé stabilizační kroky,
- návrh postupné modernizace,
- doporučení, co zachovat a co nahradit,
- návrh první realistické etapy,
- rámcový odhad náročnosti dalšího postupu.
Audit, který pouze označí problémy, ale neurčí jejich prioritu, dopad a doporučené řešení, neposkytuje vedení dostatečný podklad pro rozhodnutí.
Jak poznat kvalitní technický audit
Před objednáním auditu si ověřte, zda dodavatel:
- propojuje technické nálezy s provozními a obchodními dopady,
- řadí rizika podle závažnosti,
- odděluje rychlé opravy od dlouhodobé modernizace,
- vysvětluje závěry srozumitelně vedení firmy,
- posuzuje také databázi, infrastrukturu a integrace,
- navrhuje konkrétní první etapu,
- zohledňuje dostupný rozpočet a provozní omezení,
- nenavrhuje automaticky kompletní přepis.
Dobrý audit musí být dostatečně konkrétní, aby podle něj mohl pracovat i jiný technický tým. Firma by neměla zůstat závislá na auditorovi jen proto, aby pochopila jeho vlastní zprávu.
Co může následovat po auditu
Technický audit není cílový stav. Je to podklad pro rozhodnutí.
Podle výsledku může firma:
- odstranit kritická provozní nebo bezpečnostní rizika,
- doplnit monitoring, zálohy a dokumentaci,
- stabilizovat databázi nebo infrastrukturu,
- nahradit problémovou integraci,
- modernizovat vybrané části systému,
- připravit postupný přepis,
- zavést dlouhodobou technickou správu.
Firma nemusí realizovat všechna doporučení najednou. Smyslem priorit je začít krokem, který přinese největší snížení rizika nebo nejrychlejší provozní přínos.
Jak s technickým auditem pomáhá GoveSoft
GoveSoft prověřuje firemní aplikace, které se obtížně rozvíjejí, chybí jim dokumentace nebo zůstaly závislé na původním dodavateli.
Audit zaměřujeme na konkrétní rozhodnutí. Posoudíme architekturu, zdrojový kód, databázi, bezpečnost, infrastrukturu, integrace i proces nasazování. Zjištění seřadíme podle jejich dopadu a navrhneme první realistickou etapu.
Výsledkem nemá být automatické doporučení kompletního přepisu. Cílem je zjistit, co firma musí stabilizovat, co může zachovat a kde modernizace přinese skutečný provozní nebo obchodní přínos.
Potřebujete zjistit skutečný stav aplikace před převzetím, modernizací nebo větší investicí? Podívejte se, co prověřujeme při technickém auditu a jaký výstup dostanete.