---
title: "Co naprawdę znaczy SLA na otwartym stacku"
url: "https://kybertis.com/pl/blog/co-znaczy-sla-na-otwartym-stacku"
description: "Umowa wsparcia na oprogramowanie, którego dostawca nie jest właścicielem, to inna obietnica. Oto co można w niej uczciwie zadeklarować, a czego nie."
---

# Co naprawdę znaczy SLA na otwartym stacku

20 sierpnia 2026·2 min czytania·Redakcja

Podręczne urządzenie dyżurne obok zaokrąglonej klepsydry, w której przesypała się połowa piasku

Umowa wsparcia na oprogramowanie, które dostawca sam napisał, to prosta obietnica: kod jest jego, więc może naprawić wszystko. Umowa na oprogramowanie open source to obietnica innego rodzaju, a udawanie, że jest inaczej, to najczęstsza nieuczciwość w tej branży. Użyteczna wersja zaczyna się od jasnego rozdzielenia tego, co da się zadeklarować, od tego, czego się nie da.

## Co można uczciwie obiecać

**Czas reakcji.** Kompetentna osoba patrzy na Twój problem w zdefiniowanym oknie, zależnym od priorytetu. To leży całkowicie po stronie dostawcy i to jest rdzeń tego, co kupujesz.

**Diagnoza.** Informacja, co jest nie tak — czy to Twoja konfiguracja, Twoja infrastruktura, czy oprogramowanie — i jakie są opcje. W praktyce to większość wartości: większość incydentów to konfiguracja albo środowisko, a wiedza o tym w ciągu godziny powstrzymuje zły dzień przed staniem się złym tygodniem.

**Obejście.** Przywrócenie działania, co zwykle nie jest tym samym co usunięcie przyczyny. Wycofanie zmiany, przekonfigurowanie, dołożenie mocy, czasowe przełączenie na inną ścieżkę.

**Poprawka albo upstream.** Tam, gdzie defekt jest w oprogramowaniu — albo łatamy go dla Ciebie, albo niesiemy zmianę do projektu. Obie rzeczy to realna praca i obie da się zadeklarować.

## Czego nie można uczciwie obiecać

**Naprawy w konkretnym czasie, dla dowolnego błędu.** Nikt nie może tego obiecać — nawet dostawca będący właścicielem kodu, choć on chętniej to zasugeruje. Obiecać można wysiłek, eskalację i obejście, a dostawca deklarujący więcej albo jest niedoświadczony, albo liczy na to, że nie przeczytasz wyłączeń.

**Przyjęcia zmiany w upstreamie.** Patch zaniesiony do projektu może zostać odrzucony, przeprojektowany albo leżeć rok. Zobowiązaniem może być utrzymywanie go dla Ciebie w międzyczasie, a nie kontrola nad społecznością, której nie prowadzisz.

**Zachowania modelu.** Szczególnie istotne tutaj. „Prognoza wyglądała źle” nie jest defektem, dopóki nie zostanie scharakteryzowana, a proces zamiany tego w defekt wygląda inaczej niż przy awarii. To powinno być w umowie wprost, a nie odkrywane przy pierwszym sporze.

## Części, których nikt nie czyta, a mają największe znaczenie

**Definicje priorytetów.** Czyja definicja słowa „krytyczny”? Jeśli priorytet nadaje dostawca, każdy incydent jest negocjacją. Zapisz kryteria w kategoriach wpływu na biznes — magazyn stoi, zamknięcie miesiąca się nie kończy — a spór znika.

**Zegar.** Kiedy zaczyna biec czas reakcji: gdy wysyłasz maila, gdy człowiek go czyta, czy gdy zgłoszenie zostaje przypisane? Czy biegnie w nocy? Drobny druk o dużych konsekwencjach.

**Granice zakresu.** Które komponenty, które wersje, które integracje. Umowa obejmująca stack, ale nie integrację z Twoim ERP, obejmuje akurat tę część, która rzadko się psuje.

**Eskalacja.** Do kogo docierasz, gdy pierwsza reakcja nie działa, i jak szybko. Osoba z imienia bije kolejkę, a kolejka bije formularz.

## Dlaczego klauzula wyjścia należy do tej samej rozmowy

Niewygodna prawda o umowach wsparcia jest taka, że dostawca ma interes w tym, żebyś go dalej potrzebował. Przy oprogramowaniu zamkniętym masz mały wybór. Przy open source masz — i liczy się to tylko wtedy, gdy praktyczne wyjście naprawdę istnieje.

Umowa powinna więc mówić, co się dzieje przy odejściu: konfiguracja przekazana w używalnej formie, dokumentacja tego, co i dlaczego zmieniono, zdefiniowany okres przejściowy. Ustalone na starcie, kiedy masz siłę negocjacyjną.

Dostawca, który nie chce tego zapisać, właśnie powiedział Ci, na czym opiera swoją retencję.

-   SLA
-   wsparcie
-   umowy
-   open source

## Czytaj dalej

-   [Jak wygląda wdrożenie Kyber krok po kroku](https://kybertis.com/pl/blog/jak-wyglada-wdrozenie-kyber)
-   [Kiedy firma powinna pożyczać moc z KyberFusion, a kiedy nie](https://kybertis.com/pl/blog/kiedy-pozyczac-moc-z-kyberfusion)