Polityka poziomu usług i utrzymania Vis-Sol.
Publiczne zasady dla stron, aplikacji, automatyzacji, Narzędziowni, VSA, Concept i utrzymania. Parametry indywidualnej usługi mogą być wyższe, jeżeli zostały uzgodnione w ofercie lub umowie.
1. Zasada działania
Publiczna polityka Vis-Sol nie deklaruje obsługi 24/7. Zgłoszenia mogą być przesyłane w dowolnym czasie, natomiast publiczne cele reakcji są liczone w dniach roboczych w Polsce.
Szybszy czas reakcji, dyżur awaryjny, konkretne RPO/RTO lub gwarantowany poziom dostępności mogą zostać ustalone indywidualnie dla konkretnej usługi produkcyjnej.
2. Zakres
Polityka obejmuje strony i serwisy WWW, aplikacje, CRM/WMS, panele i systemy B2B, automatyzacje, integracje i API, audyty, Narzędziownię Vis-Sol, VSA, Concept / Concept Core, support, monitoring, backup, wdrożenia dedykowane i R&D.
3. Klasy usług
S1 — produkcja zarządzana
System aktywnie używany w działalności klienta i objęty uzgodnionym utrzymaniem. Może posiadać indywidualne parametry dostępności, czasu reakcji, monitoringu, backupu i odtworzenia.
S2 — produkcja bez stałego utrzymania
Rozwiązanie działa produkcyjnie, ale nie jest objęte ciągłym monitoringiem ani stałą umową utrzymaniową. Reakcja następuje po zgłoszeniu i zgodnie z aktualnym zakresem zlecenia.
S3 — narzędzie publiczne / utility
Kalkulatory, analizatory, generatory, AutoAudit, Knowledge Scan i pozostała Narzędziownia. Domyślnie działają w modelu best effort i nie są systemem krytycznym klienta.
S4 — Pilot / beta / Concept / R&D
Prototypy, demonstratory, Concept Core, sandboxy i funkcje eksperymentalne. Domyślnie nie posiadają gwarancji ciągłej dostępności ani trwałości środowiska, dopóki konkretna funkcja nie zostanie formalnie przeniesiona do produkcji.
4. Priorytety i cele pierwszej reakcji
P1 — krytyczny: do 1 dnia roboczego
Przykładowo: brak kluczowej usługi produkcyjnej, istotny incydent bezpieczeństwa, utrata integralności lub dostępności danych albo brak obejścia kluczowego procesu.
P2 — wysoki: do 2 dni roboczych
Istotna funkcja produkcyjna nie działa albo znacząca część procesu jest zaburzona, ale istnieje obejście.
P3 — standardowy: do 3 dni roboczych
Błąd funkcji, wydajności, konfiguracji lub interfejsu, który nie blokuje podstawowego procesu.
P4 — rozwój: do 5 dni roboczych lub termin uzgodniony
Zmiana treści, optymalizacja, nowa funkcja, usprawnienie lub praca planowana.
Czas reakcji oznacza rozpoczęcie analizy i potwierdzenie przyjęcia zgłoszenia. Nie jest gwarantowanym czasem pełnego usunięcia awarii.
5. Granice odpowiedzialności
Vis-Sol odpowiada za elementy pozostające pod jego techniczną kontrolą i objęte zakresem usługi. Poza bezpośrednią kontrolą mogą pozostawać m.in. hosting lub infrastruktura klienta, domena i DNS, operator poczty, zewnętrzne API, zewnętrzne usługi AI lub obliczeniowe, systemy klienta, łącza oraz urządzenia użytkownika.
Awaria zależności zewnętrznej nie jest automatycznie naruszeniem dostępności Vis-Sol. Jeżeli usługa jest objęta utrzymaniem, Vis-Sol podejmuje diagnostykę i działania możliwe w ramach swojej kontroli.
6. Dostępność i uptime
Vis-Sol nie publikuje jednego współczynnika dostępności dla całego ekosystemu. Uptime staje się parametrem wiążącym wyłącznie dla konkretnej usługi S1, jeżeli określono sposób i punkt pomiaru, wyłączenia, okres rozliczeniowy oraz zakres odpowiedzialności.
S3 i S4 nie posiadają gwarantowanego uptime, jeżeli nie wskazano inaczej.
7. Planowane prace
Dla S1 przewidywalne prace powodujące istotną niedostępność są, gdy jest to praktycznie możliwe, komunikowane co najmniej 2 dni robocze wcześniej. Awaryjne poprawki bezpieczeństwa mogą być wykonywane bez standardowego wyprzedzenia, jeżeli zwłoka zwiększa ryzyko.
8. Monitoring
Zakres monitoringu może obejmować endpointy, kody odpowiedzi, stan procesów, zasoby, kolejki, logi błędów, certyfikaty, integracje, backup i wybrane wskaźniki aplikacyjne. Monitoring 24/7 nie jest elementem każdej usługi i musi wynikać z konkretnego zakresu S1.
9. Backup i odtwarzanie
Dla S1 dokumentacja lub umowa powinna określać zakres backupu, częstotliwość, retencję, miejsce przechowywania, test odtworzeniowy oraz RPO/RTO, jeżeli są wymagane. S3 i S4 mogą nie posiadać backupu, jeżeli charakter narzędzia lub środowiska tego nie wymaga.
10. Bezpieczeństwo
W przypadku podejrzenia incydentu Vis-Sol może ograniczyć dostęp, wyłączyć funkcję lub integrację, zresetować poświadczenia, odizolować środowisko, zabezpieczyć logi i rozpocząć procedurę diagnostyczną.
11. VSA
VSA obejmuje m.in. Pilot, Instance, Connect, Care, moduły i integracje. Dostępność zewnętrznego modelu AI nie jest równoznaczna z dostępnością całej warstwy VSA. Parametry produkcyjnej instancji są ustalane indywidualnie.
12. Narzędziownia
Narzędziownia jest domyślnie klasą S3, chyba że konkretne narzędzie zostało częścią indywidualnego procesu produkcyjnego lub płatnej usługi.
13. Concept / Concept Core
Concept i funkcje eksperymentalne są domyślnie S4. Przejście konkretnej funkcji do S1 wymaga określenia celu produkcyjnego, danych i odpowiedzialności, testów, bezpieczeństwa, monitoringu, procedury rollback/odtworzenia oraz zasad wsparcia.
14. Zgłaszanie problemu
Zgłoszenie powinno — jeżeli to możliwe — zawierać nazwę systemu, opis problemu, czas zauważenia, wpływ na użytkowników lub proces, komunikat błędu i informację o istniejącym obejściu.
15. Wyłączenia
Publiczne cele SLA nie obejmują, o ile nie uzgodniono inaczej: planowanych prac, siły wyższej, awarii dostawcy poza kontrolą Vis-Sol, zmian wykonanych przez klienta lub osobę trzecią bez uzgodnienia, przekroczenia uzgodnionych limitów, błędnych danych wejściowych oraz używania S3/S4 jako systemu produkcyjnego wbrew jego przeznaczeniu.
16. Indywidualne SLA
Oferta, zamówienie lub umowa może określać krótsze czasy reakcji, uptime, rozszerzone godziny wsparcia, RPO/RTO, kanał awaryjny i zasady eskalacji. W razie sprzeczności wiążące ustalenia indywidualne mają pierwszeństwo.
17. Rozwój dokumentu
Nowe systemy i moduły są przypisywane do klas S1–S4 albo powodują rozszerzenie niniejszej polityki. Vis-Sol nie tworzy osobnego publicznego SLA dla każdego kolejnego narzędzia, chyba że charakter lub kontrakt konkretnej usługi tego wymaga.
Service Level Policy 1.0 · 19 sierpnia 2026 r.