Status i Uptime

Jak monitorujemy produkcję i reagujemy na incydenty

Wysoki uptime to fundament niezawodnych aplikacji. Pokazujemy, jak monitorujemy produkcję, jakie narzędzia stosujemy i jak reagujemy na problemy, zanim wpłyną na użytkowników.

Nasze SLO (Service Level Objectives)

Mierzalne cele jakości usług

SLO to konkretne cele, które zobowiązujemy się utrzymać. Nie są to obietnice, ale mierzalne wskaźniki, które regularnie raportujemy.

Uptime (dostępność)

99.9% na miesiąc

Maksymalnie 43 minuty przestoju miesięcznie. Planowane okna serwisowe nie wliczają się do tego czasu.

Response Time (czas odpowiedzi)

< 500ms (p95)

95% żądań API musi być obsłużonych w mniej niż 500 ms. Dla stron HTML: < 1.5s Time to First Byte.

Error Rate (wskaźnik błędów)

< 0.1%

Mniej niż 1 błędne żądanie na 1000. Błędy 5xx są traktowane priorytetowo i naprawiane natychmiast.

Incident Response (reakcja na incydent)

< 15 minut

Od wykrycia incydentu do rozpoczęcia pracy nad rozwiązaniem. On-call dostępny 24/7 dla krytycznych systemów.

SLO mogą być dostosowane do specyfiki projektu. Powyższe wartości są standardem dla aplikacji produkcyjnych.

Stos monitoringu i alertingu

Narzędzia, które dają nam pełen wgląd w stan aplikacji

Synthetic Monitoring

Uptime Robot / Pingdom

Sprawdzanie dostępności aplikacji co 1-5 minut z różnych lokalizacji geograficznych. Alerty SMS/email w przypadku niedostępności.

Application Performance Monitoring (APM)

Application Insights / New Relic

Śledzenie wydajności: czasy odpowiedzi, obciążenie CPU/RAM, wolne zapytania SQL. Distributed tracing dla microservices.

Error Tracking

Sentry / Azure Monitor

Automatyczne zbieranie błędów JavaScript, .NET, SQL. Stack trace, user context, breadcrumbs. Alertowanie w czasie rzeczywistym.

Logs Aggregation

Azure Log Analytics / ELK Stack

Centralizowane logi z wszystkich środowisk. Wyszukiwanie, filtrowanie, korelacja zdarzeń. Retention 30-90 dni.

Infrastructure Monitoring

Azure Monitor / Datadog

Monitoring infrastruktury: serwery, bazy danych, kolejki, cache. Metryki: CPU, RAM, disk I/O, network throughput.

Real User Monitoring (RUM)

Google Analytics 4 / Plausible

Monitorowanie rzeczywistych użytkowników: Core Web Vitals (LCP, CLS, INP), błędy JS, nawigacja. Privacy-friendly analytics.

Przykłady alertów i polityka eskalacji

Automatyczne alerty w przypadku problemów

Konfigurujemy alerty tak, aby informowały o problemach zanim wpłyną na użytkowników. Każdy alert ma zdefiniowany próg i procedurę eskalacji.

HTTP 5xx > 1% przez 5 minut

Krytyczny

Natychmiastowy alert SMS + email do on-call. Automatyczne uruchomienie playbook diagnostycznego.

Response Time p95 > 2s przez 10 minut

Wysoki

Alert email + Slack do zespołu. Analiza slow queries i bottlenecków. Eskalacja po 30 minutach.

Uptime check failed (3 próby)

Krytyczny

Alert SMS + email. Sprawdzenie health endpoint, reboot jeśli to nie pomaga. Informacja do klienta.

Disk space > 85%

Średni

Alert email. Czyszczenie starych logów/temp files. Planowanie zwiększenia pojemności.

Failed logins > 10 w ciągu minuty

Wysoki

Potencjalny atak brute-force. Tymczasowa blokada IP. Alert do security team.

Polityka eskalacji

Poziom 1: On-call engineer

Pierwsza linia reakcji. Dostępny 24/7 dla incydentów krytycznych. Czas reakcji: do 15 minut.

Poziom 2: Senior engineer / Team lead

Eskalacja jeśli problem nie jest rozwiązany w 30 minut lub wymaga głębszej wiedzy. Decyzje o rollback.

Poziom 3: CTO / Architecture team

Eskalacja dla problemów systemowych, zmian infrastruktury, decyzji strategicznych. Informacja do klienta.

Jak reagujemy na incydenty

Proces reakcji i komunikacja

On-call i dostępność

Dla aplikacji produkcyjnych utrzymujemy dyżury on-call 24/7. Inżynier on-call ma dostęp do wszystkich systemów i może podejmować decyzje o rollback czy failover.

•Rotacja on-call: tygodniowa, z backup person
•Alerty: SMS + email + Slack (redundancja)
•Dostęp zdalny: VPN + jump server + MFA
•Playbooki: udokumentowane procedury dla częstych problemów

Proces obsługi incydentu

1. Wykrycie i alert

Automatyczne alerty z monitoringu lub zgłoszenie od użytkownika/klienta.

2. Triaging (do 15 minut)

Ocena wpływu, przypisanie priorytetu, powiadomienie zespołu.

3. Mitigation (natychmiastowa pomoc)

Rollback, restart, failover - cokolwiek przywróci działanie jak najszybciej.

4. Root cause analysis

Analiza przyczyny źródłowej po przywróceniu działania.

5. Fix i deploy

Trwała naprawa, testy na staging, wdrożenie na produkcję.

6. Post-mortem

Raport z incydentu: co się stało, dlaczego, jak zapobiegniemy w przyszłości.

Okna serwisowe (maintenance windows)

Planowane prace serwisowe wykonujemy w ustalonych oknach czasowych, aby zminimalizować wpływ na użytkowników.

Standardowe okno

Poniedziałek-czwartek, 22:00-02:00 CET. Minimalne ryzyko wpływu na użytkowników.

Powiadomienie z wyprzedzeniem

Minimum 48 godzin przed planowanym oknem. Email + status page + banner w aplikacji.

Zero-downtime deployment

Gdy to możliwe, stosujemy blue-green deployment lub canary releases - bez przestoju.

Rollback plan

Każde okno serwisowe ma przygotowany plan awaryjnego wycofania zmian.

Powiązane informacje

SLA i Bezpieczeństwo

Szczegółowe zasady SLA reakcji, praktyki bezpieczeństwa, code review i change management.

SLA i Bezpieczeństwo

Zobacz nasze projekty

Przykłady aplikacji, które monitorujemy i utrzymujemy dla klientów.

Zobacz nasze projekty

Masz pytania o monitoring i uptime?

Porozmawiajmy o tym, jak możemy zapewnić niezawodność Twojej aplikacji

Skontaktuj się