# Raport incydentu - 2026-01-15

## Podsumowanie

| Parametr | Wartość |
|----------|---------|
| **Data/Czas** | 2026-01-15, ~06:20-06:42 UTC |
| **Czas trwania** | ~22 minuty |
| **Serwer** | NORDABIZ-01 (VM 249, 10.22.68.249) |
| **Wpływ** | Wysokie CPU (85%+), spowolnienie SSH |
| **Status** | Rozwiązany |

## Opis zdarzenia

### Chronologia

1. **06:20** - Pierwsza próba uruchomienia skryptu `fix_google_news_images.py` przez SSH
2. **06:26** - Druga próba (timeout SSH, ale proces się uruchomił)
3. **06:30** - Trzecia próba (timeout SSH, kolejny proces)
4. **06:39** - Alert Zabbix: CPU VM 249 > 85% przez 5 minut
5. **06:41** - Diagnostyka przez QEMU guest agent
6. **06:42** - Procesy zabite, system wraca do normy

### Przyczyna

SSH timeout do serwera NORDABIZ-01 nie oznaczał, że komendy nie zostały wykonane. Procesy uruchomiły się na serwerze, ale odpowiedź SSH nie wróciła do klienta (timeout during banner exchange).

W efekcie uruchomiono 3 instancje skryptu `fix_google_news_images.py`:

| PID | CPU | RAM | Start |
|-----|-----|-----|-------|
| 1005812 | 34.8% | 33% | 06:20 |
| 1006003 | 30.9% | 26% | 06:26 |
| 1006162 | 24.6% | 21% | 06:30 |

**Łącznie: ~90% CPU, ~80% RAM**

### Objawy

- SSH timeout (Connection timed out during banner exchange)
- Zabbix alert: CPU > 85% przez 5 minut
- Potencjalne spowolnienie strony (nie potwierdzone - health check działał)

## Rozwiązanie

1. Diagnostyka przez SSH do Proxmox (10.22.68.123)
2. Użycie QEMU guest agent do sprawdzenia procesów: `qm guest exec 249 -- ps aux`
3. Zabicie procesów: `qm guest exec 249 -- pkill -f 'fix_google_news_images.py'`
4. Weryfikacja powrotu do normy

## Wnioski i działania zapobiegawcze

### Problem 1: SSH timeout nie oznacza nieudanego wykonania

**Ryzyko:** Przy timeout SSH, komenda może zostać wykonana ale odpowiedź nie wraca.

**Rozwiązanie:**
- Zawsze sprawdzaj czy poprzedni proces nie działa przed ponowną próbą
- Używaj `nohup` lub `screen` dla długich operacji
- Przed ponownym uruchomieniem sprawdź `ps aux | grep <skrypt>`

### Problem 2: Brak bezpośredniego dostępu SSH do VM 249

**Przyczyna nieustalona:** SSH timeout during banner exchange mimo otwartego portu 22.

**Możliwe przyczyny:**
- Obciążenie CPU uniemożliwiło odpowiedź sshd
- Problem z konfiguracją sshd po hardeningu
- Ograniczenia firewall na poziomie VM

**Do zbadania:**
- Sprawdzić logi sshd na VM 249
- Zweryfikować konfigurację `/etc/ssh/sshd_config`
- Sprawdzić czy fail2ban nie blokuje IP

### Problem 3: Brak alternatywnego dostępu

**Rozwiązanie wdrożone:** Użycie QEMU guest agent przez Proxmox API

**Komenda diagnostyczna:**
```bash
ssh root@10.22.68.123 "qm guest exec 249 -- <komenda>"
```

## Akcje do wykonania

- [x] Zabić procesy obciążające CPU
- [x] Zweryfikować działanie strony
- [x] Utworzyć raport incydentu
- [ ] Zbadać dlaczego SSH nie działa bezpośrednio
- [ ] Dodać ostrzeżenia do CLAUDE.md
- [ ] Uruchomić skrypt poprawnie (jedna instancja)

## Kontakt

- **Zabbix Dashboard:** https://zabbix4norda.inpi.pl/zabbix/
- **Proxmox:** https://10.22.68.123:8006/

---
*Raport wygenerowany: 2026-01-15 06:45 UTC*