SLA i bezpieczeństwo
Transparentne zasady reagowania na incydenty i praktyki zabezpieczania aplikacji
SLA reakcji i napraw
Czasy reakcji na zgłoszenia w zależności od priorytetu
Poniższa tabela pokazuje maksymalne czasy reakcji i naprawy dla różnych poziomów priorytetów incydentów. Priorytety ustalane są wspólnie z klientem na podstawie wpływu na biznes.
| Priorytet | Definicja | Czas reakcji | Cel naprawy |
|---|---|---|---|
| Krytyczny | Aplikacja nie działa lub jest niedostępna dla użytkowników. Utrata danych. Zagrożenie bezpieczeństwa. | Do 4 godzin | 24 godziny |
| Wysoki | Ważna funkcjonalność nie działa. Błąd wpływa na działanie biznesu. Obejście problemu istnieje. | Do 1 dnia roboczego | 3 dni robocze |
| Średni | Funkcjonalność działa nieprawidłowo, ale nie blokuje pracy. Błędy wizualne lub UX. | Do 3 dni roboczych | 1-2 tygodnie |
| Niski | Drobne błędy, usprawnienia, prośby o nowe funkcje. Nie wpływa na działanie aplikacji. | W najbliższym sprincie | Zgodnie z backlogiem |
Czasy SLA dotyczą klientów z aktywnym pakietem wsparcia. Dla projektów w fazie rozwoju obowiązują inne ustalenia.
Gwarancje jakości
Procesy zapewniające najwyższą jakość kodu i bezpieczeństwo aplikacji
Obowiązkowy przegląd kodu
Każda zmiana w kodzie przechodzi przegląd przed wdrożeniem na produkcję
Testy automatyczne
CI/CD pipeline z testami jednostkowymi, integracyjnymi i bezpieczeństwa
Codzienne kopie zapasowe
Automatyczne kopie danych z testami odtwarzania, zgodnie z parametrami danego pakietu
Monitoring 24/7
Proaktywne monitorowanie wydajności, błędów i dostępności aplikacji
Audyt bezpieczeństwa
Regularne skanowanie podatności (SAST, dependency scanning, OWASP)
Dokumentacja zmian
Pełna historia zmian, changelog i release notes dla każdego wdrożenia
Kopie zapasowe i odtwarzanie
Codzienne kopie zapasowe
Automatyczne kopie zapasowe bazy danych i plików wykonywane codziennie w godzinach nocnych.
Przechowywanie
Backupy przechowywane przez 30 dni w geograficznie rozproszonych lokalizacjach (multi-region).
Testy odtwarzania
Regularne testy odtwarzania danych z kopii zapasowych (co najmniej raz na kwartał).
RTO i RPO
Recovery Time Objective (RTO): do 4 godzin. Recovery Point Objective (RPO): maksymalnie 24 godziny.
Kontrola dostępu i uwierzytelnianie
Uwierzytelnianie wieloskładnikowe (2FA)
Obowiązkowe 2FA dla wszystkich członków zespołu mających dostęp do produkcji i repozytoriów.
Kontrola dostępu oparta na rolach (RBAC)
Minimalne przywileje (principle of least privilege) - każdy użytkownik ma tylko niezbędne uprawnienia.
Audyt logowań
Wszystkie logowania do systemów produkcyjnych są rejestrowane i monitorowane.
Rotacja kluczy
Regularna zmiana kluczy API, certyfikatów i haseł dostępowych (co najmniej co 90 dni).
Przegląd kodu i standardy jakości
Obowiązkowy przegląd kodu
Każda zmiana w kodzie przechodzi przegląd - przed połączeniem musi ją zaakceptować co najmniej jedna osoba.
Automatyczne testy
CI/CD pipeline uruchamia testy jednostkowe, integracyjne i bezpieczeństwa przed każdym deploymentem.
Analiza statyczna kodu
Automatyczne skanowanie kodu pod kątem podatności bezpieczeństwa (SAST) i jakości (ESLint, SonarQube).
Dependency scanning
Regularne skanowanie zależności (npm, NuGet) w poszukiwaniu znanych luk bezpieczeństwa.
Monitoring i alerty
Proaktywne monitorowanie aplikacji w celu wykrywania problemów przed ich wpływem na użytkowników.
Monitoring wydajności (APM)
Śledzenie czasów odpowiedzi, obciążenia CPU, pamięci, zapytań do bazy danych.
Error tracking
Automatyczne zbieranie i alertowanie o błędach w aplikacji (Sentry, Application Insights).
Uptime monitoring
Sprawdzanie dostępności aplikacji co 1-5 minut z różnych lokalizacji geograficznych.
Alerty w czasie rzeczywistym
Automatyczne powiadomienia (email, Slack, SMS) w przypadku przekroczenia progów lub awarii.
Zasady zmian produkcyjnych (Change Management)
Kontrolowany proces wdrażania zmian minimalizujący ryzyko i zapewniający stabilność produkcji.
Środowiska staging i produkcja
Każda zmiana najpierw testowana na staging, identycznym z produkcją.
Okna wdrożeniowe
Wdrożenia planowane w ustalonych oknach czasowych (np. wieczory, weekendy) lub poza godzinami szczytu.
Rollback plan
Każde wdrożenie ma przygotowany plan awaryjnego wycofania zmian w przypadku problemów.
Dokumentacja zmian
Changelog i release notes dla każdego wdrożenia - transparentna komunikacja zmian.
Post-deployment monitoring
Wzmożone monitorowanie przez pierwsze 24-48 godzin po wdrożeniu.
Najczęściej zadawane pytania
Czy SLA obowiązuje 24/7?
Czasy reakcji SLA liczymy w godzinach roboczych (poniedziałek-piątek, 9:00-17:00 CET), chyba że pakiet wsparcia obejmuje obsługę całodobową. Dokładne zasady dla incydentów krytycznych zapisujemy w umowie.
Jak zgłosić incydent krytyczny?
Incydenty krytyczne zgłaszaj poprzez dedykowany kanał (email, telefon alarmowy, Slack). Zawsze otrzymujesz automatyczne potwierdzenie zgłoszenia oraz regularne aktualizacje statusu do czasu rozwiązania.
Czy mogę zażądać kopii zapasowej swoich danych?
Tak. Możesz poprosić o udostępnienie kopii swoich danych. Eksport przekazujemy w terminie i formacie ustalonym dla danego systemu, na przykład SQL, JSON lub CSV.
Jak często aktualizujecie zależności i biblioteki?
Poprawki bezpieczeństwa oceniamy według ryzyka i wdrażamy zgodnie z uzgodnionym priorytetem, po testach na środowisku przedprodukcyjnym. Harmonogram pozostałych aktualizacji zależy od pakietu utrzymaniowego.
Masz pytania o SLA lub bezpieczeństwo?
Chętnie odpowiemy na pytania i dostosujemy warunki SLA do specyfiki Twojego projektu