Przejdź do treści
Codivine
Biznes

Ile kosztuje utrzymanie strony i oprogramowania?

Co dokładnie składa się na utrzymanie strony lub systemu, dlaczego oszczędzanie na nim jest droższe niż sam koszt i jak zaplanować ten budżet, zanim coś się zepsuje.

Oskar Szymczak4 min czytania

Prawie każde zapytanie, które do nas trafia, zawiera budżet na zbudowanie czegoś. Rzadko zawiera budżet na utrzymanie tego w działaniu. To jest powód, dla którego firmy co kilka lat płacą za tę samą stronę albo ten sam system od nowa.

Utrzymanie nie jest opłatą za czekanie, aż coś się zepsuje. To praca, która sprawia, że działające oprogramowanie dalej działa w świecie, który się pod nim zmienia.

Z czego naprawdę składa się utrzymanie

Aktualizacje zależności i platformy

Twoja strona albo aplikacja stoi na cudzym kodzie: frameworku, bibliotekach, środowisku uruchomieniowym, systemie płatności, bramce mailowej. Te rzeczy wydają nowe wersje, wycofują stare i łatają luki bezpieczeństwa — niezależnie od tego, czy masz na to czas.

Aktualizowane po trochu, regularnie, to godziny. Odłożone na trzy lata zamieniają się w projekt: wersja, z której korzystasz, nie jest już wspierana, a przeskok do obecnej to kilka wersji głównych naraz, każda z własnymi zmianami łamiącymi zgodność.

Bezpieczeństwo

Zgłoszone luki w popularnych paczkach są publiczne — automaty skanują internet w ich poszukiwaniu w ciągu dni od ujawnienia. Utrzymanie to jest moment, w którym ktoś faktycznie te zgłoszenia czyta i decyduje, które Cię dotyczą.

Do tego dochodzi rotacja kluczy i tokenów, przeglądy dostępów po odejściu pracownika oraz sprawdzanie, czy kopie zapasowe naprawdę się odtwarzają. Kopia, której nikt nigdy nie przywrócił, to nie kopia — to założenie.

Monitoring i reagowanie

Ktoś musi wiedzieć, że coś padło, zanim powie Ci o tym klient. To znaczy: alerty o niedostępności, zbieranie błędów, logi, limity u dostawców i ktoś po drugiej stronie tych alertów.

Drobne zmiany, których nikt nie nazywa projektem

Nowa cena, nowy formularz, zmiana w regulaminie, dodanie pracownika do CRM-a, poprawka treści, nowy raport dla księgowości. Pojedynczo trwają minuty. Przez rok to realna pozycja — i to one decydują, czy system nadąża za firmą, czy zaczyna ją hamować.

Dryf integracji

Jeśli coś jest podłączone do czegoś innego — a dzisiaj prawie wszystko jest — to drugie coś będzie się zmieniać. API dostają nowe wersje, stare są wyłączane, dostawcy zmieniają format danych albo limity zapytań. Twoja integracja nie zepsuła się „sama”: zepsuła się, bo świat po drugiej stronie poszedł dalej. Pilnowanie tego jest częścią pracy przy integracjach.

Hosting i usługi

Serwer, baza, CDN, domena, certyfikaty, poczta transakcyjna, narzędzia analityczne, licencje. To jedyna część, którą większość firm rzeczywiście ma w budżecie — i zwykle najmniejsza.

Dlaczego to nie jest pozycja, na której się oszczędza

Kosztu utrzymania nie da się nie ponieść. Da się go tylko odłożyć — i wtedy rośnie:

  • Odłożone aktualizacje zamieniają się w migrację, która kosztuje kilkukrotnie więcej niż suma pominiętych aktualizacji.
  • Odłożone bezpieczeństwo kosztuje dokładnie zero, dopóki nie kosztuje bardzo dużo, zwykle razem z obowiązkiem zgłoszenia naruszenia danych.
  • Odłożone drobne zmiany uczą zespół, że „strony nie da się zmienić”, więc pojawia się arkusz kalkulacyjny obok systemu. Potem drugi. To jest początek sytuacji, w której firma ma dane w pięciu miejscach i żadnego z nich nie traktuje poważnie.
  • Odłożona wiedza. Po dwóch latach bez kontaktu nikt już nie pamięta, dlaczego ten fragment wygląda tak dziwnie. Pierwsza zmiana po długiej przerwie jest droga, bo zaczyna się od czytania własnej historii.

Najdroższy wariant jest zawsze ten sam: system działa bez opieki tak długo, aż tanie zmiany stają się niemożliwe, i wtedy jedyną ofertą, jaką ktokolwiek chce złożyć, jest „zbudujmy to od nowa”. Czasem przepisanie faktycznie ma sens, ale rzadko dlatego, że to była najtańsza droga.

Jak to zaplanować

Nie musisz zgadywać. Wystarczą trzy ustalenia przed startem projektu, a nie po nim.

1. Ustal, co jest objęte, a co jest nowym zakresem. Granica jest prosta i warto ją zapisać: utrzymanie to „to, co działało, dalej działa”. Nowa funkcja to nowy zakres. Bez tej granicy każda rozmowa o rachunku jest negocjacją.

2. Ustal czas reakcji, a nie tylko liczbę godzin. „Osiem godzin miesięcznie” niewiele znaczy, jeśli sklep stoi w piątek wieczorem. Sensowna umowa mówi, w jakim czasie ktoś odpowiada na awarię, a w jakim na zwykłe zgłoszenie — i czym jedno różni się od drugiego.

3. Ustal, czyje są dostępy. Repozytorium, hosting, domena, konta u dostawców, klucze API. Powinny należeć do Twojej firmy, a wykonawca powinien mieć do nich dostęp — nie odwrotnie. To jedno zdanie w umowie decyduje o tym, czy za dwa lata masz wybór.

Rozsądny punkt wyjścia do budżetowania: zarezerwuj roczną kwotę rzędu kilkunastu do dwudziestu kilku procent kosztu wdrożenia na utrzymanie i drobny rozwój. Na prostej stronie firmowej będzie to mniej, przy systemie z integracjami i płatnościami — więcej. To nie jest wycena, to pozycja w planie, która sprawia, że nie zostaniesz zaskoczony.

Co z tym zrobić, jeśli masz już coś, czego nikt nie pilnuje

Zacznij od inwentaryzacji, nie od przebudowy. Spisz: co stoi na czym, kto ma dostępy, kiedy ostatnio była aktualizacja, czy kopie się odtwarzają, co się stanie, jeśli jutro padnie. Zwykle wychodzi z tego krótka lista rzeczy pilnych i dużo dłuższa lista rzeczy, które mogą poczekać — i to jest dobra wiadomość, bo oznacza, że da się to prowadzić etapami.

Taki przegląd robimy też jako osobną, małą pracę — bez zobowiązania, że cokolwiek potem budujemy. Jeśli nie wiesz, w jakim stanie jest Twoje oprogramowanie, napisz do nas i przejdziemy to z Tobą.

Oskar Szymczak

Założyciel i inżynier oprogramowania

Odpowiada za techniczną stronę każdego projektu — architekturę, programowanie i decyzje, które później drogo zmieniać.

Więcej o zespole

Potrzebujesz w tym pomocy?

To jest praca, którą wykonujemy. Te strony wyjaśniają, jak do niej podchodzimy.

Masz podobny problem?

Opisz go własnymi słowami. Powiemy, co byśmy z nim zrobili — i czy w ogóle warto się tym zajmować.

Nie potrzebujesz specyfikacji. Opis problemu wystarczy, żeby zacząć.