Poctivou měsíční cenu údržby nelze určit, dokud není jasné, kdo za co odpovídá. Náklady závisí na stavu systému, použité technologii, infrastruktuře, počtu důležitých procesů a integrací, potřebném monitoringu, způsobu zálohování a nasazování, množství požadavků i dohodnutých hodinách reakce.
Smysluplný odhad odděluje čtyři skupiny nákladů: infrastrukturu a externí služby, stálou připravenost týmu, skutečně provedené práce a větší rozvoj. Teprve potom lze dvě nabídky srovnat podle stejného rozsahu.
Hosting je pouze jedna část nákladů
Server, doména a certifikát umožňují aplikaci fungovat, ale samy ji neudržují. Hosting automaticky nezjistí, že se zastavila úloha odesílající faktury, integrace přestala stahovat objednávky nebo databázovou zálohu nelze obnovit. Neaktualizuje ani kód a neopraví chybu po změně externího API, pokud taková odpovědnost nebyla výslovně dohodnuta.
Stejně je to se zálohami. Vytvořený soubor ještě nepotvrzuje, že obsahuje všechna potřebná data a že z něj lze obnovit funkční systém. Nabídka by měla určit rozsah zálohy, četnost, dobu uchování, místo uložení a způsob testování obnovy.
Z čeho se skládají náklady na údržbu?
| Skupina nákladů | Co může zahrnovat | Za co firma skutečně platí |
|---|---|---|
| Infrastruktura a externí služby | server nebo cloud, doménu, e-mail, SMS, platby, úložiště souborů, monitoring a externí API | zdroje a přístup ke službám, které aplikace potřebuje |
| Pravidelná péče a připravenost | přijímání upozornění a požadavků, kontrolu záloh, plánování aktualizací a odpovědnost v dohodnutých hodinách | dostupnost člověka, který zná dohodnutý rozsah a dokáže zahájit řešení problému |
| Práce prováděné v systému | diagnostiku, opravy, aktualizace, nasazení, konfiguraci a drobné změny | konkrétní práci zahrnutou v paušálu, limitu nebo samostatné objednávce |
| Větší rozvoj | nové moduly, migrace, modernizaci, přestavbu infrastruktury nebo obnovu po závažném incidentu | samostatný projekt, který by neměl být skrytý pod obecným pojmem „údržba“ |
Jedna nabídka může obsahovat pouze server a reakci na nahlášený problém. Jiná navíc zahrnuje monitoring důležitých procesů, kontrolu záloh, pravidelné aktualizace a dohodnutý limit práce. Samotné srovnání měsíčních částek proto může být zavádějící.
Co má na cenu největší vliv?
Význam systému pro firmu
Jiné nároky má informační web a jiné systém, který přijímá objednávky, rezervace nebo poskytuje zaměstnancům data po celý den. Čím větší jsou následky výpadku, tím důležitější je monitoring, jasný kanál pro hlášení a předem dohodnutý způsob reakce.
Stav kódu a technologie
Náklady rostou, pokud projekt používá nepodporované verze PHP, frameworku nebo knihoven, nemá testy nebo vyžaduje ruční nasazování bez bezpečné možnosti návratu. PHP zveřejňuje období podpory jednotlivých větví a Laravel má vlastní pravidla pro opravy a bezpečnostní aktualizace. Verze technologií je proto potřeba sledovat po celou dobu provozu.
Počet procesů a integrací
Kontrola domovské stránky neodhalí všechny chyby. Samostatný dohled mohou potřebovat fronty, plánované úlohy, platby, odesílání zpráv, importy, exporty a spojení s dalšími systémy. Každý proces přináší vlastní chybové situace a závislost na externím dodavateli.
Dokumentace a přístupy
Repozitář, popis infrastruktury, seznam služeb, postup nasazení a informace o zálohách zkracují diagnostiku. Pokud je předchozí dodavatel nepředal, prvním krokem může být uspořádání přístupů a kontrola stavu systému. Pomůže kontrolní seznam převzetí aplikace, ale nenahrazuje prověření kódu a serveru.
Požadované hodiny podpory a doba reakce
Připravenost má cenu i v měsíci bez poruchy. Kratší doba první reakce vyžaduje rezervovanou kapacitu a znalost konkrétního systému. Je také nutné odlišit zahájení řešení od dokončení opravy. Termín vyřešení lze často určit až po diagnostice.
Kdy stačí jednorázová práce?
Ne každá aplikace potřebuje měsíční paušál. Jednorázová zakázka může stačit, pokud systém nepodporuje kritický proces, firma přijme plánovaný termín a potřebuje konkrétní aktualizaci, konfiguraci nebo opravu. Monitoring, zálohy a komunikace s hostingem pak musí mít jiného vlastníka.
Pravidelná péče dává větší smysl, pokud se aplikace používá denně, průběžně se mění, má integrace nebo úlohy běžící na pozadí. Je užitečná také tehdy, když chce firma jedné straně přiřadit odpovědnost za upozornění, kontrolu záloh, plán aktualizací a řízené nasazování.
V Domin Software můžeme dohodnout jednorázové práce, pravidelnou péči nebo samostatně naceněnou variantu s dobou reakce. Vhodný model závisí na systému a následcích jeho nedostupnosti.
Proč SLA ovlivňuje cenu?
SLA nemá být neurčitým slibem rychlé pomoci. Musí uvádět zahrnuté aplikace a prostředí, dny a hodiny podpory, kanály pro hlášení, úrovně závažnosti, dobu první reakce a povinnosti obou stran.
Domin Software nezveřejňuje jedno SLA pro všechny zákazníky a neslibuje podporu 24/7. Standardně zpracováváme požadavky od neděle do pátku, od 8:00 do 17:00 v časovém pásmu Europe/Warsaw. V sobotu podporu neposkytujeme. O polských státních svátcích můžeme reagovat pouze na předem dohodnuté kritické události. Přesné podmínky začnou platit až po jejich uvedení v nabídce nebo smlouvě.
Nepřetržitý monitoring automaticky neznamená nepřetržitou reakci člověka. Může problém zjistit a uložit upozornění, ale termín řešení závisí na dohodnuté pohotovosti.
Jak porovnat dvě nabídky údržby?
| Otázka | Co by mělo být jasně uvedeno |
|---|---|
| Co je zahrnuto? | aplikace, prostředí, server, integrace a důležité procesy |
| Co se monitoruje? | konkrétní adresy, úlohy, fronty, integrace a příjemci upozornění |
| Jak se kontrolují zálohy? | rozsah, četnost, doba uchování, umístění a test obnovy |
| Kdy se řeší požadavky? | dny, hodiny, časové pásmo, kanály a pravidla eskalace |
| Co znamená doba reakce? | potvrzení, první posouzení a zahájení řešení, nikoli automaticky dokončenou opravu |
| Jak se provádějí změny? | testy, schválení, nasazení a možnost návratu |
| Co zahrnuje paušál? | připravenost, pojmenované povinnosti a případný limit práce |
| Co se platí zvlášť? | větší rozvoj, migrace, audity, obnova po útoku a práce mimo rozsah |
| Kdo vlastní účty? | klient by měl mít kontrolu nad hostingem, doménou, daty a platbami |
Pokud nabídka tyto informace neobsahuje, je vhodné je doplnit před porovnáním ceny. Nejnižší částka může znamenat nejmenší rozsah odpovědnosti. Vyšší cena sama o sobě také nedokazuje lepší ochranu. Rozhoduje písemný rozsah a způsob kontroly služby.
Co připravit pro nacenění péče?
Na začátku stačí popis účelu aplikace a nejdůležitějších procesů. Užitečné jsou také:
- technologie a verze, pokud jsou známé;
- seznam prostředí, integrací, úloh na pozadí a externích služeb;
- informace o repozitáři, dokumentaci, testech a způsobu nasazení;
- současný rozsah monitoringu a záloh;
- následky výpadku a přijatelné hodiny podpory;
- typické požadavky a očekávaný rozsah drobných změn;
- informace o vlastnictví účtů a schvalování nasazení.
Do kontaktního formuláře neposílejte hesla, klíče, databáze ani údaje klientů. V prvním kroku potřebujeme popis situace, nikoli přístup do produkce.
Plánovač správy aplikace pomůže informace shromáždit a vytvoří pracovní souhrn. Výsledek není automatickou cenovou nabídkou ani smlouvou SLA.
Co ukazují naše předchozí projekty?
Vývoj systému 44Islands neskončil prvním nasazením. Další etapy rozšířily správu rezervací, role uživatelů a přímý prodej. Tento příklad ukazuje, že péče o fungující aplikaci může zahrnovat stávající rozsah i samostatně dohodnutý rozvoj.
Historická péče o tři obchody PrestaShop 1.6 zahrnovala konfiguraci VPS a prostředí, domén, Apache a PHP, instalaci modulů a úpravy výkonu i šablon. Trvala přibližně rok. Obchody již nejsou v produkci, takže tento příklad potvrzuje druh prováděných prací, nikoli jejich současný stav nebo cenu nové služby.
V obou případech vycházel rozsah z konkrétního systému. Předchozí realizace nejsou hotovým ceníkem pro dalšího klienta.
Nejčastější otázky
Zahrnuje hosting údržbu aplikace?
Ne, pokud nabídka obě služby výslovně nespojuje a nepopisuje odpovědnost. Hosting poskytuje zdroje, zatímco údržba může zahrnovat monitoring procesů, zálohy, aktualizace, diagnostiku, nasazování a řešení požadavků.
Obsahuje pravidelná péče vždy určitý počet hodin programátora?
Nemusí. Poplatek může zahrnovat připravenost a konkrétní povinnosti, případně také limit práce. Smlouva by měla uvést, co se stane po vyčerpání limitu a které úkoly jsou samostatným projektem.
Stačí vytvořit zálohu?
Ne. Je potřeba vědět, co záloha obsahuje, kde je uložena, jak dlouho se uchovává a zda z ní lze obnovit funkční systém. Test obnovy by měl mít dohodnutý rozsah a četnost.
Lze určit cenu bez přístupu ke kódu?
Bez přístupu lze předběžně určit model spolupráce a informace potřebné pro nabídku. Přesná odpovědnost za existující systém však může vyžadovat placené prověření kódu, infrastruktury, verzí a nasazování.
Znamená monitoring reakci 24/7?
Ne. Monitoring může běžet stále, ale upozornění se řeší v hodinách uvedených ve smlouvě. Pohotovost mimo standardní časy vyžaduje samostatnou dohodu.
Patří vývoj nových funkcí do údržby?
Drobné změny se mohou vejít do dohodnutého limitu. Větší moduly, migrace a modernizace by měly mít vlastní rozsah, kritéria převzetí a cenu.
Zvolte další krok
Pokud si potřebujete nejprve uspořádat požadavky, použijte plánovač správy aplikace. Shromažďuje informace o systému, zálohách, monitoringu, požadavcích a očekávaném modelu spolupráce, ale data automaticky neodesílá a nevytváří cenovou nabídku.
Pokud je rozsah již známý, podívejte se na správu aplikací a e-shopů. Popište účel systému, nejdůležitější procesy, následky výpadku a očekávané hodiny podpory. Na tomto základě určíme, zda je vhodná jednorázová práce, pravidelná péče nebo samostatně dohodnutá varianta SLA.
Zdroje
- PHP Supported Versions, přístup ověřen 28. 10. 2026.
- Laravel Release Notes and Support Policy, přístup ověřen 28. 10. 2026.
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning, přístup ověřen 28. 10. 2026.
- OWASP A06:2021, Vulnerable and Outdated Components, přístup ověřen 28. 10. 2026.